EME2940820
Clubman
posted 08-07-09 12:52 PM
ET (US)
1 / 15
Very perceptive, Rasteve. I will have to check this one out.
I wonder if analogous situations occur for the following: Phoenicia's wood gathering rate with respect to the Woodworking, Artisanship, and Craftmanship; Egypt's gold gathering rate with respect to Gold Mining; and Babylon's stone gathering rate with respect to Stone Mining. These would all be much more difficult to test.
Suppiluliuma
AoEH Seraph
posted 08-09-09 11:00 AM
ET (US)
3 / 15
You're saying that in custom scenarios nobility changes hitpoint of egyptian chariots as if they had normal (i.e. non egyptian) hitpoints? what happensa if one starts a Random game from stone age? Does the same happen?
What are your results? What are the expected HPs and the real Hps for egyptian chariots (considering the hp bonus was considered before nobility)?
Rasteve
Clubman
posted 08-09-09 01:21 PM
ET (US)
4 / 15
Good ol' fashion Nobility
Chariot100 to 114
CA 70 to 80
Scythe 120 to 137
cav 150to 172
heavy 150 to 172
cat 180to 206
cam 125to 143
scout 60 to 68
ha 60 to 68
hha 90 to 103
Egyptians pre-Nobility
Char 100 to 133
CA 70 to 93
Scythe 120 to 159
Egyptians +Nobility (researched)
Char 152
CA 106
Scythe 182
Egyptians Iron/Post-Iron Nobility (scenario builder)
Char 151
CA 106
Scythe 182
Expected Results
I was expecting nobility to increase hit points via multiplication (*1.15), Egyptian or not. Egyptian bonus should be applied as *1.33 (33% bonus), which if you round down it does. However, as nobility goes through some strange rounding routine, it messes things up for egypt.
As for the order in which things are done, multiplication should yield the same results whether *1.15 * 1.33 or *1.33 * 1.15. But as nobility isn't applied as a clean multiplication (results indicate a rounding then subtraction of 1) then the order does matter (i.e. each order gives different results).
Strangly, nobility and the egyptian bonus should be applied in the same way. They are both set up to multiply the target units by 1.15 or 1.33 - but only nobility actually goes through a different process.
Babylonian/Shang wall hit points doesn't go through this process but I believe the yamato boat hp bonus does (just testing now).
Possible Causes
As yet I cannot see anything which really sets the nobility and egyptian bonus apart, or something that nobility (technically) has in common with yamato ship hp bonus that egpytian chariot hp bonus doesnt....
Rasteve
Clubman
posted 08-10-09 01:58 AM
ET (US)
6 / 15
Take the chariot for example (100 hp). Nobility should multiply it by 1.15 (15% increase) to achieve 115 but you end up with 114. I can only see 2 reasons:
1. All nobility removes 1hp as part of a process?
2. The multiplication is buggy and you end up with say 114.99999... which is then rounded down?
Rasteve
Clubman
posted 08-10-09 04:28 AM
ET (US)
8 / 15
I can help you with this
techage_34_4_type: 1
Change player attribute (such as resources etc)
techage_34_4_unit: 21
Technology count
techage_34_4_class: 1
Add
techage_34_4_attribute: -1
Not used
techage_34_4_amount: 1
+1
Rasteve
Clubman
posted 08-10-09 04:57 AM
ET (US)
10 / 15
Yes, which makes it strange why units such as chariots hp (100) * 1.15 result in 114 (s/b 115!!!!).
Rasteve
Clubman
posted 08-11-09 05:51 PM
ET (US)
12 / 15
Here are my conclusions on the nobility bug:
Pick any 2 numbers, no matter how close, and mathematically there are infinite numbers in between. When trying to represent such numbers in a machine we are restricted to the number of bytes, and therefore it is expected by experienced programmers that certain calculations can yield inaccurate results. Or another way of looking at it, the one binary code representing a multiple range of numbers.
One example I found was the following snippet from C++
double a=111.567,b=111,c;
c=a-b;
We are expecting c to equal 0.567.
But during the calculation a becomes 111.56699999999999, b becomes 111.00000000000000 and c becomes 0.56699999999999307
Now applying this to say Chariot hit points we could have the following snippet of code (I am just speculating here)
double a = 100, b = 1.15, c;
c = a*b;
But instead of c = 115 (as we can show with any old calculator) we have 114!!
Ok, so maybe in this case a becomes 99.9999999...
Then c = 114.9999...
Finally the answer c is converted back to an int (like darky stated, the decimal is dropped) to give 114.
As much as it is a C++ (or any other language as far as I am aware) issue, there are methods which can solve this issue (such as using a mathematical library which deals with such occurances).
Actually, as the issue with nobility consistently knocks 1 off the expected results, I'm guessing the 1.15 becomes 1.1499999999....
On ES part, I have no doubt they were aware of this issue. Many of the bonuses quoted in the manual are stated as percentages, which naturally should be applied via multiplication. However, ES avoided at all costs to use multiplication unless forced (most bonuses are applied via addition). Nobility requires multiplication due to the Egyptian chariot bonus.
Darky, I can remember previously that you had experience with Java. Does this sound familiar? Maybe the math library works around this, but in C++ the issue is known, and it is up to the developer to create a work around.
Rasteve
Clubman
posted 08-12-09 08:39 AM
ET (US)
14 / 15
If you ever do mathematical calculations in C++, be aware of conversion to and from floating point numbers. I have read a little more into it today and it seems to be a very well known problem with industry-programmers.
I may load up netbeans today and plug the nobility values in to see if I can replicate this bug.