Pb with display of "units details" in game

[welk]

Working in editor, I noticed that : When you give to an unit a decimal value (0,5 ; 1,5, etc), this value is correctly displayed in editor but not in the game

The game always choices the immediatly inferior value to be displayed
Example :
a unit set with 0,5 in attack infantry will be displayed as 0,5 in editor and as 0 in game
a unit set with 1,5 in attack infantry will be displayed as 1,5 in editor and 1 in game
etc

Perhaps is it voluntary or a technical necessity of the program, I report it just in case of utility

[Hubert Cater]

It is purposeful where the final values are whole numbers only in game.

[welk]

It is purposeful where the final values are whole numbers only in game.

A question about that, please : does it mean :

1- The program works only with whole numbers and does ignore decimal values (in this case, to set decimal values in editor would signify that they are not taken in mind by the program => decimal values = not usefull and not efficient)

2- The program only display whole numbers : it works with decimal numbers but it display only whole numbers
(=> decimal values = usefull and efficient but not displayed in game)

What solution is correct : 1 or 2 ?

[Elessar2]

My testing has indicated that the values do NOT round down (i.e. if it is 1.5 in the editor it doesn't revert to 1 in the game exe calculations, as 1.5 is used in the algorithms). Maybe I missed something, but we tested this extensively with shore bombardment among many other things, and s.b. of 0 inflicted no damage to coastal ground units, 0.5 inflicted some, and 1.0 inflicted quite a bit, and in fact after I set it to 1 in an early build I had to dial it back to 0.5 as coastal units were getting murdered.

Clarification on this would be vital as I am currently working on my next update, and if they DO round down, well it will mean a LOT of reworking of combat values. Note I'll do more tests to confirm it on my end if need be.

Note several upgrades in vanilla use half points (such as ground attach tech for bombers). I know binary either-or stats such as de-entrenchment do round down, which is to be expected.

[welk]

Ok, thanks a lot for these precisions.
Then, considering your tests, at this point (and waiting more precisions from staff+ your complementary tests) we may consider that :
1- Decimal values set in editor seem be full taken in mind by the program in game (decimal values don't round down in algorithmes)
2- Decimal values seem never displayed by the program (decimal values do round down for display)

[Hubert Cater]

The game/program will only use the values as seen in game, e.g. the whole number values.

But this does not necessarily mean that the decimal values are useless, e.g. sometimes we want a few levels of upgrades at 0.5 at a time before the next improvement takes effect, e.g. a whole number increase has finally been achieved etc

[Hubert Cater]

My testing has indicated that the values do NOT round down (i.e. if it is 1.5 in the editor it doesn't revert to 1 in the game exe calculations, as 1.5 is used in the algorithms). Maybe I missed something, but we tested this extensively with shore bombardment among many other things, and s.b. of 0 inflicted no damage to coastal ground units, 0.5 inflicted some, and 1.0 inflicted quite a bit, and in fact after I set it to 1 in an early build I had to dial it back to 0.5 as coastal units were getting murdered.

Clarification on this would be vital as I am currently working on my next update, and if they DO round down, well it will mean a LOT of reworking of combat values. Note I'll do more tests to confirm it on my end if need be.

Note several upgrades in vanilla use half points (such as ground attach tech for bombers). I know binary either-or stats such as de-entrenchment do round down, which is to be expected.

Let me double check as it may depend on which specific attributes, as you are right de-entrenchment doesn't ever get reduced by 0.5 points, but when it comes to combat, internal calculations deal with decimals all the time until it comes time to round the final values for application of losses etc

[Hubert Cater]

Elessar is correct, in most cases it is not rounded down, just with some logical exceptions