LE,
I normally do not see timers calculated in 10ths of a second (ie., cast_time of 0.5 = 5... cast time of 10 = 100, etc). Is there a specific reason you chose 10ths instead of the more common "millisecond" approach? I am bringing this up because now that we're entering data for spells, we have inconsistencies that are confusing - before we get too far ahead, I'd like to discuss them with you to see if we can either get them all changed to ms, or understand why they are this way.
For instance,
`cast_time` is 1/10th of a second
`recast` is a whole integer
`range` is whole
etc...
Also:
`resistibility` is a percentage input, but is "unsigned" so cannot take the proper .34 value to represent 34% (which I know I can fix, but need to ensure with YOU it will not break something internally).
There are a few values that are unsigned that require fractional input, so I will have to change those to signed values. Will this effect the server any?
What are your thoughts of the inconsistent timers?
Thanks

I *think* it's done that way because casting time and reuse times can both be decimal numbers (0.5) or whole numbers (5), whereas range will always be >= 0. That's just what I've noticed from any spells from live. Those are just my observations though.
The only thing I have a concern about is the resistability. I have put in 0.25 because I wanted to make one of the spells show 25%. But instead it raised it to 75%.

Scatman, I am speaking specifically to why the server needs 10ths of a second instead of milliseconds on these values. My gut feeling on this is that these are all tables that were just tossed together (by LE, alfa, and me) as a "we'll fine tune them later" sorta thing - which, later = now... time to fine tune.
I am just checking a) that 10ths are expected, and not milliseconds (server-side) and b) that if I changed float unsigned to signed, it will not break anything. The latter will give you the 0.5, .25 you are needing.

The way it is in the database is the way the client expects it and the format that SOE used for EQ2. I could do some conversions on the data after it is read from the database, but I dont really think it is necessary.

Nah, how you have it is fine. I will just make sure to let the editors know what data is expected. I hate inconsistency, but I can live with it rather than putting unnecessary work on you
Thanks for the clarification.