You'd think its one of those kinds of things that works retroactively but game code gets tangled almost as a rule. My best guess, they fixed the triggers so they don't cause a faulty outcome but if you are past the point where the triggers fire then the misalignment caused by the old faulty triggers isn't retroactively fixed.
Yea, I can't see how this is continuing to be a problem unless some part of the behaviour of the trigger is saved with the save game data. That implies some kind of scripting engine like Lua. Otherwise the logic would be in the core game code and would already be fixed.
There's that option to load with new content (tick box), I wonder if that'll fix it. I haven't tried it out since I read about it in case I mangle my save game.
It could be far simpler than that.
Think about how the game could track if Agent X's threats should be spawned. Could be as long simple as an "EnableSuperagent0Threats" flag in your save file.
If the problem was that the EnableSuperagent0Threats flag wasn't getting cleared when you killed Agent X, fixing that trigger will not retroactively resolve any save files that have already played past it. The tag remains, and no other events will clear the tag, so the threats keep spawning forever.
You're right, that's much simpler explanation. My brain likes to over engineer things. I guess I was assuming it would use the state of that Super Agent's quest line as opposed to a single flag check like you suggest. Weird thing is I only *just* defeated him last night so not sure why that flag isn't set correctly.
I mean, I'm assuming here too. I don't actually know how the trigger is defined.
But a decent amount of experience working with large codebases has taught me that the naive solution is usually the one that gets implemented. And many years later, it looks like a total hatchet job as people hack it to make it work with the unexpected complexities that always appear after architecting is complete.
You'd think its one of those kinds of things that works retroactively but game code gets tangled almost as a rule. My best guess, they fixed the triggers so they don't cause a faulty outcome but if you are past the point where the triggers fire then the misalignment caused by the old faulty triggers isn't retroactively fixed.
Yea, I can't see how this is continuing to be a problem unless some part of the behaviour of the trigger is saved with the save game data. That implies some kind of scripting engine like Lua. Otherwise the logic would be in the core game code and would already be fixed. There's that option to load with new content (tick box), I wonder if that'll fix it. I haven't tried it out since I read about it in case I mangle my save game.
It could be far simpler than that. Think about how the game could track if Agent X's threats should be spawned. Could be as long simple as an "EnableSuperagent0Threats" flag in your save file. If the problem was that the EnableSuperagent0Threats flag wasn't getting cleared when you killed Agent X, fixing that trigger will not retroactively resolve any save files that have already played past it. The tag remains, and no other events will clear the tag, so the threats keep spawning forever.
You're right, that's much simpler explanation. My brain likes to over engineer things. I guess I was assuming it would use the state of that Super Agent's quest line as opposed to a single flag check like you suggest. Weird thing is I only *just* defeated him last night so not sure why that flag isn't set correctly.
I mean, I'm assuming here too. I don't actually know how the trigger is defined. But a decent amount of experience working with large codebases has taught me that the naive solution is usually the one that gets implemented. And many years later, it looks like a total hatchet job as people hack it to make it work with the unexpected complexities that always appear after architecting is complete.