**Introduction**Simutrans-Experimental will soon have a completely overhauled revenue system, which will replace the revenue system currently used in Simutrans-Standard with something that I think, at least, is somewhat more sophisticated. Although it is not yet quite finished, and has not yet been tested, the bulk of the work is now done, and I wanted to take a brief rest from coding to announce what I have done here. As ever, all feedback and suggestions are greatly appreciated - even better, however, would be offers to test it and help to calibrate it (changes to the calibration settings can be made in somuconf.tab) when it is released. More details on releases will follow in due course.

**Executive summary***Following requests after the original version of this message was posted, I have produced the following executive summary of the main new features.*- Revenue is based on actual, average speed, not maximum speed
- Average speed is recorded on a new graph
- The effect of speed on revenue varies with the distance: speed is more important at longer distances
- Goods/passengers pay for the route distance, not the straight line distance, but the route distance is capped at twice the straight line distance
- The revenue is reduced if the goods' origin stop is overcrowded (proportion of happy to unhappy users)
- Passenger vehicles have a comfort rating: more comfortable vehicles attract more revenue than less comfortable ones
- Comfort is more important the more time that the journey takes
- There is a new graph for comfort per line and per convoy
- Passenger convoys can have catering: this increases the comfort and produces revenue of its own.
- The revenue produced by catering increases with the length (in time, not distance) of the journey.
- There are 5 different levels of catering: the higher levels produce more revenue, but are only effective with longer journeys
- The mail equivalent of catering is the travelling post office: a convoy with TPO vehicles will earn extra revenue, but only for longer journeys

**Feature overview**In Simutrans-Standard, the revenue is calculated by taking the base price of the goods to be transported, multiplying that by the distance travelled, and then applying a "speed bonus", representing either an increase or decrease of revenue above or below that normal level depending on how fast that the

*maximum* speed of the convoy is compared to a pre-set database of speeds, specified in a file called speedbonus.tab. Different kinds of goods have a different speed bonus rating, expressed in percent, which affects how big that the speed bonus (or, as the case may be, penalty) is.

The New Revenue Model retains some of that basic logic, including the idea of a speed bonus, but, in the New Revenue Model, the speed bonus is based on the

*actual* speed travelled, rather than the maximum speed of the convoy. This is more realistic, and also makes the game a little more challenging for players, who have to adapt their

*network* to allow vehicles to travel at their maximum speeds. The bonus under the New Revenue Model is based on the

*average* speed of the line (or, if the convoy has no line, the convoy itself). The average speed of a convoy and a line is tracked and recorded on a new graph in the convoy's and line's windows: see the image below. Players can now have fun optimising their networks to maximise average speeds in order to get the most revenue out of their routes.

Also, unlike in Simutrans-Standard, the speed is more important the longer the journey. So, for a five minute 'bus ride across town, passengers will not pay significantly more for a fast ride than a slow one, but for a long train ride to the other end of the country and back, they will pay significantly more for a speedy journey. This also mirrors reality, and gives players more interesting and varied choices about the different kinds of vehicles to use for different sorts of transport. No longer is the fastest vehicle the best for everything: slower, cheaper, higher capacity vehicles are now preferable on shorter routes, while faster vehicles will come into their own on longer journeys, where they can get up to their full speed.

The New Revenue Model has a new way of dealing with the relationship between the route distance and the straight line distance between the origin and destination. In reality, the price paid to transport passengers or goods is always based on the route distance, but, in Simutrans, this can give rise to an exploit, where players use deliberately circuitous routes to earn a large amount of revenue from a trivially short journey. Previous efforts in Simutrans-Standard have involved using the straight line distance, but this has meant an unrealistic reduction in revenue, and the spectacle of goods earning a

*negative* revenue for certain parts of their journey, which was counter-intuitive, to say the least. The New Revenue Model's approach is to use the route distance, but subject to a cap based on a certain multiplier (currently 2) of the straight line distance: if, therefore, the actual route distance is more than twice the straight line distance, only twice the straight line distance is paid for. This, along with calculating the revenue for a journey at the

*end* of each leg, rather than at each station, should make for a more realistic and intuitive way of dealing with revenue, without allowing for any significant exploits.

Another feature of the New Revenue Model is that, if the passengers'/goods origin stop is crowded, the revenue will go down in proportion to the proportion of unhappy to happy people. This makes it important for players to have stops of the right capacity so that revenue is not impacted by the extra amount of time that goods are having to wait to be loaded, or the discomfort that passengers suffer at an overcrowded station.

On the subject of comfort, that is an integral part of the New Revenue Model, too, for passengers. Each vehicle has a comfort rating. For each length of journey, passengers have a certain level of comfort that they find tolerable. Below that, and they pay significantly less. Above that, they will pay a little more, but, just as in reality, Simutrans passengers are more motivated by avoiding discomfort than finding luxury (although this can be customised - see below). As with speed, what counts is the

*average* comfort for the line (or, if there is no line, for the convoy). As with the speed, this is because passengers buy their tickets on the basis of the overall reputation of their route, without knowing which particular vehicle will transport them that day. It also makes thing easier to track for players. Also as with speed, the line and convoy windows have a graph showing average comfort: see the picture below.

As with speed, this allows for more interest and variety as vehicles can more effectively be specialised for particular tasks: high capacity urban 'buses with plenty of standing room for short routes in busy towns, or luxurious coaches with no standing room and a trolley service for longer trips between towns. On the subject of standing room, vehicles can now have an overcrowded capacity: that represents the number of passengers that are allowed to stand (the figure is frequently quoted for 'buses). Overcrowding is a cheap way of accommodating extra passengers, but a standing passenger is a very uncomfortable one: if passengers have to stand too often, they will depress the comfort rating of the whole line, so a fine balance will have to be drawn between maximising capacity on shorter routes, but making sure that longer routes are not so overcrowded as significantly to depress revenue.

Catering is also a feature of the new revenue model. There are five catering levels (6 if one includes 0, which means no catering). Having a single catering vehicle in a convoy affects the whole convoy, so a buffet car, for example, can service an entire train. The 5 levels of catering represent a trolley service (1), a mini-buffet (2), a restaurant buffet (3), an at-seat meal service (4) and a luxury, Pullman-style catering service (5). For shorter journeys, of under an hour or so, adding catering brings in no significant revenue. However, as the journeys get longer, so passengers get hungrier, and buy more food on board. At shorter times, the higher levels of catering do not earn any more revenue than the lower levels, but, for longer journeys, the higher levels earn more per-passenger revenue than the lower levels. In addition to that, having catering makes the passengers feel more comfortable, too, and adds to the comfort rating of the line/convoy. Just as in real life, however, as new, faster vehicles become available, and journey times decrease, so passengers have less need for a meal on the move, and the opportunity for catering revenue becomes more limited.

Mail is not left out, either: trains can be fitted with travelling post office vehicles (mail's equivalent of catering), which earn extra revenue per mailbag - but only if the journey is long enough.

All that has already been coded (although not fully tested), and is awaiting release, which I hope will come shortly. What has yet to be done is to use some of those factors (comfort, average speed, overcrowding of stops) so that goods and passengers choose which route to take on the basis of which is the best according to those metrics (with some element of randomisation, too). That will also be used for passengers when deciding whether to take their private car or use the player's transport. Also yet to be done (not strictly part of the New Revenue Model, but closely related) is to restore Isidoro's original version of overcrowding handling, in which passengers who find themselves at an overcrowded station part-way through their journey leave and get a taxi the rest of the way, adding to the unhappiness at that station (similarly with goods, which, one can imagine, are transported by private hire lorry). The current system of refusing to route over overcrowded stations gives rise to intractable deadlocks (incomprehensible to all but the most seasoned players, and difficult for even them to solve), which are entirely unrealistic. Simutrans-Experimental will do away with all that, but not make it too easy for the players, since any discarded packets will increase unhappiness, and therefore adversely impact on the revenue of all routes that use that station.

Overall, therefore, the New Revenue Model should help to make Simutrans more varied and realistic, and simultaneously be easier to understand for players as well as providing players with new and interesting challenges (how to keep their average speeds up, or balance comfort with capacity, for instance). It will also give Pakset authors the opportunity to have fun in providing a greater variety of vehicles to meet the differing needs of different situations under the New Revenue Model.

**Technical details**A great amount of the calibration of the New Revenue Model will be customisable via settings in simuconf.tab. The best way of describing the techincal workings of the New Revenue Model is to reproduce the extensive documentation that I have written in the comments of my prototype simuconf.tab, which I reproduce below.

The New Revenue Model, as stated above, uses the existing speedbonus.tab, but measures

*average* speeds, rather than

*maximum* speeds. Therefore, in order to use the New Revenue Model effectively, a pakset will have to have a recalibrated speedbonus.tab, with much lower speeds, so that revenue is not excessively reduced: vehicles will hardly ever sustain anything near their theoretical top speeds. Some testing will be required to set the appropriate levels of average speeds in the speedbonus.tab file, and any help in that regard would be much appreciated. I recommend that there be no distinction made between different types of transport now that average speed is used, except for sea transport, which should continue to have slower speeds.

`# Settings for calibrating the revenue system`

#

# These settings calibrate the way in which revenue is calculated in the game. Changing

# them might make the game easier or harder, or, if they are changed in odd ways, make it

# behave eratically. Make sure to know what you are doing before changing these values.

# 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 tiles.

#

# 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 = 16

median_bonus_distance = 128

max_bonus_min_distance = 1024

max_bonus_multiplier_percent = 300

# For comfort, and the revenues from catering and travelling post offices, the game needs to

# know the length of a journey. This is done by dividing the number of tiles by the average speed

# in kilometers per hour of the line or convoy, one tile representing one kilometer. However, this

# can produce very long journey times: travelling by 'bus at an average of 45kph or so accross a

# village can produce a journey time of 15-20 minutes, for example. This would make less comfortable,

# but higher capacity vehicles for local transport pointless in most cases.

#

# To counteract this, the journey_time_multiplier_precent is used. This enables the journey times to

# be reduced uniformly to match the approximate scale of the map as played. The default is 30, which

# reduces journey times to a third (which is somewhat more realistic in comparison to the size of

# and space between towns on a typical Simutrans map).

journey_time_multiplier_percent = 30

# These next settings affect the interaction between comfort and revenue in Simutrans. Comfort only

# affects passenger traffic, for obvious reasons. Passengers have a certain level of comfort that

# they will tolerate for certain distances. All comfort ratings are in the range of between 0 and

# 255. At the tolerable level, the revnue is unaffected. At above the tolerable level, a luxury

# bonus is applied. At below the tolerable level, a discomfort penalty is applied. The values can

# be set to anything, but, to reflect real life, it is suggested that the discomfort penalty is

# significantly higher than the luxury bonus.

#

# tolerable_comfort_short is the tolerable comfort rating of a vehicle (0 - 255) for a journey of no

# more than tolerable_comfort_short_minutes.

#

# tolerable_comfort_median_short is the tolerable comfort rating of a vehicle for a journey of no more

# than tolerable_comfort_median_short minutes.

#

# tolerable_comfort_median_median is the tolerable comfort rating of a vehicle for a journey of no more

# than tolerable_comfort_median_median minutes.

#

# tolerable_comfort_median_long is the tolerable comfort rating of a vehicle for a journey of no more

# than tolerable_comfort_median_long minutes.

#

# tolerable_comfort_long is the tolerable comfort rating of a vehicle for a journey of at least

# tolerable_comfort_long minutes.

#

# For any journeys of a time between any of the values, a scaled proportion is taken.

tolerable_comfort_short_minutes=2

tolerable_comfort_short=15

tolerable_comfort_median_short_minutes=30

tolerable_comfort_median_short=60

#Two hours

tolerable_comfort_median_median_minutes=120

tolerable_comfort_median_median=100

#Five hours

tolerable_comfort_median_long_minutes=300

tolerable_comfort_median_long=160

#12 hours

tolerable_comfort_long_minutes=720

tolerable_comfort_long=220

# max_luxury_bonus_differential is the maximum number of comfort rating points above the tolerable level

# that affects the luxury bonus. Anything beyond that, and further added luxury makes no difference to the

# revenue.

#

# max_luxury_bonus_percent is the percentage increase in revenue from the maximum level of luxury specified in

# max_luxury_bonus_differential. So, if the tolerable comfort level for any given distance was 100, the

# max_luxury_bonus_differential 50, and the max_luxury_bonus_percent 50, then the revenue would increase up to

# 50% beyond the normal revenue for additional comfort up to 150, but would not increase further with any increase

# in comfort beyond 150.

max_luxury_bonus_differential=55

max_luxury_bonus_percent=40

# The discomfort penalty works in exactly the same way as the comfort bonus. max_discomfort_penalty_percent is the

# percentage decrease in revenue from the maximum level of discomfort specified in max_discomfort_penalty_differential.

max_discomfort_penalty_differential=200

max_discomfort_penalty_percent=95

# These settings control the revenue that can be earned from catering and travelling post offices. Note that catering

# vehicles on a convoy also increase the comfort by a small amount, which has an indirect effect on the revenue. These

# settings do not affect that: these settings affect the revenue earned from the catering itself: i.e., by selling food

# and drink.

#

# catering_min_minutes is the shortest journey time that will provide any catering revenue. Anything below that, and

# passengers will not bother to buy any food or drink at all.

#

# catering_level1_minutes is the journey time at which any convoy with a catering level of 1 or higher will earn, per

# passenger, the number of Simu-cents (1/100th of a Simucredit) specified in catering_level1_max_revenue.

#

# The same applies for each subsequent catering level: in other words, higher catering levels only earn more than lower

# catering levels on journeys of at least the catering_levelX_minutes (where X is the catering level in question).

#

# Between each level, the a scaled proportion is applied. So, for example, if catering_min_minutes is 100,

# catering_level1_minutes is 200, and the actual journey time is 150 minutes, then, any convoy with a catering level

# of at least 1 will earn 50% of the amount specified in catering_level1_max_revenue per passenger.

catering_min_minutes=60

catering_level1_minutes=90

catering_level1_max_revenue=150

catering_level2_minutes=120

catering_level2_max_revenue=250

catering_level3_minutes=150

catering_level3_max_revenue=350

catering_level4_minutes=240

catering_level4_max_revenue=400

catering_level5_minutes=300

catering_level5_max_revenue=475

# Travelling post office revenue is simpler than catering revenue. For every journey that mail makes in a convoy containing

# a travelling post office vehicle (that is, a mail carrying vehicle with a catering level above zero) where the journey time

# exceeds that specified in tpo_min_minutes, the trip will earn the amount specified in tpo_revenue, multiplied by the number

# of mail bags carried, in addition to the ordinary revenue.

tpo_min_minutes=120

tpo_revenue=300

**Known issues**Currently, the "list of all goods" will still display prices based on the existing speed bonus system, not that from the New Revenue Model. I have not yet investigated how to change that, but would appreciate any pointers. It would have to take a number of additional parameters, based on the journey distance and comfort rating and catering to be able to give accurate figures, and could get quite complicated. Another possibility is to go the other way, and simplify the list, giving only the base prices, rather than the adjusted prices, but that may then make it hard for players to understand what prices that they will get in certain conditions. Any feedback on this aspect would be appreciated. For those who play often, how many use the "list of all goods" regularly to make decisions based on the pricing information?

Also, it might be helpful to have some extra graphs in the convoy and line windows, but, the last time that I tried to add an extra graph to the convoy window, it seemed to overspill, so I shall have to consider whether that is a possibility. Useful graphs might include average journey times and average catering levels. Any feedback on whether those, or what other graphs might be useful would be much appreciated.

The calculation of the revenue under the new system is considerably more complicated computationally than under the old system, but, set against that, it is only called once for every leg of the journey, rather than for every stop along the way (hop). I do not know what the overall effect on performance is, as I have not been able to profile, but, in my very brief tests, the performance has seemed acceptable in debug mode.

Finally, for some strange reason, the little floating numbers that are supposed to appear when a convoy earns revenue have stopped working when I switched to the new revenue model. I copied the code for booking the final revenue exactly from the old code, so I do not quite understand what the problem is. I should be very grateful if anyone familiar with the code could give me any pointers (the incomplete code for the New Revenue Model is currently on my

Github repository. Any comments/suggestions on the code would also be appreciated.