When using the property as is in NML...
Code: Select all
property {
...
running_cost_factor: 256;
...
}
But if i use a callback...
Code: Select all
switch(FEAT_TRAINS, PARENT, switch_running_cost_factor, 0) {
256;
}
...
graphics {
...
running_cost_factor: switch_running_cost_factor;
...
}
Then it would actually be "set" to 256. Or rather, it would internally in code be applied to the "GetRunningCost()" (in engine.cpp @~ 314) function in source code where the storage variable is uint and the callback return variable is uint16.
And that uint variable is "cost_factor" which is later used as...
Code: Select all
return GetPrice(base_price, cost_factor, this->GetGRF(), -8);
So here's a couple of questions for you guru's out there...
1) Does returning values > 255 in the callback have any possible negative implications?
2) Are there any other implications other than the limits of uint16 to consider, like the bit shifting of GetPrice?
3) How come this behavior isn't documented anywhere? Or did i miss it? Should it be documented?
4) In NML, can i rely on that the property value of "running_cost_factor" will remain the same once declared? For example, can i...
Code: Select all
return current_speed * 100 / max_speed * running_cost_factor / 100;
5) Is this common knowledge in the "circles" or did i stumble on something new even for you?
... One more question...
6) The NewGRF debug windows are great and all. But is there any other way to debug grf's? I want to know what the values in the temporary registers are at evaluation time so i can actually verify some assumptions i've made.
Thanks!