Revenue-problem in Exp7.3

[AvG]

I restarted 7.3 a couple of times because I had financial problems.
Again in the running one.
I use now maintenance 900, 1 tile = 1 km and bits per month 21.
Analysing the problem leads to the following conclusion:
It seems there is a BIG error in the revenue math.
Line-revenues are made up by the sum of all line-vehicle-revenues. (As far as I know)
From 13 road-lines it is probably correct for 11.
One line however shows in the LineManagement-window a revenue of 216, where the vehicle-total is 493.
The 13th line is even worse. The 2 vehicles are making a revenue of 304 and the LineManagement window
shows a NEGATIVE value of -1037
Also the Finance-window shows for the previous month a revenue of -5013
With this problem 7.3 is not playable.
Can I do something wrong? The vehicles I altered like written in an other entry. They act normal in their own
windows.
AvG

Edit: A quick glance in an other 4tiles/km scenario shows several negative entries in the LineMan-window

[jamespetts]

AvG,

thank you for your report. Would it be possible for you to upload a saved game so that I can try to find the problem? And, can I clarify: the problem is that the line management graphs/figures are not showing the correct sum of the profits of all the individual vehicles in the line?

One thing to remember is that, in 7.2 and later, any passengers/goods that are discarded en route because they have to wait too long or because they reach an overcrowded station/stop get a refund of an approximation of what they have probably already paid to get where they are. This is not easily attributable to any individual vehicle, so it is taken from the line that they would next board to get to their destination. For that reason, you will sometimes see a lesser (and possibly even negative) value in the line management statistics than you will by summing all the vehicle numbers, and this is correct and intended. To solve the problem, reduce waiting times and/or overcrowding.

[AvG]

James,
Thanks for your answer.
I do have a save-game. It is however 1,3 Mb Will probably not fit in the additional options.
But let me first check if your explanation of negative revenues can be the cause. It is possible that I did not pay enough attention to overcrowd messages.
This will take a while, but I will let you know the result.
AvG

[jamespetts]

AvG,

thank you for your investigations: do let me know what you find. If you need to upload a larger file than will fit on the board, try http://files.simutrans-germany.com.

[sanna]

One thing to remember is that, in 7.2 and later, any passengers/goods that are discarded en route because they have to wait too long or because they reach an overcrowded station/stop get a refund of an approximation of what they have probably already paid to get where they are. This is not easily attributable to any individual vehicle, so it is taken from the line that they would next board to get to their destination. For that reason, you will sometimes see a lesser (and possibly even negative) value in the line management statistics than you will by summing all the vehicle numbers, and this is correct and intended. To solve the problem, reduce waiting times and/or overcrowding.

James, am I correct in deducing from this post that it is nowhere explicitly stated (and therefore checkable by user) how much revenue that has been deducted from a line due refunding?

[jamespetts]

Sanna,

indeed; it would take quite a bit of work to put in a GUI specifically for that, and I'm not really sure where the information would go.

[AvG]

James,
I am still trying to get financial matters under control.
Just saw how 30 tons of transported milk to a "collecting" station vanished just before being picked up.
I am beginning to believe that you are right that it is a matter of how the newest .exe handles waiting times. (In my case it is not a matter of overcrowding, because the stops have enough capacity)

I am curious now to hear from anybody, playing the early years (1830), is succeeding in running a profitable situation.
I started 1-1-1830. Now it is 28-8-1830. So almost 8 monthes and my capital is allready reduced from 500K to 188K.
My monthly "profit" is around -16K and and I have still negative revenues, despite a lot of investment in overcapacities.

I am wondering if this way of fining the player for overcrowding and long waiting times is the right way.
Simutrans has been allways pretty straightforward in it's possibilities of analysing the financial situation.
That is completely gone now.
IMHO it is also not realistic. If in reality a transportcompany does a bad job w.r.t. the before mentioned matters, customers will stay away, because they do NOT like you anymore.
There is already a system of measuring unhappiness of passengers. Would it be possible and feasible to extend this in such a way that you can see what the rest of the world is thinking about your company. ( % Content)
That % could be used to reduce the passenger-tolerances (mins) and the capacity of industries.

If you say NO the system must stay as is, IMHO you have to make it possible to trace where your money is gone. F.i. a message for every instant in the messagebox.
But please keep in mind that to much analysing will spoil the fun.
AvG

[jamespetts]

AvG,

thank you for your feedback. The new way of dealing with refunding (which is intended to be realistic: if the journey cannot be completed, the people don't pay) is discussed more fully here. A general contentment percentage that affects how long that people are prepared to travel and wait does not strike me as reflecting real life behaviour: people are not willing to take longer to go somewhere merely because the transport company that would take them there has a good reputation; and what of the case where more than one transport company is involved?

As to showing the player what is happening; can you suggest a GUI mechanism that would explain it clearly? I cannot think of an easy one at present. Thank you again for your testing, though!

(Incidentally, if the milk disappears far too soon, before any train on any sensibly efficient network has had any chance to collect it, then it might be necessary to tweak the waiting time tolerance figures in simuconf.tab).

[sanna]

Sanna,

indeed; it would take quite a bit of work to put in a GUI specifically for that, and I'm not really sure where the information would go.

One possibility would be another curve in the line diagram... Refunds....

[AvG]

James,
I read the background "here". In general : How to fine a bad transport-company!!!
Another matter: Multiplayer/AI-players. My basic idea is that Simutrans is not a good game for Multiplaying, simply by the fact of the lots of time it consumes when playing. My last experience with Simutrans-AI dates from 2007-2008. I had forgotten to click away the AI-player. With time-line ON he was transporting coal in 1900 with transportvehicles of 2000+.
What I want to make clear is that, expanding Simutrans with these possibilities, is an enormous job. I know from the past what it means to develop AI-players. (Did a lot of programming on my own WW2-sim before Window95).
To make and keep Simutrans fit for standalone, AI-players and Multiplay is IMHO waste of time.
If people insist to go on with these extra features, just because they like to do that, it's fine. As long as development of standalone is not hampered in some way.

Now back to the problem. Suppose I am AvG-Trans (famous transport-company) and you decide to travel with me to Wellington New-Zealand. The cabdriver, supposed to transport you to your hotel is 5 minutes late, due to a traffic-jam. In your system you vanish and I am supposed to refund the ticket for the flight. Highly unlikely. Reality: Next time you fly BA, because you are not content with me.

Will be continued in the next entry because this Post-Window is very difficult to handle with larger post. Window will not expand, so I have to practice sort of blind-typing.
AvG

[jamespetts]

AvG,

AI is indeed enormously difficult to get right (although I think that they at least use vehicles of the correct era now), and I do not design with that in mind. But network multiplayer is in the process of being implemented in Standard. There is a rather simple solution to the time problem: just set up the server so that it pauses whenever nobody is logged in, and allow people to log on and off at will, using a password to access their own transport company. Because time passes so slowly in Simutrans, players would be able to dip into and out of a multiplayer game for months on end: just as they do with a single player game. There'd be no need to have everyone online at once.

As to the refund point: the model that you suggest doesn't work well when, as is almost always the case, there is only one transport company that will take one to one's final destination (and a 5 minute lateness will not trigger the refund mechanism in any event: there has to be a substantial delay). Bear in mind, however, that it would be the cab driver paying for the refund (and then only if there is no other route to one's final destination from the airport, and it is too far to walk).

[AvG]

James,
After reworking two times the city network in a bigger town (12000 inh) it is still the main cause of my losses.
A couple of questions:
- I think I have read somewhere that you prefer map-scale 1 tyle = 1 km. Is this true?
I am using that scale now and am wondering if that is causing the financial problems. The only item (connected to scale) I changed in the config are the max tolerances for travel-time. I doubled them. Maybe not enough, I get however enough passengers.
What is your advise? Go to scale 250 m?
AvG

[jamespetts]

AvG,

the scale of 1km/tile is the scale used in Standard; 250m/tile is the standard scale for Pak128.Britain-Ex, and is to be preferred. If the scale is causing financial problems, then it is not the scale that needs to be changed, but other things rebalancing to make that scale work: 1km/tile does not allow enough detail or refinement, especially in urban networks.

The problem may well be the cost of stations and/or depots. Perhaps if you could upload a saved game, I could have a look?

[AvG]

James,
I am already running now a 250 meter scenario.
Will use this for analysing purposes.
2 cities with an internal network. City A=~8K and B=~4,5K inh. Year 1831
Let it run at high speed for a 1/2 year.
During that period:
City A: Revenue quite constant ~800 Cr  Profit also const at ~400 CR.
City B: Revenue quite constant ~440 Cr  Profit also const at ~250 CR
NB: All 4 lines were slightly going UP.
During the second 1/2 year: A and B are connected now.
City A: Revenue quite constant ~800 Cr  Profit also const at ~400 CR.
City B: Revenue quite constant ~440 Cr  Profit also const at ~250 CR
Lines of A slightly falling, but lines of B clearly rising. B had a babyboom in in August of 323.
What did this year prove:
- Allthough a profit-increase in both towns was to be expected in the 2nd half-year it did not show up.
In A "Transported" stayed the whole year at 1300; in B it rose from 700-770. The connecting line transported ~350/m. A lot of passengers are vanished.
- In the second half-year it was also interesting to notice that A-Revenue-line was only rising, where the same graph for B was very jumpy. Negative jumps of 20-30 were observed.
The network of A consists of 7 vehicles, where B has only 4. Maybe that A therefore is better fit for fluctuances and does not get fined to often.
Does that prove the need of some overcapacity?

Most important: I making money now, so I can go on.
AvG

[jamespetts]

AvG,

thank you very much for your analysis. Glad that you are making money, but would still like to see a saved game to understand your analysis even better. Do you have just the two cities on the whole map, or are those just the two that you have connected?

One possible reason for a fall in internal passengers after connecting the two towns is the alternative destinations feature: passengers may have been going to their second, third or fourth choice destinations in town A, and are now instead going to their first, second or third choice destinations in town B.

Monthly fluctuations do not necessarily mean that anything is going wrong - they are to be expected on small routes.

In any event, thank you for your feedback, and do let me know how you get along!

[AvG]

James,
Thanks for your explanations.
I want to know exactly what's goiing on so here is a new question:

Scenario-info: 1tile=250m; bits_per_month=21; year 1832
Distance A to B = 44 tiles, so 11 km.
Train: "Locomotion" : Average speed on A-B 13 km/h
Expected traveltime 11/13 ~ 51 mins.
These 51 mins are, I think, quite inline with the station-window-chart info which says 46 mins. I checked the real travel-time, which has probably a little higher average speed.
The left-bottom time indicator gives however a total diiferent result: 2760 mins (nearly 2* 24-hours), or 60 times the indicated value.
What is the explanation on this matter?

Am I the only one testing 7.3 and in the early years

I have save-games. The realy heavy financial problems are probably related to 1 tile=1km. Maybe waste of time to look into.
Just tell me what you want.
AvG

[jamespetts]

AvG,

what do you mean by the "left bottom indicator" here?

[AvG]

In the left bottom corner you have the game date-time running. The elapsed time there is what I mean.
AvG

[jamespetts]

AvG,

ahh, that is intentional. The rate at which the years/months pass is not the same as the rate of time at which passengers/goods travel, for, if it was, it would take months of real time for a game year to pass, and playing would be no fun at all! This is not specific to Simutrans-Experimental: the ratio is the same as in Standard (based on the speeds of vehicles: if you imagine that every tile is 1km and a vehicle is travelling at its stated speed, you will find that it does not tally with the time in the bottom left indicator, either), although it is made more explicit in Simutrans-Experimental because travelling and waiting times are measured and displayed.

[AvG]

Hi James,
I am still running Exp7.3 and it is March 1834 now.
It is a big problem. The last 4 game-monthes I had to spend them entirely on analising and reworking the relatively small network I have at the moment. The Operating Profit went down from 17,5 K to 2 K.
First a couple of questions:
A. In the first part of the config, dealing with calculating the number of upcoming passengers, the data for distance are not 100% clear to me. Are we talking about tiles or Km?

B. Some lines later, in the part of the revenue-system, you state clearly that we are talking Km in that part.
Again some lines later you declare  passenger_max_wait = 2700. How did you get that value of 2700?
You divide that value by a speed-bonus? Which one, the standard or the value from speedbonus.tab?
I am thinking of altering that 2700, but before doing so I should know exactly what I am talking about.
I have the feeling that most problems are related to the era I playing in. Like low-speed, low prod-levels, money, capacity, etc.

C. You have a line with 2* milk-farm and one dairy. It happens that the 2nd farm is producing milk that is not picked up in time and therefore vanishes. Am I fined for that?
In my next entry I will bring up some nasty experiences.
AvG

[jamespetts]

AvG,

thank you very much for your feedback. In version 8.0, I will be adding a "refunds" graph to lines and convoys to make it clear how much is being lost in this way, which should make financial analysis easier (and thank you to Sanna for that suggestion).

To your questions: (A) I am afraid that I don't quite follow. What do you mean by "the number of upcoming passengers" here? (B) passenger_max_wait is the maximum time, in tenths of minutes, that passengers are prepared to wait before they discontinue their journeys. 2700 = 270 minutes, or four and a half hours. It is quite a generous limit.

(C) You should not have to pay a refund if you don't start to transport goods/passengers in the first place at all, as the idea is that you pay back (approximately) what has already been paid to you for the wasted trip. It is a refund, not a fine. However, if this happens with passengers, the number of "unhappy" passengers will increase, which will reduce the profit that you can make on trips from that station, and will also make passengers more likely to use their private cars instead of travel from your station.

Edit: As to (A) - if you mean the distance in the "goods list" window, that is in kilometres. I shall amend the text on that to make it clear in future what is meant.

[AvG]

Hi James,
Thanks again for your answers.

A. Upcoming passengers sounded very nice to me as an english expression. Seems it's not.
What do I mean.
Search in the config for # The ranges *may* overlap.
The next 6 lines give values for min/max distances. These values can be tiles or Km.

B. Your explanation differs from what I see in the config. Here the 2700 are divided by a speed-bonus.
If the latter is right, I could experiment with lower or even negative speedbonuses in order to increase the max waiting time before being discarded.
Maybe it is possible to make a .tab-file (like speedbonus.tab) to make that 2700 era-dependent.
With only part of the map in use my longest cooled-goods line has already a travelling time of 602 mins, due to max speed 30 of small cooled goods wagons in 1834.
Max waiting time for cooled goods 2700/15=180 mins. For a line that long you need at least 8 cooledgoods convoys to prevent a refund situation.

C. Is clear now. Thank you.

AvG

[jamespetts]

AvG,

(A) ahh, I know what you mean now. These values are in kilometres. I shall amend the comments in the next release to make that clear. ]

(B) Oops - I had mis-remembered my own settings: apologies. The worked example for the number of 2,700 is given in the comments: divide it by the speed bonus level for the type of goods (passengers being 18) to get the figure in minutes, in this case 150, which gives two and a half hours. To work it the other way around, suppose that you wanted to increase the time to three hours: put three hours into minutes (180) and multiply that by 18, to get 3240. The maximum wait time of goods with a speed bonus of 10 would accordingly be 3240 / 10 = 324 minutes, or 5 hours and 24 minutes.

I hope that this is helpful!

[AvG]

James,
A. Is clear now.

B1. How to do the math-work is clear. The speedbonus in the math however can be the fixed one of 18 (passengers) from the example, or the speedbonus as a result from speedbonus.tab. Which speedbonus is 7.3 using??

B2. What about the suggestion to set up an era-dependent max_waittime.tab??
I am sure that people and goods of 1830-era were a lot less in a hurry than 2000-era ones.
In case of perishable goods a Cooled-Warehouse could be implemented.

[jamespetts]

AvG,

(B1) I think that you might be confusing the speed bonus with the speed bonus rating. The speed bonus rating, expressed in a percentage, is a measure of how important that speed is to a particular type of cargo. For passengers, it is 18%; for coal, 0%; and so forth. The speed bonus itself is the speed at which all types of cargo expect to be transported. If their speed bonus rating is greater than zero, they will pay less than their default rate if they are transported slower than that speed, and more than their default rate if they are transported faster than that speed. Just how much more or less depends on the speed bonus rating.

(B2) I don't think that this works from a realism perspective, because the only reason that people are more in a rush now is precisely because transportation is better now. I don't think that use different cost/benefit analyses: if a person could get from London to Edinburgh in 20 minutes in 1750, more or less the same proportion of people would travel there as if they could do that now. One of the main points of the journey time tolerance system was to simulate the fact that fewer people travelled in the past because it took longer to get anywhere. Having the journey time tolerance tighten in later years would remove this effect, which effect was a design purpose of the system.

As to perishable goods, it would require some quite fundamental changes to the code to make that work. An alternative possibility is just to have a "fresh food" and "frozen food" goods type.

[AvG]

James,
I do NOT want to make problems, if not necessary.
I am running my scenario now on the other PC and what I see makes me crying.(well almost)
After 4 game-monthes of investigation, analising and adding lots of overcapacity in many places I made a profit again of 20K/month.
The next 2 monthes it was already sinking a bit (16-17K), but not realy worrying.
Then, the next month, it is down to 2K.
The last month it is -10K. (with maintenance of 6K/month)
Looking at the behaviour of the profit-line in the finance-tab you see negative jumps of 4-6K, which are compensated by small real profits. One gets the feeling that the refund-formula has a comma-error of one or even 2 places.
Another cause of the problem can be towngrowth. Most of my villages start with ~600 inh. I checked towngrowth and this turns out to be 25%-55% per year in 1834. If that goes on they all will be in 2000, metropoles with each the whole earth-population.
In 1834 there are no transport-means which can deal with mass-transport. Please James, have a look into that problem.

Another matter is the problem of connectec goods-lines.
The normal situation is: several small collecting lines end in A. From A > B the big fast mainline. From B several small distribution lines to customers.
In the existing situation this is impossible because chances, that goods have to wait in A or B to long, and your refunds are higher than your income.

Your vision on B2:
I agree completely with  your example in 1750. I think however there is only one thing you oversee: In those days people had no idea of the travelling possibilities 250 years later. If they decided to make a real long voyage (longdistance_passengers_max_distance =16384) they were prepared to wait if necessary for days.
My own experience: In the eighties of the previous century I had to travel quite a lot between Amsterdam and Taipei. Very often I had to wait in HongKong for over 6 hours. (and never have been discarded)

Can you tell me if I alter that value of 2700 in the config, will it be used after saving and loading or do I have to start allover again with a new scenario.
AvG

[jamespetts]

AvG,

thank you very much for your feedback - as ever, most helpful. Firstly, it would make it easier for me to analyse your issues if you could upload a copy of your saved game so that I can make adjustments and run it on the latest development version of Simutrans-Experimental and see whether it makes a difference to what you report.

As to the refunds, I have double-checked the formula, and there are no decimal point errors. The formula is this:

r = q * p * d * 2

Where:

r = the refund amount;
q = the quantity of the goods;
p = the base price of the goods; and
d = the straight line distance between the goods' origin and the current position.

The multiplication by 2 was intended to approximate the fact that the goods will not have taken the straightest route. I have changed it to 1.5 for the next release, as it seems that 2 might be a little too harsh.

As to the town growth, I have looked at that in detail, and spotted an error which had lurked previously undiscovered in the simuconf.tab files. Recently, Simutrans-Standard changed the way in which it dealt with town growth: it now defines three categories of towns, based on their size (village, cities and capitals), each with their own "growth factor" (the number by which the raw growth numbers are divided to produce a final amount of growth). By default, these are 400, 200 and 100 respectively. However, in error, I had put them in the configuration files as 100, 200 and 400 respectively, meaning that villages (smaller towns) grew far faster than they should have done. This error will be corrected in the next release.

As to waiting times: it would again help me if I could see your saved game to get a proper idea of the sort of network that we are dealing with, especially if I could open it with my development version of Simutrans-Experimental in which refunds are separately plotted on their own graph, as they will be in the next release version. It would help me to understand whether the values are as presently set correctly calibrated or whether they need adjustments, and, if so, what adjustments are needed.

Changing simuconf.tab values does not affect existing saved games (either in Standard or Experimental). These values can be changed by using a hex editor or a compiler with a debugger (easier), but not otherwise.

Edit: Thinking a little more about the waiting time tolerance issue, I will try a new approach from the next version onwards: setting the value to 19440, or eighteen hours (for passengers). In this model, discarding will be a last resort, and the real control of journey times will be through the journey time tolerance feature. When the next version is released, I'd be very interested to know whether this works better overall. Thank you again for the very useful feedback.

[AvG]

James,
Thanks for your reactions on the problems.
I am looking forward to the next release.
On my side I have a couple of options:
-Start a new scenario with the settings you mention.
If I decide to do that I better have a look first at balance of the vehicles, which is very bad. I will try to fit them in my DRC-system.
We need also some vehicles for mass road-transport in town. I thinks of horse-trams.
- I can also try to use a hex-editor and make some changes in the last save. I seem to remember that the .sve files are in a compressed format. If so which unzipper can be used?

Later I will upload some .sve files you asked for.

Edit: Is Exp7.7 an option, so I can use the latest ideas and settings? Maybe not official-you (can) have my E-mail-address.

Edit 2: Was in a hurry!! Of course EXP7.4 is meant i.s.o. 7.7
AvG

[sdog]

Looking at the behaviour of the profit-line in the finance-tab you see negative jumps of 4-6K, which are compensated by small real profits.

I've noticed similar jumps in my recent game also. However i don't think they are errors.

Please bear in mind that below is only based on pheonmenologic observation, and not real analysis, and it is not reproduced. I'm relying a bit to much on my intuition for a complex non linear system -- wich is rather dangerous.

The fluctuations dissapeared when i replaced a slow long range ship line with a train line. The surprising thing however is, that the ship line transportet only about 10 to 20 passengers a month. It seems very likely that too long travel times on the line caused the passengers to dissapear. They did not do it on the ships however, i could not see it there. It must rather have happened in their destinations local network, where i could not track them.

Interestingly this seemed often be linked to inefficiency at the beginning local network (collecting). Thus it is likely the total traveling time that kicks in here.

The second cause is a train line i was runing 2 circles on a short branch and one cycle on a long branch. The long branch caused extended wait times at the denser part of the line. The wait was seemingly not long enough to trigger max travel time. But the pier for the ship line was also on that line, causing both effects to correspond.

In the worst cases revenues droped by about 30%, bringing operating profits to the negative. It seemed that both effects combined caused the passengers in one local network to ebb.
This also made the collecting network more efficient, and after passengers returned there was also a surge of about +10%.

Measures against it:
Increases in transport capacity in the collector network could reduce it. This also reduce their profits however, since they needed to be about 60% full. Bunching had to be prevented too.

Bunching of boats was very important to have an eye on.

Replacing the train with a shorter long branch train and another local train helped to reduce the fluctuation greatly. But it did not make it dissapear.

Replacing the ship line with a fast train line also got rid of the fluctuations.


ps.: @AvG:
perhaps you should have a look on dropbox, it's very usefull to share files and synchonise them between computers.
http://en.wikipedia.org/wiki/Dropbox_(storage_provider)

[AvG]

Sdog,
What era are you playing??

Indeed, complex lines have to be avoided as is. Especially if the middle part is long and in the early days the travel-times are long.
I think however that, when the value of 2700 is replaced by 19440, the multiplier of 2 by 1,5 and the towngrowth corrected, most of the problems will be gone.

In era 1830 there are very few roadtransport means available. The only one for passengers and realy useable is the Horse Omnibus. In city-areas however they are to fast. (15km/h)
Therefore I am thinking of replacing city_road by a couple of era-dependent city-roads. Until 1915 citylimitspeed 10 km/h, then untill 1935 25km/h, after 1935 50km/h
I think these values are not unrealistic.
My grandma died somewhere in the late fourties at the age of 97. I still remember the interesting stories she told about life in the 19th centuries. a.o. the first autocars were only allowed to drive in town if preceeded by a walking man with a red flag.

Edit: Sdog, are you sure that link is still valid?
AvG

[AvG]

James,
The .sve files are uploaded to simutrans-germany.
Recogniseable by AvG as namestart.
The 2nd one shows in the long milkline between Weert-Schiedam a profit which is impossible high. (The Planet-Loc is far to expensive for this line)
Looking forward to your comments.

AvG

[AvG]

James,
I don't know the formula for towngrowth you are using.
Just did a little math.
Start city of 5000 inhab in 1750. With an average growth of 5%/year is will be near to a milliard in year 2000.
Hope your formulas can deal with that.
AvG

[sdog]

Ad,
the link is fixed now. There was an ')' missing.

i've been playing with 7.3 and pak britain 0.6, starting in 1910. Here's more about the game:
http://forum.simutrans.com/index.php?topic=4867.msg48758#msg48758

[jamespetts]

A number of the changes in Simutrans-Experimental 8.0 have arisen out of this discussion. A bug was fixed that meant that stations cost more to maintain than they ought to have done; there is now a "refunds" graph that shows what is lost by way of refunds so that it shows separately rather than appearing as negative revenue; the refunds are now a third less than they previously were; the default waiting time tolerance in simuconf.tab has been greatly increased; town growth has been reduced (and the algorithm fine-tuned with more simuconf.tab options); and, as a result of sdog's saved game, I am slowly adding to Pak128.Britain more vehicles that would make more sense than some of the vehicles that sdog was forced to use for the situations in which he found himself.

I should be interested for any feedback on how these things work out in practice in 8.0 - thank you all for your feedback so far :-)