[Bug] Function for revenue calculation not monotonic

[HeinBloed]

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:





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

[jamespetts]

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.

[Milko]

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

[HeinBloed]

@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.

[jamespetts]

This is now fixed on the -devel branch. Thank you for the report!

[HeinBloed]

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:


after:


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?

[jamespetts]

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.

[HeinBloed]

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:



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. 

[jamespetts]

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.