New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cargo callback "profit" probably broken #209
Comments
Please add some example code. |
|
Example code here. Not sure about #9095. It makes sense tried it, but it still does not work, there must be something else. One thing is it seems to me NML is parsing the proft return values incorrectly. Honestly I don't see what is wrong at the moment. |
C064 is wrong for -100. It would be correct if the result is simply flipped, but it's not. |
Ok, I agree. But still. Returning -100 in NML profit callback results in positive cargo payment even with the #9095 fix. |
Fix #209 seems it might improve the problem. I can't try it, because there is not new NML binary and compiling from python is not my thing. For more consideration though, see attached zip. In commented nfo/cargo-profit.nfo is NFO code as I would write it for the same thing I am trying in NML. It's quite simple and works fine. In commented nfo/cargo-profit.nml-decoded.nfo is the decoded code from GRF coded from the NML source. Here you can see NML adds lot of clutter code, but ok, if it works, it works. |
…hen there was no unit. The 'profit' callback in NML is supposed to be used like this: cargo_income = callback_result * cargo_amount * price_factor To do something similar as the default-payment, you can use callback_result = distance * time_penalty with 'time_penalty' in range 0..1. The old code got confused about 'price_factor' because NML applies a unit conversion in the property, and applied this unit conversion a second time.
…hen there was no unit. The 'profit' callback in NML was supposed to be used like this: cargo_income = callback_result * cargo_amount * price_factor But since NML defines 'price_factor' as income per 10 units over 20 tiles without time-penalty (=255/256), this definition results in a very weird meaning of 'callback_result'. NML applied some unit conversion to the callback result, which was supposed to revert this 20*10*255/256 scaling, but this only made it harder to use. By removing the unit conversion in the callback, the 'callback_result' can now be defined as relative scaling of the 'price_factor'. To do something similar as the default-payment, you can now use callback_result = distance * time_penalty with 'time_penalty' in range 0..1.
Returning negative values as positive sometimes? Is this 15 bit callback result dropping the signed bit? |
Not here @andythenorth, this callback is a proper 15bit one, with sign bit in bit 14, but nml applies some weird unit conversion. |
This was reported before on forum, cargo calback in NML doesn't match in result with the game's code, increasing profit by 10-30%, depending on distance: |
Cargo callback "profit" behaves strangely.
The problem is that when returning negative values, the cargo payment is for some values actually positive. Not sure if that is intended, but seems counter-intuitive.
Also cargo property "price_factor" is strange. Wiki states it is float type, but does not tells any lmit. In the NFO it is DWORD, so basically UINT32.
Anyway, its behaviour is not linear. When its value is increased lineary, the cargo payment sometimes drops back to lower values.
The text was updated successfully, but these errors were encountered: