Dwarf Fortress Bug Tracker - Dwarf Fortress
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006393Dwarf FortressCreaturespublic2013-11-25 09:492014-12-02 21:39
ReporterButton 
Assigned ToFootkerchief 
PrioritynormalSeverityminorReproducibilityalways
StatusconfirmedResolutionreopened 
PlatformOSOS Version
Product Version0.34.11 
Target VersionFixed in Version 
Summary0006393: CV_CONVERT_TAG doesn't require an exact match; creature variations are applied in reverse order
DescriptionI added the following to the [CREATURE_VARIATION:GIANT] creature template (in this order):

    [CV_CONVERT_TAG]
        [CVCT_MASTER:BODY]
        [CVCT_TARGET:HEAD_HORN]
        [CVCT_REPLACEMENT:3HEAD_HORN_NUMBERED]
    [CV_CONVERT_TAG]
        [CVCT_MASTER:BODY]
        [CVCT_TARGET:2HEAD_HORN]
        [CVCT_REPLACEMENT:4HEAD_HORN]

I get the following error:

*** Error(s) found in the file "data/save/region14/raw/objects/creature_temperate_new.txt"
GIANT_IBEX:Unrecognized Creature Caste Body Token: 43HEAD_HORN_NUMBERED

For reference, the IBEX's body tag is:

[BODY:QUADRUPED_HOOF:TAIL:2EYES:2EARS:NOSE:2LUNGS:HEART:GUTS:ORGANS:THROAT:NECK:SPINE:BRAIN:SKULL:2HEAD_HORN:MOUTH:GENERIC_TEETH:RIBCAGE]

It appears that the CV_CONVERT_TAG is stripping the 4 from 4HEAD_HORN when it goes looking for HEAD_HORNs to replace with 3HEAD_HORN_NUMBERED.
Steps To ReproduceCopy the above into your raws and create a giant ibex in Arena.
Additional Information
TagsIntentional/Expected?, raw, raw file, raw files
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-11-25 09:49ButtonNew Issue
2013-11-25 09:50ButtonTag Attached: raw
2013-11-25 09:50ButtonTag Attached: raw file
2013-11-25 09:50ButtonTag Attached: raw files
2013-11-25 10:26ButtonNote Added: 0024227
2013-11-25 10:26ButtonTag Attached: Probable Quick Fix
2013-11-25 14:08QuietustNote Added: 0024229
2013-11-27 10:45ButtonNote Added: 0024231
2014-01-17 10:33Kirig StonebeardIssue Monitored: Kirig Stonebeard
2014-01-17 17:26FootkerchiefTag Detached: Probable Quick Fix
2014-01-17 17:26FootkerchiefStatusnew => resolved
2014-01-17 17:26FootkerchiefResolutionopen => no change required
2014-01-17 17:26FootkerchiefAssigned To => Footkerchief
2014-01-17 17:27FootkerchiefSummaryCV_CONVERT_TAG doesn't respect numbers in BODY tag => CV_CONVERT_TAG doesn't require an exact match; creature variations are applied in reverse order
2014-01-17 17:27FootkerchiefNote Added: 0024279
2014-01-24 12:34ButtonNote Added: 0024347
2014-01-24 12:34ButtonStatusresolved => needs feedback
2014-01-24 12:34ButtonResolutionno change required => reopened
2014-01-24 12:48FootkerchiefTag Attached: Intentional/Expected?
2014-06-05 09:30FootkerchiefStatusneeds feedback => acknowledged
2014-12-02 14:37ButtonNote Added: 0031244
2014-12-02 14:38ButtonNote Edited: 0031244bug_revision_view_page.php?bugnote_id=0031244#r12460
2014-12-02 21:39FootkerchiefStatusacknowledged => confirmed

Notes
(0024227)
Button   
2013-11-25 10:26   
Oh I should have mentioned, 4HEAD_HORN and 3HEAD_HORN_NUMBERED were/are both custom body tags of mine.

Update: changing the name of the 4HEAD_HORN custom BODY tag to 4HEAD_HORNS creates the illegal body tag 43HEAD_HORN_NUMBEREDS . So it's not just numbers that are disregarded - it's a 'contains' comparison when it should be an equality comparison.

Renaming the custom tag to 4HEAD__HORNS (two underscores) solves the problem.
(0024229)
Quietust   
2013-11-25 14:08   
The problem is that it isn't requiring an exact match on the relevant token - when replacing HEAD_HORN with 3HEAD_HORN_NUMBERED, it changes 4HEAD_HORN to 43HEAD_HORN_NUMBERED.

It's also a problem with the order in which the replacements are being performed - if you put the 2HEAD_HORN -> 4HEAD_HORN one at the top, it might avoid the conflict.
(0024231)
Button   
2013-11-27 10:45   
Upon further experimentation I have found that in fact, creature variation tags are applied in reverse order - from bottom to top.

I've been assuming this whole time that it would apply them from top to bottom, and creating my variations accordingly! This changes everything!
(0024279)
Footkerchief   
2014-01-17 17:27   
Given those revelations, I'm closing the report, but if you still consider this behavior a bug, feel free to reopen it. I'm on the fence.
(0024347)
Button   
2014-01-24 12:34   
I think the partial token match issue still qualifies as a bug. Knowing the order in which variation tags are applied is nice, but the behavior is still there and could seriously trip up future creature raws.
(0031244)
Button   
2014-12-02 14:37   
(edited on: 2014-12-02 14:38)
Update, this is definitely still an issue in 40.19. I modded in MAXAGE increases to the giant creature template. It scales up the maxages for giant creatures to at least 10 years, thus:

    [CV_CONVERT_TAG]
        [CVCT_MASTER:MAXAGE]
        [CVCT_TARGET:1]
        [CVCT_REPLACEMENT:10]
    [CV_CONVERT_TAG]
        [CVCT_MASTER:MAXAGE]
        [CVCT_TARGET:2]
        [CVCT_REPLACEMENT:10]

and so on. So, giant creatures belonging to base creatures with a 2-digit lifespan would receive maxages of 1010 years minimum, no matter how I order the conversions.