General enlightenments:

• using @prev or @scope at the end of an event_target, or var, will substitute the game's ID for that object

HOWEVER!!!

localisation does not like event_target:[email protected] but it will do event_target:some_leader_@root_0.some_variable

---

From the Den

Gladry — 06/09/2024 9:15 PM don't forget optimize_memory

TTFTCUTS (Gigastructures) — 06/09/2024 9:18 PM well it's a script value not a scripted_trigger or effect, so I don't think that's even usable there, but that's for very large effects or ones used at many different places, so they're only kept in one place in memory to reduce their impact on overall memory footprint at the cost of ruining error log entries about their contents (can't list the right line in script any more)

---

Shoobers — 06/04/2024 8:49 AM Yeah, you REALLY want to have a good grasp of math if you are going to work with factors. The main takeaway is that 1.0 doesn't mean yes. All factors are ratios. If you have factor 20, it means they're 20x more likely to say yes than a 1, only providing there is a 1 factor in there. If you have it set up as 20 100 and 5, it's 20/125, 100/125, and 5/125 chance As for mtth factors, ALL factors that can affect the outcome are always applied multiplicatively Have 20 .75s? Your mtth is quartered 20 times. So 5000 quartered 20 times ends up as 16ish, not a negative value or clamped at 0 or 1

---

---

Gladry — Today at 1:29 PM Im great at inlines, not in TTFT's class, but better than many. If I were to make 5, I would, yes, use inlines for it I would prefer not to do it that way if possible. here is, for example, on of my buildings current inlines.

inline_script = {
    script    = iscience_dcp 

    tier    = "two"
    reqtech = "tech_that_science"
    conversions = "        "

    POPS    = 2.5    # multiply x regular jobs * 1.25
    RSRC0    = "sr_dark_matter"
    RSRC1    = "exotic_gases"
    NRG    = 2.5 #multiplication factor for energy/minerals
}

I find multiple versions of everything....inelegant.

resources = {
    category = planet_districts$type$
    upkeep = {
        $rsrc0$     = @[ $kbase$ ]
        $rsrc1$     = @[ $kbase$ * 0.7) ]
        $strat$     = @[ $kbase$ * 0.5 ]
        energy     = @[ $kbase$ * $nrg$) ]
    }
    cost = {
        trigger = { always = yes }
        $rsrc0$     = @[ $pcost$ * $pops$ ]
        $rsrc1$     = @[ $pcost$ * $pops$ * 0.75 ]
        $strat$     = @[ $pcost$ * $pops$ * 0.50 ]
        minerals = @[ $pcost$ * $pops$ * 0.90 * $nrg$ ]
        energy     = @[ $pcost$ * $pops$ * $nrg$*3 ]
        $factors$ 
    }

---

---

---

https://discord.com/channels/378985949373399040/379554282204168193/1253245274785185843

---

https://discord.com/channels/378985949373399040/499742235949006868/1226512106417950791

---

About overwrites

MingCR wrote: https://discord.com/channels/378985949373399040/379554282204168193/1248393698916565043

for example lets say the trigger you wanna check just checks for a specific planet class. lets say a desert planet

some_modded_trigger = { is_planet_class = pc_desert }

then you make a trigger like this with the same name in a file that starts with "!!!!!_" (scripted triggers are lios, so this will probably get loaded before what youre checking and therefore will get overwritten)

some_modded_trigger = { always = no }

then you spawn in a desert planet and check the trigger on it (you can delete the planet afterwards). the return value of the trigger is equivalent to whether or not it exists. can be expanded to arbitraily complex situations, you just need to make sure that

• your filename has more ! at the beginning than theirs
• youre checking the trigger on a scope that you know the return value of and have made your trigger return the exact opposite

---

About organizing mod files and scripted effects

https://discord.com/channels/378985949373399040/379554282204168193/1270093116304658464

MingCR — Today at 2:56 PM thats why, for my bigger projects, i often set up folder structures with triggers and effects put into folders with a scope name. and then i make sure to only ever use stuff from the correct folder. if im in a species scope eg, i only do

#include "shared_effects/species/do_something.txt"

even if stuff from other scopes would work. if something works across scopes, i always explicitely copy it and dont make any assumptions. so in files like shared_effects/pop/so_something.txt id put

#include "../species/do_something.txt"

but id never assume any multi-scope compatibility without explicitely having it in the internal structure, id never include species/ txts inside a pop scope directly. then oopsies like that can litearally never happen. i cant believe my modding environment is more organized than the literal game itself