Originally posted by The Engineer Pop:

Does remove_district = district_mining not mean removing 1 mining district at the beginning of the game?

Effects have to be invoked somewhere in order to do something. A common place to do that is through the initializer:

It can also be done through game_start events, which are invoked in the on_action folder. I'm pretty sure that there's an on_game_start event that goes through and adds starting configurations to empire homeworlds. Events can also invoke effects:

So, I'd suggest you take a close look at the initializer and the game_start events (events are stored in the root folder at the same level as "common" ) to verify that there's not some other operation adding the district back after you've removed it.

No. *The same code* gives 1 agricultural district and doesn't remove 1 mining district. If you're right 1 agricultural district shouldn't be given too.

Originally posted by The Engineer Pop:

No. *The same code* gives 1 agricultural district and doesn't remove 1 mining district. If you're right 1 agricultural district shouldn't be given too.

OK. The place where you are making your changes - to scripted_effects - is not a space where self-executing code is stored. What I'm saying is that it's not clear to me from the presentation of your problem that you are controlling adequately for what other effects might be operating on the same object.

The answer to your initial question is that yes, "remove_district = district_mining" removes a mining district. You can test it for yourself in the live environment through the console by typing "effect = { remove_district = district_mining }" while you have the planet selected (so that it will be in scope).

If you're not aware of it, the error.txt file in the "documents\paradox interactive\stellaris\logs" folder provides very granular details on everything that fails on launch and pretty good descriptions of why it fails. If your function is failing that would also be a good way to hunt down why it is failing.

The precise definitions of the conditionals that you are invoking - "is_individual_machine" and "is_lithoid_empire" can both be found in "common/scripted_triggers/00_scripted_triggers.txt" so that can also be a place to check if you're not seeing a function fire on occasions where you expect it to.

Originally posted by Geoff:

Originally posted by The Engineer Pop:

No. *The same code* gives 1 agricultural district and doesn't remove 1 mining district. If you're right 1 agricultural district shouldn't be given too.

OK. The place where you are making your changes - to scripted_effects - is not a space where self-executing code is stored. What I'm saying is that it's not clear to me from the presentation of your problem that you are controlling adequately for what other effects might be operating on the same object.

The answer to your initial question is that yes, "remove_district = district_mining" removes a mining district. You can test it for yourself in the live environment through the console by typing "effect = { remove_district = district_mining }" while you have the planet selected (so that it will be in scope).

If you're not aware of it, the error.txt file in the "documents\paradox interactive\stellaris\logs" folder provides very granular details on everything that fails on launch and pretty good descriptions of why it fails. If your function is failing that would also be a good way to hunt down why it is failing.

The precise definitions of the conditionals that you are invoking - "is_individual_machine" and "is_lithoid_empire" can both be found in "common/scripted_triggers/00_scripted_triggers.txt" so that can also be a place to check if you're not seeing a function fire on occasions where you expect it to.

Thanks. In logs folder there are plenty of logs which are logged when I turn on the game.

Solved by myself. I put that code too forward of the code file to be appropriately executed.

Originally posted by The Engineer Pop:

Thanks. In logs folder there are plenty of logs which are logged when I turn on the game.

Error.txt is the log that's been indispensable for me. There's one you can write to from the scripts, but for things like running down routine typing errors, the error log is where it's at. I'm glad you found the issue.