Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
0004973Dwarf FortressReactionspublic2011-11-30 13:072020-04-13 09:12
Toady One 
normalminorhave not tried
0004973: Vermin reactions do not recognize caste
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").
No tags attached.
parent of 0000722resolved Toady One Embark profile warns that fish not available, but they actually are 
Issue History
2011-11-30 13:07QuietustNew Issue
2011-12-01 20:32QuietustNote Added: 0019060
2012-03-02 13:26QuietustNote Added: 0021000
2014-09-15 14:05lethosorAssigned To => lethosor
2014-09-15 14:05lethosorStatusnew => confirmed
2014-09-15 14:12QuietustNote Added: 0030204
2015-03-01 09:19chaosvoltNote Added: 0032296
2020-04-12 06:50QuietustNote Added: 0040456
2020-04-12 09:28lethosorNote Added: 0040457
2020-04-12 09:28lethosorStatusconfirmed => resolved
2020-04-12 09:28lethosorFixed in Version => 0.47.01
2020-04-12 09:28lethosorResolutionopen => fixed
2020-04-12 09:28lethosorAssigned Tolethosor => Toady One
2020-04-13 09:11lethosorNote Added: 0040459
2020-04-13 09:11lethosorFixed in Version0.47.01 => 0.43.03
2020-04-13 09:12lethosorRelationship addedparent of 0000722
2020-04-13 09:12lethosorNote Edited: 0040459bug_revision_view_page.php?bugnote_id=0040459#r16439
2020-04-13 09:13lethosorNote Edited: 0040459bug_revision_view_page.php?bugnote_id=0040459#r16440

2011-12-01 20:32   
Further analysis suggests that items of type REMAINS, FISH, FISH_RAW, and EGG may also be affected by this.
2012-03-02 13:26   
A quick test confirms that this is still the case in version 0.34.04.
2014-09-15 14:12   
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).
2015-03-01 09:19   
No idea whether defining a fallback caste titled NONE would avoid this issue or not. Anyone tried !!SCIENCE!! on that?
2020-04-12 06:50   
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.
2020-04-12 09:28   
Cool, I'll mark it as fixed in 0.47.01, but let me know if that should be changed.
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.