A grf what renembers parameters at ingame alter

[thgergo]

I just have made some compatibilities for my TBRS. But I could figure why my OTTD remembers its parameters after a parameter remove... As I can see, many other sets doesn't have this behavior... If I attach some parameters for example to TTRS3, reload the newgrfs, then removing the parameters, the reloading again, the changes what I made is vanish. But here is a grf what have a weird behavior, if I start a game with it, it just changes the speed of the first bridge to 20MPH. If I set the parameters to "0 1", it changes its speed to 30MPH, but if I remove all parameters, then refresh the newgrfs again, the speed stays at 30MPH. How come? Can somebody make an explanation what this is happening for me, but for other sets don't, why my grf stores its parameters?

Also, I couldn't find why the nforenum gives warning one of my labels, its false, because it called with an action07 same way as many other labels do. How on Earth this is happening?

Code: Select all

 //!!Warning (107): Label E0 has not been goto'ed. 

Although these not a very big problems, I don't have an idea why these two things happening... I just dont want to tell the users, you need to reload the game if you want to lose the parameter definitions...
.. Im getting lose my mind today ..

[DaleStan]

Also, I couldn't find why the nforenum gives warning one of my labels, its false, because it called with an action07 same way as many other labels do. How on Earth this is happening?

Code: Select all

 //!!Warning (107): Label E0 has not been goto'ed. 

No, it's not. There's something very significantly different about that action 7 as compared to all the others. Information on why it is different has, unfortunately, been lost.

[thgergo]

Also, I couldn't find why the nforenum gives warning one of my labels, its false, because it called with an action07 same way as many other labels do. How on Earth this is happening?

Code: Select all

 //!!Warning (107): Label E0 has not been goto'ed. 

No, it's not. There's something very significantly different about that action 7 as compared to all the others. Information on why it is different has, unfortunately, been lost.

Then acton 9 is the same, using that gives the same error... Oh well, this is well documented:)

[FooBar]

I haven't checked your code thoroughly, but have you put in one of these?

Code: Select all

-1 * 0 0D 00 80 FF 00 00 00 00 00

In fact what that does is set the parameter (in this case 00) to value 0 if it's not defined. This way the parameter value will always be reset if no parameter value is defined in the config.

[mart3p]

How come? Can somebody make an explanation what this is happening for me, but for other sets don't, why my grf stores its parameters?

It’s not only your grf, I found the same problem with the narrow gauge rails grf. Using the code FooBar posted fixes the problem.

[thgergo]

How come? Can somebody make an explanation what this is happening for me, but for other sets don't, why my grf stores its parameters?

It’s not only your grf, I found the same problem with the narrow gauge rails grf. Using the code FooBar posted fixes the problem.

thx ill look onto that:)

[DaleStan]

Then acton 9 is the same, using that gives the same error.

I seriously doubt that. Look again at the sprite number and length for the purported action that NFORenum does not recognize as jumping to label E0.

I'll wait.

Done? Good. Has enlightenment been acheived?
If not, <rot>ybbx ng gur svefg gjb punenpgref bs gur yvar pbagnvavat gur checbegrq npgvba.</rot>