Inconsistent level prices

[MCollett]

Two odd things are happening with stops or station buildings whose price is determined by their level rather than being set explicitly in the pak:

• The actual cost of construction is (level)*(price displayed to the user).  e.g. in pak64.exp if you mouse over a long bus stop (level 2) in the tool bar it reports the construction cost as 50 credits, but if you build one you are actually charged 100 credits.  I reported this a while ago as a bug in Pak128.Britain Experimental, but it is evidently a program error, not a pak one.
• If you load a pak with addons, then in a newly started game all such prices are divided by the number of tiles per kilometre. e.g. the same long bus stop from pak64.exp is now reported as costing 12.50c (and actually costs 25c), since that pak has 250m per tile.  This behaviour is completely independent of the content of the addons; it appears even when the addon folder is empty, as long as it is present so that you can choose "With user addons" at startup.  It does not affect games that were started without addons, and then later loaded with addons.

Incidentally, since tiles/km is relevant here: in the development version of Pak128.Britain Experimental, simuconf.tab says meters_per_tile = 125 but all distances and prices in the game are calculated as if it were 120;  I presume an unintended truncation to multiples of 10 metres is occurring somewhere.

-devel commit 41d9404 (18/8/2012), compiled on Mac OS X 10.6.8.

Best wishes,
Matthew

[jamespetts]

Thank you for those reports, and apologies for having missed the earlier issue in the previous post. I think that I have found and fixed issue no. 1 on -devel now.

As to no. 2, I fixed an error a short while ago relating to the scaling of prices which might well be connected to this issue - would you mind re-checking with the latest -devel commit to see whether this issue is fixed there?

[MCollett]

I think that I have found and fixed issue no. 1 on -devel now.

Improved, but not completely fixed.  The actual construction costs of bus-stops now agree with their advertised prices, but advertised price of affected train platforms is now consistently 50% higher than the actual cost.   Shouldn't the price calculation just be done in one place? Then both the UI and the internal accountant can go to that place, ask the same question, and get the same answer.

Also, a pak dependent comment on the prices as they were before this fix. Internal consistency suggested to me that in both pak64.exp and the released version of Pak128.Britain Experimental the advertised bus-stop prices were correct, and the actual ones in error.  In the case of the -devel version of Pak128.Britain Experimental the opposite appeared to be the case; since the disagreement has been resolved in favour of the advertised price, you might want to consider increasing the prices therein to compensate.

As to no. 2, I fixed an error a short while ago relating to the scaling of prices which might well be connected to this issue - would you mind re-checking with the latest -devel commit to see whether this issue is fixed there?

No, still there, unchanged.

Best wishes,
Matthew

[jamespetts]

Hmm - I can't reproduce the problem that you describe in respect of no. 1, I'm afraid: using the latest -devel commit and also the latest Github push of Pak128.Britain-Ex, both station platforms whose price are individually set and those which are not are deducted in the advertised amount.

As to the addons issue, do you have a particular set of addons and pakset with which I can test this?

[MCollett]

I can't reproduce the problem that you describe in respect of no. 1, I'm afraid: using the latest -devel commit and also the latest Github push of Pak128.Britain-Ex, both station platforms whose price are individually set and those which are not are deducted in the advertised amount.

I didn't even realise there were any platforms in Pak128.Britain-Ex that didn't have individual prices.  I observed the effect with pak64.exp.

As to the addons issue, do you have a particular set of addons and pakset with which I can test this?

Just an empty addon folder for either pak64.exp or Pak128.Britain-Ex does it for me.

Best wishes,
Matthew

[jamespetts]

Thank you for the more detailed feedback. I have now had another go at fixing the first issue - are you able to confirm whether the fix has worked?

As to the second issue, I am having some trouble reproducing it. I have created a directory /simutrans/addons/Pak128.Britain-Ex-0.9.0, but when I start Simutrans-Experimental with Pak128.Britain-Ex-0.9.0, the prices for both 'bus stops and railway stations are the same as without that directory being present. Have I correctly understood the required steps to reproduce this issue?

[MCollett]

I have now had another go at fixing the first issue - are you able to confirm whether the fix has worked?

Yes, it looks OK now.  Thanks for that.

As to the second issue, I am having some trouble reproducing it. I have created a directory /simutrans/addons/Pak128.Britain-Ex-0.9.0, but when I start Simutrans-Experimental with Pak128.Britain-Ex-0.9.0, the prices for both 'bus stops and railway stations are the same as without that directory being present. Have I correctly understood the required steps to reproduce this issue?

You have to choose 'With user addons' from the list of paks at startup.   If you are not being offered that option, well, that's a different problem, the workaround for which is to put a copy of the empty folder directly in /simutrans as well as in /simutrans/addons.

Best wishes,
Matthew

[ras52]

Not sure whether this is related to the bug-fix discussed in this topic, but at the moment on the -devel branch, stops that have station_price set in the pak (e.g. the 1750 staging post in pak128.Britain-Ex) cost a negative amount — i.e. you get given money when you build one of these stops.  I think the problem is with the five lines in simwerkz.cc that do:

Code Select Expand

cost = besch->get_station_price();
Simply adding a minus sign seems to fix it.  The other branch is fine because settings_t::cst_multiply_dock is already negative.
Edit Fixed on my github -devel branch in this commit.

[jamespetts]

Thank you very much! Merged and pushed now. Very helpful.