OpenTTD

Tasklist

FS#5487 - Provide the global random seed to NewGRFs

Attached to Project: OpenTTD
Opened by Johannes E. Krause (Eddi) - Monday, 25 February 2013, 15:13 GMT
Last edited by andythenorth (andythenorth) - Saturday, 02 September 2017, 12:14 GMT
Type Feature Request
Category NewGRF
Status With patch
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version Version?
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

This patch introduces NewGRF global var 26, offering the world generation seed to NewGRFs, to potentially randomize parameters of the NewGRF.

What remains to be checked is that the value _settings_game.game_creation.generation_seed is already initialized during GRF activation and will not be changed afterwards.
This task depends upon

Comment by frosch (frosch) - Monday, 25 February 2013, 18:03 GMT
I guess in theory this would belong to Action D Patch Vars.
Comment by Johannes E. Krause (Eddi) - Tuesday, 26 February 2013, 19:21 GMT
judging from the comment:
* Returns VarAction2 variable 'param' resp. Action7/9/D variable '0x80 + param'.

i assume they use the same code.
Comment by Johannes E. Krause (Eddi) - Tuesday, 26 February 2013, 20:31 GMT
I have an update here, that also adds a variable 27 which has different random bits for each GRF. in theory (tm) this should provide the same random bits on reload and on reapply GRFs, unless you change the number or order of GRFs.
Comment by frosch (frosch) - Tuesday, 26 February 2013, 20:42 GMT
I think you should better store those in the save instead of making them depend on the GRF loading order. That should be more fail-safe wrt. changes to the way base graphics work or similar.

Also, what is then intention of this feature wrt. scenarios? Shall they have the same value everytime, or shall it be rerandomised on scenario start like vehicle reliabilities?

My earlier comment refers to using GetPatchVariable() instead of GetGlobalVariable(). The former is more suitable for stuff which does not change during a game.
Comment by Johannes E. Krause (Eddi) - Tuesday, 26 February 2013, 21:38 GMT
this attempt features a completely different method, instead of providing variables, the action 14 is amended with a "random" type, where the parameter will be filled with random bits. needs additional magic to make sure the chosen random value is within the given limits of the parameter.
Comment by Johannes E. Krause (Eddi) - Sunday, 03 March 2013, 18:04 GMT
improved version now with support for min/max ranges

next task would be some test grfs for functionality tests. and when does/should rerandomisation happen? (upon starting the grf scan, upon adding the grf to the list, upon scenario/savegame creation?)
Comment by frosch (frosch) - Sunday, 03 March 2013, 18:23 GMT
I guess it should no rerandomise when starting a prepared scenario.

So I guess randomisation should happen when adding a GRF to a game, that is when starting a game, or when adding in mid-game. Though I am not sure how the editing of GRFs in-game compares to adding GRFS when starting a new game.
Comment by frosch (frosch) - Sunday, 04 August 2013, 12:15 GMT
How should the NewGRF parameter GUI handle this? Hide parameter completely?
Comment by Johannes E. Krause (Eddi) - Sunday, 04 August 2013, 16:42 GMT
Yes, doesn't make a lot of sense to display it, i think.
Comment by Johannes E. Krause (Eddi) - Sunday, 24 August 2014, 10:02 GMT
the currently best idea to handle randomization is to have the generator for the parameter values be initialized iwth (map_seed XOR grfid). this means there is no correlation between random bits for different NewGRFs, but the same NewGRF will retain values even when reordering NewGRFs or updating versions.

Loading...