Dwarf Fortress Bug Tracker - Dwarf Fortress |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0004973 | Dwarf Fortress | Reactions | public | 2011-11-30 13:07 | 2020-04-13 09:12 |
|
Reporter | Quietust | |
Assigned To | Toady One | |
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | |
Platform | | OS | | OS Version | |
Product Version | 0.31.25 | |
Target Version | | Fixed in Version | 0.43.03 | |
|
Summary | 0004973: Vermin reactions do not recognize caste |
Description | When using custom reactions which deal with items of type VERMIN and PET, the material type is interpreted as a creature ID, but the material subtype is ignored (e.g. "VERMIN:NONE:ANT:SOLDIER" gets treated as "VERMIN:NONE:ANT:NONE"); as a result, any reaction which attempts to create a vermin will make them using a nonexistent caste (and it will not behave correctly, the most readily observable effect being that it roams around at maximum speed when dropped).
The underlying item code itself returns the caste ID when requesting the material subtype (and the same for setting it), so this seems like something that ought to work better than it does right now - indeed, if I edit the 'reaction_product_item' structure in-memory and put the proper caste ID in the field normally used for material subtype, then the reaction will produce the vermin using the correct caste (it'll show up as a "live ant" in my inventory, but once I drop it it'll become a slowly roaming "soldier ant" instead of a super-fast "ant"). |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | parent of | 0000722 | resolved | Toady One | Embark profile warns that fish not available, but they actually are |
|
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
2011-11-30 13:07 | Quietust | New Issue | |
2011-12-01 20:32 | Quietust | Note Added: 0019060 | |
2012-03-02 13:26 | Quietust | Note Added: 0021000 | |
2014-09-15 14:05 | lethosor | Assigned To | => lethosor |
2014-09-15 14:05 | lethosor | Status | new => confirmed |
2014-09-15 14:12 | Quietust | Note Added: 0030204 | |
2015-03-01 09:19 | chaosvolt | Note Added: 0032296 | |
2020-04-12 06:50 | Quietust | Note Added: 0040456 | |
2020-04-12 09:28 | lethosor | Note Added: 0040457 | |
2020-04-12 09:28 | lethosor | Status | confirmed => resolved |
2020-04-12 09:28 | lethosor | Fixed in Version | => 0.47.01 |
2020-04-12 09:28 | lethosor | Resolution | open => fixed |
2020-04-12 09:28 | lethosor | Assigned To | lethosor => Toady One |
2020-04-13 09:11 | lethosor | Note Added: 0040459 | |
2020-04-13 09:11 | lethosor | Fixed in Version | 0.47.01 => 0.43.03 |
2020-04-13 09:12 | lethosor | Relationship added | parent of 0000722 |
2020-04-13 09:12 | lethosor | Note Edited: 0040459 | bug_revision_view_page.php?bugnote_id=0040459#r16439 |
2020-04-13 09:13 | lethosor | Note Edited: 0040459 | bug_revision_view_page.php?bugnote_id=0040459#r16440 |
Notes |
|
|
Further analysis suggests that items of type REMAINS, FISH, FISH_RAW, and EGG may also be affected by this. |
|
|
|
A quick test confirms that this is still the case in version 0.34.04. |
|
|
|
Disassembly analysis against 0.40.12 confirms that this is still the case - for the above listed item types, the first token of the material is parsed as a Creature ID and the second token is discarded (instead of being interpreted as a caste for that creature). |
|
|
|
No idea whether defining a fallback caste titled NONE would avoid this issue or not. Anyone tried !!SCIENCE!! on that? |
|
|
|
As of version 0.47.04, this appears to have been fixed - I performed a custom reaction with "[PRODUCT:100:1:VERMIN:NONE:ANT:SOLDIER]" and dropped the resulting "live ant" on the floor, and it turned into a "soldier ant" as expected. |
|
|
|
Cool, I'll mark it as fixed in 0.47.01, but let me know if that should be changed. |
|
|
(0040459)
|
lethosor
|
2020-04-13 09:11
(edited on: 2020-04-13 09:13) |
|
Thanks to Quietust for investigating further - turns out this was the same issue as 0000722, and was fixed when that was:
0000722 was mis-parsing "[ITEM:15:FISH:NONE:LOBSTER_CAVE:FEMALE]" as if it were "[ITEM:15:FISH:NONE:LOBSTER_CAVE:NONE]" (and then complaining that it didn't exist). The same code was used for embark profiles and custom reactions, so fixing one fixed the other.
|
|