DF2014 Talk:Creature token

+	This talk page has been created by request by 178.167.254.128 (talk | contribs). To remove this message, delete the {{newpage}} (or {{np}}) tag from this page.

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)