There's several factors at work here that can get confusing, but I'll do my best to explain.
Speed is just a model level property. The engine does not keep a separate
speed value for each entity spawned from the model. What actually happens is that when an entity walks, the engine checks the model
speed value, and applies it the the entity's
velocity property, taking into account certain other factors (like Z vs X movement). In turn,
velocity is combined with any
move attributes (normally those are 0) to determine a final move value. That move value is as you guessed, a pixel per timed engine tick (one increment of the engine's elapsed time value).
You are also right that the numbers you see no make sense. So obviously something has to give. The secret is the value you set with the
speed attribute is not what the engine uses. The actual value is a much smaller floating point (and so are positions). This is because the original
speed attribute was meant to be kind of idiot proof, so it does quite a bit of sanitizing before sending the value on. Here's the actual code that reads in a
speed value for models:
Code:
case CMD_MODEL_SPEED:
value = GET_ARG(1);
newchar->speed = atof(value);
newchar->speed /= 10;
if(newchar->speed < 0.5)
{
newchar->speed = 0.5;
}
if(newchar->speed > 30)
{
newchar->speed = 30;
}
So basically, the value you enter is divided by 10, and the end result is never allowed below 0.5 or above 30. Speed 5 is really speed 0.5. Thus, a velocity, and presumably final move calculation of 0.5 pixels per tick when the entity is walking. The engine then rounds the floating position to a whole pixel for display on screen.
That's why when you use script, the velocity and position values look so different than the text values. With script, you are accessing the real values.
Thankfully, there is also
speedf. It's a model attribute just like
speed, but it does not limit or sanitize the value you enter in any way.
HTH,
DC
