is_triggered_only = yes broken in 2.1.2 beta?

[Zag14]

All who play in latest beta with mods, be careful! This issue can kill your SSD haha. In my last playthrough on 2.1.2 beta some mods that have events with string is_triggered_only = yes are bugged. In 2.1.1 there are no errors like this and everything ok. I have massive error.log spam with something like this:

Spoiler: Error.log

[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: modmenu.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: tcf.9
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: autobuild.200
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: autosurveyatstart.1
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMagCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMapsrCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMescCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMeutabCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMgpmCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMmemCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMutexpCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CoreGameMechanicsBuildings.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: modmenu.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: tcf.9
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: autobuild.200
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: autosurveyatstart.1
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMagCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMapsrCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMescCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMeutabCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMgpmCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMmemCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMutexpCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CoreGameMechanicsBuildings.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: modmenu.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: tcf.9
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: autobuild.200
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: autosurveyatstart.1
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMagCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMapsrCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMescCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMeutabCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMgpmCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMmemCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CGMutexpCompPatch.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: direct_build_CoreGameMechanicsBuildings.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: modmenu.2
[*][19:35:15][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: tcf.9

And size of my error log is about 20 GB now, that cause massive lags and make game completely unplayable with mods. Questions: am i the only one who suffer from this issue and maybe paradox just change something in is_triggered_only? Or it is bug and i should report it on bug forum?

 

[Zag14]

few examples with events that use fire_only_once
1. https://steamcommunity.com/sharedfiles/filedetails/?id=691008512&searchtext=autobuild
2. https://steamcommunity.com/sharedfiles/filedetails/?id=784249404&searchtext=auto+survey+at

Spoiler: Code

# set global flag
country_event = {
    id = autobuild.200
    hide_window = yes
    fire_only_once = yes

    immediate = {
        set_global_flag = autobuild_installed
    }
}

# for on game start
event = {
    id = autobuild.201
    hide_window = yes
    is_triggered_only = yes

    immediate = {
        set_global_flag = autobuild_installed
    }
}

namespace = autosurveyatstart

country_event = {
    id = autosurveyatstart.1
    hide_window = yes
    #is_triggered_only = yes
    fire_only_once = yes

    immediate = {
        every_country = {
            limit = {
                not = {
                    has_technology = tech_automated_exploration
                }
            }
            give_technology = { tech = tech_automated_exploration message = no }
        }
    }
}

country_event = {
    id = autosurveyatstart.2
    hide_window = yes
    is_triggered_only = yes

    immediate = {
        give_technology = { tech = tech_automated_exploration message = no }
    }
}

 

[Bankipriel]

Ugh. I really hope they didn't change their logic/scripting w/out telling the modding community ... again.

 

[The Founder]

The lack of logging is generally a bug, that needs to be fixed. Re-cheking those events propably cost relevant performance. That it only happens with mods indicates that there are proper counters in place for vanilla events. Mod events should also have those. The mod author needs to fix it.

Errors should be exposed so they can be fixed. This is baseline of proper programming, but something many beginners need to learn:
https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/
https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

This is not even a case for a vexing Exception. It is trivial to implement the same checks Paradox does for their code (usually a Global/Coutnry flag).

"Triggered only once" is evidently a fallback measure that was missused instead of a proper check.

TL;DR: It is the mods fault, not the game. If there was any fault of the game, it was not logging that before.

 

[Zag14]

The lack of logging is generally a bug, that needs to be fixed. Re-cheking those events propably cost relevant performance. That it only happens with mods indicates that there are proper counters in place for vanilla events. Mod events should also have those. The mod author needs to fix it.

Errors should be exposed so they can be fixed. This is baseline of proper programming, but something many beginners need to learn:
https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/
https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

This is not even a case for a vexing Exception. It is trivial to implement the same checks Paradox does for their code (usually a Global/Coutnry flag).

"Triggered only once" is evidently a fallback measure that was missused instead of a proper check.

TL;DR: It is the mods fault, not the game. If there was any fault of the game, it was not logging that before.

Strange, but as i already told, there are no such errors in previous version. Anyway, thank you for explanation

 

[The Founder]

Strange, but as i already told, there are no such errors in previous version. Anyway, thank you for explanetion

It should definitely have been in the Change Log. As this was clear a fix of a bug.

 

[ExNihil]

The lack of logging is generally a bug, that needs to be fixed. Re-cheking those events propably cost relevant performance. That it only happens with mods indicates that there are proper counters in place for vanilla events. Mod events should also have those. The mod author needs to fix it.

Errors should be exposed so they can be fixed. This is baseline of proper programming, but something many beginners need to learn:
https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/
https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

This is not even a case for a vexing Exception. It is trivial to implement the same checks Paradox does for their code (usually a Global/Coutnry flag).

"Triggered only once" is evidently a fallback measure that was missused instead of a proper check.

TL;DR: It is the mods fault, not the game. If there was any fault of the game, it was not logging that before.

Wot?

is_triggered_only is not 'misused'. What OP reports is a serious bug.

 

[Caligula Caesar]

I think this probably has nothing to do with is_triggered_only and everything to do with using fire_only_once in a way that makes it try to fire the event every day for every scope only for the game to find it has already happened, which is not too clever for performance and something I would not advocate, but otherwise not a bug.

Actually, there is the case to be made that this appearing in the error log is a bug, since fire_only_once is meant to stop an event firing twice rather than be a marker for events with conditions that make them impossible to fire twice. If one wants to call people out on performance, it would be trivial to make the error log demand an event has either mtth or is_triggered_only (Dayshine does) instead of creating error log spam...

 

[ExNihil]

This seems to be a fire only once issue - why it attempts to readd the events to the array? This is a serious issue.

 

[Zag14]

Plz someone write about this issue in bugreport, im not best in modding and in english

 

[Dayshine]

Just a quick minimum repro:

Spoiler: Code

namespace = test
event = {
    id = test.1
        title = test1
    desc = "test2"
    hide_window = yes
    is_triggered_only = yes

    immediate = {
        country_event = { id = test.2 }
    }
}

country_event = {
    id = test.2
    is_triggered_only = yes
    fire_only_once = yes
    immediate = {
        log = "fired"
    }
}

gives the following log when `event = test.1` is run four times from the console.

[08:14:55][eventwindow.cpp:202]: Triggered Event test.2 has no valid options!
[08:14:58][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: test.2
[08:14:59][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: test.2
[08:15:00][eventmanager.cpp:505]: Attempting to fire OnlyOnce event a second time: test.2

Which is fine, except for the fact that logging is a very performance heavy operation. I'm not sure repeatedly logging the same error adds any real benefit. It does however have the serious drawback of tanking performance far more than the cost of the underlying script error!

Bug report: https://forum.paradoxplaza.com/forum/index.php?threads/stellaris-stellaris-2-1-2-46fa.1108110/

 

[ViolentBeetle]

Why even have this error? I mean, you have a parameter explicitly set to prevent events firing no matter what, yet log it as an error?

Might as well start logging "event is called, but trigger failed" while you are at it. Surely someone only add trigger block and then calls the event by mistake.

 

[LordMune]

I checked in with our tech lead and posted in the bug report thread linked above.

 

[Gratak]

The lack of logging is generally a bug, that needs to be fixed. Re-cheking those events propably cost relevant performance. That it only happens with mods indicates that there are proper counters in place for vanilla events. Mod events should also have those. The mod author needs to fix it.

Errors should be exposed so they can be fixed. This is baseline of proper programming, but something many beginners need to learn:
https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/
https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET

This is not even a case for a vexing Exception. It is trivial to implement the same checks Paradox does for their code (usually a Global/Coutnry flag).

"Triggered only once" is evidently a fallback measure that was missused instead of a proper check.

TL;DR: It is the mods fault, not the game. If there was any fault of the game, it was not logging that before.

This is plain and simply wrong! "fire_only_once" is a thing that is also used in the base game files quite a lot. And it is not only the log that has been added. Mods that work in the release version suddenly break at strange places in the beta.

 

[AlphaAsh]

It should definitely have been in the Change Log. As this was clear a fix of a bug.

So vanilla events that don't have the imaginary restrictions you imagined are supposed to generate massive error logs? I'm clearly doing this modding thing wrong. Thanks for clearing that up.

 

[Walshicus]

Why even have this error? I mean, you have a parameter explicitly set to prevent events firing no matter what, yet log it as an error?

Might as well start logging "event is called, but trigger failed" while you are at it. Surely someone only add trigger block and then calls the event by mistake.

Kind of agree.

While we *can* set flags to prevent multiple firings... I really don't think it's inappropriate to use established features to shorten this process down. Which is what fire_only_once does or should do.

 

[Gratak]

Kind of agree.

While we *can* set flags to prevent multiple firings... I really don't think it's inappropriate to use established features to shorten this process down. Which is what fire_only_once does or should do.

Execution

By default every event has all its triggers checked against every game object at least once per game day, possibly once per game tick. For the objects where the triggers are all met, the code of the event is executed with the scope of said object.

The setting is_triggered_only = yes will excempt the event from this persistent polling.

Similarily works fire_only_once = yes. However unlike is_triggered_only the code will still be polled, only to be removed after it was executed at least once.

There is nothing written in the wiki about stopping the event from being called directly, just stopping it from being called via MTTH. Though in the beta MTTH does call those events and leads to the worst error spams

Btw: Link to bug report with unsatisfying reply:
https://forum.paradoxplaza.com/forum/index.php?threads/stellaris-stellaris-2-1-2-46fa.1108110/

 

[The Founder]

Wot?

is_triggered_only is not 'misused'. What OP reports is a serious bug.

Is it?
Do you have word of the devs that "is_triggerd_only_once" is supposed to be the first thing to prevent re-triggering?
Or that it is supposed to be a fallback?

Considering that 0 of the vanilla code seems to run into this, it would seem the position as a failsafe is clear.

Which is fine, except for the fact that logging is a very performance heavy operation. I'm not sure repeatedly logging the same error adds any real benefit. It does however have the serious drawback of tanking performance far more than the cost of the underlying script error!

Let us see the options:
a) Run into performance issues because people keep making a mistake for the entire remaining lifetime of the game.
b) Loosing a bit of speed for one itteration of the game. Until the mods are fixed. With a bit of luck, maybe even before this patch even goes life (because that is still a beta).

I can not undertand why you would prefer a) at any point or in any situatiuon bar the end of the games support

This is plain and simply wrong! "fire_only_once" is a thing that is also used in the base game files quite a lot. And it is not only the log that has been added. Mods that work in the release version suddenly break at strange places in the beta.

None of the basegame scripts run into the issue. So apparently this is a case of boneheaded exceptions - once you could avoid using the same magic the devs do:
"Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. You should not catch them; doing so is hiding a bug in your code. Rather, you should write your code so that the exception cannot possibly happen in the first place, and therefore does not need to be caught. That argument is null, that typecast is bad, that index is out of range, you're trying to divide by zero – these are all problems that you could have prevented very easily in the first place, so prevent the mess in the first place rather than trying to clean it up."

One you should have been avoiding this whole time, using the magic the devs use. One you now finally know to avoid, thanks to proper logging.

 

[AlphaAsh]

"Don't fix something that ain't broken."
The performance hit of checking fire_only_once every tick is far lower than checking fire_only_once and puking redundancy into error.log every tick.

The so-called "poor coding" of modders "mis-using" a so-called fallback is not bogging the game down. Fallbacks are there to get hit, repeatedly. Good error-handling is as silent as possible and doesn't generate 20 Gb logs.

edit - And I'd expect fire_only_once being checked every tick, rather than some soft-coded flag, would be less performance intensive. Not every event is useful in a month/year pulse. Modders should expect to be able to event in 'real-time' and rely on these fallbacks to help with performance. That's what they're for.

 

[Gratak]

Is it?
Do you have word of the devs that "is_triggerd_only_once" is supposed to be the first thing to prevent re-triggering?
Or that it is supposed to be a fallback?

Considering that 0 of the vanilla code seems to run into this, it would seem the position as a failsafe is clear.


Let us see the options:
a) Run into performance issues because people keep making a mistake for the entire remaining lifetime of the game.
b) Loosing a bit of speed for one itteration of the game. Until the mods are fixed. With a bit of luck, maybe even before this patch even goes life (because that is still a beta).

I can not undertand why you would prefer a) at any point or in any situatiuon bar the end of the games support


None of the basegame scripts run into the issue. So apparently this is a case of boneheaded exceptions - once you could avoid using the same magic the devs do:
"Boneheaded exceptions are your own darn fault, you could have prevented them and therefore they are bugs in your code. You should not catch them; doing so is hiding a bug in your code. Rather, you should write your code so that the exception cannot possibly happen in the first place, and therefore does not need to be caught. That argument is null, that typecast is bad, that index is out of range, you're trying to divide by zero – these are all problems that you could have prevented very easily in the first place, so prevent the mess in the first place rather than trying to clean it up."

One you should have been avoiding this whole time, using the magic the devs use. One you now finally know to avoid, thanks to proper logging.

# Vanguard Arrives (HIDDEN)
country_event = {
    id = crisis.17
    hide_window = yes
    fire_only_once = yes
   
    mean_time_to_happen = {
        months = 30
    }
   
    trigger = {
        has_global_flag = prethoryn_transmission
    }

"prethoryn_transmission" is never removed anywhere in the code (at least not in the release version, to lazy to switch to beta now).

(found at least two more but stopped searching. The only reason mods have the major problems is that they use such events with zero MTTH for modding reasons.)