Feature Request #4222

Allow more than 64 user-defined parameters

Added by planetmaker about 7 years ago. Updated about 7 years ago.

Status:NewStart date:2012-09-19
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

In order to make a nice basecost NewGRF it needs 70 parameters

This particular problem could either be solved by allowing to put more parameters (also ints) into one actual parameter (like the booleans) or it could be solved by lifting the restriction on the amount of user parameters.

I'm suggesting the latter, as it would also give NML the option to use the non-used part of the 64 user-parameters for varaction2 etc (or does it do that already? I got a bit lost when trying to find the places in the source)

Associated revisions

Revision 2009:ea2f9f10d80e
Added by Hirundo about 7 years ago

Change #4222: Allocate parameters starting at 127 instead of 64.

Revision 2009:ea2f9f10d80e
Added by Hirundo about 7 years ago

Change #4222: Allocate parameters starting at 127 instead of 64.

History

#1 Updated by Hirundo about 7 years ago

Currently NML uses parameters 64-127 for internal calculations, while 0-63 are kept free for the user
We could detect what parameters are used, but that fails for param[param [1]]-like code

Perhaps an easy 'solution' would be to use the parameters 64-127 in reverse order, so 127 is used first by NML. Then, using 70 parameters, although not officially supported, would most likely work (unless NML needs more than 58 params).

#2 Updated by planetmaker about 7 years ago

That would work for the use case I envision.

For the reverse case where NML needs more (internal) parameters: could the user be asked to reserve the parameter ids he needs if using constructs like param[param1]?

#3 Updated by planetmaker about 7 years ago

I consider this mostly dealt with with r2009. Thanks a lot :-)

Also available in: Atom PDF