(10-23-2015 06:57 PM)XuN Wrote: 1) What if you change TICK_PER_SEC to 100 to have 100 ticks instead of 10?
2) Yes, SetTimeout will generate a timer that, on the next CChar::OnTick(), will call NPC_OnTickAction(). Think about this as ' it will take me X tenths of seconds to do this move, when I finish i'll think what to do next.
Hey XuN, thanks for your answers!
So this means that in my personal case * TICK_PER_SEC / 10 are 2 useless arithmetic operations.
We're re-writing our sphere 56b shard specificly to RunUO (actually it's just C#, there's not much left from RunUO atm) for nearly 2.5 years now, we're almost there( too bad Sphere was not open source back then
). So I've copied this formula exactly like it is in sphere core. My AI Timer ticks every 100 miliseconds, the NPC's have the same dex and moverate amount converted and it still doesn't work as it should work on Sphere
I suspend NPC decisions for the amount of ticks this formula generates and it just doesn't work...
For example, I have guards with 200 - 250 dex generated and 20 moverate ( overridden ).
Let's take this and calculate by using your formula:
run is true.
moverate is 20 (defind within the char def)
dex is 250
iTickNext = 10 / 4 + random((100-(250*20)/100)/ 5)
( I wont do this * 10 and /10 as it is pretty useless in my case)
so now we're getting 250*20= 5000, 5000/100 = 50, 100-50 =50, 50/5 = 10 and we take a random number from 0 to 10, I will take the avg = 5.
Therefore we get :
10/4 +5 which ends up as 7 ticks.
but the random factor is pretty huge here, we might get a number between 2 and 11, which is 0.2 sec or 1.1 sec and guards on our sphere shard have nearly same movementspeed as mounted players( achieved by doing 2 steps at the same time in sphere), which looks more like always 0.2 sec with this "double-step" feature.
They're running very fast and smooth, so the randomization can not be that huge.
By applying this formula as it is exactly here they're barely moving on our new platform...
Do you have any suggestions on this?