View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0005041 | Valley 1 | Bug - Gameplay | Oct 27, 2011 9:02 am | Oct 27, 2011 10:37 am | |
| Reporter | tbogue | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.534 | ||||
| Fixed in Version | 0.535 | ||||
| Summary | 0005041: Overflow producing unhappy people in new settlements | ||||
| Description | I just gained a level with the new release and apparently gained 4 new settlements. Visiting them I found that some of the population had their morale at 1, making them pretty useless. Checking the morale calculation (thanks for including that -- it makes morale much more intelligible!), I found that morale was being calculated as negative after going from 20,953,472 to -17,805,506 by being multiplied by 120%. After a few turns and getting them food, water, and housing, the problem persists. I note that even in my happier people in these new settlements, the interim happiness cap doesn't seem to be displayed, though it is in my main settlement. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | Major Problem | ||||
|
|
Keith, I should note that there's no reason to be doing FInt math on this if that's what the problem is. With this game the floating point should be sufficiently accurate for this, especially given the networking model we're winding up with, shouldn't it? |
|
|
@tbogue: can you attach a zip of your world file? If necessary you can omit all the Region folders (not regions.dat, need that) except the one corresponding to a settlement with the calculation problem. @Chris: I'm not using the FInt class if that's what you mean. It is all integer math with stuff like "*= 120; /= 100" as an equivalent for * 1.2. You're right that floating point is probably fine but I would really prefer to be certain that the projections that the player is being shown on their clients is exactly what the server will be seeing (within the assumptions that the client has to make). |
|
|
I would think that at this scale, 1.2 is not likely to have any difference between machines. We're using floating point stuff everywhere else in the damage calculations and movement calculations and so on, so I imagine it's fine. If it were to be off, it would be when it's something like 1.200347 or something, and that's being multiplied by another float and then getting rounded slightly differently. With AI War my fear was getting that critical rounding error where your numbers are off by 1, and then those offsets continuously accumulate over time until there's a true desync. And that was happening back in the day, between 32bit and 64bit machines. But that was with thousands of ships, and the amount of difference was miniscule at any given time, and only the compounding of it made any substantial difference over the course of 20-40 minutes of play. In other words, I think that the scenario here simply isn't worth the worry, and the overflows from the integer math are a lot more harmful. My thoughts anyhow. |
|
|
For 0.535: * Fixed a bug where death-of-lieutenant and death-of-overlord events were multiplying morale and not being checked for intermediate arithmetic-overflow prevention. @Chris: I already had overflow prevention in, but the world-scope events would early-out of the loop before the intermediate cap was checked for, and that's fixed now. Even with float or double we'd still have the same fundamental problem: being multipled by 4.0 and/or 1.2 a Whole Bunch Of Times (tm) can exceed the capacity of any finite datatype. So I'm going to need the intermediate caps either way and in general am more comfortable with the integer math (granted, more for historical-psychological reasons than truly technical ones at this point). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Oct 27, 2011 9:02 am | tbogue | New Issue | |
| Oct 27, 2011 9:04 am | tigersfan | Internal Weight | => Major Problem |
| Oct 27, 2011 9:04 am | tigersfan | Assigned To | => keith.lamothe |
| Oct 27, 2011 9:04 am | tigersfan | Status | new => assigned |
| Oct 27, 2011 9:04 am | Chris_McElligottPark | Note Added: 0017236 | |
| Oct 27, 2011 9:33 am | keith.lamothe | Note Added: 0017240 | |
| Oct 27, 2011 9:39 am | Chris_McElligottPark | Note Added: 0017241 | |
| Oct 27, 2011 10:37 am | keith.lamothe | Note Added: 0017243 | |
| Oct 27, 2011 10:37 am | keith.lamothe | Status | assigned => resolved |
| Oct 27, 2011 10:37 am | keith.lamothe | Fixed in Version | => 0.535 |
| Oct 27, 2011 10:37 am | keith.lamothe | Resolution | open => fixed |
