Hello all, I seem to have hit a wall. So I created an image and saved a unit's current life and it's initial life. The image's X is set to the unit's current life / the unit's maximum life x 200. I did this instead of unit life because different units have different amounts of life and by deviating the current by the max I get the same length from the image that is tracking the current life. Once I put in the / however it seems to not work. I will post the map below, does anyone know why this does not work?
It looks to me like it is due to all your values are integers. When programming, an integer divided by another integer is not going to yield a floating point number. Example: 1 / 10 will yield 0 instead of 0.1.
So essentially, use floating point aritmetics if you want a division to give a non-int result. Change default life to a real instead of integer, for instance.
Heh, and this is also one thing that bugs me with using the trigger editor, since it gets a bit messy with all those dialog boxes where you need to change from integer to real and back again, and similar.
What you could do is also:
Int( currentLife / (defaultLife * 200.0))
changing the 200 to 200.0 should allow the division to work later. But since the retrieved health is of floating type (real) anyway, I don't see why the variables would not be reals.
Oh well, that was a bit much of yapping of me, I guess. But hope it helps!
hmm, from what I am reading 1 / 10 should equal .1 but it wants it to be a real number so it rounds it to 0. So is there any other way to do this is the question. hmmm....... I will give a couple more tries at this but from what I am hearing it may be imposable.
Yay i got it to work!!!! to get rid of the 0 when the division started i did 200 x current life / default life instead of current life / default life x 200. when the unit dies it still leaves a tiny sliver but that can be worked out by another if ur unit dies then destroy the remainder of the dialog item. I will post the map with the changes for anyone who is interested.
by the way the ghost has such an odd health value because it usually has 100 health and i wanted to force it out of whole numbers for a moment to make sure that the only reason why it was working was not because of the nice round 100 health.
thank the lord for good old order of operations :D
hmm, from what I am reading 1 / 10 should equal .1 but it wants it to be a real number so it rounds it to 0.
Well, if 1 is an integer and 10 is an integer, then the result in an integer, always, unless converted along the way. But it looks like your issue was another thing all along, nevertheless. Good you got it solved!
hmm then possibly the editor simply does not like to divide then multiply? I am curious what the real issue was but i do want to continue making progress with this lol...
By multiplying two integers, you will always be certain that the product you get is an integer. This division thing is not limited to just starcraft 2, it's the way division works on computers if they aren't floating point numbers.
The real issue for you seemed to be that you took currentLife / (unitMaxLife * 200) resulted in a larger divisor, since the maxlife was multiplied by 200 before the division occured. What I assumed you would have wanted instead is currentLife / unitMaxLife * 200, or as you did it, 200 * currentLife / unitMaxLife. While it being integers, the latter choice is probably also the most reliable way to do it since multiplication first before the division will eliminate issues one can have with the integer division. But it all depends of what you want in the first place.
Eg, compare 11 / 10 * 20 and 20 * 11 / 10.
The first will result in 1 * 20 = 20
and the second 220 / 10 = 22
The first example happen to have given integer division rounding "errors" while the latter did not.
In calculations * and / are having the same priority when they're not encapsulated in parentheses. Without them the calculation will simply be calculated going from left to right in the expression. If the numbers would have been chosen to be numbers where a division between them would not round the result, or if it would have been floating-point numbers, then the order of * and / would not matter.
A / B * C
ex. 1200 / 1250 * 200 = (int)0.96 * 200 = 0 * 200 = 0
After:
C * A / B
ex. 200 * 1200 / 1250 = 240000 / 1250 = (int)192 = 192
Indeed, the second option is the most wise because it does not have typecasting and does not lose integer data in this case. However, it's still better just to use real values.
Hello all, I seem to have hit a wall. So I created an image and saved a unit's current life and it's initial life. The image's X is set to the unit's current life / the unit's maximum life x 200. I did this instead of unit life because different units have different amounts of life and by deviating the current by the max I get the same length from the image that is tracking the current life. Once I put in the / however it seems to not work. I will post the map below, does anyone know why this does not work?
It looks to me like it is due to all your values are integers. When programming, an integer divided by another integer is not going to yield a floating point number. Example: 1 / 10 will yield 0 instead of 0.1. So essentially, use floating point aritmetics if you want a division to give a non-int result. Change default life to a real instead of integer, for instance.
Heh, and this is also one thing that bugs me with using the trigger editor, since it gets a bit messy with all those dialog boxes where you need to change from integer to real and back again, and similar.
What you could do is also: Int( currentLife / (defaultLife * 200.0)) changing the 200 to 200.0 should allow the division to work later. But since the retrieved health is of floating type (real) anyway, I don't see why the variables would not be reals.
Oh well, that was a bit much of yapping of me, I guess. But hope it helps!
hmm, from what I am reading 1 / 10 should equal .1 but it wants it to be a real number so it rounds it to 0. So is there any other way to do this is the question. hmmm....... I will give a couple more tries at this
but from what I am hearing it may be imposable.Yay i got it to work!!!! to get rid of the 0 when the division started i did 200 x current life / default life instead of current life / default life x 200. when the unit dies it still leaves a tiny sliver but that can be worked out by another if ur unit dies then destroy the remainder of the dialog item. I will post the map with the changes for anyone who is interested.
by the way the ghost has such an odd health value because it usually has 100 health and i wanted to force it out of whole numbers for a moment to make sure that the only reason why it was working was not because of the nice round 100 health.
thank the lord for good old order of operations :D
Well, if 1 is an integer and 10 is an integer, then the result in an integer, always, unless converted along the way. But it looks like your issue was another thing all along, nevertheless. Good you got it solved!
hmm then possibly the editor simply does not like to divide then multiply? I am curious what the real issue was but i do want to continue making progress with this lol...
By multiplying two integers, you will always be certain that the product you get is an integer. This division thing is not limited to just starcraft 2, it's the way division works on computers if they aren't floating point numbers.
The real issue for you seemed to be that you took currentLife / (unitMaxLife * 200) resulted in a larger divisor, since the maxlife was multiplied by 200 before the division occured. What I assumed you would have wanted instead is currentLife / unitMaxLife * 200, or as you did it, 200 * currentLife / unitMaxLife. While it being integers, the latter choice is probably also the most reliable way to do it since multiplication first before the division will eliminate issues one can have with the integer division. But it all depends of what you want in the first place.
Eg, compare 11 / 10 * 20 and 20 * 11 / 10. The first will result in 1 * 20 = 20 and the second 220 / 10 = 22 The first example happen to have given integer division rounding "errors" while the latter did not.
In calculations * and / are having the same priority when they're not encapsulated in parentheses. Without them the calculation will simply be calculated going from left to right in the expression. If the numbers would have been chosen to be numbers where a division between them would not round the result, or if it would have been floating-point numbers, then the order of * and / would not matter.
In plain English:
What you did before was:
A / B * C
ex. 1200 / 1250 * 200 = (int)0.96 * 200 = 0 * 200 = 0
After:
C * A / B
ex. 200 * 1200 / 1250 = 240000 / 1250 = (int)192 = 192
Indeed, the second option is the most wise because it does not have typecasting and does not lose integer data in this case. However, it's still better just to use real values.
thanks for helping me to understand :D
Liked both of ur posts, so i converted it back to real values and it worked just as well with less variables thus saving even more space.