Viewing curve speed limits and calculating acceleration time/distance

[dannyliux]

Recently I've been playing Transport Fever, and while it's a more casual type of transport sim it does have some useful features. The first is the ability to see track curve speed limits:



And secondly the ability to see how long, in terms of distance and time, a consist will take to accelerate to max speed on flat ground.



As far as I am aware, these features don't seem to be present in Simutrans Extended? I think it'll be really useful to know the track speed limit without having to run a train through it. And perhaps the acceleration distance could be posted beside the braking distance? Right now it's mostly down to guesswork because locomotive power ratings seem to be peak power, and thus my calculations almost always underestimate the acceleration distance.

[jamespetts]

I can see that this might be useful - but this would be very complex to implement in Extended, not least because the curvature is extrapolated from neighbouring tiles to make up for the very limited granularity in directions (on a tile by tile level, one can only have 45 degree or 90 degree corners, and even the 45 degree corners are a hack combining two 90 degree corners in opposite directions). This means that the same tile of track can have a different speed limit depending on what goes before and after it, which is especially an issue at junctions.

Incidentally, I will move this to the Simutrans-Extended development forum, as this is a feature request.

[jamespetts]

This is an interesting patch; thank you. I should note that doing this in km/h/s is almost certainly far clearer to a player than doing it in m/s², as the former measure is related to something that the player can readily understand (km/h), whereas m/s is not a normal way of thinking about the speed of transport vehicles.

I wonder whether this display might also be added to the convoy detail display?

[Vladki]

The acceleration of (fast) passenger cars is often specified as the time needed to accelerate from 0 to 100 km/h. Although the acceleration is not constant, it can be estimated from km/h/s (x100).
Many vehicles in simutrans will not be able to run that fast, but it could be modified to time needed to gain full/max speed, or some portion of it.

Other countries may use something else for acceleration, just as with fuel consumption. Here we use liters per 100 km (less is better), americans use miles per gallon (more is better).

[Mariculous]

Yep, gear i simutrans it really that simple.
effective_power=power*gear
It has nothing to do with actual gearing, it should better be named something like power_loss_factor.

I am wondering how exactly you calculate acceleration. Force decreases with growing speed, thus acceleration als decreases.
Did you calculate starting acceleration, average 0-100 acceleration, average overall acceleration?

[jamespetts]

"Gear" is a very poor name for this, and very confusing. In the Simutrans-Extended English translation texts, it has been renamed to "power output ratio". It is used simply to simulate transmission losses so that a vehicle's nominal power output based on actual research can be used even when that nominal power output does not take into account transmission losses.

[dannyliux]

Personally, I think a 'time/distance to accelerate to top speed/100kph' would be better, firstly because of the variable acceleration. Secondly, I think that information is more useful since players use the distance between stops or journey time when planning consists, it makes more sense to include distance/time info.

As for the curve speed, is there any formula or look-up tables for players to calculate it manually? I would still like to be able to plan my route better, but I understand that the overlay approach may not be feasible.

[jamespetts]

Personally, I think a 'time/distance to accelerate to top speed/100kph' would be better, firstly because of the variable acceleration. Secondly, I think that information is more useful since players use the distance between stops or journey time when planning consists, it makes more sense to include distance/time info.

I can see the merit in that approach, as it might be easier for players to interpret than a km/h/s figure, especially given the non-linearity of acceleration. Distance to reach top speed is probably the most useful figure for players in this context.

As for the curve speed, is there any formula or look-up tables for players to calculate it manually? I would still like to be able to plan my route better, but I understand that the overlay approach may not be feasible.

There is a formula, based on real railway cornering speeds, but I must confess that I cannot remember what it is now. It should be in the code somewhere; I think that there is a link to the website that described the formula either in the code, on this forum, or both.

[Ves]

I would like there to be both the "0-100km/h in X seconds", as well as "top speed reached in X meters". The first is useful to compare vehicles against each other. The later is useful especially for trains as that might help you with the track and signal layout. 

As for curve speed, I think we talked about it a while ago.
Don't you think it would be possible for the infowindow of a piece of track to count the tiles in either direction and from that determine it's gradient at its tile? Will be hard at junctions, but that should perhaps just kill the search, or perhaps do some clever tile counting to determine the straightest path through the junction and display that.

[jamespetts]

I would like there to be both the "0-100km/h in X seconds", as well as "top speed reached in X meters". The first is useful to compare vehicles against each other. The later is useful especially for trains as that might help you with the track and signal layout. 

The trouble with using a fixed speed is that there are a lot of vehicles that have a low top speed, less than 100km/h.

As for curve speed, I think we talked about it a while ago.
Don't you think it would be possible for the infowindow of a piece of track to count the tiles in either direction and from that determine it's gradient at its tile? Will be hard at junctions, but that should perhaps just kill the search, or perhaps do some clever tile counting to determine the straightest path through the junction and display that.

I am sure that it is possible in theory to do this, but the workload of this would be very high and its priority low compared to many, many years' worth of other features.

[Mariculous]

We had already discussed this in another thread.
I still think the only really useful acceleration information is something like "accelerates to n km/h in x km or tiles", where n can be chosen by the player.

Especially steam engines don't reach their vmax often and later on for stopping services it may be of much more interesst to know how quick a train that is mainly used at 120 km/h whill reach that 120 km/h instead of trains maximum speed of e.g. 140 km/h
Same foes for tube trains whkch can't reach tvekr full speed in tube tunnels or any other train service that has short stop distances so it doesn't really matter how fast they reach maximum speed as they won't accelerate to that speed pretty often.

To compare trains even better, we need to calculate and display trains travel times for a given line, which is currently indev afaik.

[DrSuperGood]

Acceleration slows as higher speeds are approached due to increased losses. Hence a simple metric of one point of acceleration that is not very useful.

This is why I recommended acceleration against speed graphs to show acceleration to the player. This instantly gives the player feedback as to what a reasonable to obtain speed for the vehicle would be since when acceleration is just 1 or less km/hour/sec it will likely not reach or progress past those speeds. The player could also set a load weight for the graph simulating some volume of goods being transported since weight affects acceleration.

[Mariculous]

A graph is also fine but speed/acceleration is not what players usually want to know. They are usually interessted in speed/distance or speed/time.

[DrSuperGood]

speed/distance

Not that meaningful due to how the two relate. Where as speed and acceleration are finite, distance is not. It is not clearly showing the acceleration.

This is the sort of value that a field could calculate if queried by the player. For example the player could request to know what speed the vehicle will reach in 10km, or what distance would be required to reach 100km/h. These have applications for some kinds of line optimization, but generally does not give an idea of how quickly a train reaches a functional speed.

A possible use case for this might be optimizing distances between stops to reach a desired average speed. However such graph would not be showing the deceleration required so is not useful for this anyway. Instead another graph would be needed, average speed against distance between stops. The graph could have some reasonable upper limit such as 90% of the maximum speed at which distance the convoys would be operating very efficiently irrespective of acceleration.

speed/time

This is more meaningful and gives the player an idea of how quickly it will reach a reasonable speed. If one has a cut-off of 5 or 10 minutes of acceleration then one gets a reasonable idea of what practical speed a vehicle might reach.

A graph is also fine but speed/acceleration is not what players usually want to know.

It still has value with respect to knowing how well the vehicle accelerates when at speed. When the acceleration (Y axis) is low then that is likely a speed that is not reasonable to obtain.

The point of graphs would be to help the player visualize what they could expect from their vehicles. For example their steam engine train configuration might have a maximum speed of 120 km/h but looking at the graphs that speed is in a very bad place for acceleration, so something like 90-100 km/h would be more reasonable to expect it to run at as acceleration is good up until then.

The acceleration is constant from speed 0 to the rated speed as shown in the graph in that article. This is a characteristic of electric motors, but in simutrans extended, all powered vehicles show the rated speed, and we speculate that diesel engines may also behave like electric motors. In that case, even in the case of a diesel engine, it should be correct as an in-game specification.

Any UI system needs to be pretty general and apply to steam and other vehicle types as well. It also must return values which are consistent with the physics used to move the vehicles rather than to real life directly.

[Qayyum]

When pressure out of engine = pressure into the engine, acceleration is countered by equal drag, you get maximum operable speed.

[jamespetts]

I found something in the code, is this still visible on the GUI?

Code Select Expand


#ifdef ACCELERATION_BUTTON
//Bernd Gabriel, Sep, 24 2009: acceleration curve:
if (filterButtons[ACCELERATION_BUTTON].is_visible() && filterButtons[ACCELERATION_BUTTON].pressed)
{
const int akt_speed_soll = kmh_to_speed(convoy.calc_max_speed(convoy.get_weight_summary()));
float32e8_t akt_v = 0;
sint32 akt_speed = 0;
sint32 sp_soll = 0;
int i = MAX_MONTHS;
physics_curves[--i][0] = akt_speed;
while (i > 0)
{
convoy.calc_move(welt->get_settings(), 15 * 64, akt_speed_soll, akt_speed_soll, SINT32_MAX_VALUE, SINT32_MAX_VALUE, akt_speed, sp_soll, akt_v);
physics_curves[--i][0] = speed_to_kmh(akt_speed);
}
}
#endif


I believe not, as the relevant preprocessor directive is not defined. I am not quite sure what happened to this in the end; I suspect that it may be incomplete, but I am not sure how incomplete.

[Mariculous]

Speed/tiles or time/tiles is what players are interessted in. The only thing one could read from speed/acceleration is a guess for maximum expected speed but it's hard to guess from that gurve how much distance it will need to get to that point.
Thus, this information might be roughly useful for long distance trains, It is nearly useless for stopping trains and I don't think it's much harder to see where the speed/tiles curve becomes roughly flat, compared to see where acceleration/time curve gets close to 0.

However, these all seem to be useful in some case, so maybe we could add multiple graphs just like in any other graph window, where we can select which graph to show. We have to make changes to current graph display in either cases anyway bcecause tve current grid is too large.

Useful canditates would be imho v/t: easyest to compare acceleration performance to a given speed but not easy to understand how long the distance has to be to reach a given speed.
v/d: roughly the same as v/t but one can immediately see how much distance is needed to reach a given speed. The downside of this is that the curve will flatten the faster the train gets even if acceleration was constant.
v/a: we can immediately see the acceleration at a given speed, so we can also see where our trains speed is capped, which can be useful for long stop distances but it's not pretty useful to compare vehicles for short stop distances especially if their characteristics are different e.g. one has a high starting acceleration but can't hold it for a long time (high tractive effort, low power) where the other one has a lower starting acceleration that it can hold up much longer (low tractive effort, high power)

The point of graphs would be to help the player visualize what they could expect from their vehicles.

For a stopping train, I want to know if I can expect a vehicle to reach a given speed roughly as fast as another vehicle. Comparing acceleration c

[Vladki]

I think that the starting acceleration suggested by ranran is enough for comparison purposes. I guess it is as simple as

Code Select Expand

acceleration = tractive_force / conwoy_weight

[jamespetts]

I think that the starting acceleration suggested by ranran is enough for comparison purposes. I guess it is as simple as

Code Select Expand

acceleration = tractive_force / conwoy_weight

A basic metric of acceleration is likely to be sufficient for comparison; but do we want more than comparison? And, if we do, is the more than comparison that we want more than Ranran can sensibly code in a reasonable time?

Also, it is not as simple as acceleration = tractive effort / total weight, as steam engines have different acceleration physics compared to other types of vehicle; there is also the issue of some vehicles having a lower aerodynamic drag (as specified in the .dat files) and different waytypes having different rolling resistance to overcome.

[Vladki]

I think starting acceleration is enough for the game purpose - we get 80% precision with 20% effort. Further improvements (remaining 20% of precision) would require another 80% effort.  (Or was the rule 10/90 ?)
Aerodynamic drag depends on speed - so it can be ignored in starting acceleration when speed is 0. So how about:

Code Select Expand

acceleration = (tractive_force - rolling resistance) / conwoy_weight
Maybe two values would be interesting - for empty and fully loaded convoy.

[Qayyum]

Drag (rolling resistance) can be measured by considering air pushing the surface area facing front when front face is straight. When front face is slanted, air pushing surface area slanted be less force.

[DrSuperGood]

I think starting acceleration is enough for the game purpose

When playing on the bridgewater brunel server I never had issues with starting acceleration. I always had issues with guessing maximum reasonably obtainable speed for steam engines. My steam engines ratted at 120 km/h would struggle to get anywhere near that despite having sufficient power due to the very low acceleration at higher speeds.

[Vladki]

When playing on the bridgewater brunel server I never had issues with starting acceleration. I always had issues with guessing maximum reasonably obtainable speed for steam engines. My steam engines ratted at 120 km/h would struggle to get anywhere near that despite having sufficient power due to the very low acceleration at higher speeds.

Then, it would be nice to have the value how many km it takes (on straight level track) to gain full speed. Just an opposite of braking distance.
If the convoy is too heavy, then the max possible speed with given weight.

[Mariculous]

If the convoy is too heavy, distance to reach max possible speed is pretty meaningless as it will be very high and reaching a little bit less speed will require drastically less distance.
That's why either a user selectable speed or a graph should be used.

Also note, the calculating acceleration time/distance part of this thread seems to be strongly related to https://forum.simutrans.com/index.php/topic,19363.0.html, so I won't add it to the feature request list.
If you feel it is not related, please let me know so I will add this.

The Viewing curve speed limits part would require an other approach to curve speeds, which would be nice for usability reasons, but I don't think it is something that is of high priority. Also let me know if you think it is of high priority or should be added to the list nevertheless.

[jamespetts]

This is very interesting work - thank you for this.

The acceleration graph - may I ask what units that the horizontal axis are in? Normally, the horizontal axis on the convoy graphs are in months, but clearly that is not the case with acceleration.

The starting acceleration display is interesting indeed, although the overlapping issue is unfortunate. I am not quite sure how to solve that. I should be interested in others' views on the significance of the starting acceleration display and the overlapping issue.

[jamespetts]

Code Select Expand


convoy.calc_move(welt->get_settings(), 15 * 64, akt_speed_soll, akt_speed_soll, SINT32_MAX_VALUE, SINT32_MAX_VALUE, akt_speed, sp_soll, akt_v);

You can see from this code that he has assigned 15 * 64 to delta_t.
I don't know how many seconds this shows in the game, but I think it's about 4 seconds when estimated from the starting acceleration shown in the depot.
That means that it will probably show 44 seconds of acceleration in the chart.

Interesting - thank you for working that out. Given that the horizontal axis is labelled 0 to 11, this is potentially confusing; I wonder whether there is a simple way of making this clearer to the player?

[Ves]

Perhaps split the line of text in two, so you have one very long line with acceleration details, and the following line with braking details. The cost would be that the depot window will have to grow yet another line, but that arrangement would make sense I think.

As to what it should say, I still am a big fan of the more simple "accelerates to 100km/h in X seconds". Especially if the graphs doesnt fit in the depot! For more granularity more entries could be added:
"Accelerate to: 50km/h in X seconds; 100km/h in Y seconds; 167km/h (max speed) in Z seconds."
So if there is an unreasonably big gap between some of the intervals, it is pretty obvious that the vehicle doesnt accelerate very well in this speed region.

I like the graphs in the convoy info, that looks very "engineering like"! If also the axis'es could be declared.

[Qayyum]

A slider would be convenient.

[jamespetts]

The "accelerates to 100km/h in X seconds" is probably unworkable: there will be many convoys that cannot reach 100km/h at all (think of early freight trains and trams, for instance) and there will be many that take many, many minutes more to reach 100km/h than to reach 95km/h or even 99km/h; so this display does not give a useful general comparison between vehicles, nor does it provide (except in a few cases) a useful applied metric.

Ideally, one would have an adjustable applied metric (accelerates to Xkm/h in Ykm, with players able to alter either X or Y and the other of the two numbers being calculated), but I anticipate that this may be a lot more work for RanRan. However, it is better to have at least some comparison of acceleration than none.

[Mariculous]

So what I suggest is the follwing two things:
1. Show "accelerates to <selectable speed> in ... seconds" in the depot for a given train, to get a rough overview of acceleration of a train.
2. Show calculated travel times for full and empy trains (maybe also not overcrowded full times) in between stations in the "times history" window.

The first just seems to be what you suggested
The second is just for completeness. Afaik it's WIP but don't know for sure.

[jamespetts]

Qayyum - a slider might be a fairly easy interaction for the player, but I suspect that it would be difficult to code as there is no existing control in Simutrans in the form of a slider.

Freahk - yes, there is some sense in that suggestion; but the question is whether Ranran is realistically able to code this within a reasonable time.

[Qayyum]

Maybe 'change numbers as convoy added'?

[Qayyum]

Code Select Expand

This chart shows how the convoy accelerates for one minute.
Can be changed to this"

Code Select Expand

This chart shoes the behaviour of convoy when moving forward constantly from start of journey to one minute after, assuming no junctions.

[jamespetts]

Thank you for your work on this. One question about units again, if I may: does "one minute" here refer to a minute in real time or in-game time? The latter would be more useful, I think.

[jamespetts]

I inferred that it was one minute from the acceleration display calculated from the traction force displayed in the depot. When confirmed in the game, it seems to match 1 minute in the game.

Splendid, thank you for confirming: that is very helpful. This does look very interesting. It will not be practical for me to test this until I get home next week, but I should in the meantime be interested in others' feedback on how useful that this feature is likely to be. Since it has already been coded, it only needs to be slightly useful (and not cause any other problems) to be integrated.

The real question is whether the extra space taken in the convoy overview window with charts is worth the extra data: I should be interested in players' views on that question.