Pop Upkeep/Custom Species

[White Warg]

I've been helping a mod developer update their mod to 2.2, but we've hit a brick wall. For some reason Paradox has added an additional check to species class.

is_organic_species = {
OR = {
is_species_class = HUM
is_species_class = MAM
is_species_class = REP
is_species_class = AVI
is_species_class = ART
is_species_class = MOL
is_species_class = FUN
is_species_class = PLANT
}
}

is_robotic_species = {
OR = {
is_species_class = ROBOT
is_species_class = MACHINE
}
}

From the scripted_triggers_jobs file. These lists are used to determine upkeep, all that. Now, due to the issues with adding a new species directly to existing categories...custom species don't get upkeep applied to them. My attempts to fix this-creating a custom script_trigger_jobs file for the mod have failed, as it appears no matter the file name, a hard override is applied to the vanilla file.

Effectively, you'd need to copy this list over to the mod, then add in the custom species category, for things to function.

A hard override is undesirable, considering the mod needs to be as compatible as possible. Is there any solution I'm missing?

 

[Princess Stabbity]

Tested and confirmed just now.



This seems to be the exact same issue that traits used to have when Synthetic Dawn was first released.

And in order to fix that and avoid this issue in the future, species archetypes (BIOLOGICAL, MACHINE, etc) were introduced...

These triggers should be querying not species_class explicitly, but species_archetype (while, of course, respecting archetype inheritance, which is also an existing functionality not used here.)

This mistake should not have happened again.

Speaking of which, species_archetype (accounting for inherited archetypes) should be available in event triggers. Perhaps it would be a good idea to make it useable in events so that this problem doesn't repeat for the third time?

 

[NFactor]

Still happens in 2.2.1. Just tested it myself.

This problem renders any custom species mod useless.

Vanilla race:

Custom:

OUCH.

 

[NFactor]

Similarly with resources in 2.2.1.

Vanilla:

ANY custom species:

OUCHIES.

 

[HandicapdHippo]

Have you actually reported this in the bug reports forum? Your title of this thread doesn't really draw attention to the fact this is a major issue

Edit: just gone and reported it

 

[Etiluos]

yup totally messes with my many species mods I made, well time to wait it out or never mod again.

 

[Guraan]

Okey guys, i think this is solvable ATM, i just do not get discord running so i can get it explained O
post or pmsg me the script will you?

 

[Princess Stabbity]

Okey guys, i think this is solvable ATM, i just do not get discord running so i can get it explained O
post or pmsg me the script will you?

The script is 01_scripted_triggers_jobs, these two bits are responsible for the issue:

is_organic_species = {
    OR = {
        is_species_class = HUM
        is_species_class = MAM
        is_species_class = REP
        is_species_class = AVI
        is_species_class = ART
        is_species_class = MOL
        is_species_class = FUN
        is_species_class = PLANT
    }
}

is_robotic_species = {
    OR = {
        is_species_class = ROBOT
        is_species_class = MACHINE
    }
}

They're referencing vanilla species_classes explicitly, meaning that modded species_classes (which is pretty much all of the custom species out there since we also can't add new species to existing classes in a clean cross-compatible way) are not considered either organic or robotic unless they're added there... which given that there's hundreds of them, is not feasible and would absolutely murder anyone who would attempt to maintain a unified compatibility patch.

Back around Synthetic Dawn, we had the same issue with traits. To resolve that and avoid the same problem in the future (hello! future here! n_n) Wiz implemented species_archetypes and archetype inheritance.

Ideally, I would love if the archetype system could be reused here since it's worked perfectly so far.

 

[Guraan]

The script is 01_scripted_triggers_jobs, these two bits are responsible for the issue:

is_organic_species = {
    OR = {
        is_species_class = HUM
        is_species_class = MAM
        is_species_class = REP
        is_species_class = AVI
        is_species_class = ART
        is_species_class = MOL
        is_species_class = FUN
        is_species_class = PLANT
    }
}

is_robotic_species = {
    OR = {
        is_species_class = ROBOT
        is_species_class = MACHINE
    }
}

They're referencing vanilla species_classes explicitly, meaning that modded species_classes (which is pretty much all of the custom species out there since we also can't add new species to existing classes in a clean cross-compatible way) are not considered either organic or robotic unless they're added there... which given that there's hundreds of them, is not feasible and would absolutely murder anyone who would attempt to maintain a unified compatibility patch.

Back around Synthetic Dawn, we had the same issue with traits. To resolve that and avoid the same problem in the future (hello! future here! n_n) Wiz implemented species_archetypes and archetype inheritance.

Ideally, I would love if the archetype system could be reused here since it's worked perfectly so far.

Yeah that part i understood, and i never meddle with how our CD/GC:s has scripted stuff, will ofc bring the issue to them... but what i meant was, if you explain what you want right now and how your current script looks i might be able to help

 

[RoverStorm]

Yeah that part i understood, and i never meddle with how our CD/GC:s has scripted stuff, will ofc bring the issue to them... but what i meant was, if you explain what you want right now and how your current script looks i might be able to help

I think what they want is for upkeep to check if the pop's archetype is considered BIOLOGICAL or MECHANICAL, rather than it's class like HUM or MAM etc. Similar to how species traits are imported based on if the custom species is flagged BIOLOGICAL or MECHANICAL, which a modded species includes in it's archetype but doesn't require over-riding any core code at all.

But if I'm wrong I'll let them speak for themselves. This would be helpful to me as well.

 

[Princess Stabbity]

Yeah that part i understood, and i never meddle with how our CD/GC:s has scripted stuff, will ofc bring the issue to them... but what i meant was, if you explain what you want right now and how your current script looks i might be able to help

What RoverStorm said. The objective is for the is_organic_species and is_robotic_species checks to be able to recognise custom species without modders having to modify the vanilla 01_scripted_triggers_jobs file (or fight over any vanilla files for that matter).

I'm not sure what you're asking in terms of "my script". All custom species_classes that exist are currently not recognised by the vanilla organic and robotic checks, which means they don't get pop upkeep. There is no way for custom species_classes to get around this issue (overriding the vanilla script on our end is not a sustainable solution) since the aforementioned triggers responsible for it simply do not account for the existence of custom species_classes.

In case there is a misunderstanding: we don't need help with our code, we need a bugfix from Paradox.

 

[Guraan]

Ah, yeah i totally missunderstood! Sorry for the confusion guys

 

[Etiluos]

I been suggested this mod which uses the permanent traits of the game and goes around it pretty well. Upkeep fix for mod species

its code goes something like this. No adding other species needed.

is_organic_species = {
    OR = {
        has_trait = trait_pc_desert_preference
        has_trait = trait_pc_arid_preference
        has_trait = trait_pc_savannah_preference
        has_trait = trait_pc_tropical_preference
        has_trait = trait_pc_continental_preference
        has_trait = trait_pc_ocean_preference
        has_trait = trait_pc_arctic_preference
        has_trait = trait_pc_tundra_preference
        has_trait = trait_pc_alpine_preference
        has_trait = trait_pc_ai_preference
        has_trait = trait_pc_nuked_preference
        has_trait = trait_pc_gaia_preference
        has_trait = trait_pc_ringworld_habitable_preference
        has_trait = trait_pc_habitat_preference
        has_trait = trait_pc_machine_preference
        has_trait = trait_pc_hive_preference
        has_trait = trait_pc_city_preference
    }
}

is_robotic_species = {
    OR = {
        has_trait = trait_machine_unit
        has_trait = trait_mechanical
    }
}

 

[Princess Stabbity]

Why would it list all those habitability traits? It seems redundant and unnecessarily excludes custom planet_classes.

It could be streamlined into this:

is_organic_species = {
    NOR = {
        has_trait = trait_machine_unit
        has_trait = trait_mechanical
    }
}

is_robotic_species = {
    OR = {
        has_trait = trait_machine_unit
        has_trait = trait_mechanical
    }
}

Since there is never a situation in which a biological pop would have one of those traits (they are both restricted to the robotic archetype).

In any case, it's a temporary bandaid and should not be considered problem solved. I hope that either this solution or the one I proposed earlier that directly utilises the ROBOTIC and BIOLOGICAL species_archetypes makes it directly into the game, hopefully before Christmas. Basic species mods should work out of the box and not have to rely on a third party mod.

I truly apologise for sounding like a broken record by this point but I cannot stress enough how critical it is for this issue to be resolved by Paradox on the game's own end n_n

 

[Guraan]

hmmm so the CD:s are discussing the issue atm, i as coder are thinking of an addition to how our databases are treating scripts.
This is just hypothetical atm and i have not yet had time to think out some issues how to achieve proper error reporting nor reloading of dbs:
Vanilla:

my_db_object = { ... }

File loaded externally:

my_db_object : overwrite  = { ... } #Clears the object to default before reading it, gives error if no object to overwrite exists
my_db_object : override  = { ... } #Does not clear the object before reading so if the data is appended or overwritten is up to that atribute, gives error if no object to override exists
my_db_object = { ... } #Gives error, already exists.

Any spontaneous feedback?

 

[Princess Stabbity]

If I'm understanding correctly, "override" would allow for partial injections to existing scripts by multiple external sources? If possible, it would certainly be helpful - in fact, revolutionary! n_n That would not only solve issues like this for good but improve event-modding QoL across the board.

So using the existing issue as an example, would:

vanilla file

is_organic_species = {
    OR = {
        is_species_class = HUM
        is_species_class = MAM
        is_species_class = REP
        is_species_class = AVI
        is_species_class = ART
        is_species_class = MOL
        is_species_class = FUN
        is_species_class = PLANT
    }
}

+ mod A

is_organic_species = {
    override = {
        OR = {
            is_species_class = MODA
        }
    }
}

+ mod B

is_organic_species = {
    override = {
        OR = {
            is_species_class = MODB
        }
    }
}

= result in:

is_organic_species = {
    OR = {
        is_species_class = HUM
        is_species_class = MAM
        is_species_class = REP
        is_species_class = AVI
        is_species_class = ART
        is_species_class = MOL
        is_species_class = FUN
        is_species_class = PLANT
        is_species_class = MODA
        is_species_class = MODB
    }
}

?

 

[Guraan]

Yep exactly (syntax will prob be closer to my pseudocode because of our parser), but this is just in my mind right now and nothing we currently are doing O
Let me get back to you guys regarding the override/overwrite after new years since i am kinda crammed right now with performance improvements O
But all suggestions/feedback is appreciated, i would hate developing a modding feature without feedback from modders O

 

[Princess Stabbity]

Thank you! <3

This would definitely prevent this kind of issue from reoccuring in the long term, so I'm all for it! I hope it turns out to be doable n_n

But we would still appreciate some kind of fix on content level before Christmas, perhaps even a brute-force one like changing the original code to this:

is_organic_species = {
    NOR = {
        has_trait = trait_machine_unit
        has_trait = trait_mechanical
    }
}

is_robotic_species = {
    OR = {
        has_trait = trait_machine_unit
        has_trait = trait_mechanical
    }
}

Just to make custom species nominally functional as soon as possible until a more permanent fix can be implemented. Our users are already... being passionate about it. I'm not looking forward to dealing with torches and pitchforks over the holiday break n_~

 

[HandicapdHippo]

Yep exactly (syntax will prob be closer to my pseudocode because of our parser), but this is just in my mind right now and nothing we currently are doing O
Let me get back to you guys regarding the override/overwrite after new years since i am kinda crammed right now with performance improvements O
But all suggestions/feedback is appreciated, i would hate developing a modding feature without feedback from modders O

The overwrite method certainly sounds awesome, though as you says its just spitballing. Princesses Stabbity's suggestion is certainly workable as a stopgap, a smaller proper fix than developing a whole new override would be to extend the archetypes system. Currently traits have the following

allowed_archetypes = { BIOLOGICAL }

A similar trigger could likely be extended off this

is_organic_species = {
   archetype = BIOLOGICAL
}

is_robotic_species = { 
       OR = {
             archetype = ROBOT
             archetype = MACHINE
       }
}

 

[Guraan]

The overwrite method certainly sounds awesome, though as you says its just spitballing.

Well overwrite you have has it is right now, thats is the default method we are using for db:s. (and also this problem)

Princesses Stabbity's suggestion is certainly workable as a stopgap, a smaller proper fix than developing a whole new override would be to extend the archetypes system.

First off;
The CD:s are fixing/conjuring a fix for this as fast as possible so i think that one will be about within a week or two (will not effect this suggestion whatsoever)
Second:
This is not a new system, just a small addon that will have limited usability but something to expand on, lines of code would be less than 100, proper error reporting excluded O