New Features: Display of remaining distance to the next station and gradient in ‰

Hello there, I'm S520. I'd like to introduce new features which I added.

1. Display of remaining distance to the next station.
First of all, I added display of remaining distance. It works shown as below.



Left: Stops at the next station.
Middle: Pass the next station.
Right: 10 meters left to the stop.

Press Ctrl+D to display remaining distance to the next station in form that [Stop or Pass]: [Remaining distance (m)]. If you press Ctrl+D again, remaining distance will be displayed in mile.


2. Display of Gradient in ‰.
I also added display of gradient in ‰ mainly for Japanese users. To use this, press Ctrl+N three times.

openBVE which includes these features is now available on here.
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2018-09-18.zip

In addition, I'm working for another brand new feature. STAY TUNED!

This post was translated by F81 tec200. I really appreciate it.

Great work, thank you. I noticed something strange though:

The first image shows the gradient in per cent, the second in ratio, the third in per mille. Now the first one, the per cent seems incorrect. Shouldn't it be 1.5% instead of 15? Because 1 / 67 ≈ 0.015 - if I'm not mistaken. So the per mille value is good.

Thank you for your comment.
As you say, it is 0.015 = 0.15% = 1.5 ‰.
However, in Europe, especially in the UK, % and ‰ are said to be synonymous.

I live in Europe, in Hungary and here we talk about gradients in per mille, so I'm happy about this feature. I hope Chris will have a look at the per cent value though.

No, per cent and per mille aren't synonymous. There's a distinct difference between hundred and thousand

...and I hate typing in the forum on the mobile phone, tends to delete chunks of text... Here we go again:

What you could have heard about is that some railways rather use percent and others permille. Germany uses permille for example. What's noteworthy is that the values aren't linearly connected. In the context of steepness values, "percent" usually denotes the sine of the angle (i.e. height per track length) while "permille" usually are the tangent of the angle (i.e. height per air distance), meaning 1% isn't exactly 10‰. However the difference is purely academic, since sine and tangent don't diverge significantly until way outside the angle range feasible in rail transport.

EDIT
http://www.wolframalpha.com/input/?i=y+%3D+(tan(x)-sin(x))%2Fsin(x)+for+0+%3C%3D+x+%3C%3D+3%C2%B0
Here you can see how minuscule the difference is; for railways it rarely exceeds 0.1% of the value

Thank you for your comment.

Previously Midnight Express Ginga 81 asked leezer3 this problem.

From Midnight Express Ginga81:
When I asked to leeser3, he answered that 'in the Britain, % and per mile is the difference meaning, but display usage is the same. So, I am not schedule that the display character is change to '‰'. '

He said to me, so I thought that leeser3 is not schedule to change this problem.

Should I create a pull request to fix this probrem?
Please let me hear your opinion.

Quork, thank you for your explanation and S520 thank you for the background info.

Mathematically speaking it is quite strange that for the first Ctrl + N I see that the gradient is 15% and if I go to per mille it is 15‰, and the pitch value is the same in the route. The same number but two different units, which express a difference of ten times multiplication. The decimal point seems to be in the wrong place. With my Central European mind where gradient is expressed in ‰ I would think considering a pull request about this is a good idea.

Phonteus Nevolius, thank you for your opinion.

As you say, the decimal point is in the wrong place.
It is easy to fix this problem.
I think that I should fix below code.
https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/Graphics/Renderer/Overlays.HUD.cs#L526

Missed this discussion

This seems to be a case where the units get horribly complicated based upon the country you're in (and probably the industry too)

The 'normal' representation of gradient in the UK / Australia / NZ / US on road signs is in %


Couple of samples, UK first then US / Australia:





I'd suspect it's an English (and hence Imperial) phenomon.

I'm wondering about a simple switch case based upon the language code in use. If we assume that anything other than en-GB / en-US requires the decimal point moved left one, that's dead simple to implement.
Doesn't help when someone wants English and the other decimal point position though

Erm... Chris, I'm pretty sure most, if not all countries yous percent in roads. Railways are a different thing though. I think permille are the most common unit, but "1 in x" is used in quite a few countries as well and I think (could be wrong though) it has been historically used in Germany sometimes as well. However, a language dependant switch wouldn't be correct even for languages where things are pretty straightforward, since it should rather be dependant on the route and not the client settings.

You're actually somewhat making the point I was trying to make

Most lay users of openBVE aren't necessarily going to be familiar with what the railway uses internally, but are instead going to be familiar with the road-sign based representation they see every day.
With that in mind, IMHO the % figure needs to match what is to be expected, as otherwise all we'll get is reports that it's 'wrong' in the other direction

Unfortunately, the fact that you're a train driver means that you're thinking in railway terms, rather than what I suppose I'd term common parlance.
Having a route-specific setting is also problematic, as that just introduces exactly the same confusion.

I suppose we could add an option for the percentage style to keep everyone happy, but in some ways we then end up with an overburdening of options.....

N.B. :

For reference, British railways use the 1 in N gradient system.
All road signs and other stuff use the 15% variant, which is absolute, not per-mile.

Sir leezer3
I did read these interesting webpage sites on the gradient and the terminology
http://www.railsigns.uk/sect24page1/sect24page1.html
https://en.wikipedia.org/wiki/Ruling_gradient
https://en.wikipedia.org/wiki/List_of_steepest_gradients_on_adhesion_railways

Good day and night for you
Hijau

This is a great added feature to OpenBVE. Is there a way though that distance to next station can be read in the train's animated file so it could be added to a cab display?

This is a great added feature to OpenBVE. Is there a way though that distance to next station can be read in the train's animated file so it could be added to a cab display?

Sure
Today's build adds the following functions to animated files:

distanceNextStation The distance in m to the next station.
distanceStation[stationIndex] The distance to the station with stationIndex
stopsNextStation Whether the train stops at the next station.
stopsStation[stationIndex] Whether the train stops at the station with stationIndex

These are not supported in viewers, or in objects not attached to trains (will return 0 in these cases)

Wow, that's great support Thanks. I'm going to implement this on a R179 and train (New York Subway) I'm developing. I've already implemented station updates on cab displays, as well as internal passenger signs (FIND on NTT trains in NY) using .destination instructions in the route. Here's a sample, This will add to the trains functionality. Here's a sample

Thinking about it, a logical addition would be the following:

nextStation Returns the next station index.
nextStationStop Returns the index of the next station stop.

That would probably dispense with most simple use-cases for the Destination command.

Will try and add these at some stage later today or tomorrow.

I tested the 5/29 build and it works great, except after the last stop if you continue it will crash OpenBVE  with
00:05:24  The route and train loader encountered the following critical error: Index was outside the bounds of the array.
00:05:25  WARNING: Program crashing. Creating CrashLog file: C:\Users\TF51d1\AppData\Roaming\openBVE\Settings\OpenBVE Crash- 2019.5.31[00.05].log

Understandable since there is no next stop the array became overran it's boundaries. 



I wanted to alert you though to a problem with the next build 5/30 which appears to have broken something, maybe just a bad build, but wanted to let you know. This is from the same route, (1 stop test route I use) 

Thanks again

Fixed both of them- Small typos can have a massive effect....

Today's build should also implement the two additions mentioned above

Works like a charm! It even fixes a problem I was just going to report, where condition statement to eliminate leading zeros resulted an array out of bounds error. Now it works perfectly!  Thanks.