I observed this behaviour when I was playing around with the different parameters in the goods list: sometimes an increase in the speed bonus leads to a (much) lower displayed revenue. When I noticed that at first, the parameters I had selected for distance, comfort and speed bonus were not set to (such) extreme values, but when I tried to reproduce it today, I could only make it happen for a very low speed bonus ... but since it definitely happens for different combinations too, this must be a more general problem. Since I'm interested in the (non-linear) curve of the function, I should have a look at the source code soon anyway. Look at the revenue for pax/speed bonus here:
(http://i.imgur.com/hbnE8.png)(http://i.imgur.com/msF3c.png)(http://i.imgur.com/1SoYs.png)(http://i.imgur.com/jEuE3.png)
And then, there's also a crash bug when trying to set the speed bonus to -99 (and some of the vehicle type speeds reach 0km/h I think, so there's probably a division by zero happening), but I didn't get around yet to testing this with Standard; will post a seperate report when I investigated that.
Edit: Oops, forgot to say that I'm playing with the latest Windows complete package
Thank you for the report! I am a little behind on development generally because of the merge problems of which you are aware, as you posted in the other thread, but I shall look into this when I get a chance.
Hello
What pakset are you using?
This issue reminded me of one thing that I noticed in pak64Exp, but could instead be related to the simu exp code.
http://forum.simutrans.com/index.php?topic=8233.msg77920#msg77920
Giuseppe
@Guiseppe
I'm using Pak128.Britain-Ex version 0.8.3 (which is bundled with the Windows complete package). I couldn't observe the behaviour you describe in the other thread though, i.e. the prices being mirrored for negative and positive bonus values, so I would assume that it's a different problem.
This is now fixed on the -devel branch. Thank you for the report!
It seems to be fixed indeed, at least the non-monotonic behaviour is gone. I've seen that what you did is basically just widen the relevant variable widths in the calculation, to reduce rounding errors I guess. There's however an interesting side effect of this: revenue as a whole (for pax) is going up by quite a bit - here are screenshots showing before/after
before:
(http://i.imgur.com/1sbw1.png)(http://i.imgur.com/UpaAG.png)(http://i.imgur.com/fxqMY.png)
after:
(http://i.imgur.com/qmsRG.png)(http://i.imgur.com/NoB7q.png)(http://i.imgur.com/ePKJB.png)
I should check with 32-bit variables later to see if that leads to yet another outcome ... do you think those differences are plausible and sufficient precision (i.e. the 16-bit variables which are there now) will get rid of them? Otherwise there might be an error in the way the function works.
On a related note, when I looked at the screenshots in direct comparison, it seems like the bottom two goods are missing in the devel executable - but checking back in game I saw that there's actually just a margin of two hidden lines at the bottom of the window now, so if you enlarge it all the missing goods will become visible. Was such a change intentional?
Hein,
thank you for re-testing. The variables were set to uint16 because all of the other variables in the relevant line were also uint16 - when the variables were uint8, this would often lead to a loss of precision. It is rather less likely that calculating uint32 results from uint16 variables will make a difference here.
As to the margin at the bottom, this was not specifically intended, and is probably a merging side-effect. It does look a bit neater than the list going right to the bottom, however, and players can tell that it's not the end by the scroll bar, so I am minded to leave it as it is.
James,
I'm afraid there's another related bug, this time based on the catering level. Compare pax revenue for level 2 and level 3 on the two screenshots:
(http://i.imgur.com/Kv6DE.png)(http://i.imgur.com/EW1A0.png)
I understood that level 3 would only earn more if the journey time exceeds 120 minutes (with default settings), but it should certainly not earn less. ;) Similar as the speedbonus bug, it doesn't occur in every constellation - has to be another rounding/loss of precision problem. By the way, I stumbled across this when I was testing my very first own code change, which I hope to post very soon. :)
Finally got around to fixing this (on -devel) - thank you for the report. The problem was not loss of precision but a quirk of the formula used. I have now put in a particular condition to test to make sure that the catering revenue for a higher level is never lower than it is for a lower level.