Suggestion for scripts data storage

[lukasz1985]

I've found that game script doesn't allow to save data. This means that there is no way to save configuration for a game script and load it later.

I think it would be usefull with game scripts that have a lot of settings - the user would save different setups per game script and load them every time he wants to play that configuration instead of going through all the process again, which can take some time.

[Zuu]

A GS can save data in the save game by returning a table containing the data in the MainClass::save() method.

A GS cannot save data to external files if that is what you are looking for.

What you look for sounds like the NewGRF presets but for GS rather than allowing a running GS to save data to files. Remember that the GS does not actually run when you have selected it in the configuration screen. It will start running during the world generation process of a new game but not earlier than that.

[lukasz1985]

Well, yes exactly this is what I mean, something like NewGRF presets, but for GS.
It would actually be nice if GS configuration could be just saved to a file or something like "per GS preferences file" if it existed.

Well the problem actually is that, when I select a GS, configure it and then change it to the other game script, the configuration data is lost. This makes it pain to switch between game scripts because every time you want to start a new game with a different one - you have to configure it again.

So maybe it's not exactly that there should be "presets" for GS, but it would be fine if at least the configuration was saved for each game script.
Of course if the data was saved to an external file, this would make things more flexible, because player wouldn't have to the configuration when moving between machines, and it may be possible to share configuration with others.

This suggestion came to my mind when using CityBuilder by Aphid, where there is plenty of configuration options. It may be irrelevant for small GS, where there are only some configuration options (like maybe 2 or 3, because it's hard to remember more).

[keoz]

Of course if the data was saved to an external file, this would make things more flexible, because player wouldn't have to the configuration when moving between machines, and it may be possible to share configuration with others.

This suggestion came to my mind when using CityBuilder by Aphid, where there is plenty of configuration options. It may be irrelevant for small GS, where there are only some configuration options (like maybe 2 or 3, because it's hard to remember more).

That should be easy to do: not changing the OpenTTD code, but by tweaking directly the script files, so that they use the options you want.

Though I still couldn't say the easier way to do it. The dirty hack, could be just tweaking the info.nut file configuration options. But there is surely a better way, to include some sort of "config.txt" file, which would be added in the gamescript repository.

[lukasz1985]

The point is that this will not be done by the gamescript itself but OpenTTD core, so it would persist for every game script, no matter how it handles the configuration.

And also , I dont really know but I dont think it's possible by gamescript at all, because, last time I was looking into API, I found no way to access filesystem or any other persistent storage form inside of the GS. The only way a GS can persist data is within the savegame, but as said, this is not related to the scope of a save game, but the scope of OpenTTD installation and/or filesystem.

[Zuu]

Game Scripts can communicate with the outside world if it is tunning on a server. Then it can send and recieve data via the admin port. Server GS is an extreme case where most of the GS API can be accessed from the admin port.

That said, that need work on every GS to support setting its settings via the admin port. What is easier for you as a user is that you use different openttd.cfg files fo r each GS. With the CLI option -c you can tell OpenTTD which config file to use. This method can be used today with zero modification of GSes or OpenTTD.

Thait said it may be useful with som sort of preset also for GSes or generalising NewGRF presets to also cover GS and advanced settings, but that needs someone implementing it.

[R2dical]

Well I for one would very much like to see this feature, my wip GS currently has 30 odd settings (and counting) different combinations of which have widely different outcomes. Very ripe for presets.

Also I am tinkering with a genetic algorithm based pathfinder for my road AI which would benefit hugely with between game data store. I might take a swing at starting a fork with to do the file i/o myself if this GA thing is promising.

Another related feature which would be nice is to save the AI/GS Script Debug to a text file, for your own purposes or for others to easily post crashes. Unless I am missing something and this feature is available, or declined?

[Zuu]

Well I for one would very much like to see this feature, my wip GS currently has 30 odd settings (and counting) different combinations of which have widely different outcomes. Very ripe for presets.

I usually try to limit the number of settings to not get a forest of settings that new users have to dig through.

An other option than giving options for each cargo id or at this date known cargo label, is to delay these settings to be set in the game. For casual play it will probably work to do this via a GUI that is displayed to the first company in the game. If you want to also support automatic configuration for pro server owners, you can offer an Admin Port interface to query available cargoes and setting settings.

It will probably need some work to get this right. I haven't tested this idea yet in any GS, but think that NoCarGoal could benefit from an optional in-game cargo goal selector. Offering this in a user friendly way the game menu will be quite hard as it is not known there what NewGRFs that are loaded.

Also I am tinkering with a genetic algorithm based pathfinder for my road AI which would benefit hugely with between game data store. I might take a swing at starting a fork with to do the file i/o myself if this GA thing is promising.

If you are on windows, you need to convert OpenTTD.exe from a windows to console program and then direct stdout/stderr to a file (by running it in a terminal and append ">out.txt 2>err.txt" without quotes to the command line. If you are on non-windows you can just run OpenTTD in a terminal and direct the output without having to alter the OpenTTD binary. You also need to increase the script debug level (possible to 5 but possible more, I don't remember that in detail).

This allow you to capture all log messages by AIs and GS in the game to a file. Write a parser that grab output from your AI road path finder and process that into data that you write into a .nut file that will be read by the AI next time it is started.

[R2dical]

I usually try to limit the number of settings to not get a forest of settings that new users have to dig through.

I usually like to follow this mantra also, but the point of my GS is to provide more options for map generation (towns/industries). More parameters = more flexibility, and I assume that anyone interested in this would not mind the long list.

Also, since much of my scripts work is done in the starting quota, before game start, an in game gui wouldn't work. I think this is an awesome idea though, for the gameplay type GS, to give context choices.

This allow you to capture all log messages by AIs and GS in the game to a file.

Thanks very much for this! It will work very well, and I kind of had a hunch a solution lay in this direction. I already have it set up for this; the AI's "DNA" is stored in a table with the class variable names as key and value as values. A function prints each like they are in the .nut to the log every generation. Your solution will complete the other end of the loop