Topic: friction uphill/downhill

[Vladki]

I don't know if this is a bug or a feature.... I notice that added friction for going uphill or downhill is not constant, but somewhat accumulative. Thus making even the strongest trucks crawling on bridges like snails. Friction on flat road is 4, but on the hill, it accumulates with every tile, and it takes few tiles to get back to 4. This is really detrimental, if there is a congestion, and trucks have to stop on the slope, or in front of it. I have measured three scenarios.

One tile full height slope up: 4, 51, 38, 25, 12, 4...  (Only 51 is the uphill tile, all the others are flat)
One tile full height slope down: 4, -24, 4...
Two consecutive half height slopes up: 4, 27, 44, 31, 18, 4... (Again only 27 and 44 are uphill)
Two consecutive half height slopes down: 4, -10, -20, 4...
Two half height slopes with one flat in between up: 4, 27, 14, 37, 24, 11, 4... (Only 27 and 37 are uphill)
Two half height slopes with one flat in between down: 4, -10, 4, -10, 4...

I do not understand why the friction behaves like this

[jamespetts]

This is intended: the idea is that climbing a large number of consecutive tiles represents climbing a steep hill, whereas more spaced out tiles represents a less steep hill. It is intended as a way of spreading the gradient over a number of neighbouring tiles to simulate more realistic, gentler hills rather than 45 degree angles as we have to use in Simutrans.

Why do you think that this is a problem?

[Vladki]

It just makes road transport within a city unfeasible. You can see it in the oom-crash.sve. There is a tunnel under the railway station in trnava. Everything is fine as long as roads are empty. But if the crossroads at the exit from the tunnel is blocked, trucks have to stop and wait for clearance. But then they start with high friction, and it takes them ages to clear the crossroads. Next truck gets stuck on the slope, and cause big congestion. I tried many different setups. I have put the crossroads, half level down to have only a half slope at the exit from the tunnel, and then further half slopes on the other side of crossroads, but it did not help much. I tried to use bridge instead of tunnel, so that the trucks are not stuck uphill when waiting for clearance, but then they got stuck ant the other side of bridge due to slow or too many private cars. Making the bridge ramp longer (slope/flat/slope) did not help either. Especially in cities you cannot make the ramp very long. You are glad if you can make it two half slopes in sequence instead of one steep slope. The biggest problem is, that the trucks crawl at 1 km/h a few tiles after they get to flat surface for no apparent reason. Also putting a bus stop at the top of the hill makes a big problem - all trucks get stuck behind the bus on the stop and start crawling at 1 km/h.

And BTW full height slope is not 45°. A double height slope would be. Try raising the land and making a cube. You'll need 4 half-heights to get it as high as wide. So full height slope is 26.6° (i.e. arctan(0.5)), and half height slope is 14° (arctan(0.25)).

[jamespetts]

I am not familiar with oom-crash.sve - may I ask which pakset that that uses? This looks as though it is a calibrational issue.

[Vladki]

I am not familiar with oom-crash.sve - may I ask which pakset that that uses? This looks as though it is a calibrational issue.

http://server.exp.simutrans.com/debug-saves/oom-crash.sve
It uses pak128.Britain-ex - I posted it in another thread with another bug, but can be used to demonstrate this problem as well

And to the slopes - it is even less. One half height is 16 px high, but the tile size is not 64 but 71.55 (due to isometric). So the full height slope is 24.23° (or 45%) and half height is 12.40° (or 22%). Both are indeed very steep.
https://en.wikipedia.org/wiki/Baldwin_Street

[jamespetts]

Thank you for that - I can see the difficulty. This needs some careful and precise calibration, and it needs to be able to work well for rail as well as road. Currently, for road, the base friction is 4. A single tile of half-height slope increases this to 27, and a second consecutive tile increases it to 44. Do you have any idea of the relative levels of gravitational forces that vehicles have to overcome (relative, that is, to drag on the flat) at different gradients so that more realistic multipliers can be specified here?

[Vladki]

Thank you for that - I can see the difficulty. This needs some careful and precise calibration, and it needs to be able to work well for rail as well as road. Currently, for road, the base friction is 4. A single tile of half-height slope increases this to 27, and a second consecutive tile increases it to 44. Do you have any idea of the relative levels of gravitational forces that vehicles have to overcome (relative, that is, to drag on the flat) at different gradients so that more realistic multipliers can be specified here?

I will try to refresh my physics knowledge and come with something.

One more thought is to use different scale for height than distance. Now we have a scale of 8 tiles/km used to calculate physics (speed, acceleration) and economics (costs and revenues). Then we have the modelling scale for vehicles, buildings, etc which I don't know exactly but should be somewhere between 16 to 32 m/tile. For height I would think this way. Half height slope has not enough clearance under bridges, but full height does. What about 4 m for half height. That would approximately match with 16 m/tile. But if we make the calculation with 125 m/tile and 4 m for half height slope, we get some gentle 3% (or 6% for full height). Nice slope for road, but still quite steep for rail.

[jamespetts]

That is an interesting thought; if you could let me know how the physics work out for that, I should be grateful.

[Vladki]

What units is the friction value in convoy info using?

[jamespetts]

The relevant code is:

Code: [Select]

void weight_summary_t::add_weight(sint32 kgs, sint32 sin_alpha)
{
   weight += kgs;
   // sin_alpha <-- v.get_frictionfactor() between about -14 (downhill) and 50 (uphill).
   // Including the factor 1000 for tons to kg conversion, 50 corresponds to an inclination of 28 per mille.
   // sin_alpha == 1000 would be 90 degrees == vertically up, -1000 vertically down.
   if (sin_alpha != 0)
   {
      weight_sin += (kgs * sin_alpha + 500) / 1000;
   }
   //if (sin_alpha > 200 || sin_alpha < -200)
   //{
   //   // Below sin_alpha = 200 the deviation from correct result is less than 2%! Noone will ever see the difference,
   //   // but for the time being, we always save a lot of time skipping this evaluation.
   //   weight_cos += kgs * sqrt(1000000.0 - sin_alpha * sin_alpha); // Remember: sin(alpha)^2 + cos(alpha)^2 = 1
   //}
   //else
   {         
      weight_cos += kgs;
   }
}

void weight_summary_t::add_vehicle(const vehicle_t &v)
{
   // v.get_frictionfactor() between about -14 (downhill) and 50 (uphill).
   // Including the factor 1000 for tons to kg conversion, 50 corresponds to an inclination of 28 per mille.
   add_weight(v.get_total_weight(), v.get_frictionfactor());
}

and

Code: [Select]

void vehicle_t::calc_drag_coefficient(const grund_t *gr) //,const int h_alt, const int h_neu)
{
   if(gr == NULL)
   {
      return;
   }

   const waytype_t waytype = get_waytype();
   const sint16 base_friction = get_friction_of_waytype(waytype);
   //current_friction = base_friction;

   // Old method - not realistic. Now uses modified speed limit. Preserved optionally.
   // curve: higher friction
   if(previous_direction != direction)
   {
      //The level (if any) of additional friction to apply around corners.
      const uint8 curve_friction_factor = welt->get_settings().get_curve_friction_factor(waytype);
      current_friction += curve_friction_factor;
   }

   // or a hill?
   // Cumulative drag for hills: @author: jamespetts
   const slope_t::type hang = gr->get_weg_hang();
   if(hang != slope_t::flat)
   {
      // Bernd Gabriel, Nov, 30 2009: at least 1 partial direction must match for uphill (op '&'), but not the
      // complete direction. The hill might begin in a curve and then '==' accidently accelerates the vehicle.
      const uint slope_height = (hang & 7) ? 1 : 2;
      if(ribi_type(hang) & direction)
      {
         // Uphill
         const sint16 additional_base_friction = slope_height == 1 ? 40 : 80;
         const sint16 additional_current_friction = slope_height == 1 ? 23 : 47;
         current_friction = min(base_friction + additional_base_friction, current_friction + additional_current_friction);
      }
      else
      {
         // Downhill
         const sint16 subtractional_base_friction = slope_height == 1 ? 24 : 48;
         const sint16 subtractional_current_friction = slope_height == 1 ? 14 : 28;
         current_friction = max(base_friction - subtractional_base_friction, current_friction - subtractional_current_friction);
      }
   }
   else
   {
      current_friction = max(base_friction, current_friction - 13);
   }
}

The number is a multiplier of the base friction expressed in thousandths, from what I can make out. It was Bernd Gabriel who wrote the code, and it was some time ago, so I am not entirely clear on the details of how it works.

[Vladki]

Well I have dived into the code, and physics as well. From what I have understood there are 4 forces affecting the vehicle:
Machine force, Fr=roll resistance, Ff=air resistance, Fs=slope resistance (force).

Ff= speed^2 * air_resistance
- air_resistance is given in dat file multiplied by 100. Default for road is 0.15, which is IMHO quite low in comparison to train/tram/monorail (1.60), narowgauge (1.20), maglev (1.45) and airplanes (1.00). Ships have air_resistance 25 because it includes water_resistance as well. air_resistance for road vehicles (mainly bus/truck) should be IMHO similar to trams, hmmmm lets say 1.50 ?
- I have checked non-default air-resistances defined in pak.britain and found that trains/ner-es1.dat has resistance 1000 (10), and maglevs have 825/882. Perhaps they have been forgotten from some older version and need rescaling roughly by factor of 8

Fr= weight * g_accel * cos(alpha) * rolling_resistance
- rolling_resistance is given in dat file multiplied by 10000. Contrary to documentation it is not in N/kg, but just a constant. It has to be multiplied by g to get N/kg. Thus there is a bug in gui/components/gui_convoy_assembler.cc which displays rolling resistance in depot window as weight * rolling_resistance. But it should be weight * rolling_resistance * g_accell (9.81). I wanted to provide a patch but I did not like defining g in multiple places. g_accel is defined in convoy.cc. If it would be in convoy.h it could be included and used in gui_convoy_assembler.cc.  Or is there a better way to do it?
- cos(alpha) is defined to be 1 for simplicity. The error is <1% for slopes <14%.
- default rolling resistances are quite OK for track, monorail (0.0015), maglev (0.0013), ng (0.0017), but I think that 0.0060 for trams is quite high. According to wikipedia, dirty tram track with straights and curves has 0.0050, and this should be the value for straight track. It should be IMHO similar to track or narrowgauge, perhaps a bit higher but not that much. Also 0.0090 for roads is quite high. What I have found on wikipedia, it should be 0.0045 to 0.0080. Water and air vehicles have default rolling resistance 0.0010, but they should have 0 (nothing rolls), except for aircraft rolling on runway/taxiway. Perhaps there is some specific handling of these in the code, I have not checked yet.
- hackney-carriage.dat has specified rolling_resistance=40, while other similar vehicles have 100-180. I think 140 would be appropriate. Wikipedia says stage coach has 0.0385 to 0.073 on dirt road (with/without snow). So 140 might be ok for paved road. Perhaps an option to have additional rolling_resistance for different ways (dirt, gravel, cobblestone, concrete, asphalt; steel rail, welded steel rail, cast iron rail, plateway, ...) could be interesting

Fs= weight * g_accel * sin(alpha)
- there is an error in the comments. if sin_alpha is given multiplied by 1000, and 1000 is 90 degrees up, then sin == 50 (0.05) is not 28 per mille, but 2.8 degrees. At small angles sin_alpha is almost equal to tan_alpha = inclination in % (or per mille). So 5% slope is sin_alpha = 50.
- vehicle_t.get_frictionfactor() is used as sin_alpha. So the values used are quite ok. If we take half height to be 3 m, tile length 125m, we get 2.4% slope. 4m height would give 3.2% slope. Full height slope would then be 6-8m which should be enough for 4.5m high double decker, or train with overhead wire (5-5.5 m above rail) plus the bridge's body.
- vehicle_t::calc_drag_coefficient should IMHO calculate only slope related drag (force), and not use get_friction_of_waytype. Base friction of waytype is already accounted for in rolling_resistance from dat file. Even if specific friction factors for different ways would be implemented, it should not affect Fs, but Fr
- why the calculation of weight_sin is adding 500 (0.5) to weight*sin_alpha ?

I have noticed that air_ and rolling_resistance from dat files, as well as g_accel are defined as float32e8_t. What is that type? To me it looks like some attempt to do floating point calculations using fixed point instructions. Is it reliable? Is it necessary? Would not using doubles or other standard floating point types be better. Are floating point operations so slow that we need something like this? Throughout the code I have seen combination of doubles, float32e8_t's and integers in one formula. Is that safe for calculations?

Anyway, all the errors I have pointed above are not that bad to make truck crawling uphill. The bug must be somewhere deeper in the code... Let's have an example DAF XF with steel trailer. Empty weight = 17t, fully loaded 65t.
Fr=17000*9.81*0.0090=1.5 kN (rolling resistance empty)
Fr=65000*9.81*0.0090=5.7 kN (full)
Ff=(86/3.6)^2*0.15=0.085 kN (air resistance at full speed), probably should be 10x more
Fs=17000*9.81*0.044=7.3 kN (slope resistance for two or more half height slopes in line)
Fs=65000*9.81*0.044=28 kN
So the complete resistance is 28+5.7=33.7 kN. You can see that the air resistance is almost negligible in comparison to the effect of slope and rolling resistance. But still, DAF XF truck has tractive force 38 kN, so there should be 4 kN left for accelerating fully loaded truck on slope. This gives us 0.06 m/s^2, mm not much, but still it should be able to move...

I just wonder if the tractive force is estimated correctly. Unfortunately car manufacturers give usually only power and torque. But to convert torque to tractive force, we need to know the trasmission ratio of the whole path from engine to wheels. Which I could not find yet...

[jamespetts]

Thank you very much for this detailed analysis. I am very busy professionally this week, so do not have time at present to look into this in detail, but one or two brief comments while I have a chance. Firstly, it was not I who wrote the physics code, but Bernd Gabriel, so I am not as familiar with the details as I might have been had I written it. This will need some considerable time for me to consider in detail fully.

Secondly, the float32e8_t is indeed a class for reproducing floating point arithmetic using integers. It is definitely necessary, as the rounding precision of inherent floating point numbers is not deterministic between platforms, leading to network desyncs: finding and fixing this was the most challenging bug yet encountered in Simutrans-Extended, and the whole thing took the two of us at least four months of doing almost nothing else on Simutrans if I remember correctly. It is unfortunately a great deal slower than native floating point types, but nobody has ever been able to come up with anything better.

The tractive force figures are indeed extremely hard to find, and I have had to resort to guessing them. The road goods vehicles do not have tractive effort specified in their .dat files, as these .dat files were produced many years ago: they use the default tractive force values. 'Buses now have the tractive effort specified on the basis of extrapolating from real life data about 'bus acceleration (on the flat). If you can find more accurate data (that, when applied, gives rise to accurate rates of acceleration), then I should be most grateful.

[Jando]

Greetings!

I don't really know whether this is a pakset-related issue, I assume it is: all stage coaches (horse omnibus as well) slow down to 1 km/h at every uphill slope, no matter whether drawn by 2, 4 or 6 horses. Don't know whether intentional but seems rather harsh and unrealistic to me. Thanks!

[jamespetts]

Jando - thank you for the report.

I have merged this with this other topic, as what you report is a manifestation of what appears to be a calibration issue with the degree of extra drag for road vehicles on slopes. In any event, this appears to cause more serious problems than that first reported in this thread, so I will take a look into it in a little more detail and look through Vladki's helpful comments.

I wonder whether the problem is actually that the additional drag forces for slopes are fixed numbers added to the base drag, rather than multipliers for the base drag, meaning that the effect is disproportionately large on light, low powered vehicles.

Edit: Having looked into this in more detail, I am struggling to find the problem. Looking at the code more carefully, the statement above that the problem might be that numbers are added rather than multiplied is incorrect, as the figures in question are the coefficients which are then multiplied by the weight. The figures in get_friction_coefficient actually represent the percentage of the gradient, which is more or less correct.

The trouble always was, and remains, that I cannot get hills to have any noticeable effect on more powerful, modern vehicles without them slowing to a halt older, less powerful vehicles. I wonder whether the problem is simply that the tractive effort for horses (1kn per horse) is too low? The same might be the case for the lorries, as I have calibrated the tractive effort for motor 'buses, but not for lorries.

Edit 2: I must confess, my understanding of the mathematics of the physics is limited, as, as I note above, it was Bernd Gabriel, not I, who wrote the physics engine.

However, I see that Vladki has managed to get a good understanding of the mathematics, but not to work out why this is not working properly in the code.

So I thought that it might help to record some numbers so that Vladki might be able to analyse them to understand what might be going wrong. I am looking in the sint32 convoy_t::calc_max_speed() method. I have set a breakpoint on the "return 0" line where the inertial forces are greater than the starting force. This is hit when a braked stage coach hauled by four horses is about half-way up a half height slope.

Converting to floating point for the purposes of the output (tip for Vladki: to do this, just create test variables and use the debugger to read the output: create easy to read floating point test variables by taking the float32e8_t values and using the to_double() method to convert them), I get the following values:

Frs: 1209.4868326187132
g_accel: 9.8066499978304016
fr: 0.0038333333322952967
cos: 4000.0000000000000
sin: 107.99999999999996

Vladki - is that of any help?

[Vladki]

Just checking - are you using two pairs of yourshire horses?
If so then the numbers are like this:
- weight_cos is just the weight i.e. - 4000 kg (empty), OK
- wieght_sin = 4000*27/1000 = 108   (27 is the friction factor shown in convoy window and is equal to slope in per mille), OK
- fr - should be rolling resistance - horses have 0, coach has 115/10000=0.0115. Hmmm, 0.0115/3 = 0.0038333 how did we get that?

OK, here we go: simvehicle.cc method convoi_t::update_adverse_summary, there is adverse.fr /= count. And count is 3 (2 pairs of horses and 1 coach)
Well it is not perfect, as the weight of the coach is slighly less than weight of horses, but still quite close. For more precision, one should not average fr across the convoy, but calculate fr*weight_cos per vehicle in weight_summary_t::add_weight. But this would cause changes at many many places in the code. So for now let's be satisfied with averaging.

But anyway, the calculation is not far off, and we get the starting force Frs= g*(fr*weight_cos+weight_sin)=1210 N. And these four horses should have tractive effort of 2 kN, soooo ? Why does it say it cannot move?
Ahh I forgot about gear = 57 (%) .... So 2000 N * 0.57 = 1140 N.

Could you check by denug output - that the starting force for 4 horses is indeed 1140 N ?

If so, then one horse has tractive effort of 285 N. In your comments in horse-shire.dat you state that horse has tractive effort 330 N at 5 km/h. So I think it will have higher tractive effort when not moving.
You also write that "Gear" works only for power. But that is not so. It works for tractive_force too:
See convoy.h, method power_index_to_power - the comment says it is used for force as well. And indeed it is called from convoy.cc - potential_convoy_t::get_force_summary and existing_convoy_t::get_power_summary

Uff, I'm getting really tired now, but it seems to me that the gear is applied twice:
EDIT: checked again - no it is probably OK - once it is the vehicles gear, and second time the global gear...

convoy.cc:

Code: [Select]

float32e8_t potential_convoy_t::get_force_summary(const float32e8_t &speed /* in m/s */)
{
        sint64 force = 0;
        sint32 v = speed;
        for (uint32 i = vehicles.get_count(); i-- > 0; )
        {
                force += vehicles[i]->get_effective_force_index(v);
        }
        return power_index_to_power(force, welt->get_settings().get_global_force_factor_percent());
}
So, we sum get_effective_force_index at speed v (in our case 0), and adjust it by global_force_factor:
convoy.h

Code: [Select]

        inline float32e8_t power_index_to_power(const sint64 &power_index, sint32 power_factor)
        {
                static const float32e8_t factor = float32e8_t(10) / float32e8_t(GEAR_FACTOR);
                return float32e8_t(power_index * power_factor) * factor;
        }
In simunits.h:

Code: [Select]

// GEAR_FACTOR: a gear of 1.0 is stored as 64
#define GEAR_FACTOR 64
I dont know what is this factor for, but shouldn't there be: factor = 100/64 instead of 10/64 ?   
This might be a bug?

Anyway, now let's see what get_effective_force_index does
descriptor/vehicle_desc.cc

Code: [Select]

/**
 * Get effective force in N at given speed in m/s: effective_force_index *welt->get_settings().get_global_power_factor() / GEAR_FACTOR
 * @author Bernd Gabriel, Dec 14, 2009
 */
uint32 vehicle_desc_t::get_effective_force_index(sint32 speed /* in m/s */ ) const
{
        if (geared_force == 0)
        {
                // no force at all
                return 0;
        }
        //return speed <= force_threshold_playerseed ? geared_force : geared_power / speed;
        return geared_force[min(speed, max_speed)];
}
and in the function just above geared_force is calculated using:

Code: [Select]

        float32e8_t g_force = float32e8_t(tractive_effort) * (/*(uint32) 1000L * */ (uint32)gear);   

The code for friction and drag forces, could be improved, but is more or less OK.
I'm not so sure about the power/force calculations, perhaps a debug run that will print the calculated starting force would be helpful.
But I think it will be more or less OK.

So we are left with two options:
either the simulated slope of 2.7 % is too steep for 4 horses pulling a coach - I do not think so.
then the only left option is that the real tractive force of horses is higher.

Think of a horse working at ancient mine. There is a vertical shaft with pulley on top. The rope goes vertically down to a bucket with ore, and horizontally to the horse. The horse has to pull the rope - go away from the shaft to bring the bucket to surface. If the horse's tractive force is 285 - 330 N, it would be able to pull up a bucket with at most 28-33 kg of ore. I think that it should be able to pull more.
Of course in real mine the horse will move in rounds, and there would be some transmissions to make his work easier.

Just a thought about trucks, which seem to be underpowered as well. I was trying to find some tractive_force info, but all I could fins is the torque of the engine. But to get tractive force, one has to know the transmission ratio of all the gears between engine and wheels, to get the torque at wheels, and then the wheel radius. However, we can estimate the upper limit for tractive force using static friction between wheels and way (rubber on asphalt). If higher force is applied, wheels will slip.

[Jando]

I'm seeing odd behaviour of more modern vehicles (Bus in 1934) as well, here's a save game of such a situation: http://files.simutrans.com/index.php/s/uP0BcKLhbTFYinG

Vehicle #12 (AEC Regal T (coach)) has just left Friar's Togden Town Hall Stop travelling south and is 6 tiles away from a bridge with upslope. The vehicle will slow down to 8 km/h after the slope. Edit: fully loaded buses will slow down to 1 km/h on hat bridge.

What I also find interesting is the information provided in the vehicle's detail information. It starts with Power 19 kW and Tractive Force 1 kN, but in the vehicle section (and the depot) it says 39 kW and 3kN. I assume there's the power output ratio of 0.5 playing some role with the result rounded down to the next integer value. Because of this rounding down any vehicle with 0.5 power ratio and less than 4 kN will have 1 kN effective force.

[jamespetts]

Thank you both very much for your input, and especially to Vladki for the very detailed analysis, and apologies for not having had time to look at this sooner.

I should note that, whatever is displayed in the GUI, the code internally uses non-integral units of power and tractive force once they have been multiplied by the gear factor, so rounding errors are not the issue here.

As to the GEAR_FACTOR, this code is unchanged from Standard, so I doubt that the bug is here; and being out by a factor of 10 would in any event produce more serious issues than those described here (being confined to hills).

In relation to the calculation of the tractive effort of horses, I used this as a reference, and spent a very long time calibrating them exactly in December last year (albeit only testing them on the flat).

Vladki - how does that source fit with your analysis of the issue with horses pulling vehicles up slopes?

Edit:  Just attempting something similar to the debugging exercise that Vladki suggested, when I run a two pairs of Feresian horses plus a rigid stage coach up the half-height slope, I get the following figures in calc_move (the below figures are taken using the to_double() method where they are float328e_t types and truncated to 3 decimal places):

adverse_cf: 0.149
f (before Ff and Frs are taken into account): 624.999
Ff: 0.011
Frs: 1212.572
f (after Ff and Frs are taken into account): -588.584
v: 0.277

As f appears to be the total tractive force being exerted on the convoy (that is, the motive force from the vehicle's power source, here the horses, minus the inertial forces from the friction plus the slope), the negative value appears to indicate that the physics code is calculating that the horses do not have enough power to pull the stage coach up the hill at all. The only reason that this does not stall is that the game imposes a hard minimum of 1km/h elsewhere in the code to make things easier for players (Standard has a similar limit, but set at 4km/h - this was reduced as some vehicles, especially canal boats passing through locks, need to travel more slowly than this).

Does this cast any light upon matters, I wonder?

Edit 2 I thought that it might be useful to repeat this exercise with the same convoy on level ground. In this case, we get:

adverse_cf: 0.14999999996507551
f (before Ff and Frs are taken into account): 371.58563089370722
Ff: 1.3845938201993691
Frs: 370.20103716850275
f (after Ff and Frs are taken into account): 0.00000000000000000
v: 3.0381944430992034

I seem to have misinterpreted what f might be here; but I notice that adverse_cf appears to be constant, but Frs appears to be more than 3 times greater on the hill than on the flat, and I am not sure whether that is correct or not.

[jamespetts]

Given that I have not worked out what the underlying issue is here and that this was causing real difficulty for stage coaches faced with any hill at all, I have pushed what I hope is at least a temporary fix to this issue, by reducing the effective steepness of hills for road vehicles only. This is not ideal as it is somewhat arbitrary, but the stage coaches now seem to function realistically, although note that stage coaches on hilly routes may well benefit from a team of six rather than four horses.

I should be grateful if people could confirm whether motor vehicle behaviour is any better in light of this fix. I should still be interested in fixing the calibration properly if I can ever work out what the problem was with it originally.