Different friction for different vehicle types?

[jamespetts]

I am wondering whether there would be some merit in applying a different level of friction in the code for different waytypes, to reflect the fact that, in reality, road vehicles have to contend with less drag than ships, trains have less drag than road vehicles, and aircraft less drag than trains. This would mean that it would not be necessary to use the "gear" function, for example, to simulate the different loads that horses can pull on tram tracks compared to on roads. Technically, it would be extremely easy to code this feature, but, before I go and put it in Simutrans-Experimental, I thought that it might be a good idea to seek views on the matter, especially from Prissi, whom I understand to be knowledgeable about physics.

I was thinking of the following scheme of friction factors, but I should be grateful for any better ideas:

Air: 1
Maglev: 1
Monorail: 2
Rail (all types): 3
Road: 5
Water: 10

[The Hood]

Sounds like there could be some mileage in that idea, especially if it's easy to code  

But I'm not sure about water - can't you pull a bigger load in water than on a road (e.g. horse drawn barge = better than horse drawn road cart)?  That would be nice to get right.

[jamespetts]

The Hood,

hmm, not sure about the barge. Isn't there more drag on water? Weren't canals only used because the roads of the day were very, very poor? Perhaps Prissi will know the answer.

[prissi]

The speed and freedom of routes you can achieve also matters. You can move 30t on a barge by horse while 1t would be the limit for a wagon, since the friction of a bad wooden wagon is less than the barge at 5kmh. However, a racing sulky xan exceed 35kmh while this is completely impossible because of drag.

Moreover the speed, power and gear of the different pak-sets have been adjusted to achieve realistic accelleration and loads (apart from ships) thus I would not change this without need.

For ships the drag is really not linear but very complex, depending on speed and laminar versus turbulent flow and interface friction. I am not sure thus would change anything inside the game, since the consumption of fuel etc. is not considered and the formulars used are unphysical anyway (only good-looking).

[jamespetts]

Prissi,

ahh, thank you for your reply :-) It is indeed a complicated area. However, there may still be some merit in differentiating, say, rail and road so as not to have to use the gear with horses. Certainly, if the friction levels were read from simuconf.tab, then the issue of the already made paksets would cease to be an issue: I am particularly interested in using this for PakBritain, which is likely to be re-balanced in the near future. If the values assumed in default of specification in simuconf.tab were 1, then existing balanced paksets would not become unbalanced.

I appreciate that any such calculations will only be a rough approximation of the real physics - especially, given what you have written, in relation to water - but making the approximation slightly less rough could still enhance gameplay, especially if new paksets could be balanced effectively with far less use of gear, and by using real world information about power and weight to a greater degree. Given that level of approximation, would the numbers that I gave in the original post be more or less correct, or are the approximate/average ratios off?

[prissi]

Well friction and drag are very different (not to mention the three different kind of frictions, i.e setting something in motion "Haftreibung", simple bearings "Gleitreibung" and tires "Rollreibung".) Water has little friction but a high drag. And the word friction does not really apply to a horse. Therefore it seems a little too much just to avoid the gear (which was introduced eaxctly for the finetunig purpose) for horses.

[jamespetts]

Prissi,

forgive me, I am not sure that I quite follow. I take the point about different kinds of mechanical resistance, but I was referring to the "friction" variable used in simvehikel.cc, which seems to represent all different types of mechanical resistance in a somewhat approximate way. The "friction", for example, is increased when climbing a hill or (in the standard version, but not, unless the user changes a setting, in Simutrans-Experimental) for going around a corner. The starting friction is hard-coded at 1, and the amounts for the hill or corner are added to this number per step. It was to this program variable by the name "friction" that I was referring (which seems to be somewhat of a misnomer, since there is no additional friction, as such, when climbing a hill: "resistance" may well be a better word, since it is more general) when I asked about increasing the friction. Programatically, it would be easy to determine this starting "friction" amount by a switch/case statement on the waytype, reading the values from those read in from simuconf.tab (setting them to static to reduce function call overheads).

So, setting aside for a moment the different kinds of mechanical resistance (and the point about horses not having their own friction: the point was not that the horses themselves would have resistance, but that their carts would, and a cart of equivalent weight on a road would take more force to move than of the same weight on rails: a factor which greatly influenced the development of early tramways, and which I should very much like to simulate without "gear"), are the numbers that I gave above more or less correct for an overall mechanical resistance level for those particular kinds of transport, such that, if applied to the "friction" function in simvehikel.cc they would, with a pakset giving real-world power and weight values, produce more or less accurate performance, within the general confines of the Simutrans system?

[The Hood]

I've had another think about this - I'm not sure why you can't just leave the gear setting in as this allows a "fudge" factor to simplify all sorts of real life things.  You can get the right behaviour out of it after all by having tramway horses with higher "gear" than road horses. 

From a simutrans-experimental point of view, the more similarities with the standard version the better, as this allows paksets to be transferred with little alteration to re-balance them for simutrans-experimental (less work = better, working paksets mean more people will be willing to try experimental).  What I'm trying to say is if you can already simulate the right behaviour in the trunk versions, then why bother changing it and make more work for pakset authors (or more likely yourself ) to get paksets to balance with experimental?  Better to save your efforts for something the trunk can't do yet!

[jamespetts]

Hmm, this is a tricky question about which I have been thinking recently. On the one hand, The Hood makes a valid point about existingly balanced paksets. On the other hand, one of the reasons that I was interested in this feature in the first place was because the gear values in PakBritain seem all to be far too high, and performance is more realistic with the "gear" stripped out entirely (which I have done on my own version). But doing that involves obliterating the differences between rail and road performance for equivalent locomotives (horses most noticeably). I was looking for a way to re-balance things automatically without having to pick through each individual vehicle file.

The idea was, therefore, to have differential mechanical resistance levels that could be used either with new paksets, or ones that are being rebalanced, and have the option to disable that system for paksets that are already calibrated for the existing system.

[The Hood]

Gear values in pakBritain were balanced so that empty convoys accelerate over a given straight distance (it was anything between 2 tiles to top speed for some metro-type trains and 8 tiles to top speed for heavy long distance expresses).  What in particular makes you think gear values are too high (I'm open to suggestions on what would be a better playing balance).

[jamespetts]

Ahh - in which case, I think, the number of tiles chosen is too low. What initially put me onto the gear values being too high is when I altered the physics for steam locomotives to make them accelerate more slowly than diesel or electric locomotives: using Pak128, which tends to have neutral gear values (i.e., for the most part, at or close to 1), my modification made a noticeable difference to the performance of the trains. In PakBritain, it made no noticeable difference.

The approach that I take to physics is that the acceleration ought be more or less realistic as against the scale used for the length of the train. So, if, in reality, a train would accelerate to its full speed in Y times the length of the train, so too should the trains in Simutrans. Any other approach means that the acceleration looks wrong: vehicles appear to accelerate far too quickly. As long as everything in terms of the revenue system is calibrated to that approach, there will be no gameplay problems with such a system.

[The Hood]

Fair enough - if you want, one of things you could do when you get time for pakBritain is to suggest the number of tiles which might be better. (if I can find it I'll send you the spreadsheet which details current system, if you want to do that).

[jamespetts]

I'm not sure that a system of counting tiles for vehicles getting to their full speed is necessarily the best way of calibrating things: generally, my preference is to use real-world values for power, top speed and weight, and make the game algorithms realistic enough that that will give more or less realistic performance without having to calibrate for a "gear" setting. That approach is more satisfying and easier to maintain in the long-term. However, once I have completed my current coding plans (at present, the refurbishing and integration with Isidoro's replacing system, the new revenue system, variable dwell times and reversioning the save game files to match all of that), then I plan to turn my attention to PakBritain, partly to finish creating a PakBritain-Experimental to go with Simutrans Experimental's new features, but also partly to add things of use both to the standard and Experimental versions of PakBritain.

[kierongreen]

I'm not sure that a system of counting tiles for vehicles getting to their full speed is necessarily the best way of calibrating things: generally, my preference is to use real-world values for power, top speed and weight, and make the game algorithms realistic enough that that will give more or less realistic performance without having to calibrate for a "gear" setting. That approach is more satisfying and easier to maintain in the long-term.

Yes, however:
This is a game, and it's kinda pointless having vehicles which can't reach top speed.
The gear factor is there for fudging things to make the game playable. You can't simulate everything through real world factors.
The distances chosen are designed with the way I play simutrans. Namely that suburban trains will reach top speed within 2 tiles meaning that on a suburban line they will actually reach top speed.

[jamespetts]

I'm not sure that suburban trains normally do reach their top speeds when stations are close together (Underground trains are somewhat different, but largely because their top speed is 40mph). It's fair enough that you prefer to play in that particular way, but that's not a reason not to have a setting that enables others who prefer more realistic values to play in other ways.

[kierongreen]

But this is the point, the suburban trains have a lower top speed so reach it quicker. Anyway, all your doing is transferring the fudge factor from the dat file into simutrans. The acceleration is set to be what it is to make it playable - having a train taking several screens to get to top speed isn't fun for me.

[jamespetts]

Two things - firstly, having the "fudge factor", as you call it, in the code is preferable because that means doing the work once, not lots of times. Secondly, depending on your screen resolution, if suburban trains are taking that long to reach their (low) top speeds, the basic calculations could do with changing. Certainly, PakBritain's gear settings are far higher than that of any other pakset that I've used.

[The Hood]

I think it all comes back to the length scale problem in simutrans - that one tile graphically is only a short distance, but in "map" terms it is much longer. 

Think how big a city the size of london would be if done at the graphical scale in simutrans, and then add in your tube stops and then obviously a tube train would accelerate to top speed over more tiles than at present and long distance trains would take a lot of tiles!!!  In simutrans world, I reckon tube stops would be about 4-8 tiles apart on average, so two tiles to max speed doesn't seem stupid to me, given everything else.

But:
(a) the size of cities isn't that big in simutrans - some things are scaled down relative to the length of a train, and
(b) taking 50 tiles to reach top speed for an express train might be realistic in terms of the length of the train but would not look good and would also be frustrating from a gameplay point of view.

Seeing as by scaling some lengths down (city sizes/intercity distances) relative to others (vehicle length) implies a certain breaking of the laws of physics, there has to be a certain bit of fudging, and all I've tried to do with the gear balancing is to get something that looks good while keeping the "power" / "speed" / "weight" values about right in real world terms (obviously for steam locos there is another problem about "power" varying as a function of speed etc. too).  I'm not sure why this makes gear values so high, obviously it would be great not to need them but I am a pak maintainer/artist not a programmer, and all I'm trying to do is get things to look OK and play OK in the constraints of the simutrans program and map world (which does need to involve some suspension of real life length scales!).  And my philosphy on this, with limited time, is definitely along the lines of if it ain't broke, don't fix it .  All I can say really is that this seems like a lot of effort just to change something that can already be sorted out with a global "gear" factor.

So two things really:
1) from a pakBritain point of view, if there are any vehicles which you think are really not balanced sensibly compared to any of the others (accelerate too fast/too slow) it's probably best if you PM me and I'll investigate (when I get time).
2) generally, if you can come up with a better scheme, then why not test it out and see what it looks like, and what sort of changes would need to be made to get things to accelerate over sensible game distances?  If you can get something that works and looks good, wihtout the need to add a gear factor which might confuse people when trying to work out which vehicle is more appropriate, then do it (although if you do away with gear completely, it may be a good idea to have generic "acceleration" constant in simuconf.tab which allows people to modify how quickly all vehicles accelerate to take account that some people may find it more pleasing to have quickly accelerating vehicles while others might prefer it slower).

PS sorry for the long ramble!

[jamespetts]

Hmm, I see that this is a potentially complicated issue. I think that I shall have to consider this in more depth after some degree of testing. A global "gear" might not be such a bad idea (or at least: one global power multiplier for each waytype specified in simuconf.tab). The "gear" for each vehicle should then be used only for relative fine tuning (for example, to mimic Underground trains that physically use gears to step down the speed of the motors to enable fast acceleration with a low top speed). Once the relative power of each different type of vehicle is correctly set in the data files, the global power modifier could then be adjusted to apply the appropriate level of "fudge factor" as Kieron puts it - the extent to which the train length scale is blended with the tile length scale to produce a suitable compromise.

My view remains, however, that the individual .dat files should not contain information about how to address the scaling issues in the game, and should simply give real-world figures, and it should be for the game code (with adjusted settings in simuconf.tab if necessary) to interpret that globally to suit the correct scale. That makes things far easier to maintain: if different people have different preferences about how to handle the "fudge", or the game simulation develops such that the approach taken to it needs to be modified, then it can be corrected without having to re-do hundreds of individual gear factors.

However, this is a slightly separate issue in a way from the original suggestion, which was about just such a development. The idea was for it to be possible to give a different level of mechanical resistance to different types of transport. What I originally suggested was to have a set of global figures for each waytype, but what I am wondering about is whether the so-called "friction" value could be set in the individual .dat files (with defaults for each waytype). The purpose of that would be to require less fine tuning of the relative powers of vehicles with the "gear" setting (quite apart from the separate question of adjusting the overall "fudge" factor of the simulation).