Feature #2917

Change way of defining grf parameters

Added by Hirundo over 8 years ago. Updated over 8 years ago.

Status:ClosedStart date:2011-07-31
Priority:NormalDue date:
Assignee:-% Done:


Target version:-


Currently you have to configure explicitly which user-configurable parameters go in what internal grf parameter. IMO that should not be needed, the user need not and should not be busy with such things.

param {
    param_a_part_of_1 {}
    param_b_part_of_1 {}
param {
    param_c_part_of_2 {}

param param_a {}
param param_b {}
param param_c {}

Which user parameter goes into what grf parameter is then left to NML to decide.

Obviously, plenty of grace period would be needed to let existing grfs convert their code.



#1 Updated by planetmaker over 8 years ago

The problem with an automatic assignment is backward compatibility of the NewGRF.

Currently I can use the parameter such that I assign the meanings to specific parameters and bits thereof. Removing that, would make it quite unpredicatable to say, add another bit setting or similar - especially as I currently can influence the physical parameter number by explicitly giving it but the order in the GUI by assigning the order how they appear and are defined in the code.

#2 Updated by foobar over 8 years ago

In the new scheme, would you be able to guarantee that existing parameter values don't change when adding additional options to a parameter?

Say my grf with internal parameter values 1 0 3 gives a certain behaviour. Now I add some new parameter options which when done manually in NFO is compatible with the previous version. Can NML make sure that parameter value 1 0 3 leads to exactly the same setting in the new version? Or is there a chance that all parameters end up working completely different?

Hope you can follow my concern.

#3 Updated by foobar over 8 years ago

Edit: didn't see planetmaker's comment. But it's essentially the same as mine :)

#4 Updated by yexo over 8 years ago

The reason it works as it does now is already given by planetmaker/foobar. I can't see a good way to circumvent that, so I propose this task be closed.

#5 Updated by Hirundo over 8 years ago

  • Status changed from New to Closed


Also available in: Atom PDF