Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[drayath]

Been looking into why the workshop syndromes are not always that reliable even though autosyndrome is being used. Found a few issues.

A) dfhack issue. Autosyndrome does not fire for jobs that are on repeat!
-- User work around: dont repeat any jobs producing syndrome stones, otherwise relying on the vanilla infectious gas chance to apply.

B) Many of the raw entries are incorrectly using [SYN_CLASS:/ where they should be using [SYN_CLASS:\ this means that most of the sutosyndrome special flags (like WORKER_ONLY) are being ignored. (note seems to need a world regen for this to take affect).

B2) In V3a the guild transform stones specify WORKER_ONLY, but the need to have COMMAND first or the flag is ignored Edit: Ignore this, i'm being an idiot. Edit2: truely, because this is an issue.

From looking a the code, here are the rules on autosyndrome flag usage. Any flags not used in this way/order will be ignored.

Spoiler (click to show/hide)

Required if any of the other tokens are used (autosyndrome will still run without it using defaults)

[SYN_CLASS:\COMMAND]

Zero or more of:

[SYN_CLASS:\WORKER_ONLY] or [SYN_CLASS:\ALLOW_MULTIPLE_TARGETS]
[SYN_CLASS:\PRESERVE_ROCK]
[SYN_CLASS:\IMMUNE_IF_ALREADY_AFFECTED] or [SYN_CLASS:\RESET_DURATION_IF_ALREADY_AFFECTED] or [SYN_CLASS:\RESET_DURATION_IF_ALREADY_AFFECTED:<toTicksNumber>]

Zero or one of:

[SYN_CLASS:anCommandToPerform]

Only if [SYN_CLASS:anCommandToPerform] specified thenone or more of these (ignored otherwise).
Required tags and order depends on the specific command, see its documenation:
E.g.   [SYN_CLASS:\COMMAND] [SYN_CLASS:\PRESERVE_ROCK] [SYN_CLASS:action] [SYN_CLASS:\WORKER_ID]

[SYN_CLASS:\LOCATION]
[SYN_CLASS:\WORKER_ID]
[SYN_CLASS:\REACTION_INDEX]

----

Note: must use [\ not [/
Note: Don't specify [SYN_INHALED] [SYN_CONTACT] etc. if you are using autosyndrome to apply a syndrome it is not required, and speculating that this is why sometimes units are affected twice (once by autosyndrome applying the effect, and sometimes a second application from the vanilla syndrome gas.)

C) [SYN_INHALED] [SYN_CONTACT] are not needed on syndromes that are applied with autosyndrome. Im speculating that autosyndrome+vanilla infection is why appects are sometimes produced twice on a dwarf.

I've tested A & B by adding various debug logging to the autosyndrome plugin, C i've not yet tested.
Log output from two seperate jobs one useing \ one using /

Spoiler (click to show/hide)

==========================
plugins\autoSyndrome.cpp line 252: processing job: JOIN_GUILD_MASON.
plugins\autoSyndrome.cpp line 332: got building.
plugins\autoSyndrome.cpp line 338: Testing reaction: Join the masons guild.
plugins\autoSyndrome.cpp line 368: checking syndrome.
Testing: '\COMMAND'
autoSyndrome.cpp line 448: Start of \COMMAND .  (Successfully found flag)
Testing: '\WORKER_ONLY'
Processing command options
Still blank command
Worker only (Successfully found flag)
Testing: '\IMMUNE_IF_ALREADY_AFFECTED'
Processing command options
Still blank command
Immune if affected already  (Successfully found flag)
Consider applying, checking immunities, affected castes etc
autoSyndrome.cpp line 531: Applying syndrome to unit 4515.
plugins\autoSyndrome.cpp line 338: Testing reaction: Join the masons guild.
plugins\autoSyndrome.cpp line 368: checking syndrome.

==========================
plugins\autoSyndrome.cpp line 252: processing job: JOIN_GUILD_MERCHANT.
plugins\autoSyndrome.cpp line 332: got building.
plugins\autoSyndrome.cpp line 338: Testing reaction: Join the merchants guild.
plugins\autoSyndrome.cpp line 368: checking syndrome.
Testing: '/COMMAND'
Skipping, prior to \COMMAND
Testing: '/WORKER_ONLY'
Skipping, prior to \COMMAND
Testing: '/IMMUNE_IF_ALREADY_AFFECTED'
Skipping, prior to \COMMAND (This time no flags found)
Consider applying, checking immunities, affected castes etc
autoSyndrome.cpp line 338: Testing reaction: Join the merchants guild.
autoSyndrome.cpp line 368: checking syndrome.
Consider applying, checking immunities, affected castes etc
autoSyndrome.cpp line 531: Applying syndrome to unit 4516.

[smakemupagus]

Great finding, although i think incomplete, for example:

[SYN_CLASS:\COMMAND] isn't required for an autosyndrome to execute.  Everything that *follows* \COMMAND is sent to the DFHack prompt, so there are some autosyndrome inputs that must come *before* or *without* a \COMMAND (although judging by the Ouput logs you showed, expwnent added some extra checking to make it robust against putting them after), and others that rely on DFHack scripting must come *after*.

http://www.bay12forums.com/smf/index.php?topic=91166.msg4108566#msg4108566

is a resource

[drayath]

updated comment of COMMAND (must proceed any other autosyndrome tokens or they will be ignored).

This mostly came about from trouble shooting a couple that were definatly not working, where the logging was showing a lot of the tokens were being ignored even when slashes corrected as were in the wrong order (or just present in the raws and not actually required at all)

Ah, and note the following tokens only exist in my local copy of the code at the moment unless they are going to be useful for others to use.
[SYN_CLASS:\IMMUNE_IF_ALREADY_AFFECTED]   # I.e. Dont re-apply
[SYN_CLASS:\RESET_DURATION_IF_ALREADY_AFFECTED] #I.e. reset duration if already exists on unit, otherwise add syndrome
[SYN_CLASS:\RESET_DURATION_IF_ALREADY_AFFECTED:<toTicksNumber>] I.e reset duration to a defined value already exists on unit, otherwise add syndrome. 

[sayke]

@drayath - excellent bughunting there!! that's really great detective work =) i wonder what the chances of working this into a 3b are... or how exactly can we fix it ourselves?

[smakemupagus]

updated comment of COMMAND (must proceed any other autosyndrome tokens or they will be ignored).

How sure are you about this?  it conflicts with the copy of expwnent's instructions that I have.

Certainly you are right that the *scripting* commands must be proceeded by \COMMAND.

What is the status of those new syndrome token that you say exist only in your code ... are you writing a new version of the script that uses them, or are you proposing that the developers introduce that functionality in the future?  If it's a proposal/suggestion, its a good thing to post in the DFHack thread or "Suggestions for DFHack" in the upper modding boards.

Special arguments that must be given BEFORE \COMMAND, (or without any \COMMAND at all)

"\WORKER_ONLY": When present, add the syndrome to (at most) the worker. Still check if the worker can be affected based on SYN_AFFECTED and SYN_IMMUNE stuff. When absent, try to add the syndrome to all units in the workshop.

"\PRESERVE_ROCK": When present, do NOT delete the rock that was created by the reaction. When absent, do delete it (prevents it from being inhaled conventionally).

"\ALLOW_MULTIPLE_TARGETS": When absent, any number of targets may be affected by any syndrome (as long as they are influenced according to the SYN_AFFECTED, SYN_IMMUNE, and WORKER_ONLY rules). When present, at most one unit can be affected by the syndrome.

Also interesting, future versions of autosyndrome will have a different syntax, just saw this post.
http://www.bay12forums.com/smf/index.php?topic=91166.msg4242750#msg4242750

[drayath]

@drayath - excellent bughunting there!! that's really great detective work =) i wonder what the chances of working this into a 3b are... or how exactly can we fix it ourselves?

Next released version of dfhack should fix the repeating jobs issue.

As quick fix find and replace [SYN_CLASS:/ with [SYN_CLASS:\ in:
inorganic_dfhack.txt
inorganic_guild.txt
inorganic_z_orcfort.txt
inorganic_z_orcfort_magic.txt
inorganic_zmasterwork.txt

Not going to make anything worst, and will sort out most things. [WILL NEED A WORLD REGEN] however live without for a while (guild/bard system uses a slightly diffferent technique that is reliable, if occasionally transforming babies and passing dwarves).

Not tried this out as just getting to the good point in my game. After 10 years finally have some married people start building up my population, hopefully the run covered [in progress] steampowerd [done] with extra full plate [done] worn by dwarven mages [in training] will let me have some actual survivable fights while waiting for the new babies to start growing up.
Ghia world, but dwarves and elves were killed off before year 90, though i do have a necromancer tower nearby to ...make up for it.
Only reason i am finding issue with rarly used stuff is that i am trying to power up by irriplacable supply of dwarves.

[smakemupagus]

Next released version of dfhack should fix the repeating jobs issue.

Be careful if you upgrade though, because it might also add the newly discussed requirement to use the \AUTO_SYNDROME token as a trigger rather than using the boiling point value as trigger.

Drayath, thanks, the changes to the Orcfort files are straightforward so I just used your find/replace.  They're mostly just the \WORKER_ONLY token so I think that with the broken tag, the only in game issue is that worker-only wasn't processing.  Anyway it is fixed for the future, much thanks.

Let's see how many other errors people find, and see if we hear from Meph in the next weeks -- Assuming he's away from keyboard a lot, we can eventually pull together some "unofficial patch" with the straightforward and/or well-tested fixes, if nothing else it might make it easier for Meph to make the official patches.

[drayath]

The new tokens are some things i was tying out in the code to try to stop duplicate copies of syndromes being applied (e.g. i have had 2 copies of various transform effects applied to dwarves) and i was thinking that things like the Fountain of Youth should really be a once ever complete heal which is much easier is you can use a IMMUNE_IF_ALREADY_AFFECTED flag on the syndrome rather than having to go through syndrome give interaction, self interaction has IT_CANNOT_TARGET_IF_ALREADY_AFFECTED set, interaction applies the actual syndrome.

Present logic in autosyndrom the code is

before \COMMAND  the plugin ignores all tokens.
once the first unreconized class\named command is found \WORKER_ONLY \ALLOW_MULTIPLE_TARGETS \PRESERVE_ROCK  are ignored
until any unreconized class\named command is found \LOCATION \WORKER_ID \REACTION_INDEX are ignored


Simplified core logic block from the code, which is probably clearer than my explanation.

Spoiler (click to show/hide)

Code: [Select]

// For each class in the syndrome
for ( size_t c = 0; c < syndrome->syn_class.size(); c++ ) {
std::string* clazz = syndrome->syn_class[c];

if ( foundCommand ) {
// this block skipped until find \COMMAND
if ( commandStr == "" ) {
if ( *clazz == "\\WORKER_ONLY" ) {
workerOnly = true;
} else if ( *clazz == "\\ALLOW_MULTIPLE_TARGETS" ) {
allowMultipleTargets = true;
} else if ( *clazz == "\\PRESERVE_ROCK" ) {
destroyRock = false;
} else if ( *clazz == "\\IMMUNE_IF_ALREADY_AFFECTED" ) {
immuneIfAlreadyAffected = true;
} else if ( clazz->find("\\RESET_DURATION_IF_ALREADY_AFFECTED") == 0 ) {
static int prefixLength = strlen("\\RESET_DURATION_IF_ALREADY_AFFECTED");
if(prefixLength == clazz->length()) {
resetDurationTick = 1;
} else {
resetDurationTick = atoi(clazz->substr(strlen("\\RESET_DURATION_IF_ALREADY_AFFECTED")+2).c_str());
}
} else {
// This is the only thing that sets the command
commandStr = *clazz;
}
} else {
// Only entered once command has been set in above block
if ( *clazz == "\\LOCATION" ) {
// Store location coords in args
} else if ( *clazz == "\\WORKER_ID" ) {
// store id in args
} else if ( *clazz == "\\REACTION_INDEX" ) {
// store index in args
} else {
args.push_back(*clazz);
}
}
} else if ( *clazz == "\\COMMAND" ) {
// the above code block is skipped until this happens
foundCommand = true;
}
}
}
// do all the caste/immunity etc checks
// apply the syndrome as required


edit: i need to sleep, that took 4 edits to type correctly what i had on the piece of paper next to me...

[Meph]

Yes, dish out complicated C++ scripts and raw-changes to a big part of the mod while I am just lurking around... ^^ I am not sure how feasable a 3b version is in near time. I dont have an tools with me, no programs I usually use, but I guess the smaller ones I could download on the fly. Still, I wont be coding in any foreseen time.

[sayke]

@meph - haha damn!! might smake be able to curate a 3b build in your extended absence, by any chance?

[fasquardon]

Following reaction is trying to producing blocks for no longer valid reagents D->J.

[REACTION:ROCK_GRINDING]
   [BUILDING:GRINDER:CUSTOM_SHIFT_G]
   [NAME:grind non-economic rocks (3)]
   [REAGENT:A:1:BOULDER:NONE:NONE:NONE][WORTHLESS_STONE_ONLY]
   [REAGENT:B:1:BOULDER:NONE:NONE:NONE][WORTHLESS_STONE_ONLY]
   [REAGENT:C:1:BOULDER:NONE:NONE:NONE][WORTHLESS_STONE_ONLY]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:A:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:B:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:C:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:D:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:E:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:F:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:G:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:H:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:I:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:J:NONE]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_COPPER]
   [PRODUCT:10:1:BOULDER:NO_SUBTYPE:INORGANIC:COAL_BITUMINOUS]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_PLATINUM]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_GOLD]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_SILVER]
   YESDUST[PRODUCT:100:1:BOULDER:NONE:INORGANIC:DUST][PRODUCT_DIMENSION:150]
   [SKILL:STONECRAFT]

Hmm, can someone with greater modding experience tell me how to fix this bug myself? 

Thanks in advance.

fasquardon

[smakemupagus]

[REACTION:ROCK_GRINDING]
   [BUILDING:GRINDER:CUSTOM_SHIFT_G]
   [NAME:grind non-economic rocks (3)]
   [REAGENT:A:1:BOULDER:NONE:NONE:NONE][WORTHLESS_STONE_ONLY]
   [REAGENT:B:1:BOULDER:NONE:NONE:NONE][WORTHLESS_STONE_ONLY]
   [REAGENT:C:1:BOULDER:NONE:NONE:NONE][WORTHLESS_STONE_ONLY]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:A:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:B:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:C:NONE]
   
[PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:D:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:E:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:F:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:G:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:H:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:I:NONE]
   [PRODUCT:5:1:BLOCKS:NONE:GET_MATERIAL_FROM_REAGENT:J:NONE]

   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_COPPER]
   [PRODUCT:10:1:BOULDER:NO_SUBTYPE:INORGANIC:COAL_BITUMINOUS]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_PLATINUM]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_GOLD]
   [PRODUCT:3:1:BOULDER:NO_SUBTYPE:INORGANIC:NATIVE_SILVER]
   YESDUST[PRODUCT:100:1:BOULDER:NONE:INORGANIC:DUST][PRODUCT_DIMENSION:150]
   [SKILL:STONECRAFT]

You could delete the chance for blocks from the reagents that don't exist.

Optionally you could also increase the chance to get blocks from stone A, B, and C, say by a factor of 4; change the "5" to a "20", if you think that's appropriate.

[fasquardon]

Ahhhh.  I understand the raws a bit better now as well.  Thankye kindly Smake.

fasquardon

[Meph]

It was a balancing done to RAISE the amount of outcome and LOWER the amount of input. So dont reduce it by a factor of 4, I just reduced the intake by the factor of 3. Just change the reagents id to A, B and C.

[smakemupagus]

I think we were on the same page here Meph, I was also suggesting he increase the output of type A, B, and C blocks.

@fasquardon:  of course Meph's solution is the canonical one!