Four economic tweaks for gameplay and realism

Topic: Four economic tweaks for gameplay and realism (Read 11643 times) previous topic - next topic

Four economic tweaks for gameplay and realism

December 04, 2008, 06:59:45 pm

Below, I suggest four enhancements to the Simutrans economy that, I hope, will be both simple to implement and give a dual advantage of added realism and enhanced gameplay. I have suggested these together in one post instead of in several separate posts, because, although in one sense they are separate suggestions, they are closely linked with each other, and some would not work properly (or lose part of their raison d'etre) without the others being implemented.

1. Make the effect of the speed bonus directly proportionate to distance travelled

Description: Currently, the speed bonus applies equally to journeys of all lengths: if this suggestion were implemented, the shorter the journey, the less relevant that the speed bonus would be to the calculation of the revenue, and the longer the journey, the more relevant (up to a certain limit of, perhaps, the equivalent of say 500km). The exact degree of the falloff could be set by a parameter in simuconf.tab.

Realism advantages: In reality, p****engers care far more about the speed and comfort of their journey if it is a long one than if it is a short one. Slow transport for time-sensitive goods matters far more if the journey is over hundreds of kilometres than if it is over a few kilometres. In reality, transportation networks use very different sorts of vehicles and infrastructure for local journeys than long-distance journeys, and, particularly for p****engers, use higher density, but slower and less comfortable vehicles for local journeys than for long distance journeys.

Gameplay advantages: At present, the speed bonus and revenue system together make long distance transport orders of magnitude more profitable than local transport, to an extent that the game seems unbalanced. (See, for instance, the discussion here). It can be extremely difficult to make shorter distance transport profitable. Reducing the effect of the speed bonus could increase the relative profit margin on short distance routes by making cheaper, higher capacity but slower vehicles earn higher revenues than they can at present. The fun in a game comes from making interesting decisions: if the speed bonus matters more and more the longer that the journey, the decision as to which vehicle to use for each route becomes far more interesting, as there is an additional factor to consider. A wider variety of different types of vehicles become useful, since the most profitable type of vehicle will depend on the route's length. Local commuter trains, for example, will be useful for shorter routes, whereas express trains more useful for longer routes. A player might have to strike interesting compromises between vehicles that travel different distances in different parts of the journey. Furthermore, if the disparity in profitability between long- and short-distance travel is narrowed, a wider variety of networking designs become viable, making the game more interesting by increasing overall variety. It has sometimes been remarked that Simutrans is mainly about long-distance transport: that may be so, but, both in reality and in the game as it currently stands, long-distance transport relies on short-distance transport to be viable: goods and (especially) p****engers need to be transported between their individual origins and destinations and major transport hubs before embarking upon long journeys. Besides, nothing in this suggestion would undermine any of the long-distance aspect of gameplay, or be so complicated to implement that it would take much developer time. Indeed, if it was linked to a preference in simuconf.tab, the player would be able to turn off the effect entirely if it was not desired.

2. Increase maintenance costs of obsolete vehicles

Description: The maintenance costs of all vehicles marked "obsolete" would be multiplied by a factor specified in simuconf.tab, with a default of, perhaps, 1.5 or 2.

Realism advantages: In reality, older vehicles need more maintenance. Obsolete vehicles in particular, for which spare parts are no longer readily produced and whose manufacturers may long since have gone out of business, cost a great deal more to maintain than current vehicles. It is not realistic that Stephenson's Rocket has the same maintenance cost in 2030 as it does in 1830.

Gameplay advantages: If, as suggested above, the speed bonus effect is made directly proportionate to distance travelled, the use of cheap but highly obsolete vehicles may become the most profitable option for very local transport. The speed bonus system was designed to disincentivise the use of very old vehicles, but if its effect is weakened for short-distance transport, an alternative needs to be considered. It is intuitive that an obsolete vehicle's maintenance should be considerably higher than that of a current vehicle, and should not cause players undue confusion (indeed, the present state of affairs of not having costs increase in that way might cause as much, if not more, confusion than what is proposed here). Such a measure would also mean that the difference between current and obsolete vehicles becomes more important than it currently is. If the multiplier were able to be set via simuconf.tab, players would be able to adjust the value to taste, and players who preferred not to have the effect at all could simply set the value to 1.

3. Make p****engers and mail less likely to be bound for small, distant towns

Description: As I understand it, the likelihood of p****engers and mail being bound for any given town is directly proportionate to the size of that town ("the size factor"), and inversely proportionate to the distance to that town ("the distance factor"). That, in itself, is sensible, but, what I propose is making the effect stronger, by making the distance factor stronger the lower that the size factor is. It may help to express it as an algebraic equation.

P: probability of p****engers/mail being bound for the town
D: distance from the origin of those p****engers/mail to that town (possibly multiplied by an adjustable factor)
S: size of the town (possibly multiplied by an adjustable factor)

Current model: P = S / D
Proposed model: P = S / (D / S)

Realism advantages: In reality, people are far more likely to travel a long distance to go to a large town than a small town. That is not adequately reflected by a greater likelihood of going to large towns combined with a lesser likelihood of going to distant towns, since this is not how people actually behave: the likelihood of travelling from London to a tiny village in the Highlands of Scotland is less than the likelihood of a person from London travelling to Berlin divided by the size difference between Berlin and the tiny village, and less than the chances of a person from London travelling to a small village on the outskirts of London divided by the extra distance to the Highland village. At present in Simutrans, there are large numbers of p****engers travelling to distant, but small, destinations, which is not terribly realistic. The larger the town, the more likely that people are to travel to it, but, moreover, the more likely that people are to travel to it in spite of the distance.

Gameplay advantages: The network effect of p****engers and mail is one of the most important aspects of Simutrans: unlike in other transport simulators, p****engers have a destination, and, the more destinations that one's transport network serves, the more p****engers that will be interested in travelling on it. That effect helps to make strategic planning and careful network design (all interesting decisions) more important in Simutrans than in other simulators. However, it is well-known by frequent players that this network effect can sometimes be exaggerated: especially when playing on larger maps (which, in and of themselves, are more fun because of the exponentially greater number of network options with the increasing size), once a network of p****enger transportation p****es a certain level, the demand gets so high that the game ceases to be financially challenging, the challenge instead being to keep the stations from becoming overcrowded (which challenge is itself rather limited in terms of fun, partly because there is no real disadvantage to the player in having overcrowded stations and partly because, in larger towns, the overcrowding becomes so extreme that it can be difficult to address with anything approaching realistic levels of service). It might be said that that is an interesting challenge in and of itself, and it is up to a point, but it can also become frustrating, especially when the degree of overcrowding is so high as to make the necessary remedial measures reduce substantially the realism of the network. If p****engers become less likely than they are at present to travel to distant smaller towns, the exponentiality of the network effect is tamed somewhat, keeping p****enger number growth somewhat more linear, but also more tied to the number of large cities served.

4. Reduce the speed bonus for p****engers/mail/goods originating from an overcrowded station

Description: At present, there is no particular penalty (other than stilted town growth) to having an overcrowded station. I suggest that the extent to which a station is overcrowded should affect the speed bonus. In particular, the speed bonus of cargoes transported from an overcrowded origin station should be reduced in proportion to that overcrowding (multiplied by an adjustable factor in simuconf.tab). This should link in with the suggestion above in relation to speed bonuses and local transport, such that the overcrowding penalty for speed bonuses is equally reduced in significance for shorter journeys as the speed bonus itself.

Realism advantages: If the speed bonus is supposed to reflect the comfort, speed and convenience of travel, then if it is based only on the maximum speed of the vehicles itself, a crucial element is missing: the time and convenience of boarding/loading in the first place. If, for example, a p****enger has to wait hours at a terribly crowded station because three full trains p**** before there is enough room on a train to get on, the fact that the journey thereafter is fast and relatively comfortable is rather moot. There should, as discussed elsewhere (in a thread that I cannot currently find), be some sort of penalty for overcrowded stations, because, in reality, an overcrowded station is less efficient for the p****engers/consigners of cargo than one that is not overcrowded.

Gameplay advantages: If there is little or no revenue incentive to relieve overcrowding at stations, players can feel somewhat uneasy that they are able to make large profits despite there being something wrong with their network in a very real way, and, as discussed above, the present situation leads to an economy in which revenue generation is very challenging at the beginning of the game, but trivially easy once one has p****ed a certain threshold. An effective penalty for overcrowding would have the effect of keeping the game financially challenging in the later stages, making the game more rewarding. If there was a substantial financial incentive to reduce overcrowding, the game would not only become more challenging, but involve more interesting decisions, since the player would have to plan capacity carefully before expanding, and weigh capacity considerations against capital and maintenance costs in ways which are currently, at best, optional. As with the other suggestions, if the extent to which overcrowding affects the speed bonus is set in simuconf.tab, it would be easy to adjust this effect to taste, and even turn it off entirely. Finally, if overcrowding becomes less common as a result of suggestion no. 3 above, it makes more sense to penalise it, as overcrowding would be more of an indication of a true problem than it is at present.

Re: Four economic tweaks for gameplay and realism

Reply #1 – December 04, 2008, 07:26:40 pm

I haven't read it all but I like a lot your idea.
Never thought about them! 1 & 4 is particularly interesting.

I think too this game needs financial penalty for having over crowding stations.
+ There's also way to detour slower city growth. Just build city rail station away
   from the city area. One does not even have to worry about the upgrading
   station capacity since even the most basic accept virtually infinite p****engers.
   In this regard, upgrading station capacity isn't very meaning full. It does still
   grow fast enough.

Overall you tell everything I wanted to say!

Re: Four economic tweaks for gameplay and realism

Reply #2 – December 04, 2008, 07:31:05 pm

Quote

As I understand it, the likelihood of p****engers and mail being bound for any given town is directly proportionate to the size of that town ("the size factor"), and inversely proportionate to the distance to that town ("the distance factor")

Then unfortunately you don't understand it well. Distance is not involved in the calculations. Realistic as it might be, it's simply too time and/or memory consuming to calculate. The size of the town is not directly involved, every building in the town has a weight factor.

Re: Four economic tweaks for gameplay and realism

Reply #3 – December 04, 2008, 09:44:08 pm

@jamespetts: One extension request per topic, please. You can edit you own post (remove parts and move them to new topics) in order to comply with that rule.

EDIT: jamespetts explained the issue to me, and I have to admit that it makes sense to keep at least some of these things together. But an extension request that touches many areas may become too complicated to discuss.

Re: Four economic tweaks for gameplay and realism

Reply #4 – December 04, 2008, 09:52:32 pm

Quote from: Combuijs – on December 04, 2008, 07:31:05 pm

Then unfortunately you don't understand it well. Distance is not involved in the calculations. Realistic as it might be, it's simply too time and/or memory consuming to calculate. The size of the town is not directly involved, every building in the town has a weight factor.

Hmm, forgive me, in that case, for having mistaken the analysis of the mechanics of the game. Without having read all the code it is not always easy to understand what is happening under the hood! As to the building weightings, I was aware of that element: the "size" of the towns to which I referred was meant to be an indication of the cumulative effect of all of those building weightings. Unless I am missing something, the fact that it is done that way does not make a difference as to the suggestion.

The distance issue is another matter: I was not aware that distance was not a factor at all. However, I am not convinced that it is too computationally expensive to work out the distance between different towns. The simple solution is to calculate the distance between each town and each other town once, when the map is generated, and keep a table in memory somewhere. The distance between one town and another would be based on the straight line distance (i.e. shortest distance traversing tiles: there should already be an algorithm for this somewhere when building inter-city roads and for AI players) between the respective towns' town halls. Whenever a new town is added, the calculations could be performed afresh just for that town (the distance between that town and every other town).

Then, when calculating distance, all that the buildings need to do is factor in the distance between it and the possible destination building's town when determining how to generate p****engers and mail. A simple table lookup should not be computationally expensive at all, and the table itself (which need be no more than one array of integers per town) would take little memory. The only noticeable impact on performance would be at map creation, and whenever (rarely) a new town is added.

Re: Four economic tweaks for gameplay and realism

Reply #5 – December 05, 2008, 12:01:55 am

As far as I know p****enger generation works as follows:

P****enger generation computations are calculated per station. Based on the buildings within reach of a station, every station gets an accumulated weight factor. P****engers destinations (from a station) are then distributed using that weight factor. The main advantage of this method is that you need a (permanent) list with one weight factor per station. Say we have N stations, then we need a list of N weight factors.

If you want to take distances in account you basically have two methods:

1) For every station you generate a temporary list in which you correct the weight factor with distance. You'll have to do this every time you generate p****engers for every station. This is too time consuming.
2) Keep a permanent list of destination stations per station where you correct the weight factor with distance. This will lead to a list of N * N weight factors. When you have 10 stations this is no problem, when you have 100 stations you're getting in trouble and when you have 1000 stations you have just blown up the system. So this is too memory consuming.

Re: Four economic tweaks for gameplay and realism

Reply #6 – December 05, 2008, 09:48:45 am

The second point is very interesting..

Quote

2. Increase maintenance costs of obsolete vehicles

imho, this is quite reasonable, and it will force players to update vehicles even if they are profitable. It's a new challange for them. On the other hand, it only has sense if you're playing with timeline option, hasn't it?

Another important point is that in some epochs there aren't enough vehicles available among can choose . In early 1900s, and basically from 1900 to 1940, at least in pak64, AFAIR. That's the main handicap. But if you can configure this option from simuconf.tab, there's no problem. Not enough vehicles, no increase. As simple as that....

Re: Four economic tweaks for gameplay and realism

Reply #7 – December 05, 2008, 10:35:22 am

Quote

I think is quite reasonable, and it will force players to update vehicles even if they are profitable

Yes, true, but on the other hand it causes a lot of micromanagement, which makes gameplay tedious for large games.

Re: Four economic tweaks for gameplay and realism

Reply #8 – December 05, 2008, 10:41:10 am

Especially when you use many trucks....

Re: Four economic tweaks for gameplay and realism

Reply #9 – December 05, 2008, 10:46:51 am

to vilvoh
After 1900 there are enough locomotives one can choose. More than 5.

Increased maintenance for retired engines would force me to drop more profitable old engine and to use new less profitable one.
If a player has got a lot of money, there is almost nothing that presses him to upgrade engines.
It would be very good challenge from the economical point of view.

As I "studied" in NiNiWania, two times stronger newer engine has more than two times higher costs and it cannot drag more than two times more cargo. Its profit is smaller than in the case of two old engines. So I have no need to upgrade engines except if I have to drop the number of trains because of full track and station capacity.

So, I vote for rising costs of retired engines and vehicles. It has a sense only in timeline games, of course .

to Combuijs
What is "large" game?

Today I have to change about 400 trains with kkStB110 engines for about 150 trains with new engines (timeline, year 1893).
Work for several hours of real time and 3-5 years of gameplay.
And I do not consider it as a large game.

Re: Four economic tweaks for gameplay and realism

Reply #10 – December 05, 2008, 11:01:43 am

Well It depends on several factors:
- Number of vehicles available.
- Penalty factor you have in simuconf.tab.
- If you want to update the vehicles or not.

Quote from: Lodovico – on December 05, 2008, 10:46:51 am

to vilvoh
After 1900 there are enough locomotives one can choose. More than 5.

Yes but you have only a few trucks, at least in pak64...I suppose we're refering to all kinds of vehicles.

Quote from: Lodovico – on December 05, 2008, 10:46:51 am

I have no need to upgrade engines except if I have to drop the number of trains because of full track and station capacity.

I think Simutrans compensates with the speedbonus, that unleashes player's greed to earn more money, so he must upgrade vehicles for transporting goods faster and getting that extra money.

Another point, I guess you can also use negative values for this parameter.

Quote from: Lodovico – on December 05, 2008, 10:46:51 am

to Combuijs
What is "large" game? [..]

I guess he means a game with a huge amount of different vehicles (trains, planes, trucks, buses, trams, etc..)

P.D: Now we realize how usefull is and surely will be NiNiWania for analyzing Simutrans gameplay...

Re: Four economic tweaks for gameplay and realism

Reply #11 – December 05, 2008, 11:12:56 am

Quote

Work for several hours of real time

Well, that's bothering me!

Re: Four economic tweaks for gameplay and realism

Reply #12 – December 05, 2008, 12:27:35 pm

I like your idea No. 1. Curently there is no distinct difference between vehicles for short distance and long distance. Your idea could really make vehicle choice more interesting.

But I don't like No.2, as it forces players to do something... This would be clearly annoying for me, especially having a large game.

Re: Four economic tweaks for gameplay and realism

Reply #13 – December 05, 2008, 04:32:29 pm

Thank you, everyone, for all your replies. I will have to think a little more about the distance issue: I still suspect that there should be a way to solve it.

As to nos. 1 and 2: there are obviously differing opinions about the desirability of obsolete vehicles having higher maintenance costs. Obviously, it will only make sense on a game with a timeline. Some people like the idea, others consider it to require excess micromanagement. However, in view of the facts: (1) that it should be relatively easy to code; and (2) of the fact that, as proposed, it would be trivially easy to turn it off (perhaps with it automatically turned off whenever a timeline is not used), there is every reason to add it to satisfy those who do want it.

My view on the micromanagement issue, incidentally, is this: in any event, there will be an incentive to replace obsolete vehicles, because the introduction of newer vehicles makes older vehicles less profitable because of the speed bonus. That will involve an element of micromanagement all of itself, and that is considered an acceptable degree of micromanagement (some have requested - quite understandably - an automated way of doing this to reduce micromanagement - this would also be sensible, if feasible). As far as I can tell, the game, at least with the timeline enabled, was always designed to encourage players to upgrade vehicles. Vehicles become obsolete, after all, for a reason. The increase of maintenance costs for obsolete vehicles should not cause significantly more micromanagement (in principle, at least) than the existence of the speed bonus itself.

However, in cases where the speed bonus has little impact (either, as things stand now, for bulk goods, or, as things will be if my suggestion no. 1 is implemented, for local traffic), the incentive to replace obsolete vehicles is impaired, and the number of interesting decisions thereby reduced. If my suggestion no. 1 is implemented, this will be more of an issue than it is at present. The game is evidently designed to be at least partly realistic, and also to be economically challenging. Both of those aims will be more effectively achieved if obsolete vehicles cost more to maintain than current vehicles.

I realise, of course, that, as with all forms of entertainment, what people enjoy is inherently subjective. That is evident from the differences of opinion on this thread. That is why it is better to have a feature such as this customisable, such that those who dislike it can disable it, and those who like it can enable it.

Re: Four economic tweaks for gameplay and realism

Reply #14 – December 05, 2008, 08:40:13 pm

Some clarification:
1) The distance dependent speed bonus would just make a higher revenue for longer distance (since it would get more and more birdlike distance). Moreover it would require some extra field which would eat up considerable memory and CPU time. (There is a patch, serach for it in the old forum).

2) Maintenance cost for old vehicles could be easily increased. However, in Simutrans vehicles are usually available for a large time period. Moreover, the speed bonus does exactly this penalizing. This is the aim of the speedbonus, penalizing old vehicles, not getting extra income.

3) The p****engers to certain towns involve mainly the size of the town (the larger the more likely) and the distance (close than 100 tiles more likely). Thus I would consider this a fulfilled.

Re: Four economic tweaks for gameplay and realism

Reply #15 – December 05, 2008, 09:46:49 pm

So second point is already implemented, as currently the speedbonus is loaded from a file, isn't it?

Re: Four economic tweaks for gameplay and realism

Reply #16 – December 06, 2008, 01:32:36 pm

Quote from: prissi – on December 05, 2008, 08:40:13 pm

Some clarification:
1) The distance dependent speed bonus would just make a higher revenue for longer distance (since it would get more and more birdlike distance). Moreover it would require some extra field which would eat up considerable memory and CPU time. (There is a patch, serach for it in the old forum).

Did you mean this one? If so, judging at least by the description given, it is very different to what I proposed in no. 1. Also, what do you mean by "birdlike" here? I am having trouble understanding your first sentence. Thank you for replying, though :-)

Re: Four economic tweaks for gameplay and realism

Reply #17 – December 06, 2008, 01:37:40 pm

Birdlike = direct = Euclidean = ... (Δx² + Δy²)^½

~~I can't find any good comprehensive article~~, but you might want to take a look at Manhattan distance, Chebyshev distance and the likes. (iirc Simutrans uses manhattan)

http://www.simugraph.com/h-world/pmwiki/pmwiki.php?n=Library.Formulas

Re: Four economic tweaks for gameplay and realism

Reply #18 – December 06, 2008, 04:14:19 pm

This appears to be the method in the code dealing with calculating the revenue from each journey:

Code: [Select]

sint64 vehikel_t::calc_gewinn(koord start, koord end) const 
{
	//Calculate profit
	// may happen when waiting in station
	if(start==end) {
		return 0;
	}

	//const long dist = abs(end.x - start.x) + abs(end.y - start.y);
	const sint32 ref_speed = welt->get_average_speed( gib_besch()->get_waytype() );
	const sint32 speed_base = (100*speed_to_kmh(cnv->gib_min_top_speed()))/ref_speed-100;

	sint64 value = 0;
	slist_tpl<ware_t> kill_queue;
	slist_iterator_tpl <ware_t> iter (fracht);

	while( iter.next() ) {

		const ware_t & ware = iter.get_current();

		if(ware.menge==0  ||  !ware.gib_zwischenziel().is_bound()) {
			continue;
		}

		// now only use the real gain in difference for the revenue (may as well be negative!)
		const koord zwpos = ware.gib_zwischenziel()->gib_basis_pos();
		const long dist = abs(zwpos.x - start.x) + abs(zwpos.y - start.y) - (abs(end.x - zwpos.x) + abs(end.y - zwpos.y));

		const sint32 grundwert128 = ware.gib_besch()->gib_preis()<<7;	// bonus price will be always at least 0.128 of the real price
		const sint32 grundwert_bonus = (ware.gib_besch()->gib_preis()*(1000+speed_base*ware.gib_besch()->gib_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;
}

I am looking into whether a small tweak to that could acheive what I am suggesting at no. 1, and, if so, what effect on play that it would have. Does anyone have any suggestions as to the best way of going about it? The fact that the code was written with German field/method names is not helpful for an English speaker, but thank goodness for Google translations ;-)

Re: Four economic tweaks for gameplay and realism

Reply #19 – December 06, 2008, 08:24:53 pm

No, there is no easy way to achieve this. YOu have to go the way of the patch, i.e. extend the ware field with one additional field for timekeeping purposes and have to change the routines that join goods. When I denied the patch the last time, it was exactly for these reasons.

Re: Four economic tweaks for gameplay and realism

Reply #20 – December 07, 2008, 11:03:20 am

Quote from: prissi – on December 06, 2008, 08:24:53 pm

No, there is no easy way to achieve this. YOu have to go the way of the patch, i.e. extend the ware field with one additional field for timekeeping purposes and have to change the routines that join goods. When I denied the patch the last time, it was exactly for these reasons.

I'm not sure that I follow, I'm afraid - what exactly was the reason that you denied the patch the last time? As I wrote before, that patch does something completely different to what I'm seeking to achieve: that patch tries to make the actual time taken to transport the goods feature in the revenue calculation, like Transport Tycoon, etc.. I am not trying to do that. I am just trying to make the speed bonus less and less relevant the shorter the journey. From my preliminary testing, that seems as if it might require awarding a supplemental bonus for all local transport no matter what its speed to prevent local transport that would otherwise have been profitable because of the large speed bonus being rather less profitable, although that should probably be an adjustable factor, since it all rather depends on the paksets.

Re: Four economic tweaks for gameplay and realism

Reply #21 – December 07, 2008, 02:16:59 pm

I have created a patch to the code which gives effect to suggestion no. 1. I have tested it briefly, and the code compiles, and runs without either crashing or being noticeably or measurably slower than the default version. I have noticed, however, that, on Pak128 (which I am using for testing), with the older vehicles downloaded from addons.simutrans.com installed, the speed bonus settings are far too low: the road speed bonus in 1900, for instance, is 21kph, whereas the ordinary 'busses have a maximum speed of 88kph, giving a m****ive speed bonus to all 'bus traffic. Reducing the effect of the speed bonus locally then means that that bonus is reduced, having the opposite effect desired. For this patch to have the desired effect, the settings in speedbonus.tab will have to be set more accurately to reflect the speeds of the available vehicles in the era. If that is done, the "local_bonus_supplement" value can then be reduced.

Edit: I have now found how to create a patch file: it is here. Here is the code (all in the simvehikel.cc file):

(1) Field declarations

Code: [Select]

//@author: jamespetts
//These values should in due course be read from simuconf.tab, not just hard-coded.
long min_bonus_max_distance = 16;
long max_bonus_min_distance = 256;
float local_bonus_multiplier = 0.75; // 0 = No local bonus. 1 = full speed bonus automatically applied to all local transport (below min_bonus_max_distance, proportionate thereafter).
uint16 local_bonus_supplement = 0; //A supplementary bonus for local transportation, if needed, to compensate for not having the effect of the long-distance speed bonus

(2) Revenue calculations:

Code: [Select]

while( iter.next() ) {

		const ware_t & ware = iter.get_current();

		
		if(ware.menge==0  ||  !ware.gib_zwischenziel().is_bound()) {
			continue;
		}

		// now only use the real gain in difference for the revenue (may as well be negative!)
		const koord zwpos = ware.gib_zwischenziel()->gib_basis_pos();
		const long dist = abs(zwpos.x - start.x) + abs(zwpos.y - start.y) - (abs(end.x - zwpos.x) + abs(end.y - zwpos.y));

		const sint32 grundwert128 = ware.gib_besch()->gib_preis()<<7;	// bonus price will be always at least 0.128 of the real price
		
		//@author: jamespetts
		const uint16 base_bonus = ware.gib_besch()->gib_speed_bonus();
		uint16 adjusted_bonus = 0;
		local_bonus_supplement = local_bonus_multiplier * base_bonus;
	
		if(dist <= min_bonus_max_distance)
		{
			//If distance of journey too low, disapply speed bonus entirely, but apply local bonus supplement instead.
			adjusted_bonus = local_bonus_supplement;
		}
		
		else if(dist > min_bonus_max_distance && dist < max_bonus_min_distance)
		{
			//Apply proportionate mix of local bonus supplement and conventional speed bonus. 
			//The effect of this code is that, if the local supplement is set to 1, a 100% speed bonus is applied until max_bonus_min_distance is reached.
			//For that reason, it is better not to set local supplement to 1. 
			float proportion_distance = dist / (max_bonus_min_distance - min_bonus_max_distance);
			uint16 intermediate_bonus = base_bonus * proportion_distance;
			uint16 intermediate_local_supplement = local_bonus_supplement * (1 / proportion_distance);
			adjusted_bonus = intermediate_bonus + intermediate_local_supplement;
		}

		else if(dist >= max_bonus_min_distance)
		{
			//Apply full speed bonus in conventional way.
			adjusted_bonus = base_bonus;
		}

		const sint32 grundwert_bonus = (ware.gib_besch()->gib_preis()*(1000+speed_base*adjusted_bonus));
		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;
}

I hope that I have adequately complied with the coding style guidelines - I could not find the post setting them out, so do excuse me if I have made any mistakes.

Edit: I have now posted an updated version of the patch here, which reads the values from simuconf.tab.