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:

0%

Category:-
Target version:-

Description

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.
Current:

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

Suggestion:
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.

Thoughts?

History

#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

agreed

Also available in: Atom PDF