DF2014 Talk:Creature token

APPLY_CREATURE_VARIATION versus APPLY_CURRENT_CREATURE_VARIATION

Based on testing, APPLY_CREATURE_VARIATION has instant effect (in reverse order, as noted elsewhere), whereas APPLY_CURRENT_CREATURE_VARIATION is used to manually apply any creature variation tags, such as CV_ADD_TAG or CV_REMOVE_TAG, that have been manually added to the creature definition instead of being defined in a creature variation. In other words, APPLY_CURRENT_CREATURE_VARIATION has no effect if you are simply using APPLY_CREATURE_VARIATION to load creature variations. Think of a creature variation defined in an OBJECT:CREATURE_VARIATION file as a "template", which is applied with APPLY_CREATURE_VARIATION. Think of a "current creature variation" as any manually-defined creature variations that have been added to the creature definition itself, which must be applied to the creature with APPLY_CURRENT_CREATURE_VARIATION after you have made all of the necessary modifications.

For example, the following is a use of APPLY_CREATURE_VARIATION, which takes instantaneous effect without any need for APPLY_CURRENT_CREATURE_VARIATION.:

	[APPLY_CREATURE_VARIATION:REMOVE_STUB_ARMS]

This is an example of the use of APPLY_CURRENT_CREATURE_VARIATION:

	[COPY_TAGS_FROM:MY_CREATURE]
	[CV_REMOVE_TAG:TISSUE_LAYER_UNDER]
	[TISSUE_LAYER_UNDER:BY_CATEGORY:BODY:GAS]
	[TISSUE_LAYER_UNDER:BY_CATEGORY:WING:GAS]
	[APPLY_CURRENT_CREATURE_VARIATION]

--JT (talk) 05:43, 13 August 2014 (UTC)

Littersize Creature Token

I just tested the [LITTERSIZE] token and it still works, just a note for those interested.

[LOCAL_POPS_CONTROLLABLE] and [LOCAL_POPS_PRODUCE_HEROES] prevent trading creature

Specifically this prevents Elves from adding the creature as a trade-able (tame) caged creature to caravans. This is notable as they can currently trade pets that have [CAN_LEARN] and [CAN_SPEAK] enabled. Found this by save scumming an incoming Elven caravan while testing out creature addition and removal from a civilization using populate.rb

[FREQUENCY] affects how often creature appears in trade caravans

I found that by setting [FREQUENCY:5] on a creature that the local Elves could trade, and save scumming an incoming caravan. The rate of the creature appearing in the caravan dropped to 1/40 caravans (not truly 1/20 as it had to compete with roughly 100 other creatures with varying frequency settings). By setting it to [FREQUENCY:100] it now appears in roughly 1/6 caravans. (I'd test it more thoroughly if loading worlds took less time on my PC)

[COPY_TAGS_FROM] does not copy caste tags applied to a creature

Wanted to note this here, as I've seen Giant versions of pack animals without the [PACK_ANIMAL] flag set in creature_raws[creature_index].caste[caste_index].flags.PACK_ANIMAL as viewed through DFHack. As the [PACK_ANIMAL] flag CAN be set on the entire animal, and then pushed onto the male/female/whatever castes. It is still a caste flag, and does not get copied when using [COPY_TAGS_FROM]. Which only appears to copy creature wide tags.

SLOW_LEARNER doesn't apply CAN_LEARN

The SLOW_LEARNER token both sets all skill learn rates for a caste, and sets a special SLOW_LEARNER flag in its caste (which in turn gives the creature itself the HAS_ANY_SLOW_LEARNER flag). It doesn't change the INTELLIGENT_LEARNS flag of a caste (the one set by the CAN_LEARN token that enables the creature to learn). You'll see in troll's raws that CAN_LEARN is added alongside SLOW_LEARNER to make trolls able to learn.

You can make a caste that has the SLOW_LEARNER flag while still having standard skill rates by simply including [SKILL_LEARN_RATES:100] afterwards to override the extra changes to learn rates. I don't know if the system that checks for giving goblins access to creatures like trolls simply checks for the SLOW_LEARNER flag (well, presumably the HAS_ANY_SLOW_LEARNER of the creature), the skill learn rates, or a combination of both, but I'd guess (without testing) that it's likely that they just check for the flag.

This was all tested with some raw modding + digging through structures in DFhack.

Re COPY_TAGS_FROM: “Copies creature tags, but not caste tags”

The table entry for [COPY_TAGS_FROM] currently reads: “Copies creature tags, but not caste tags, from another specified creature.” What is the source of this assertion? Is it accurate?

I notice that animal people with [COPY_TAGS_FROM:BIRD_x] (such as BLUEJAY_MAN) generally end up with “[FEMALE][LAYS_EGGS]” in the computed raws. But by usage, and per the table, [LAYS_EGGS] is a caste tag, and therefore shouldn't be found on the new creature. Is the entry wrong, or have I misunderstood something?

—οɼѕаk 20:51, 4 February 2021 (UTC)

Where are you obtaining the "computed raws" from? If it's from DF2014:Bluejay_man/raw, that is generated with the DFRawFunctions extension, which is a reimplementation of DF's logic that could potentially have bugs. —Lethosor (talk) 01:57, 6 February 2021 (UTC)

If DFRawFunctions is how DFHack does it, then yes, that's what I mean by “computed raws.” But I investigated this after finding that a modded-in Bluejay man civilization (using a tweaked version of the original creature) produces offspring during worldgen, but not during gameplay. Pregnancies created via DFHack (using the same process as catsplosion) even count down to zero with birth never occurring. After I added CV_REMOVE_TAG:LAYS_EGGS to the modded Bluejay man creature, births (forced and otherwise) occur as expected. —οɼѕаk 16:39, 6 February 2021 (UTC)

To be more specific, this is the line I entered into the dfhack console (with a bluejay man selected):

:lua (function () for _,v in pairs(df.creature_raw.find(dfhack.gui.getSelectedUnit().race).raws) do print(v.value) end end)()

—οɼѕаk 16:47, 6 February 2021 (UTC)

Oh, DFHack does not use DFRawFunctions - DFHack is showing you the actual in-game data computed by DF, while DFRawFunctions is only used on the wiki (and is written in PHP, so it couldn't run under DFHack anyway). I didn't realize that the "raws" vector contained the computed raws in-game, but that's good to know! (You don't strictly need the enclosing function, by the way - just :lua for _,v in pairs(df.creature_raw.find(dfhack.gui.getSelectedUnit().race).raws) do print(v.value) end will work.)

From an initial inspection, it looks like COPY_TAGS_FROM is copying caste tags and intended to do so. Other animal men that I checked, including chipmunk man and lizard man, don't specify [MALE] or [FEMALE] for the relevant castes, but they are in the computed raws, as they should be. Note that it's possible that something else I don't understand is adding these tags. I checked APPLY_CREATURE_VARIATION, but I don't think the ANIMAL_PERSON variation is doing anything to the MALE/FEMALE tags.

Short version: could be a mistake in the article, but I'm not really sure. People on the modding forum might have a better idea. —Lethosor (talk) 01:05, 7 February 2021 (UTC)

I'm used to enclosing snippets in anonymous functions just to keep from polluting the global environment. I haven't read the docs or the internals religiously, so I wouldn't be surprised if they do something to keep that from happening anyway. It just helps me sleep at night. —οɼѕаk 14:17, 7 February 2021 (UTC)

Well, I haven't used the forums in a long time—I've forgotten my old login and then created a new one so many times—but maybe I'll ask around. Thanks for giving it a look, though. —οɼѕаk 14:32, 7 February 2021 (UTC)

Caste token?

Should Caste be linked here as token ? --Jan (talk) 22:41, 1 February 2022 (UTC)

questions about our table syntax

SELECT_MATERIAL	Creature	<material token>	Selects a locally defined material. Can be ALL.
SELECT_TISSUE	Creature	tissue token	Selects a tissue for editing.

Is there any significance to the angular brackets surrounding the 'material token' link?
Any reason why 'tissue token' (or any other token argument we document) should be linked i.e. tissue token?

--Jan (talk) 14:56, 2 February 2022 (UTC)