[1.1.0] Main menu background simulation doesn't run mods' control.lua but runs lua migrations

[theRustyKnife]

I'd say the simulation should either run control.lua and then lua migrations the same way the game does normally, or just don't run anything at all. Not sure which is the correct approach but I'd be fine with either - as long as it doesn't require having two separate branches of logic for main menu simulation and the main game

edit: grammar

[Rseding91]

I've changed it so migrations don't run in simulations for the next release. It seems intended that normal control.lua doesn't run (there's an explicit if condition) so this just makes it consistent.

[eradicator]

It seems intended that normal control.lua doesn't run

So basically script-controlled buildings will never work in simulations? If i understand correctly that also means tutorial tips won't work either?

For example my Stockpiles mod uses LuaRendering with on_tick update. Not even sure what would happen with the renderings that already exist when the simulation is saved?

Can you explain why it was decided to do this? Or am i misunderstanding something?

[Rseding91]

Can you explain why it was decided to do this? Or am i misunderstanding something?

I wasn't the one who decided on the mechanics of how the tips-and-tricks or main-menu simulations would function so I can only speculate.

My theories:

• Mods break all kinds of assumptions about how things work
• The tips-and-tricks/main menu stuff was primarily intended for base game use and "mods could use them too" came second
• Dealing with all of the ways mods could break stuff when being run from inside a tips-and-tricks/main-menu simulation wasn't worth the time

These are of course just guesses. But they seem to line up fairly well with past issues we've had around mods and things like tutorials.

Personally; if I was given absolute control on the topic I would blanket disable all menu simulations and tips and tricks when any mod is present. We already have several crash/corruption issues with them just in base game and we are 100% in control of what code they run there. There's a hole world of issues waiting to be found when mods start doing weird stuff inside menu simulations/tips-and-tricks. It's simply not worth it in my opinion.

That is all of course just my opinion. The one(s) who decided to do the menu simulations think differently (at least on some of the points). So, we'll see where it goes from here.

[-DeadlyKitten]

Would it be posable to allow mods' control.lua to work on an opt-in basis for each tips and tricks?
This would allow the vanilla tips and tricks to operate but still allow mods to make their own tips and tricks.
It would also put the responsibility to make it work explicitly on them.

edit: as you've said you are not working on the tips and tricks I am assuming the person who is working on it will see this suggestion.

[eradicator]

That is all of course just my opinion. The one(s) who decided to do the menu simulations think differently (at least on some of the points). So, we'll see where it goes from here.

Thank you for taking the time to write a detailed answer! I guess i was just a bit hyped because FFF 361 promised "moddable" tips'n'tricks. Albeit @Bilka discovered that scenario based control.lua still seems to be working as expected. So that should allow simulations to load exactly the mods that they themselfs expect - preventing other third party mods from randomly interfering. That might actually be a good thing :).

[Stringweasel]

I've changed it so migrations don't run in simulations for the next release.

@Rseding91 will migrations be disabled for menu simulations saves inside mod folders as well?

[eradicator]

That is all of course just my opinion. The one(s) who decided to do the menu simulations think differently (at least on some of the points). So, we'll see where it goes from here.

Thank you for taking the time to write a detailed answer! I guess i was just a bit hyped because FFF 361 promised "moddable" tips'n'tricks. Albeit @Bilka discovered that scenario based control.lua still seems to be working as expected. So that should allow simulations to load exactly the mods that they themselfs expect - preventing other third party mods from randomly interfering. That might actually be a good thing :).

On second thought... this only works to load a single mod because multiple mods would overwrite each others events. So each simulation can only use a single mod. Ultimately boilding down to the old "allow scenarios to specify what mods they require" problem. A simple whitelist would allow vanilla simulations to stay isolated while allowing mods to do whatever they want.