Is there any way to access modParams in a game_script without resorting to using an external file?
Access modParams in game-scripts?
Willkommen in der Transport Fever Community
Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
-
-
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. -
Thanks!
-
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.
-
-
[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
-
Yeah, I figured out @doug's solution didn't work for me. I managed to get things working as I need, through the Console State of the game. I must say, the way communication between states is implemented seems a bit wonky and with the limited api-documentation a lot of trail-and-error.
-
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
-
VacuumTube: The SendScriptEvent (from gui to engine) seems to work differently depending on context as well. Sometimes you need to go through the console with a SendCommand->SendScriptEvent. It took me 2 days to figure that one out
-
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.