Problem with explicite statements in triggers and intermod compatibility

[Elimdur]

I just stumbled over an issue with my custon portrait species just not eating and after a little seach found this...

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
    }
}

This is a problem. As soon as you use two mods adding new species classes (which is another such problem as adding portraits to an existing species class leads to similar compatibility issues because of explicite statements of portraits belonging to the species class in the species_class entry rather than letting the portrait state to which species class it belongs in the portrait entry) which both have to overwrite the "is_organic_species" scripted trigger in order to be recognized as organic one of those mods loses.

Why does it not just check, if the species class has archetype = BIOLOGICAL ? This would not cause any such issues.

 

[Elimdur]

This is the problem I mentioned in species classes:

HUM = {
    archetype = BIOLOGICAL

    possible = { authority = { NOT = { value = auth_machine_intelligence text = SPECIES_CLASS_MUST_NOT_USE_MACHINE_INTELLIGENCE } } }

    portraits = {
        "human"
        "humanoid_02"
        "humanoid_03"
        "humanoid_04"
        "humanoid_05"
    }
    custom_portraits = {
        randomized = { host_has_dlc = "Humanoids Species Pack" }
        playable = { local_has_dlc = "Humanoids Species Pack" }
        portraits = {
            "humanoid_hp_01"
            "humanoid_hp_02"
            "humanoid_hp_06"
            "humanoid_hp_07"
            "humanoid_hp_08"
            "humanoid_hp_09"
            "humanoid_hp_10"
            "humanoid_hp_11"
            "humanoid_hp_12"
            "humanoid_hp_13"
        }
    }
    
    # These should not be used for randomly generated species
    non_randomized_portraits = {
        "human"
    }
    
    graphical_culture = humanoid_01
    move_pop_sound_effect = "moving_pop_confirmation"
}

As you see all portraits belonging to this species class are stated explicitely in this central place. Any mod adding a new portrait to this existing class would have to modify this species_class entry.

If you could declare in your portrait entry to which species class it should belong this problem wouldn't exist.

 

[Darrien]

This applies to districts, pop jobs because the job weight is in the job code instead of traits so trait mods will not be compatible with each other anymore without compatibility patches which are pain to deal with. The second issue applies to economic categories. If you add new ships if you want them to be able to use the base upkeep and other modifiers that are in vanilla techs you HAVE to overwrite the ships category. So they opened up more things but made intermod compatibility a lot worse.

 

[Elimdur]

Here is yet another place where this leads to problems:

district_city = {
    base_buildtime = 480
    is_capped_by_modifier = no
  
    show_on_uncolonized = {
        from = { is_regular_empire = yes }
        NOT = { is_planet_class = pc_habitat }
        NOT = { is_planet_class = pc_city }
    }
  
    potential = {
        exists = owner
        owner = { is_regular_empire = yes }
        NOT = { is_planet_class = pc_habitat }
        NOT = { is_planet_class = pc_city }
    }
  
    allow = {
        NOT = { has_modifier = resort_colony }
        NOT = { has_modifier = slave_colony }
    }
[...]

If you add a new colonizable planet class which should not use standard districts you are forced to overwrite vanilla entries which screws you over if another mod does the same because it also adds new planet classes.

So how could this problem be solved?

Instead of declaring in the district entry on which planet classes they are allowed, this should happen per planet class. If a planet class clearly states which districts are allowed on them under which circumstances there would be no compatibility issue.

 

[grommile]

Instead of declaring in the district entry on which planet classes they are allowed, this should happen per planet class. If a planet class clearly states which districts are allowed on them under which circumstances there would be no compatibility issue.

Until you want to install two different mods that both add new types of permitted district to the same planet class, at which point you have the same problem in reverse

 

[Elimdur]

Until you want to install two different mods that both add new types of permitted district to the same planet class, at which point you have the same problem in reverse

An alternative would be to add a statement to the district entry and the planet class.

Lets call it:

is_special_class = yes

in planet class entry

and

in the triggers for standard districts:

is_special_class = no

This way you could circumvent the hassle and be able to set up new districts without having to care for the rest.

Of course the same could be achieved using a scripted trigger, but then again that scripted trigger would have to state planet classes explicitely leading to the same problems.