News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

balancing the pakset

Started by asaphxiix, November 14, 2012, 02:42:23 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

asaphxiix

so I took the liberty! of playing a bit with the dat files. I'm mostly working on trams now - trying to get them profitable, earlier in the 19th century (horse cars), and also the electric cars. I've reduced track costs to 4/km now, horsecars to 25 horse/75 wagon (wagon increased to 55 capacity and limited to one wagon per convoy, as horses can't take much more than that). Also the late trams, e.g. TB24 lowered to 50/31, etc.

Also modified factories to spread them out a bit more, over the years.

My fear is that I'm balancing the game to my favor (so what I think is a reasonable line/combination of lines should make moderate profit taking infra into account), but since I'm not an experienced or very talented player, this may become too easy for other players, which is a concern since I want to play this pak online. For the trams, so far I've found them to be way too expensive at any stage of the game.

I'd love to hear any thoughts, advice or guidance, also if it's of any value I can post the files here when I'm finished.



Carl

Asaph -- this is great, thanks! I've been rather preoccupied and not able to undertake this work, so I'm very grateful to you for doing so. Please do post the files here when you're finished!

asaphxiix

thanks carl. any chance you know a good source of information for this? so far it's just experimenting for me.

also, are you aware of any specific bits in the pak that need more balancing?

I'm very keen on doing this, but also quite insecure, at first at least :)

Carl

There are a couple of topics in this forum that talk of specific balancing issues: check out jk271's comments in the 0.4 release thread. Beyond this, I have little experience of balancing paksets. One approach would be to take a look at pak128.Britain-ex and the balancing issues that have arisen there. The same issues will likely be important here too.

Don't be insecure, throw yourself into it -- we all learn by doing! :)

ӔO

I think it's best to play it online and make notes of which vehicles make excessive or not enough income. Trying to aim for a margin of around 15~25% should be good, I think.

It's probably best if you try figuring out what would be too high or too low first. Then you can hone the figures in.
And don't forget you can always add more items if you find that there's not enough variety in infrastructure or vehicles.

I think train tracks could use one more increment between 50km/h and 120km/h. Maybe 80km/h?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Carl

I agree. I am also of the opinion that building tracks with high linespeeds should be more expensive (in cost and maintenance) than it currently is, so it's not always the default option.

asaphxiix

great input, guys!

if by any chance, you or someone else have a developed and stable game saved, preferably with multiple modes (bus tram ship air etc), and you can share it, that'd be great (for many purposes:))

asaphxiix

I will create more tracks, using track graphics from other pak64's for differentiation (I can't really draw I'm afraid). What do you think about using similar track stats as pak128UK exp?

greenling

asaphxiix
I think that's more Tracks are usefull it.
But i work in the background on a drill up project for pak64.
I will build in Narrow gauge in Pak64.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!


asaphxiix

the current default setting is (4-1600km) for min/max distance for speedbonus. This, I think, will work on huge maps, but on standard or large size (100-400km² length) it's way too much, and thus speed bonus is hardly felt when comparing trains, while comfort plays a more major (perhaps too major) part. I would think that speed and comfort should play at least an equal part in pricing, if not more for speed.

I don't feel I have a very good understanding on the works of speed bonus yet, so I'd like to hear your thoughts on what should be the default values here, assuming a player likes to play on a map of about 400km length, or for reference purposes, when comparing trains to balance pak.

greenling

asaphxiix
On Friday evening can we talk over balancing the pakset from pak64 experimental.
There have i freetime.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

asaphxiix

that's great greenling... I'll be here as always :)

anyone else?

asaphxiix

#13
so my research goes deeper into the revenue system. In all my inquiries so far of historical and current data  (one of particular interest is http://www.airlines.org/Documents/economicreports/1971.pdf p. 42), I have found that the very high rate of speed bonus in simutrans in general is not realistic (and also on the side I've found that airlines have never been a very profitable industry). So I plan on reducing that drastically in the works of balancing the pakset.

I guess speed bonus is too much of an important aspect of the game to simply forgo, so I wouldn't reduce it to a meager effect, but currently speed bonus (for 100 speed bonus, that is, double the expected speed for the era), in default settings can be up to 5 times the base fare, which is quite extreme. What do you think?

Of course, other ways will have to be found to balance things out and provide incentives for fast and reliable service, but such way already exist to a very good extent in experimental, mainly the journey time tolerance, but also time/space/engineering constraints when carrying large volumes of passengers, and even comfort rating. Also, maintenance levels will probably have to be fitted to this change. Other than that, I don't see any simulation-wise or game-fun-wise reason that air travel should pay 3-4 times more than train or bus in experimental.

Perhaps this idea can be of interest for pak128 UK as well.

greenling

hey asaphxiix
you have with the link http://www.airlines.org/Documents/economicreports/1971.pdf , what found that very heavy it,
that i on the first look not understand. I self must that first in peace read that i that understand.
( sorry asaphxiix that here a the moment must giveup.) ::( ::( ::(
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

That is interesting, especially as to the speed bonus. May I ask - where in the document did you get the figures on which you base the conclusion that 6% is the best speed bonus? Some brief research that I undertook into comparative pricing between rail and coaches between London and Oxford in a transport economics text book showed the existing figure of 18% to be about right (one might say that the comfort is different, but I suspect, and I should add the caveat that comfort is an inherently subjective thing, that the coaches running from London to Oxford are very comfortable for coaches, whereas I know that the trains are often not the most comfortable types (often outer suburban 3+2 seater diesel multiple units), so the actual comfort of the two is probably broadly comparable).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

greenling that's cool - whenever you got time :)

james - I made some comparisons on a larger scale between flight prices (now and back then) and rail and coach prices, and found that today, in various regions of the world, rail and plane prices are not very different, and in some places like Europe, flying is much cheaper actually. Even in India, a plane ticket from New Delhi to Goa will not cost more than double the train fare, I have found. So on a bigger scale of transportation, speed (given the extremity of flight speed) just doesn't seem to be rewarded so much, not now and not in the past. On the other hand, trains indeed more expensive to ride than buses, which is something I haven't investigated, but as you can see in the table, it's not by much.

The other thing is that from many many different test scenarios I've played in pak64 (and according to goods list, in pak128 as well), I can say that a speed bonus rating of 18% or 15% gives well over that figure in percentage from the base revenue - more like 500% from what I've seen. So with speed bonus rating 6% I'm currently testing, I can get the bonus to be 50% on a 91km trip at a 100 speed bonus value. This still is too much I think, if you take into account a 400 km journey will get over 100% speed bonus, so I'm trying to figure out another way to reduce this percentage, perhaps playing with the median/max speed bonus distance factors.

jamespetts

Interesting indeed. Hmm - perhaps the single set of figures that I took was anomalous. Can you give the figures and specific sources for your comparisons so that we can compare the raw data and computational methods?

Perhaps the answer lies in adjusting the min_bonus_max distance (etc.) values as you are looking into. In Pak128.Britain-Ex, the values are:


min_bonus_max_distance = 4
median_bonus_distance = 75
max_bonus_min_distance = 250
max_bonus_multiplier_percent = 300


What are you looking at coding them as at present?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

#18
Quote from: jamespetts on December 21, 2012, 10:10:32 PM
Interesting indeed. Hmm - perhaps the single set of figures that I took was anomalous. Can you give the figures and specific sources for your comparisons so that we can compare the raw data and computational methods?

Not sure I understand the question about computational methods? I looked into rail and flight tickets in Europe (Paris to Rome - 70-120GBP on train second class @ http://www.raileurope.co.uk, and on plane you can find Ryanair tickets from 15€),

in the US (NYC-SF - about 250$ train (Amtrack.com) and 160$ for plane journey http://www.kayak.com/flights/NYC-SFO/2013-01-31),

in India (Delhi-Goa flight http://book.mustseeindia.com/flights?trip_type=one+way&from=Delhi+%28DEL%29&to=Goa+%28GOI%29&depart=06%2F01%2F2013&adults=1&children=0&infants=0 6000 rupee, not much info on trains (blocked for some reason) but found this that quotes 3000-4000 rupee http://www.indiamike.com/india/goa-f23/train-to-goa-from-delhi-t14855/

In Israel, Tel Aviv - Haifa line (85km) - train takes 1:08h costs 30NIS, bus goes about 1:30 on average, 24 NIS (however both are probably subsidized). Going further North from Haifa to Naharia (35km) - about the same duration in both bus and train (off-peak at least), train costs 15 bus costs 18.

Quote from: jamespetts on December 21, 2012, 10:10:32 PM

Perhaps the answer lies in adjusting the min_bonus_max distance (etc.) values as you are looking into. In Pak128.Britain-Ex, the values are:


min_bonus_max_distance = 4
median_bonus_distance = 75
max_bonus_min_distance = 250
max_bonus_multiplier_percent = 300


What are you looking at coding them as at present?

I didn't realize pak128 uk exp had these values. Are they default? When I open the settings for a new map the default values seem to be

min_bonus_max_distance = 16
median_bonus_distance = 300
max_bonus_min_distance = 1000
max_bonus_multiplier_percent = 300

the last one doesn't have any effect that I can account for. Before, I was trying to increase these distances, but now I think maybe low values (shorter than the map) are the way to go, but still, given the immense revenue bonus I get from even just 6%, I don't see how this is viable with 18% speed bonus rating. Trying these values, I get in the goods list 5$ pax rev in speed bonus 0, and 49$ (almost 1000%) with speed bonus 100.

Maybe I'm missing something?

The last setting I was trying on pak64 was 16/434/868, and then just before I went out I tried some 1736/868/1, but got some strange results there... Anyway I thought that increasing mid/max distance would reduce bonus for normal distance, but you're saying it's the other way?

jamespetts

The values are the defaults from the simuconf.tab file of Pak128.Britain-Ex, not Pak128 (which is a different pakset). To get a full idea of the function of this part of the code, have a look at the comments in simuconf.tab:


# These settings calibrate the speed bonus. Note that, with Simutrans-Experimental, unlike
# Simutrans-Standard, the speed bonus is based on the convoy or line's *average* speed, not
# the convoy's maximum speed.
#
# All distances in these settings are measured in kilometres and calibrated using the
# meters_per_tile setting.
#
# min_bonus_max_distance is the distance below which the speed bonus (or penalty) does not
# apply. Below this distance, goods pay the same no matter what the average speed.
#
# median_bonus_distance is the distance at which 100% of the speed bonus/penalty applies.
# At anything between min_bonus_max_distance and median_bonus_distance, a scaled proportion
# of the speed bonus applies. For example, if the min_bonus_max_distance was 10, and the
# median_bonus_distance was 110, then, for a journey of 50 tiles, 50% of the speed bonus or
# penalty would apply. median_bonus_distance is optional: if it is not specified, or set to
# 0, it will be calculated as the mid point between min_bonus_max_distance and
# max_bonus_min_distance.
#
# max_bonus_min_distance is the distance above which the rate of the speed bonus increases
# no further. In other words, the rate of the speed bonus (or penalty) keeps increasing with
# the distance, until it reaches the max_bonus_min_distance, after which it remains steady.
#
# max_bonus_multiplier_percent is the percentage of the speed bonus that applies at or above
# the distance specified in max_bonus_min_distance. So, if the speed bonus rating was 10%, the
# distance exceeded the max_bonus_min_distance value, and the max_bonus_multiplier_percent was
# set to 200, the speed bonus rating would effectively be 20% for that journey.
# Between the median_bonus_distance and the max_bonus_min_distance, a scaled proportion applies.
# So, if, for example, the median_bonus_distance was 100, the max_bonus_min_distance was 1,100
# the actual distance 500, and the max_bonus_multiplier_percent 200, the speed bonus rating
# would be increased by half of the multiplier, or 150%.

min_bonus_max_distance = 4
median_bonus_distance = 75
max_bonus_min_distance = 250
max_bonus_multiplier_percent = 300


Does this help at all?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

nope, these have been taken into account.

if I open a new simutrans exp installation with pak 0.8.4 on it, I think it will have the median/max values I stated above as default...

jamespetts

Ahh - these were taken from the latest on the Github repository, the forthcoming 0.9.0, which might explain why they differ from the values on 0.8.4. Perhaps you could try with those values and see whether it works any better?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

yep I did - this is what I get in the goods list - and if I change speed bonus value to '0', the pax rev will change to just 5$:



jamespetts

Hmm, I will have to look into this and check that the code is producing the intended effects.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix


jamespetts

Hmm, I think that this is working as intended. (The figures, incidentally, are different in 0.8.3 to 0.9.0, but that is another matter). The max_bonus_min_distance is 250km, so the effect of the speed bonus continues to increase until the journey gets to 250km, at which point the effect reaches its zenith and remains there for any longer journey.

At its maximum effect, the speed bonus is multiplied by max_bonus_multiplier_percent. So, for a speed bonus of 18%, for journeys at and over 250km, this is multiplied by 300% (in other words, multiplied by 3) to get an effective speed bonus rating of 54%. At median_bonus_distance, the speed bonus rating works at its default value 0f 75. At below min_bonus_max_distance (in this case, 4km), no speed bonus applies at all. For journeys of 4km or less, in other words, passenger revenues are not affected by speed. At points between those three set points, the level of the speed bonus is scaled in a linear fashion. So, for example, half-way between the median_bonus_distance of 75km and the max_bonus_min_distance of 250km, being 162.5km, the speed bonus (18%) is multiplied by half the max_bonus_multiplier_percent (being 150%, or 1.5), to get an effective speed bonus rating for that distance of 27%.

I hope that this helps with your calibration!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

So why do I get, in a situation like the screenshot I uploaded, almost 1000% speed bonus? If I change the '100' value in speed bonus there to '0' (base revenue, if I got it right), it will become 5$, instead of 48$...

For this calculation I would expect: base rev 5$. at 100km distance (25km more than the median 75, which is 16% from the difference between 75 and 250), I should get base_rev (5) + bonus (5 * 0.16 * 3) = 7.4 (or slightly more as makes no matter), and not 48...?

jamespetts

Hmm, this is very odd - I can't reproduce your base figures. With 0.8.4 and 10.18, I get 23.95c with distance of 100, comfort of 75, catering level of 1 and speedbonus of 100. Have you made any changes?

But in any event, the speed bonus calculation. In 1825 in Pak128.Britain-Ex 0.8.4, a distance of 100 gives an effective speed bonus rating of 21%. The base fare for that distance is 48.74c. However, a 100km journey at 20km/h takes 299 minutes. For a 299 minute journey, a comfort rating of no less than 189 is tolerable, and so a substantial discomfort penalty is applied.

At a speed bonus of 0, and a speed of 10km/h, the journey takes 599 minutes. The minimum tolerable comfort for a journey of that duration is 225. An enormous discomfort penalty is applied for making passengers spend nearly 10 hours in conditions equivalent to a commuter train from the 19th century.

The effects that you are seeing are due to comfort, not due to the speed bonus, I think.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

thank you for your patience james - sorry for being difficult on this issue.

I tried now with 255 comfort rating, in the year 2012, also I changed 'max discomfort penalty' to 0 & 0 in the pre-game settings, and still, for:
distance 75, comfort 255, catering 1, I get 13.63$ with speedbonus value 0, and 85.67$ on speedbonus value 100%.

Playing with comfort level seems to have little effect.

Also in 1825 without reducing max_discomfort_penalty, and setting distance 100, comfort 225, catering 1, I get 16.95$ on 0 and 132.25$ on 100. No matter what comfort I set 1-255, I still get a 700-1100% increase in fare, between 0<>100 speeds.

10.18/0.8.4 - no changes in the pakset.

jamespetts

#29
Hmm. There does seem to be something of an oddity with this: the issue seems to be around the calculation of the fare when the speed bonus is at zero. I am afraid that I don't have time to look into it fully at present, as I need to wrap my Christmas presents before I go to visit my parents, but, for reference, here is the chunk of code that calculates the revenue (this is the part that calculates it for display in the list of goods window - the code is duplicated, with some alterations, for use in calculating the revenue for actual function in the game):


const sint64 base_fare = wtyp->get_fare(distance);
      const sint64 min_fare = base_fare / 10ll;
      const sint64 speed_bonus_rating = (sint64)convoi_t::calc_adjusted_speed_bonus(wtyp->get_speed_bonus(), distance, welt);
      const sint64 base_bonus = base_fare * (1000ll + ((sint64)bonus - 100ll) * speed_bonus_rating);
      const sint64 revenue = max(min_fare, base_bonus);
      sint64 price = revenue;

      //const uint16 journey_minutes = ((float)distance / (((float)welt->get_average_speed(way_type) * bonus) / 100)) *welt->get_settings().get_meters_per_tile() * 6;
      const uint16 divider = (welt->get_average_speed(way_type) * bonus) / 100;
      const uint16 journey_minutes = (((distance * 100) / (divider > 0 ? divider : 1)) * welt->get_settings().get_meters_per_tile()) / 1667;

      if(wtyp->get_catg_index() < 1)
      {
         //Passengers care about their comfort
         const uint8 tolerable_comfort = convoi_t::calc_tolerable_comfort(journey_minutes, welt);

         // Comfort matters more the longer the journey.
         // @author: jamespetts, March 2010
         sint64 comfort_modifier;
         if(journey_minutes <= welt->get_settings().get_tolerable_comfort_short_minutes())
         {
            comfort_modifier = 20ll;
         }
         else if(journey_minutes >= welt->get_settings().get_tolerable_comfort_median_long_minutes())
         {
            comfort_modifier = 100ll;
         }
         else
         {
            const uint16 differential = journey_minutes - welt->get_settings().get_tolerable_comfort_short_minutes();
            const uint16 max_differential = welt->get_settings().get_tolerable_comfort_median_long_minutes() -welt->get_settings().get_tolerable_comfort_short_minutes();
            const uint32 proportion = differential * 100 / max_differential;
            comfort_modifier = (80ll * (sint64)proportion / 100ll) + 20ll;
         }

         if(comfort > tolerable_comfort)
         {
            // Apply luxury bonus
            const uint8 max_differential = welt->get_settings().get_max_luxury_bonus_differential();
            const uint8 differential = comfort - tolerable_comfort;
            const sint64 multiplier = ((sint64)welt->get_settings().get_max_luxury_bonus_percent() * comfort_modifier) / 100ll;
            if(differential >= max_differential)
            {
               price += (revenue * (sint64)multiplier) / 100ll;
            }
            else
            {
               const sint64 proportion = ((sint64)differential * 100ll) / (sint64)max_differential;
               price += (revenue * (sint64)(multiplier * proportion)) / 10000ll;
            }
         }
         else if(comfort < tolerable_comfort)
         {
            // Apply discomfort penalty
            const uint8 max_differential = welt->get_settings().get_max_discomfort_penalty_differential();
            const uint8 differential = tolerable_comfort - comfort;
            sint64 multiplier = ((sint64)welt->get_settings().get_max_discomfort_penalty_percent() * comfort_modifier) / 100ll;
            multiplier = multiplier < 95ll ? multiplier : 95ll;
            if(differential >= max_differential)
            {
               price -= (revenue * (sint64)multiplier) / 100ll;
            }
            else
            {
               const sint64 proportion = ((sint64)differential * 100ll) / (sint64)max_differential;
               price -= (revenue * (multiplier * proportion)) / 10000ll;
            }
         }
     
         // Do nothing if comfort == tolerable_comfort         
      }

      // Add catering or TPO revenue
      if(catering_level > 0)
      {
         if(wtyp->get_catg_index() == 1)
         {
            // Mail
            if(journey_minutes >=welt->get_settings().get_tpo_min_minutes())
            {
               price += (sint64)(welt->get_settings().get_tpo_revenue() * 1000);
            }
         }
         else if(wtyp->get_catg_index() == 0)
         {           
            // Passengers
            sint64 proportion = 0;
            // Knightly : Reorganised the switch cases to get rid of goto statements
            switch(catering_level)
            {

            default:
            case 5:
               if(journey_minutes >= welt->get_settings().get_catering_level4_minutes())
               {
                  if(journey_minutes > welt->get_settings().get_catering_level5_minutes())
                  {
                     price += (welt->get_settings().get_catering_level5_max_revenue() * 1000);
                     break;
                  }
               
                  proportion = (sint64)((journey_minutes - welt->get_settings().get_catering_level4_minutes()) * 1000) / (welt->get_settings().get_catering_level5_minutes() -welt->get_settings().get_catering_level4_minutes());
                  price += max((sint64)(proportion * (welt->get_settings().get_catering_level5_max_revenue())), ((sint64)(welt->get_settings().get_catering_level4_max_revenue() * 1000) + 4000));
                  break;
               }

            case 4:
               if(journey_minutes >= welt->get_settings().get_catering_level3_minutes())
               {
                  if(journey_minutes > welt->get_settings().get_catering_level4_minutes())
                  {
                     price += (sint64)(welt->get_settings().get_catering_level4_max_revenue() * 1000);
                     break;
                  }
               
                  proportion = ((journey_minutes -welt->get_settings().get_catering_level3_minutes()) * 1000) / (welt->get_settings().get_catering_level4_minutes() - welt->get_settings().get_catering_level3_minutes());
                  price += max((sint64)(proportion * (welt->get_settings().get_catering_level4_max_revenue())), ((sint64)(welt->get_settings().get_catering_level3_max_revenue() * 1000) + 4000));
                  break;
               }

            case 3:
               if(journey_minutes >= welt->get_settings().get_catering_level2_minutes())
               {
                  if(journey_minutes > welt->get_settings().get_catering_level3_minutes())
                  {
                     price += (sint64)(welt->get_settings().get_catering_level3_max_revenue() * 1000);
                     break;
                  }
               
                  proportion = ((journey_minutes - welt->get_settings().get_catering_level2_minutes()) * 1000) / (welt->get_settings().get_catering_level3_minutes() - welt->get_settings().get_catering_level2_minutes());
                  price += max((sint64)((proportion * welt->get_settings().get_catering_level3_max_revenue())), ((sint64)(welt->get_settings().get_catering_level2_max_revenue() * 1000) + 4000));
                  break;
               }

            case 2:
               if(journey_minutes >= welt->get_settings().get_catering_level1_minutes())
               {
                  if(journey_minutes > welt->get_settings().get_catering_level2_minutes())
                  {
                     price += (sint64)(welt->get_settings().get_catering_level2_max_revenue() * 1000);
                     break;
                  }
               
                  proportion = ((journey_minutes - welt->get_settings().get_catering_level1_minutes()) * 1000) / (welt->get_settings().get_catering_level2_minutes() - welt->get_settings().get_catering_level1_minutes());
                  price +=  max((sint64)(proportion * (welt->get_settings().get_catering_level2_max_revenue())), ((sint64)(welt->get_settings().get_catering_level1_max_revenue() * 1000) + 4000));
                  break;
               }

            case 1:
               if(journey_minutes < welt->get_settings().get_catering_min_minutes())
               {
                  break;
               }
               if(journey_minutes > welt->get_settings().get_catering_level1_minutes())
               {
                  price += (sint64)(welt->get_settings().get_catering_level1_max_revenue() * 1000);
                  break;
               }

               proportion = ((journey_minutes - welt->get_settings().get_catering_min_minutes()) * 1000) / (welt->get_settings().get_catering_level1_minutes() - welt->get_settings().get_catering_min_minutes());
               price += (sint64)(proportion * (welt->get_settings().get_catering_level1_max_revenue()));
               break;

            };
         }
      }

      money_to_string( money_buf, (double)price/300000.0 );
      buf.clear();
      buf.printf(money_buf);
      display_proportional_clip(offset.x + 170, yoff, buf,    ALIGN_RIGHT,    COL_BLACK, true);

      buf.clear();
      buf.printf("%d%%", wtyp->get_speed_bonus());
      display_proportional_clip(offset.x + 205, yoff, buf, ALIGN_RIGHT, COL_BLACK, true);

      buf.clear();
      buf.printf( "%s",   translator::translate(wtyp->get_catg_name()));
      display_proportional_clip(offset.x + 220, yoff, buf,    ALIGN_LEFT, COL_BLACK,    true);

      buf.clear();
      buf.printf("%dKg", wtyp->get_weight_per_unit());
      display_proportional_clip(offset.x + 360, yoff, buf, ALIGN_RIGHT, COL_BLACK, true);

      yoff += LINESPACE+1;


Edit: The basic formulation seems to be: base fare * 1000 + (percentage deviation from the speed bonus * speed bonus rating), + 1,500 / 3,000.

So, suppose that the base fare is 100. If the speed bonus speed is, say, 15km/h, and the convoy actually travels at 15km/h, the percentage deviation from the speed bonus is 0. 0 multiplied by 18 is zero, so we end up with 100,000 (being 100 * 1,000), to which we add 1,500 (101,500) and then divide by 3,000 to get 33. (This division of fares by a third is historical from Standard and I am not quite sure the reason for it).

Alternatively, suppose that the base fare is 100, but now the convoy travels at 30km/h. The percentage deviation from the speed bonus is now +100%. The formula then works out as follows: 100 multiplied by 18 is 1,800, to which we add the 1,000 to get 2,800 then multiply by the base fare of 100 to get 280,000. We then add the 1,500 and divide the whole thing by 3,000 to get 93.

This basic formula is the same as in Standard, where the code is:


else {
      // pay distance traveled
      const long dist = koord_distance( start, end );
      FOR(slist_tpl<ware_t>, const& ware, fracht) {
         if(ware.menge==0  ||  !ware.get_zwischenziel().is_bound()) {
            continue;
         }

         // now only use the real gain in difference for the revenue (may as well be negative!)
         const sint32 grundwert128 = ware.get_besch()->get_preis() * welt->get_settings().get_bonus_basefactor();   // bonus price will be always at least this
         const sint32 grundwert_bonus = (ware.get_besch()->get_preis()*(1000+kmh_base*ware.get_besch()->get_speed_bonus()));
         const sint64 price = (sint64)(grundwert128>grundwert_bonus ? grundwert128 : grundwert_bonus) * (sint64)dist * (sint64)ware.menge;

         // sum up new price
         value += price;
      }
   }

   // Hajo: Rounded value, in cents
   // prissi: Why on earth 1/3???
   return (value+1500ll)/3000ll;


In Experimental, we add comfort and catering (but after the speed bonus calculation), and we also vary the speed bonus rating depending on the distance, but the basic calculation of the bonus itself is the same.

Does this make sense now? The reason that I was initially confused is that I had forgotten that the fares were divided by three.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

#30
It still doesn't match the numbers I got, even when I seemingly neutralized comfort effects (I bet I didn't really though).

And anyway, even in Simutrans standard, the final result of SB deviation 100 still gives a bonus twofold greater than the base fare, and in experimental (with the 0.8.4 settings) a great deal more than that. Would you agree that in any case, this is way too much, so either fixing the code, or greatly reducing SB rating is called for?

I've also noticed in my tests that using the old default settings at least (where max/median SB distances are set 1000/1600, multiplier 300), this is much more sensible - if comfort is 255, at 100km journey, the <+100> fare shows to be only 27% greater than the <0> fare. Still a bit too much but much more sensible. However in 200km journey, this grows to 69%.

jamespetts

I don't understand, I have to say, why you are getting different figures to me - we are using the same pakset and the same executable (you are using 10.18?). Can you run again with a clean install of the pakset to see whether you have any rogue entries in simuconf.tab?

When you refer to "fixing the code" what do you mean exactly here? It is working as intended; do you mean that the system for calculating the speed bonus needs to be changed? If so, to what do you suggest that it be changed?

As to the distances for the speed bonus, the best solution might indeed be substantially to increase these so that the maximum speed bonus is only achievable at much longer distances. Do you have any particular figures in mind for this?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

ok, I just ran a clean install of 10.18 0.8.4 (however some settings may be affected by my simutrans folder in my documents or other location?).

Default distance settings: 16/300/1000 (min/med/max). changed to 4/75/250, start game enfore t/l at 1825. In the goods list, check: distance 75, comfort 255, catering 1; sb value 0 = fare 18.09$; sb value 100 = far 107.10$.

So these are the numbers I get. If these numbers are correct, and if the game indeed behaves like this, the final result seems to be that a journey that's twice as fast will gain almost tenfold the revenue. Even in the numbers you've given, there seems to be a very large increase in revenue, much more than 18% (93$=33$*2.81).

So if this is the case (and I must say I've never really witnessed this distinctively in real play, only in testing), then something is wrong I think - the revenue increase should not be so great. Should it? So the system should somehow be changed to reduce it, either by working the code if necessary (not sure how), or fixing the variables to get the desired effect (sb distance/rating). This is to my understanding.

Again I have to say, in the game itself, especially in BW, I've noticed no such problem that requires fixing... but that doesn't necessarily mean it's not there.


jamespetts

Quote from: asaphxiix on December 24, 2012, 02:43:55 AM
ok, I just ran a clean install of 10.18 0.8.4 (however some settings may be affected by my simutrans folder in my documents or other location?).

Default distance settings: 16/300/1000 (min/med/max). changed to 4/75/250, start game enfore t/l at 1825. In the goods list, check: distance 75, comfort 255, catering 1; sb value 0 = fare 18.09$; sb value 100 = far 107.10$.

Hmm. I am trying this from a different computer where I am staying at my parents' house, which runs Linux. The 16/300/1000 values, which are the default for 0.8.4, give the figures that I had reported previously. The numbers that you gave give 107.10c just as you have it, so we seem at least to be able to reproduce the figures consistently now.

QuoteSo these are the numbers I get. If these numbers are correct, and if the game indeed behaves like this, the final result seems to be that a journey that's twice as fast will gain almost tenfold the revenue. Even in the numbers you've given, there seems to be a very large increase in revenue, much more than 18% (93$=33$*2.81).

So if this is the case (and I must say I've never really witnessed this distinctively in real play, only in testing), then something is wrong I think - the revenue increase should not be so great. Should it? So the system should somehow be changed to reduce it, either by working the code if necessary (not sure how), or fixing the variables to get the desired effect (sb distance/rating). This is to my understanding.

Again I have to say, in the game itself, especially in BW, I've noticed no such problem that requires fixing... but that doesn't necessarily mean it's not there.

I don't think that the speed bonus rating figure was ever intended to be a percentage by which the fare increases if the speed reaches a particular amount: the basic formula is the same as in Standard, and is set out in my earlier post as below. It should be noted that, until about 2007, I think, the speed bonus speed was based on either the fastest speed actually obtained by a convoy of that way type (note the speed records that are still mentioned in Standard) or the average of the maximum speeds of all of the various vehicles available for that waytype at the relevant time. This was changed to a .tab file based system when somebody made a Concorde vehicle for pak64 which was excessively profitable.

What ought the differentials in the fares be, do you think, for speed? Might a solution be simply to add another parameter capping the effect of the speed bonus at x % of the base fare?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

I would think so. End-users often don't really mind formulas and how stuff works exactly - all we see is the end result, which it seems here, is that a faster convoy = much more money. Also, although I'm not a native English speaker, my intuitive interpretation about "18% speed bonus rating for pax" was that a faster convoy would get (at a certain proportion of base speed) 18% bonus to the fare. It seems that this is not the case, though I'm still not really getting what is the case - what is exactly the effect that speedbonus has/should have, if not a percentage by which the fare increases if the speed reaches a particular amuont?.

So I think some measure should be taken to counter this - the one you suggest sounds good enough :) Question is, what will be the cap? Perhaps we should take this to the EXP Discussion forum? My own opinion is that maybe 18% will suffice, but I can't really determine without trying :)

jamespetts

My suggestion is to have the cap as something that can be set independently in simuconf.tab as a max_speedbonus_percent_of_base_fare value. It then becomes a matter for each pakset author to find an appropriate figure. (Incidentally, the Standard code already provides for a minimum amount, as the speed "bonus" also provides a penalty when the speed is below the bonus amount).

It is quite possible that the speed bonus code was not designed to be used in the way in which it is now being used by Experimental, as, in Standard, the bonus amount refers to the maximum, not the average speed of the convoy. Until recently, it referred simply to the lowest top speed of the vehicles in the convoy, but now the convoy's weight and maximum speed of the ways are taken into account, too.

As to the level of the cap, the proposal is for the max_speedbonus_percent_of_base_fare to apply to all goods equally, not just passengers, so setting it at 18% would make this figure of 18% apply to cargoes whose speed bonus is 15% or 6% as well as passengers whose speed bonus is 18%.

Do you have any historical research on the maximum differential for different speeds? It is also possible, I suppose, that we should look again at the minimum figure as being too low. This is currently 1/10th of the base fare for trips below the speed bonus speed. Perhaps this, too, ought be set in simuconf.tab? What would you recommend that this figure be?

As to research, I have some information from "Applied Transport Economics" by Stuart Cole (ISBN 978-0749439644). In 2004, a trip from London to Oxford by coach took about 100 minutes and cost £12.00 at peak time and £7.00 off peak. A trip by train took 60-90 minutes and cost £31.00 at peak time and £16.50 off peak. The distance is about 50-60 miles, but the train takes a somewhat indirect route via Reading, whereas the coach takes a more direct route up the M40.

Another price versus speed comparison arises with aircraft. Before the service was withdrawn, a ticket for a Concorde flight from London to New York cost £8,200. This contrasts with £4,000 for a Virgin Atlantic "Upper Class" fare of a few years later (2005), somewhere between £1,847 and £6,642 for British Airways first class (non-Concorde - depending on whether the ticket was refundable and the time of the flight) and £200-£500 British Airways Economy class.

Taking out of account the economy fares, this represents an increase of anything from 23% to 340% on the various first class ticket prices for a trip of about 2 hours compared with a trip of about 5 hours.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

greenling

asaphxiix
my help at your projekt must i a little bit gear down.
I must first my Simutrans data new sorting.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

jamespetts

I am wondering whether the speed bonus needs to be reconsidered somewhat, following the above discussion. I have started a more general thread on this topic and invited discussion on it in the hope of reaching a useful conclusion. I should be interested in any input.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

I wonder whether speedbonuses having a maximum of 400% and a minimum of 25% (4x bonus and /4 penalty) would be sufficient, when combined with altering the speed bonus rating...?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

the numbers I'm using right now as basis for speed bonus and time tolerance:

speed bonus min/med/max distance: 10/420/868 km.
Speed bonus rating for pax: 6%, for other goods TBD. This seems to allow for up to 40% speed bonus for the maximum distance (a bit over 50% for median distance), I may increase this a bit.

local (0-100 km) journeys: 70% chance, Time Tolerance min 40, "waiting tolerance max. min" 80 (what does this field mean? I think it's just "Time Tolerance Max", but I don't see why it's named this way - isn't waiting included in the journey time calculation?).

mid-range (80-400km): 22%: 80-200 minutes

long dist. (360- km): 8% : 150-3200 minutes (this should allow a journey of say 1500km to happen within 53 hours, or 28 km/h).

I know that there's a problem with the time tolerance system, but I'm not sure about its nature - will my time tolerance values have the desired effect for extra long journeys? I do wish there were more than 3 levels for the time tolerance purpose. It just doesn't feel right giving the same tolerance range for journeys of 400 km and 1500 km (or more).

I still don't have a very clear understanding of how the speed bonus penalty works, trying to figure that out.

jamespetts

Thank you - that is useful! Do let me know when you have made more progress with the speed bonus for goods. Do you have any thoughts on the appropriate speed bonus for mail? 5%, perhaps?

As for the journey time tolerances - the essential nature of the problem is that the spread is too even. If we say, for example, that the journey time tolerance for long distance passengers is anything between half an hour and two weeks, the median value will be a week, which means that a very high proportion of "long distance" travellers will take excessively long journeys. What is needed is a system of biasing the range towards the lower end so that, for the same range as indicated, 95% of passengers (for example) will be generated with a tolerance of 3 hours or less, with the remainder having much longer tolerances. The exact figures I shall need to work out once I have finished calibrating the base level of passenger generation.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

Thanks James!

Yeah I think 5% should work for mail, or maybe 4%. I don't really have any research to base this on, but when trying to order a book from Amazon, I can choose between standard post (18-32 days) for 10$, or express (8-16 days) for 15$. So 5% should work, I guess, yeah.

I'm afraid I couldn't quite understand your explanation... If the range for long distance is say, 400-1500km (assuming 1500km is the longest journey allowed by the map), wouldn't the proportions of the journeys themselves be the same as the proportions of the time tolerance values?
meaning, the median/average value of the journeys themselves will be 950km, which supposedly matches the median value of one week tolerance?

assuming a normal distribution of journeys between 400-1500km, why would we want 95% of them to have the lowest tolerance value?

jamespetts

For mail, don't forget that we are simulating the roles of the transport companies, not the Post Office, so what end users are charged for conveyance may have little relationship to what transport providers will be paid.

The answer to your question is that very few people actually make journeys that take that long. Only a tiny proportion of people should be prepared to travel for more than a few hours. If people can go thousands of kilometers in a few hours, far, far more people will travel thousands of kilometres than if doing so takes weeks. Likewise, if going from the City of London to High Barnet (formerly Chipping Barnet) takes a whole day (as it did in the 18th century), only a fraction of even "long distance" travellers should be prepared to travel that far, whereas, if it takes an hour or so, a high proportion of "long distance" travellers, and a good proportion of "medium distance" travellers should be prepared to do it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

right... so in our current state detailed above....

for a 1500km journey - say it takes 1750 minutes, and the time tolerance is 500-3000 minutes, then half of the people wanting to do it will do it, right? but if the range is 500-2000 minutes, then only 16% of the people (the people who drew 1750-2000 tolerance) wanting to do it will do it? This sounds right to me. But I see the problem, there's no way of reducing the proportional amount of people willing to go at 1750 minutes, without lowering the uppermost limit of the time tolerance (which will disable the said journey altogether at a certain duration, e.g 2050 min).

jamespetts

Yes, indeed - so I need to introduce a non-linear system; but I can't calibrate that until I've calibrated the raw passenger numbers, hence the passenger calibration thread's investigations into these things.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

jamespetts

Incidentally, with your figure of 6%, is it still necessary to have the 400% / 25% caps, do you think?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

asaphxiix

It would appear not, I suppose, though I don't really have the best understanding of the mechanism, I work "empirically"... :)

River

Hello,

I see there are big plans for balancing the pak set, but at the moment i can't seem to get any profit from moving passengers.  I tried to change the config files but i didn't manage to increase my income with passengers. If anyone got an idea about good settings i would like them.

River

jamespetts

The easiest thing would be using beginner mode, which multiplies all revenues by 1.5, but also cross-connects all the industries (that is, all industries accept freight from all other industries supplying the right type of freight).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Isaac Eiland-Hall

Quote from: jamespetts on June 19, 2015, 08:33:01 PM
but also cross-connects all the industries

Huh. Today I learned....

Spenk009

Circular bus routes and stations in the hearts of cities (not towns) help, using the "alternate directions" option. I am surprised, but I got a pax-only game going in 1925 with no help from the public hand just by this strategy.

River

How big are the cities you start in? because i now tried starting in 1930 on a small map, I had one city that would run a "profit" for the others i just had one bus covering multiple towns. I finaly made more money than the exploitation cost but still needed double that to also cover the monthly cost.

Spenk009

I did this in PakBritain. Only saw Experimental.. But there doesn't seem to be a minimum size, as long as the bus route is sufficiently long.

River

#53
I tryed that, and the busses are running a profit, but i need to few busses on a long line to make a profit with so many bus stops. atm i got 3 busses covering 10 cities/towns. At some point the waiting time is gone be to high for people to even take the bus. This will drop income even more.  At this point my income is around half of what i need to turn a profit, this is what i get with most of the games.

This of course is with the pak64.