Print

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

[FantasticDorf]

int_32t is a type defined in the C standard and does not have any emotion system defined within it. Your entire issue seems to be based on a fundamental misunderstanding of what enums are.

https://github.com/DFHack/df-structures/blob/0e8313dc86617796b7145a306df274a882474175/df.unit-thoughts.xml.

I thought (no pun intended) that i might have forgotten to add this. Thoughts are emotions pretty much. To my observable knowledge it is impossible to have a 'high emotion' without a relevant 'high' thought taking place or being staged internally (pre 42.01 animals had none of these features bar perhaps fear for benign creatures in avoiding combat, now they express desires to pray and weep, get anxious and and distracted)

> I've expressed before im not the MOST technical person around on the matter but im pretty certain in most uncertainty that this is what i am describing when i express a emotional system in ('int_32t'). Some more elaboration on what precisely im misunderstanding would be great as im reading though and learning a little bit from that guide you linked including tidbits on scoping rules which are interesting adding on what i gleamed from the syntax . I've definitely cruised github before and got familiar with looking at C++ code (and only a little bit proficient at writing it, but DF code is in language to what i've seen and usually familiar with)

> creature_raw is defined as int_32t's core function on the syntax, and the enum type is used simultaneously between the animal functions too (as far as i see there is nothing to differentiate them into a group) so it seems to be a unintended effect in trying to apply the emotion system via enum fields without actually distinguishing intelligents as the recipient and throwing it on all life with unintented consequences that we see now.

Spoiler (click to show/hide)

Code: ("Taken from <data-definition> <enum-type type-name='emotion_type' base-type='int32_t'>) [Select]

<enum-type type-name='unit_thought_type'>
        <enum-attr name='caption'/>

        <enum-item name='Conflict'>
            <item-attr name='caption' value='while in conflict'/>
        </enum-item>
        <enum-item name='Trauma'>
            <item-attr name='caption' value='after experiencing trauma'/>
        </enum-item>
        <enum-item name='WitnessDeath'>
            <item-attr name='caption' value='after seeing somebody die'/>
        </enum-item>
        <enum-item name='UnexpectedDeath'>
            <item-attr name='caption' value='at the unexpected death of [somebody]'/>
        </enum-item>
        <enum-item name='Death'>
            <item-attr name='caption' value="at somebody's death"/>
        </enum-item>
        <enum-item name='Kill'>
            <item-attr name='caption' value='while killing somebody'/>
        </enum-item>
        <enum-item name='LoveSeparated'>
            <item-attr name='caption' value='at being separated from a loved one'/>
        </enum-item>
        <enum-item name='LoveReunited'>
            <item-attr name='caption' value='after being reunited with a loved one'/>
</enum-item>

Again i quote from the same field...

Code: [Select]

        <enum-item name='NeedsUnfulfilled'>
            <item-attr name='caption' value='after [varying]'/>
        </enum-item>
        <enum-item name='Prayer'>
            <item-attr name='caption' value='after communing with [deity]'/>
</enum-item>
I know witness death thoughts happen, because you can spill any aggressive creatures brains out and over time their morale will break and they will eventually become fearful of the race/entity or perpetrators who have commited the crime. And locally nearly all creatures who go off and back on the map again will express the same fear (which is a methodically replicatable experiment with chains & troggs, in selectively killing troggs in sight on chains until they are terrified and let them loose to contaminate the collective behavior of the rest of the troggs)

[Putnam]

Trust me, if any problem you have is related to int_32t in particular then you're barking up the wrong tree. I'll try to address some grievances:

1. Emotions are felt due to thoughts. This is simply how the game works.

2. Needs (desire for prayer) are not thoughts. Thoughts can happen due to lack of need fulfillment, but being focused or distracted is not related to the thoughts system.

3. Animals and sentient beings feel emotions and needs identically, yes, but you're overcomplicating things heavily with all this talk of "enums". the problem is that animals and intelligent beings act the same as regards to thoughts. This has nothing to do with any types being used or anything, it's a problem with function logic. We can work around the issues by manually changing distractedness and stress.

[FantasticDorf]

Trust me, if any problem you have is related to int_32t in particular then you're barking up the wrong tree. I'll try to address some grievances:

1. Emotions are felt due to thoughts. This is simply how the game works.

2. Needs (desire for prayer) are not thoughts. Thoughts can happen due to lack of need fulfillment, but being focused or distracted is not related to the thoughts system.

Perfectly reasonable i guess, i never precisely found the 'core' of the thought system though i definitely rooted around for it. Perhaps it's squirreled away somewhere i haven't thought to look, but this emotional system is the largest common link towards the behaviors. In my own mind it must be running through some kind of process in order to execute the behaviour we're seeing and the mind facilitiates that (given that when you die, from being turned into a corpse and not a unit your thoughts stop even though you experience body health trauma) even though its non-interfacable, applications like dwarf therapist shows that in lesser beings thoughts still go through on subjects like nakedness.

3. Animals and sentient beings feel emotions and needs identically, yes, but you're overcomplicating things heavily with all this talk of "enums". the problem is that animals and intelligent beings act the same as regards to thoughts. This has nothing to do with any types being used or anything, it's a problem with function logic. We can work around the issues by manually changing distractedness and stress.

Immediate problem here is that even on the guide you described to me, all of the problem areas of location features, animal training and emotions are not properly scoped out and are sorted into the base type. [EDIT - Hang on every new name creates a new bitfield in 'int32_t' for reference after looking though primitives, which is interesting but definitely pokes some holes in my arguement unless it is somehow processing it wrong]

[Putnam]

They're not "sorted into the base type"--you're misunderstanding something pretty fundamental here and I'm not sure what. Location features and animal training have absolutely nothing to do with this.

By the "core" of the thought system, do you mean the structure that defines thoughts? That would be unit.status.current_soul.emotions. See add-thought for a bit more detail.

[FantasticDorf]

They're not "sorted into the base type"--you're misunderstanding something pretty fundamental here and I'm not sure what. Location features and animal training have absolutely nothing to do with this.

By the "core" of the thought system, do you mean the structure that defines thoughts? That would be unit.status.current_soul.emotions.

I only recently learned in my edit that 'int32_t' creates new fields from names, what i seemed to be misunderstanding was seeing all these same entries of 'int32_t' being put into the same space without anything definitively setting them apart implying that they were all 'in the same basket' interacting with each other in a round about way (going back to the point on scoping that you helped enlighten me about, as its required to differentiate)

Code: [Select]

sub render_enum_core($$) {
    my ($name,$tag) = @_;

    my $base = 0;
    my $count = 0;

my $base_type = get_primitive_base($tag, 'int32_t');
Yes. Thats useful thank you. Im combing through it now, there are a lot of unknowns but some traces of (the bitfield in name=type doesn't appear to be closed off properly and/or a bit precarious interspersed there, seems a bit sensitive calling it 'type' and also structuring it that way but i might well be wrong)

[Putnam]

int_32t is merely a type. Two structures that both happen to be vectors of int_32t numbers will be independent of one another. There's no relationship between them just because they're both a vector of type int_32t. For example:

Code: [Select]

int main() {
    int_32t array_size; //a new int_32t
    array_size=5; //defines array_size to equal 5
    int_32t[array_size] array1; //makes a new array made up of 5 int_32t numbers (well, pointers to 5 int_32t numbers, but that's overcomplicating things)
    int_32t[array_size] array2; //completely independent of array1! will point to an entirely new data structure, despite being defined in an identical way
}


[FantasticDorf]

I do respect your input as you know more than myself on the matter. And i know more about where i went wrong from your information to drop that lead of inquiry, I can accept its the wrong place to look. So i followed the grapevine from what i found out elsewhere and pottered around looking at this.

Spoiler: Im concious im taking a lot of space in this thread so i've sealed it up inside spoilers to keep pagesize down (click to show/hide)

Code: [Select]

<enum-type type-name="world_population_type">
        <enum-item name='Animal'/>     //Shared between ALL living units?
        <enum-item name='Vermin'/>
        <enum-item name='Unk2'/>
        <enum-item name='VerminInnumerable'/>
        <enum-item name='ColonyInsect'/>
        <enum-item name='Tree'/>
        <enum-item name='Grass'/>
        <enum-item name='Bush'/>
</enum-type>
If Clowns aren't also innumerable in this code (For the unknown value above) this really distinguishes that the game only recognizes 'animals' as entities on a site population map (given there isn't specific code in place to distinguish intelligents), so naturally when you make a system for intelligent life only it isn't being discriminated and therefore applied on all 'animal units' which entities are minus their intelligence flags. Entity populations have a seperate counter of 'populations'

These bugs with intelligent animals occurred at exactly the same time as the mind system was implemented, what seems across all things without further code elaboration or relevant links that are observable anyway.

Code: ("For referencing the 'population' including animal/cavern features) [Select]

        <int32_t name="population_idx">
            <code-helper name='refers-to'>
                (let* ((info $$._global)
                       (wdata $global.world.world_data)
                       (x $info.region_x)
                       (y $info.region_y)
                       (reg (or (when (/= $info.feature_idx -1)
                                  (let* ((rip $wdata.feature_map[(floor x 16)][(floor y 16)])
                                         (flst $rip.features.feature_init[(logand x 15)][(logand y 15)]))
                                    $flst[$info.feature_idx].feature))
                                (awhen $info.cave_id.ref-target
                                  $it.feature_init.feature)
                                (find-instance $world_region ;
                                               $wdata.region_map[x][y].region_id))))
                  $reg.population[$])
            </code-helper>
        </int32_t>

        <int16_t name="depth"/>
    </struct-type>

    <struct-type type-name='local_population'>
        <enum base-type='int8_t' name='type' type-name='world_population_type'/>

        <compound is-union='true'>
            <int16_t name="race" ref-target='creature_raw'/>
            <int16_t name="plant" ref-target='plant_raw'/>
        </compound>

        <int32_t name="quantity"/>
        <int32_t name="quantity2" comment='v0.40.01'/>

        <bitfield name='flags' base-type='uint8_t'>
            <flag-bit name='discovered'/>
            <flag-bit name='extinct' comment='guessed, based on 23a'/>
            <flag-bit name='already_removed' comment='no longer in world.populations'/>
            <flag-bit name='unk3' comment='prevents it from showing up, related to world.unk_59dc4'/>
        </bitfield>

        <compound name='population' type-name='world_population_ref'/>

        <int32_t name='wp_unk_10' init-value='-1'/>
        <int32_t name='wp_unk_18' init-value='-1'/>
        <int32_t name='wp_unk_1c' init-value='-1'/>
</struct-type>


When the game runs a check of site population, this is what it's reading off. The compiler also seems unhappy about ("world_site.units.*.*" :STATUS :UNCHECKED) with those little asterisks. Essentially in order to bring the emotion and thought system to all intelligents it has to apply it to all the creatures too, which is as good as going through creature raws and slapping it on everything besides vermin and insects (which to my knowledge neither are reported to have been showing any symptoms.)

In DF.Unit the soul aspect (or the mind for interfacing) is also shared between units because they are sorted by race (Which from DF.world.data XML (<int16_t name="race" ref-target='creature_raw'/>)) so everything inherits the fundamental requirement to express emotions in response to stress, as a byproduct animals are also counted in. Prior to the mind ui and function update this would have been fine with the code we have, because animals could have possessed a 'soul' but been unable to express it.

Code: (In the shared structure between all living things) [Select]

        <compound name='animal'>
<compound name='population' type-name='world_population_ref'/>

...

    <struct-type type-name='unit_soul'>
        <int32_t name='unit_id' ref-target='unit'/>

        <compound name='name' type-name='language_name'/>

        <uint32_t name='race' ref-target='creature_raw'/>
        <int8_t name='sex' comment='-1 n/a, 0 female, 1 male'/>
        <uint16_t name='caste' ref-target='caste_raw' aux-value='$$.race'/>

        <code-helper name='describe'>
            (describe-obj $.name)
            (awhen (find-creature $.race)
            (fmt "~:(~A ~A~)" $it.caste[$.caste].caste_id $it.creature_id))
</code-helper>
Toady would need to create a duplicative and simpler soul system and abstract animals from entities as respected site population types in order to quench these issues i am assuming because the game only seems to care/emphasises about local site population for particular behaviors. (2 different 'population' (<- Animals) and 'populations' (<- Entities ->) 'population_id' doesn't appear to be efficient though adding the s to differentiate is logical) given that all the abnormal behavior consistently happens on sites where the player is present across adventure & fortress mode (particularly fortress mode's static location & malleable ethic combat engagement rules affected by the rule of the settling civ that somehow alters all the localised site behaviour)

Code: [Select]

    <struct-type type-name='local_population'>
<enum base-type='int8_t' name='type' type-name='world_population_type'/>

Again always feel free to point out if im wrong, it's troublesome to be sent back to the drawing board but i enjoy the input.

[Putnam]

enum items aren't "shared between" anything. df.world_population_type.Animal==0, that's literally all it is, it's more a code helper than something altogether meaningful, useful for forwards compatibility and compile checking but not actually something with special logic attached AFAIK.

I don't know why you seem to think that the emotion system is supposed to only apply to intelligent races. I don't think that was ever a stated goal. Emotions are not part of the [INTELLIGENT] or [CAN_LEARN] or [CAN_SPEAK] tokens, it's something all creatures without [NOEMOTION] will have.

[Roses]

Another thing I think you might be misunderstanding is that the code you have referenced is not DF code but is simply the structures that DFHack has access to and the names that have been given to them. Each of those structures represent a unique memory reference that can be accessed by DFHack. Some of those memory address expect an integer, some of those integers are expected to be 32 bit integers. That is all the int_32t is representing. And the only thing the enum items are doing is providing easier DFHack coding abilities. Reading the structures can be a bit daunting, but just remember that each entry in the structure is a unique memory address.

That aside, you seem to be saying that you don't want creatures without the [INTELLIGENT] flag to experience emotions, is that correct? Or do you simply not want them to experience certain emotions?

[FantasticDorf]

Another thing I think you might be misunderstanding is that the code you have referenced is not DF code but is simply the structures that DFHack has access to and the names that have been given to them. Each of those structures represent a unique memory reference that can be accessed by DFHack. Some of those memory address expect an integer, some of those integers are expected to be 32 bit integers. That is all the int_32t is representing. And the only thing the enum items are doing is providing easier DFHack coding abilities. Reading the structures can be a bit daunting, but just remember that each entry in the structure is a unique memory address.

That aside, you seem to be saying that you don't want creatures without the [INTELLIGENT] flag to experience emotions, is that correct? Or do you simply not want them to experience certain emotions?

Its anomalous (/badly implemented) behavior for the system, i understand that this is a memory repository for DFhack and imperfect to the final DF product (which dfhack draws and applies code from in order to get effects) but its as close to looking at the memory/code guts as we can get of the game.

The games memory seems to set out that it was accepted for release because it affected all intelligent creatures (to which the GUI was created for, that was a the intention) globally as intended but instead it affects every animal defined anyway despite how entity populations already exist alternatively. Therefore they would need to be seperated in order to keep the mind system (which keeps one aspect of animals learning skills etc as they are in df.unit.soul) and have animals properly execute behaviours (Intelligent large predators for example and other [large predator] stop being aggressive etc once exposed to these emotional changes.) because flags are phased out in favour of unit emotion or dont work together thanks to overlaps.

The mind system was a one size fits all for all units defined as animals in creature raws across the board against the flags designed to simulate behavior.

enum items aren't "shared between" anything. df.world_population_type.Animal==0, that's literally all it is, it's more a code helper than something altogether meaningful, useful for forwards compatibility and compile checking but not actually something with special logic attached AFAIK.

I don't know why you seem to think that the emotion system is supposed to only apply to intelligent races. I don't think that was ever a stated goal. Emotions are not part of the [INTELLIGENT] or [CAN_LEARN] or [CAN_SPEAK] tokens, it's something all creatures without [NOEMOTION] will have.

Having intelligent units with the GUI and UI created for them (health screen, thought screen, posession screen etc) with the thought and personality system was a goal for intelligent creatures by Toady, the rest of the animal kingdom wasn't initially defined or expanded on, so you could reasonably say it was initially a low level concern (at the moment its not game breaking but pretty instrumental to lots of bugs/petty grievances) or Toady simply wasn't aware about it.

Spoiler (click to show/hide)

Code: (df.map.xml#L555) [Select]

    <class-type type-name='feature' original-name='featurest'>
<stl-vector name='population' pointer-type='world_population'/>
Features are counted into world population as seen above, so all the creatures and world population type there.

Code: (df.entities.xml#L111) [Select]

        <static-array name='unit_counts' type-name='int16_t' count='152' index-enum='profession'/>
        <int16_t name='population'/>
        <int16_t/>
        <int16_t/>
        <int16_t/>
        <int16_t name='trained_animals'/>
        <int16_t name='other_animals'/>
        <int16_t/>
<int32_t/>
This above suggests that all other creatures (with the overlapping local site feature counting aswell counting up local non affiliated animals) is causing site population counting to be severely inflated in cases like elves (who have duality in having automatic exotic beasts), while all of the time making them the first targets of high megabeasts, and with so many sites across the world, invaders never turn up because they are too busy attacking the site with 20 wild moose on top of its existing citizens inflating the numbers so your fortress barely touching 120 people is small fry and they'll be busy elsewhere before you're even considered a target.

> Generate world, set a lot of megabeast/semi caves in custom params and beasts and no titans so there isn't cheating from forest titans, all elven settlements will be sacked within the first 10 years by hydra's etc because even with atrophically low starting numbers, the animals wild and free on site inflate those values, aboveground will be totally devoid of all animal life for the site x & y that it spans unless of course adventure mode causes units to path into those areas, nothing will already be within

Code: (df.world-data.xml#L60 & df.world.xml#L428) [Select]

<struct-type type-name='local_population'>
        <enum base-type='int8_t' name='type' type-name='world_population_type'/>

        <compound is-union='true'>
            <int16_t name="race" ref-target='creature_raw'/> //So generally all animals, given that in DF.unit animal is defined as creature=raw, though that is often applied as a reference value
            <int16_t name="plant" ref-target='plant_raw'/>
</compound>

...

        <stl-vector name='coin_batches' pointer-type='coin_batch'/>
<stl-vector name='populations' pointer-type='local_population'/>
Are inconsistently created because populations is already a name for entity population (there are a lot of alternative names and inconsistency in the structures in regards for keeping and defining seperate population names when they could respectably be filed into 1 easy to read type or intelligible alternative types rather than small grammatical scopes because they are easy to confuse and lose track of). Also the union draws upon everything listed with those values in int16_t.

Code: (df.entities.xml#L351) [Select]

        <stl-vector name='populations' type-name='int32_t' ref-target='entity_population'
comment='1st entry copies to unit.population_id for Adventurer?'/>
I suggest that you could instead do this.

Code: ( suggested amendment to WORLD.DATA.XML) [Select]

<enum-type type-name="world_population_type">
        <enum-item name='Animal'/>
        <enum-item name='Vermin'/>
        <enum-item name= Entity/> // Meaning that it becomes part of the worldtype set of intelligent creatures/settled site creatures
        <enum-item name='Unk2'/>
        <enum-item name='VerminInnumerable'/>
        <enum-item name='ColonyInsect'/>
        <enum-item name='Tree'/>
        <enum-item name='Grass'/>
        <enum-item name='Bush'/>
</enum-type>

...

<struct-type type-name='local_population'>
        <enum base-type='int8_t' name='type' type-name='world_population_type'/>

        <compound is-union='true'>
            <int16_t name="animal" ref-target='creature_raw'/>
            <int16_t name="plant" ref-target='plant_raw'/>
            <int16_t name ="entity" ref-target='entity_population'/>
</compound>
ref-target= entity_population down the line is fed animal creature raw, which then changes its state into entity population, simulating the [INTELLIGENT] flag and safeguarding against future issues with creatures in-game being 'uplifted' to higher intelligence status if such features like the myth generator required it, it would also allow the UI to more articulately and straightfoward identify populations and discriminate ethics if there wasn't a hitch against anything else.

And then have the 'race' as i describe before seperately feed into the entity, creating the population of intelligents, reading it back off the world data it would be animals, entity members & plants, and  because sentient life is generated alongside animals future settlements should hopefully work too rather than some kind of inconsistency, though i could be blatently wrong with my logic and in the existing format creatures would be regarded to be the same as entities.

[lethosor]

Reading the structures can be a bit daunting, but just remember that each entry in the structure is a unique memory address.

They're not unique, really. Most of them describe the layout of certain types of things in memory, and many instances of those things could exist. About the only "unique addresses" are the globals in symbols.xml.

Its anomalous (/badly implemented) behavior for the system, i understand that this is a memory repository for DFhack and imperfect to the final DF product (which dfhack draws and applies code from in order to get effects) but its as close to looking at the memory/code guts as we can get of the game.

Memory, sure, but it's hard to infer much about the code just by looking at the memory layout.

[Putnam]

Having intelligent units with the GUI and UI created for them (health screen, thought screen, posession screen etc) with the thought and personality system was a goal for intelligent creatures by Toady, the rest of the animal kingdom wasn't initially defined or expanded on, so you could reasonably say it was initially a low level concern (at the moment its not game breaking but pretty instrumental to lots of bugs/petty grievances) or Toady simply wasn't aware about it.

GUI does not dictate behavior. There are many, many, many cases in DF where stuff is happening that you have absolutely no way of seeing.

Spoiler (click to show/hide)

Code: (df.map.xml#L555) [Select]

    <class-type type-name='feature' original-name='featurest'>
<stl-vector name='population' pointer-type='world_population'/>
Features are counted into world population as seen above, so all the creatures and world population type there.

Code: (df.entities.xml#L111) [Select]

        <static-array name='unit_counts' type-name='int16_t' count='152' index-enum='profession'/>
        <int16_t name='population'/>
        <int16_t/>
        <int16_t/>
        <int16_t/>
        <int16_t name='trained_animals'/>
        <int16_t name='other_animals'/>
        <int16_t/>
<int32_t/>
This above suggests that all other creatures (with the overlapping local site feature counting aswell counting up local non affiliated animals) is causing site population counting to be severely inflated in cases like elves (who have duality in having automatic exotic beasts), while all of the time making them the first targets of high megabeasts, and with so many sites across the world, invaders never turn up because they are too busy attacking the site with 20 wild moose on top of its existing citizens inflating the numbers so your fortress barely touching 120 people is small fry and they'll be busy elsewhere before you're even considered a target.

> Generate world, set a lot of megabeast/semi caves in custom params and beasts and no titans so there isn't cheating from forest titans, all elven settlements will be sacked within the first 10 years by hydra's etc because even with atrophically low starting numbers, the animals wild and free on site inflate those values, aboveground will be totally devoid of all animal life for the site x & y that it spans unless of course adventure mode causes units to path into those areas, nothing will already be within

Code: (df.world-data.xml#L60 & df.world.xml#L428) [Select]

<struct-type type-name='local_population'>
        <enum base-type='int8_t' name='type' type-name='world_population_type'/>

        <compound is-union='true'>
            <int16_t name="race" ref-target='creature_raw'/> //So generally all animals, given that in DF.unit animal is defined as creature=raw, though that is often applied as a reference value
            <int16_t name="plant" ref-target='plant_raw'/>
</compound>

...

        <stl-vector name='coin_batches' pointer-type='coin_batch'/>
<stl-vector name='populations' pointer-type='local_population'/>
Are inconsistently created because populations is already a name for entity population (there are a lot of alternative names and inconsistency in the structures in regards for keeping and defining seperate population names when they could respectably be filed into 1 easy to read type or intelligible alternative types rather than small grammatical scopes because they are easy to confuse and lose track of). Also the union draws upon everything listed with those values in int16_t.

Code: (df.entities.xml#L351) [Select]

        <stl-vector name='populations' type-name='int32_t' ref-target='entity_population'
comment='1st entry copies to unit.population_id for Adventurer?'/>
I suggest that you could instead do this.

Code: ( suggested amendment to WORLD.DATA.XML) [Select]

<enum-type type-name="world_population_type">
        <enum-item name='Animal'/>
        <enum-item name='Vermin'/>
        <enum-item name= Entity/> // Meaning that it becomes part of the worldtype set of intelligent creatures/settled site creatures
        <enum-item name='Unk2'/>
        <enum-item name='VerminInnumerable'/>
        <enum-item name='ColonyInsect'/>
        <enum-item name='Tree'/>
        <enum-item name='Grass'/>
        <enum-item name='Bush'/>
</enum-type>

...

<struct-type type-name='local_population'>
        <enum base-type='int8_t' name='type' type-name='world_population_type'/>

        <compound is-union='true'>
            <int16_t name="animal" ref-target='creature_raw'/>
            <int16_t name="plant" ref-target='plant_raw'/>
            <int16_t name ="entity" ref-target='entity_population'/>
</compound>
ref-target= entity_population down the line is fed animal creature raw, which then changes its state into entity population, simulating the [INTELLIGENT] flag and safeguarding against future issues with creatures in-game being 'uplifted' to higher intelligence status if such features like the myth generator required it, it would also allow the UI to more articulately and straightfoward identify populations and discriminate ethics if there wasn't a hitch against anything else.

And then have the 'race' as i describe before seperately feed into the entity, creating the population of intelligents, reading it back off the world data it would be animals, entity members & plants, and  because sentient life is generated alongside animals future settlements should hopefully work too rather than some kind of inconsistency, though i could be blatently wrong with my logic and in the existing format creatures would be regarded to be the same as entities.

Feature means terrain feature, not game feature. Stuff like magma pools and lakes. Features are not "counted into world population". the most you can really say is that they're adjacent.

In fact... you're reading the XMLs completely wrong. A line ending with /> means that the next line is independent of that one.

Also, naming variables the same between two independent data structures does not cause any issues with code. Please try to understand basic scoping before making grand suggestions, it relieves a lot of frustration on every side.

And what we do with the structures XML has absolutely nothing to do with what the game itself does. It's descriptive, not prescriptive. Changing around structures will make DFHack wrong, not make DF right.

[Quietust]

Also keep in mind that some of the structures in the XML may be wrong - most of the names, whether type names (structs/classes), variable names (struct/class members), or value names (enum members), are our guesses, and some of those guesses are more accurate than others.

A very small number of things (such as all of the bits in unit_flags1 and unit_flags2) are named 100% accurately because Toady told us what they were named, and all classes that have virtual methods are also named accurately because they're visible within memory (via RTTI). Everything else is our best guess, and some of those guesses are already known to be wrong but we haven't gone back to change them because it'd be a pain (e.g. "timed_event" is almost definitely "world_event" based on the messages that appear during load/save, "manager_order" is likely "work_quota" for the same reason, and "ui" is probably "plot_info" based on an error message that never happens during gameplay but is visible in a disassembly).

[FantasticDorf]

Having intelligent units with the GUI and UI created for them (health screen, thought screen, posession screen etc) with the thought and personality system was a goal for intelligent creatures by Toady, the rest of the animal kingdom wasn't initially defined or expanded on, so you could reasonably say it was initially a low level concern (at the moment its not game breaking but pretty instrumental to lots of bugs/petty grievances) or Toady simply wasn't aware about it.

GUI does not dictate behavior. There are many, many, many cases in DF where stuff is happening that you have absolutely no way of seeing.

Feature means terrain feature, not game feature. Stuff like magma pools and lakes. Features are not "counted into world population". the most you can really say is that they're adjacent.

In fact... you're reading the XMLs completely wrong. A line ending with /> means that the next line is independent of that one.

Also, naming variables the same between two independent data structures does not cause any issues with code. Please try to understand basic scoping before making grand suggestions, it relieves a lot of frustration on every side.

And what we do with the structures XML has absolutely nothing to do with what the game itself does. It's descriptive, not prescriptive. Changing around structures will make DFHack wrong, not make DF right.

Describing the nature of the game and loosely interpreting and trying to make sense of it all is a good place to start, my own approach is to find a value and keep referencing where it eventually pools into in order to learn the relations it has. Shake the chain and see what rattles. In all cases even i'd agree my 'solution' is flimsy and non-practical but there's no harm in trying. In hindsight of your constructive criticism i won't be posting any more XML code here but i will keep looking through it privately for connections and read up a bit more about the C++ system, which i was doing anyway.

The GUI (game user interface when player are involved) or UI (menus etc) is what the player interfaces with, i am aware its a feature whether it's background or not, but toady in his initial release of the mind system he'd be working only only tailored it for the intended audiences of intelligent creatures that  benefited from it without making code to discriminate or only affect that class. Nothing was really mentioned about the fact since but bug reports like http://www.bay12games.com/dwarves/mantisbt/view.php?id=7369 started turning up regardless. There is a bug in our midst somewhere or some permeating issue.

I argue that animals & plants are 'map features' because they are referenced in population ID in relation to the biome sites they are represented in are part of features. You cannot generate a jungle map feature or a underground global feature without also having animals/plants relevant, and the population id reads off the features and its co-ordinate to find all the animals/plants within it as part of a background tally of existing units in the feature to the best of my applicative knowledge (feature defined jungle = jungle creatures & plants are put in = gets population numbers from raws and uses that)available for that site if they aren't in it already (plants being always present)

Also keep in mind that some of the structures in the XML may be wrong - most of the names, whether type names (structs/classes), variable names (struct/class members), or value names (enum members), are our guesses, and some of those guesses are more accurate than others.

A very small number of things (such as all of the bits in unit_flags1 and unit_flags2) are named 100% accurately because Toady told us what they were named, and all classes that have virtual methods are also named accurately because they're visible within memory (via RTTI). Everything else is our best guess, and some of those guesses are already known to be wrong but we haven't gone back to change them because it'd be a pain (e.g. "timed_event" is almost definitely "world_event" based on the messages that appear during load/save, "manager_order" is likely "work_quota" for the same reason, and "ui" is probably "plot_info" based on an error message that never happens during gameplay but is visible in a disassembly).

This is very true, and i have kept this in mind, and as i've mentioned before, its a imperfect community effort for DFhack but a generally trustworthy one for looking into. You could also take a pinch of salt in saying that some of the things that i've mentioned (like entity_population/various population references using atleast 3 different names for the same value/little inconsistency in proper identification) could be typos.

[Putnam]

They're not the same value. Why do you think they're the same value?

Also, intelligent creatures don't show emotions in dwarf mode unless they're citizens, not just intelligent, so the GUI argument sort of falls flat there, too.

Also, "where it pools into" isn't quite right; these structures are part of larger structures but that doesn't mean their behavior is inextricably linked with said larger structures. Just because unit.status.current_soul.emotions[0] is an emotion contained within unit doesn't mean that unit.animal.vanish_countdown is going to do anything to said emotion.