Hey guys something weird happening. I can't make proper calculation with unit's speed and real values. I got proper results only if not using values with floating point, in other case i didn't get precise calculation, for example, 6-3=3,000 (right), 6-3,5 = 2,498(right?). wtf? I just need trigger variant of speed increasing buff and cant implement it...
here is my map. Can't figure out how to fix this :( . I just want to try attribute system and need editable values, so cant use behaviours. Help will be very appreciated.
The problem is most likely, that SC2's "reals" are no floating point variables, but fixed point (in custom script, they are also called "fixed"). They work in intervals of 1/4096, which is the minimum difference between 2 fixeds. However, 6 - 3.5 should still be calculated correctly, since both numbers are exact multiplicatives of 4096.
€ in your map however, you reduce a movespeed of 2,25 by 0.1 x its value, and 0.1 can only be approximated by a fixed variable (would probably be 410/4096 = 0.100098), which causes your discrepancy. So I suggest you either use some multiple of 4096 (12.5% would probably be the next reasonable value) or you keep track of the original movespeed, so you can restore it later on. You can also use a buff system instead, since those never alter the original movespeed of the unit, so it is always restored when the buffs are removed.
Also, if your trigger is supposed to be stacking, you have a logical error: If you hit a unit once, the same movespeed is removed and then added after 3 seconds. However, if it triggered a second time during the 3 second duration, the first trigger will restore less movespeed than it removed, because you calculate again from the current movespeed. I would suggest to store the actual amount of movespeed you removed to a variable, so you can add the exact same number again.
Well you can try my map and see it yourself. They aren't working correctly. Try to change speed delta variable to something like 1,5 in my map. Besides, if you try to change hitpoints of unit it works well. Thats strange bug.
Use a buff behavior with stacks to slow the unit for a percentage of the current speed. It will work just like your triggers (=same math), just the values are restored without calculation errors as it recalculates a new value instead of re-adding calculation errors resulting in permanently lost speed.
Hey guys, sorry for doublepost, but did i get it right? So basicaly this situation means that i cant implement such systems as +% hitpoint regeneration/sec (for example item +31% overal hp regen) with triggers, because i just tested it and after many subtractions (if i have bunch of stacked buffs), i can get negative regeneration rate... This sounds realy bad, nearly as bad as ....mapping quiting for me. :/ i just can't believe it. there must be some way to fix this or maybe i don't understand something. Ahli you work on diablo map i can't believe you didnt face such issues. What can you say about them?
Hey guys, sorry for doublepost, but did i get it right? So basicaly this situation means that i cant implement such systems as +% hitpoint regeneration/sec (for example item +31% overal hp regen) with triggers, because i just tested it and after many subtractions (if i have bunch of stacked buffs), i can get negative regeneration rate... This sounds realy bad, nearly as bad as ....mapping quiting for me. :/ i just can't believe it. there must be some way to fix this or maybe i don't understand something. Ahli you work on diablo map i can't believe you didnt face such issues. What can you say about them?
Well, whats wrong with a behavior system? Also, as already mentioned, if you want to avoid calculation errors having an effect after the triggers wear off, just store whatever value you added in a variable and substract that exact same value again, instead of calculating again:
I can confirm this issue, its very weird and I also faced it in the past together with movement speed.
It always seems to substract more than it adds.
For example if you substract 0.999 from movement speed it will substract exactly 1.0, however, when adding 0.999 it will only add 0,99609375, which doesnt make any sense. It should rather always use 1.0 or 0,99609375 but should not mix both.
In addition, neither 1.0 nor 0,99609375 are a decent approximation of 0.999 using 1/4096 steps. The expected value would be 0.9990234375.
The only solution i came up with is making trigger version of behaviour system but i facing some difficulties with it cuz i almost have no experience in programming. So the concept of this system: first trigger stores each mdification in array, for example: i have 2 items one + 31% movespeed second +45% ms, i have array A[1,31 ; 1,45]. The second trigger will multiply primary movespeed each 0,0625 seconds on each member of this array. What can you say about this approach Mile?
eheh i finaly figured out what kind of shit is this. The 1/16 sec game cycle is causing this problems for all "per second' values. Here is fixed map. lol this stupid editor rly have no chance vs me :)
I can confirm this issue, its very weird and I also faced it in the past together with movement speed.
It always seems to substract more than it adds.
For example if you substract 0.999 from movement speed it will substract exactly 1.0, however, when adding 0.999 it will only add 0,99609375, which doesnt make any sense. It should rather always use 1.0 or 0,99609375 but should not mix both.
In addition, neither 1.0 nor 0,99609375 are a decent approximation of 0.999 using 1/4096 steps. The expected value would be 0.9990234375.
I did always wonder why movement speed was calculated that way. Even when you modify the unit's base speed in the data editor, it shows a post-calculation speed on the right side. It seems to be rounding down most of the time... I think it has more to do with the way movement speed is used when changing the unit's position on the map. The minimum unit of distance may be what's causing movement speed "real" values to act more like integers. The best way to interpret a unit's movement speed is "units per second." This only makes sense when you consider something like splash range. For example, a splash effect with a radius of 1 would take a unit with movement speed 2.00 exactly 1 second game-time to go from the left edge of the effect to the right edge (radius = 1, therefore diameter = 2, 2/2 = 1 second.)
Basically, it might just be impossible for a unit to move 0.9990234375 units in 1 second, so it rounds down to the nearest possible value.
Ahli you work on diablo map i can't believe you didnt face such issues. What can you say about them?
I've no small changes, but pretty much for the things that could be effected by that like mana and life regeneration bonus, I calculate the amount when it is required and not only once.
So, instead of adding/subtracting the value, save the info that you need to calculate the offset. Then calculate the new value based on your default value. This way you will never have problems like this. At least you won't notice them as you can't do that much about it.
My approach in diablo is a pretty solid one as it stands on default values which it keeps using to calculate new values when something is changed. For example, the matter that you equip items does not matter unlike D2 where it matters. I'm checking things for item requirements as a whole. It has a much worse performance, but it cannot fail unless there is a clear bug in my code.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hey guys something weird happening. I can't make proper calculation with unit's speed and real values. I got proper results only if not using values with floating point, in other case i didn't get precise calculation, for example, 6-3=3,000 (right), 6-3,5 = 2,498(right?). wtf? I just need trigger variant of speed increasing buff and cant implement it...
@abvdzh: Go
Could you please copy your triggers here? Might be easier to understand the problem that way...
here is my map. Can't figure out how to fix this :( . I just want to try attribute system and need editable values, so cant use behaviours. Help will be very appreciated.
The problem is most likely, that SC2's "reals" are no floating point variables, but fixed point (in custom script, they are also called "fixed"). They work in intervals of 1/4096, which is the minimum difference between 2 fixeds. However, 6 - 3.5 should still be calculated correctly, since both numbers are exact multiplicatives of 4096.
€ in your map however, you reduce a movespeed of 2,25 by 0.1 x its value, and 0.1 can only be approximated by a fixed variable (would probably be 410/4096 = 0.100098), which causes your discrepancy. So I suggest you either use some multiple of 4096 (12.5% would probably be the next reasonable value) or you keep track of the original movespeed, so you can restore it later on. You can also use a buff system instead, since those never alter the original movespeed of the unit, so it is always restored when the buffs are removed.
Also, if your trigger is supposed to be stacking, you have a logical error: If you hit a unit once, the same movespeed is removed and then added after 3 seconds. However, if it triggered a second time during the 3 second duration, the first trigger will restore less movespeed than it removed, because you calculate again from the current movespeed. I would suggest to store the actual amount of movespeed you removed to a variable, so you can add the exact same number again.
Well you can try my map and see it yourself. They aren't working correctly. Try to change speed delta variable to something like 1,5 in my map. Besides, if you try to change hitpoints of unit it works well. Thats strange bug.
Use a buff behavior with stacks to slow the unit for a percentage of the current speed. It will work just like your triggers (=same math), just the values are restored without calculation errors as it recalculates a new value instead of re-adding calculation errors resulting in permanently lost speed.
Hey guys, sorry for doublepost, but did i get it right? So basicaly this situation means that i cant implement such systems as +% hitpoint regeneration/sec (for example item +31% overal hp regen) with triggers, because i just tested it and after many subtractions (if i have bunch of stacked buffs), i can get negative regeneration rate... This sounds realy bad, nearly as bad as ....mapping quiting for me. :/ i just can't believe it. there must be some way to fix this or maybe i don't understand something. Ahli you work on diablo map i can't believe you didnt face such issues. What can you say about them?
Well, whats wrong with a behavior system? Also, as already mentioned, if you want to avoid calculation errors having an effect after the triggers wear off, just store whatever value you added in a variable and substract that exact same value again, instead of calculating again:
Even if your calculation is inaccurate, it adds the exact amount it substracted before, so your movespeed is restored to full every time.
Man, the trigger from your post is a trigger from my first map... The point is - it doesnt work.
I can confirm this issue, its very weird and I also faced it in the past together with movement speed.
It always seems to substract more than it adds.
For example if you substract 0.999 from movement speed it will substract exactly 1.0, however, when adding 0.999 it will only add 0,99609375, which doesnt make any sense. It should rather always use 1.0 or 0,99609375 but should not mix both.
In addition, neither 1.0 nor 0,99609375 are a decent approximation of 0.999 using 1/4096 steps. The expected value would be 0.9990234375.
The only solution i came up with is making trigger version of behaviour system but i facing some difficulties with it cuz i almost have no experience in programming. So the concept of this system: first trigger stores each mdification in array, for example: i have 2 items one + 31% movespeed second +45% ms, i have array A[1,31 ; 1,45]. The second trigger will multiply primary movespeed each 0,0625 seconds on each member of this array. What can you say about this approach Mile?
eheh i finaly figured out what kind of shit is this. The 1/16 sec game cycle is causing this problems for all "per second' values. Here is fixed map. lol this stupid editor rly have no chance vs me :)
I did always wonder why movement speed was calculated that way. Even when you modify the unit's base speed in the data editor, it shows a post-calculation speed on the right side. It seems to be rounding down most of the time... I think it has more to do with the way movement speed is used when changing the unit's position on the map. The minimum unit of distance may be what's causing movement speed "real" values to act more like integers. The best way to interpret a unit's movement speed is "units per second." This only makes sense when you consider something like splash range. For example, a splash effect with a radius of 1 would take a unit with movement speed 2.00 exactly 1 second game-time to go from the left edge of the effect to the right edge (radius = 1, therefore diameter = 2, 2/2 = 1 second.)
Basically, it might just be impossible for a unit to move 0.9990234375 units in 1 second, so it rounds down to the nearest possible value.
I've no small changes, but pretty much for the things that could be effected by that like mana and life regeneration bonus, I calculate the amount when it is required and not only once.
So, instead of adding/subtracting the value, save the info that you need to calculate the offset. Then calculate the new value based on your default value. This way you will never have problems like this. At least you won't notice them as you can't do that much about it.
My approach in diablo is a pretty solid one as it stands on default values which it keeps using to calculate new values when something is changed. For example, the matter that you equip items does not matter unlike D2 where it matters. I'm checking things for item requirements as a whole. It has a much worse performance, but it cannot fail unless there is a clear bug in my code.