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.

[Ranran]

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

I think this thread is related to the acceleration time estimation.

In Transport fever 2, the evaluation of convoy's acceleration power (power balance) is roughly evaluated as very good / good / bad, and the player determines the number of connected coaches or wagons with reference to it.
Currently in Simutrans-Extended, it is possible to estimate it from tractive force and convoy weight, but few people will be able to calculate and judge it instantly. Therefore, the acceleration notation is a good guide for players, as requested in the thread above.



This is a Japanese instant noodle patch. The display of acceleration is added next to the braking distance. check it out 

As I mentioned before, this should be able to switch the display unit like date and time display according to each country, but please note that since this is only a display test, it is a common km/h/s display in Japan. Also does not consider max loading weight yet.

[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).

[Ranran]

I overlooked a big issue - gear. (´・ω・｀)
Simutrans's "gear" simply multiplies power. So the difference in gear makes a difference in the apparent acceleration.
Perhaps setting the nominal value will show data close to the nominal acceleration, but the actual in-game acceleration may be different because gear is not taken into account.
However, I have no idea about that solution...
For example, should gear be multiplied by the value of gear based on 0.8?

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

Yes, it could be added the same display there.

[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.

[Ranran]

The acceleration I displayed in the testing dialog above is strictly called startup acceleration(起動加速度 in Japanese), and is often used in the Japanese railway to express vehicle specifications.
For example, the startup acceleration of a Class 800, known as Azuma, is 2.52 km/h/s (0.70 m/s/s), which is the startup acceleration value.
The following is the relevant article on Japanese wikipedia, but I could not find any English article that covered the same content.
https://ja.wikipedia.org/wiki/%E8%B5%B7%E5%8B%95%E5%8A%A0%E9%80%9F%E5%BA%A6


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.

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).

This complicates the calculation because the acceleration force is not constant above the rated speed. Finding the acceleration in the constant torque range is very easy because the calculation formula is simple.
(Currently the unit of tractive effort uses an integer kN and is so crude that it causes some computational errors when compared to the real one.)
It should be noted that the acceleration calculated above is estimated from the vehicle spec in the game, and is not an actual measurement of the convoy movement in the game.

I do not know how the slowdown of acceleration after exceeding the rated speed is handled in extended. In the real world, the tractive force when exceeding the rated speed can be confirmed by looking at the power notch curve, but I do not know what this formula is. Perhaps this depends on the motor, so the parameters needed for the calculation may be missing.
However, if you know the formula, you can also estimate the mileage and acceleration time.

Also, doing that calculation in convoy instead of a single vehicle can be more complicated. Because different motors have different characteristics.
When vehicles with different rated speeds are mixed in the convoy, the acceleration curve becomes complicated.


Issue
It looks like its display is already too long and may conflict with cargo capacity list.

EDIT:
I can't affirm it because I haven't played the transport fever so much yet, but the transport fever doesn't seem to simulate slowing acceleration at high speeds. Anyway, even at low speed, acceleration is slow and frustrating. 
In that case, the calculation of the acceleration distance will be easy.

[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.

[Ranran]

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


[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.

[Ranran]

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.

First of all, I really appreciate Bernd Gabriel's big job. 
I found he tried to implement the acceleration chart in the code but noticed it wasn't working properly.
So, I tried fixing it.

It was something like this. 


Now you can test it. My github branch is here 
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/dig-acceleration-curve-chart


memo:
The position of the Acceleration button is weird, but I didn't know how to fix it. (At first it was in a more weird place) (´・ω・｀)

[Ranran]

Back to the thread theme, I confirmed that we can get tractive force for each speed with the following code.

Code Select Expand

cnv->get_force_summary(speed_to_v(cnv->get_akt_speed())).to_sint32()
(This is the value multiplied by gear and it is currently used too.)

Using this (get tractive force every 1km/h up to maximum speed), it will be easy to draw the notch curve like this

This does not care that different rated speeds are mixed.
And if it display a resistance chart here, we may understand the importance of the streamline of high-speed trains


Such charts, including the BG's chart introduced in the previous post, are very useful, but they can't fit in the depot dialog.
Therefore, I think simple displays such as starting acceleration are still useful.
The chart will give you a clear visual understanding of the difference. But it is difficult to explain it in short texts.

Then I found it easy to apply the above function to estimate the time and distance needed for acceleration.
However, IMO, the distance and time required for maximum speed is not useful information in extended. It may be useful for simutrans-standard and transport fever.
In Extended, the acceleration is attenuated in the high speed range as in reality.
And, like the difference in "the gear ratio" in the real world, there is a difference between a vehicle that is good at high speed driving and a vehicle that is not good at high speed.

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.

The tractive force of a steam locomotive is almost lost at high speeds, leaving little propulsion. As you can see from the spec of the steam locomotives on the vehicle information, the rated speed is very low at around 10km/h. Steam locomotives and diesels have these characteristics, so I think they are the right settings.
It may take a long time to accelerate 1 km/h near the maximum speed. Especially when the speed is close to the balancing speed. The higher the maximum speed, the longer the distance traveled per second. As such, distance and seconds can be useless parameters, and that fact is easily overlooked.
Efforts to reach maximum speed for vehicles not good at high speeds overlook the fact that they are costly, resulting in unnecessary high costs.

For example, the vehicle in the graph above has a maximum speed of 100 km/h, but there is little tractive effort near 100 km/h. It is not advisable to pay any additional costs for reducing the distance and time for this vehicle to reach maximum speed.  (´・ω・｀)

The simple display of the starting acceleration is just one of the parameters for comparing vehicle performance when you feel the acceleration is slow.
If you feel that acceleration in the high-speed range is slow, you can check the rated speed of the powered vehicle and replace it with a vehicle with a higher rated speed.
In any case, making graphs will make them clearer.



The starting acceleration display patch is now in this state and repository is here
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/display-the-starting-acceleration




As described above, there is a problem with the display space.

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.

I made two patches in this thread;
1) the excavation of Bernd Gabriel's buried acceleration chart. This may be useful in that thread. I think there is room for improvement, but the core calculation hasn't been touched so far.

2) Add a simple starting acceleration display to the depot dialog (improve convoy performance comparison)
If we need to calculate travel distance or acceleration time, I need to add a lot of formulas, but since I didn't that so far, this seems less relevant to that thread.

[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.

[Ranran]

The acceleration graph - may I ask what units that the horizontal axis are in?

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.

[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.