Access modParams in game-scripts?

Calling api.util.getAppConfig() will return a table.

Among other things, it will contain all the modParams currently saved by the game, including those for mods not currently active.
It will also contain a sub-table of active mods in the game.

I would have done a jump in the air if I had got a mechanism to get all installed mods after looking for something like that. But it shows me only "activeMods", whatever it may be.

This is only the default values for starting a new game.

The savegame values can be different.

But there is another way of transfering from runFn to gamescript:

write it somewhere into

 game.myModName = { modparams = modParams}

Then it is accessible in all other Lua Threads.

[OT] This is interesting. A pity that it doesn't work with postRunFn.

Can you hack into the api.* table in postRunFn?

No.

api and game.interface are created fresh for each lua state... so adding something there won't transfer to other states...

And if I remember correctly game.something couldn't be altered in postRunFn, as changes won't propagate to other states.

Technical my solution if my CommonAPI2 dll / so isn't loaded:

- filesystem.lua to resets it sync data on game load/restart. (find path of mod, you don't have any lua interfaces there)

- write a file with serial number as comment in first line, then serialize data to a lua function

- in a state, my code reads the first fileline and checks if the serial is different

- if serial is different, the file will be loaded with loadfile, run data fn to get new data.

- if new data needs to written, it will increase the serial (if 1000 set to 1) and then write new serial number as comment and serialized data as function.

- Technical this means, only if the file serial changes , I really need to reload the whole file

There is no communication allowed by UG, all states should be independent.... I couldn't change their opinion, so please send mails to UG, so they may reconsider this...

The only thing there is officially, is the gamescript. It allows for communication from Engine thread to Gui thread with the lua variable "state". This can contain pretty much everything (only standard lua types, no userdata).

The other way, there is the "sendScriptEvent" method from gui to engine (handleEvent).

But indeed it is lacking flexibility.

For example the load function has actually 2 jobs, as it is the only function called by engine thread (1x at startup) AND by gui thread (continously 5x/sec). There is no way to define things that should be done only at loading once, e.g. state initialization.

Second, a scriptEvent from Engine to Gui would be very useful. At the moment you have to do the following:

-write something in state (state.gui.doThis=true)

-in load check the state (if state.gui.doThis then)

-then you need to send an event to the Engine Thread again, because you cannot modify state in gui as it is reseted each time.

-Then in handleEvent, you need to remove the flag (state.gui.doThis=nil)

Sometimes the lack of communication from construction callbacks to gamescript is mentioned.

There need to be more events, e.g. at construction update.

This is also the reason, why Build with Collision does not work for construction upgrades.

There is even more under the hood:

If you use some api functions:

CGame::RunGameSimLoop ->

game_script engine thread state:

unpack the data via load

In a callback (update/handleEvent function) you use lua api.engine.getComponent,

the lua c++ function has some kind of reference to a std::function<const GameState&()>

There it does something like:

GameStateEngine = m_data->gameStates[ some_simIdx ]->GetEngine()

So technical it may happen, if you store the result of an ecs::component call in some kind of a global variable to crash the engine,

as soon as it internal switches gameStates and the gameState the component lua references is removed. (say by a recorded command)

end of callbacks

simThread has done all stuff,

pack the data via save

commands are executed

gameStates get synced

next loop

How UG prevents that the a ui thread lua references to components won't get screwed up when the gameState dance is done still puzzles me.

The more I look at the simulation handling the more questions I have

The communication between the logical levels of the game is a terrible thing. But also the API-internal communication between GUI and engine is terrible, as VacuumTube already said. At this moment I try to improve some of my edge marker tools, and you may have heard me cursing about multithreading synchronization problems. You do not know how often commands are repeated until they are executed, and the state.xyz thing is also very difficult to control. You often have this ping-pong effect, and sometimes you can only stop it by brute force and dirty or complicated tricks. For example you must reset a command as well in GUI and in engine to shorten the repetition process. And even then it will run through more than once. If you do commands very short behind one another, you may have an "overlap" effect - or you are forced to execute commands very slowly or have to suppress some commands until the event loop has finally stopped. This is very annoying and because of the random results very hard to debug.