Dwarf Fortress Bug Tracker - Dwarf Fortress |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0006334 | Dwarf Fortress | Creatures | public | 2013-05-31 09:24 | 2014-11-25 22:59 |
|
| Reporter | verdantsf | |
| Assigned To | Toady One | |
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | 0.34.11 | |
| Target Version | | Fixed in Version | 0.40.02 | |
|
| Summary | 0006334: Creatures, including dwarves, born in the fortress do not grow to full adult size. |
| Description | Two separate forum threads discovered significant differences in body size between creatures born in the fort vs. those who migrated or were purchased. Butchering results for animals born in the fort are less than the expected adult size result. Dwarf soldiers born in the fort are much less effective with blunt weapons compared to their migrant peers. |
| Steps To Reproduce | Observe butchering or combat results for creatures and dwarves born in the fortress. |
| Additional Information | Thread on butchering discrepency:
http://www.bay12forums.com/smf/index.php?topic=91166.msg4284557#msg4284557 [^]
Thread on weapon performance discrepency:
http://www.bay12forums.com/smf/index.php?topic=126558.msg4283868#msg4283868 [^] |
| Tags | binary patch |
| Relationships | | has duplicate | 0001047 | resolved | Footkerchief | Butchered cats only produce skulls, possibly related to aging while caged | | related to | 0007067 | resolved | Footkerchief | Animals do not age or mature |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2013-05-31 09:24 | verdantsf | New Issue | |
| 2013-05-31 09:37 | verdantsf | Note Added: 0023987 | |
| 2013-06-01 17:08 | verdantsf | Note Edited: 0023987 | bug_revision_view_page.php?bugnote_id=0023987#r8935 |
| 2013-06-01 17:09 | verdantsf | Note Edited: 0023987 | bug_revision_view_page.php?bugnote_id=0023987#r8936 |
| 2013-06-01 17:10 | verdantsf | Note Edited: 0023987 | bug_revision_view_page.php?bugnote_id=0023987#r8937 |
| 2013-06-01 17:11 | verdantsf | Note Edited: 0023987 | bug_revision_view_page.php?bugnote_id=0023987#r8938 |
| 2013-06-01 17:12 | verdantsf | Note Edited: 0023987 | bug_revision_view_page.php?bugnote_id=0023987#r8939 |
| 2013-06-03 23:22 | InsanityPrelude | Issue Monitored: InsanityPrelude | |
| 2013-06-07 03:52 | Steb | Issue Monitored: Steb | |
| 2013-06-08 18:37 | jfw25 | Issue Monitored: jfw25 | |
| 2013-06-11 09:13 | verdantsf | Note Added: 0023997 | |
| 2013-06-11 09:19 | Quietust | Note Added: 0023998 | |
| 2013-06-13 09:16 | verdantsf | Note Added: 0024002 | |
| 2013-06-16 21:42 | krenshala | Issue Monitored: krenshala | |
| 2013-08-26 15:35 | Cobbler89 | Note Added: 0024100 | |
| 2013-11-04 10:49 | Footkerchief | Tag Attached: binary patch | |
| 2014-01-15 14:48 | Kirig Stonebeard II | Issue Monitored: Kirig Stonebeard II | |
| 2014-01-15 20:38 | BenLubar | Note Added: 0024276 | |
| 2014-01-17 10:03 | Kirig Stonebeard | Issue Monitored: Kirig Stonebeard | |
| 2014-03-25 13:11 | Dwarfu | Assigned To | => Dwarfu |
| 2014-03-25 13:11 | Dwarfu | Status | new => acknowledged |
| 2014-07-10 12:37 | Toady One | Note Added: 0025572 | |
| 2014-07-10 12:37 | Toady One | Status | acknowledged => resolved |
| 2014-07-10 12:37 | Toady One | Resolution | open => fixed |
| 2014-07-10 12:37 | Toady One | Assigned To | Dwarfu => Toady One |
| 2014-07-10 12:39 | Toady One | Status | resolved => assigned |
| 2014-07-10 12:39 | Toady One | Assigned To | Toady One => Logical2u |
| 2014-07-10 12:39 | Toady One | Status | assigned => resolved |
| 2014-07-10 12:39 | Toady One | Fixed in Version | => Next Version |
| 2014-07-10 12:39 | Toady One | Assigned To | Logical2u => Toady One |
| 2014-07-12 09:33 | Footkerchief | Relationship added | related to 0007067 |
| 2014-07-14 02:57 | Steb | Issue End Monitor: Steb | |
| 2014-07-23 10:06 | Footkerchief | Relationship added | has duplicate 0001047 |
| 2014-07-23 10:06 | Footkerchief | Issue Monitored: thvaz | |
| 2014-07-23 12:28 | thvaz | Issue End Monitor: thvaz | |
| 2014-08-11 18:11 | krenshala | Issue End Monitor: krenshala | |
| 2014-11-25 22:59 | InsanityPrelude | Issue End Monitor: InsanityPrelude | |
|
Notes |
|
|
(0023987)
|
|
verdantsf
|
2013-05-31 09:37
(edited on: 2013-06-01 17:12) |
|
|
|
|
|
|
|
|
|
In summary, it appears that unit growth is intended to be recalculated once per day (and offset by the time of day the creature was born), but there's a further restriction that it only does that check once every 10 ticks, so if the creature's birth time is not a multiple of 10 ticks, its size does not properly get updated.
if (((cur_year_tick % 10) == 0) && (((cur_year_tick - birth_time) % 1200) == 0)) { update stuff }
http://www.bay12forums.com/smf/index.php?topic=91166.msg4311166#msg4311166 [^] |
|
|
|
|
|
|
|
|
Working off the assumption that the (probably simplified) example code above is essentially accurate, and just thinking out loud here... This could be fixed by making the birth times only be multiples of ten (which is currently done after the fact in the DFHack fix), but that could introduce other bugs in the game code if not done perfectly (for instance, if it only allowed births every ten ticks, you wouldn't want there only to be 1/10th the offspring on average; if it simply rounded the birth time instead of using the real birth time, it would need to always round down to prevent creating a birth time in the future and whatever problems that could potentially cause for all of <9 ticks -- obscure things like that). It could also be fixed by checking for updates on every tick, but then the check portion of the code would use up ten times as much processing since it's firing ten times as often (then again, the portion that restricts it to every tenth tick would be using up none, so I guess it depends on the relative complexity of the two spots in the actual code -- I would imagine the "once every ten ticks" part of the code is an if block inside of which is a loop through the units to check their ages, so the one check only fires once per tick and the other fires, on the relevant ticks, once per unit per relevant tick). Finally, assuming the code above is something like how it's done, it could be fixed by changing that last "== 0" to "< 10" (or, conceivably, instead of literal 10 have a constant that's used there and where the number of ticks to skip over is set, so that if its value is ever changed in the one place it's changed in the other).
Of course, Toady probably doesn't need my coding advice... but here's where it gets interesting: I wonder if we could find where this operation is occuring in the binary and patch it to be a "< 10" comparison instead of "== 0"? Not that it would be easy to find; but I am curious whether it could theoretically be fixed if somebody found it -- whether, in short, the binary code for "< 10" would take up the same space as the binary code for "== 0"? |
|
|
|
|
Well, the check requires:
- a subtraction
- a division
- a jump-when-zero (or jump-when-not-zero, depending on where the compiler put the body of the if statement)
The code that makes the check only run once every ten ticks requires:
- a division
- a jump-when(-not)?-zero
So really all we're saving is a single subtraction nine out of ten ticks in exchange for an extra division and an extra conditional jump one out of ten ticks. Even if we did that a million times per tick, that's still less than a millisecond saved or lost by the optimization. Subtraction is cheap. |
|
|
|
|
|
Thanks to everybody that helped figure this one out. Hopefully it is all sorted out for next time. |
|