News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

Load long distance passengers patch

Started by Markohs, September 25, 2014, 10:22:07 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ters

One feature of simuconf tab that's difficult to make otherwise is that pak sets have their own simuconf.tab overrides. A GUI for setting the defaults, as opposed to the per-game settings, will have to deal with whether the user is setting defaults for the game or for the pak set. Then you get a a hierarchy of global defaults, pak set defaults, global user overrides, pak set user overrides and game specific settings.

hreintke

Based on the longdistance-6.patch I did a first implementation of proportional loading.

In order to apply the 6.patch to the current HEAD I needed to update line 111 in the file to :

lb_waitlevel(NULL, SYSCOL_TEXT_HIGHLIGHT, gui_label_t::right),

due to a conflict with a later patch from prissi.

As said, it is the first implementation in which I restructured some of the fetch_goods-* routine and needs further testing and cleaning/deduplication of code.


DrSuperGood

QuoteOne feature of simuconf tab that's difficult to make otherwise is that pak sets have their own simuconf.tab overrides. A GUI for setting the defaults, as opposed to the per-game settings, will have to deal with whether the user is setting defaults for the game or for the pak set. Then you get a a hierarchy of global defaults, pak set defaults, global user overrides, pak set user overrides and game specific settings.
From my very quick encounter of settings to make JIT2 it appears that most gameplay altering settings are stored as part of the game save so only suffer from inheritance and things when starting new games. Any override of them would change the setting during runtime independently of any inheritance.

There really needs to be two changes to the game setting model.
1. Separation of setting classification. Settings that affect game mechanics (JIT model, industry payment, growth etc) should be declared in separate files from those that affect client behaviour (frames behind, full screen, server info etc). Currently they are all mixed together in a way that does not always seem logical. The classification for separation would be settings that are part of the map (saved with it) and settings which affect the playing of the map (client/server settings).
2. To support run-time changing of settings there needs to be an event socket for setting changes with an active running session. In the case of my JIT2 code (another thread) it would bind a special handler to convert between the industry models when you change the settings during run time to assure correct conversion and function. Some changes (such as growth) do not need this but any that result in major logic changes do. Currently the only way is to reload the map after the change and that can produce undesirable results (eg my JIT2 uses a union which is set to "garbage" from JIT1 values and stored during the conversion).

Ters

Quote from: DrSuperGood on October 20, 2014, 05:59:04 PM
From my very quick encounter of settings to make JIT2 it appears that most gameplay altering settings are stored as part of the game save so only suffer from inheritance and things when starting new games. Any override of them would change the setting during runtime independently of any inheritance.

I think it's nice to be able to set defaults so that one doesn't have to set them every time a new game is started. Some of these user defaults might be pak set dependent, some might be for all pak sets.

Currently, I have modified my simuconf.tab in the SVN workspace, so that incomming changes to defaults merge with my own customizations as automatically as possible.

Quote from: DrSuperGood on October 20, 2014, 05:59:04 PM
1. Separation of setting classification. Settings that affect game mechanics (JIT model, industry payment, growth etc) should be declared in separate files from those that affect client behaviour (frames behind, full screen, server info etc). Currently they are all mixed together in a way that does not always seem logical. The classification for separation would be settings that are part of the map (saved with it) and settings which affect the playing of the map (client/server settings).

I agree.

Yona-TYT


@Markohs....   That's true, most new players do not even know it exists simuconf.