[steamer_ctn]

Hi Dave,

Genma Saotome, on 06 August 2018 - 08:18 AM, said:

especially if the header data is skimpy.

I think that the code sets a standard framework for all the HUD pages, so that the Main HUD info is always shown regardless of what Advanced HUD page is showing. (If this is what you meant by header data)

Genma Saotome, on 06 August 2018 - 08:18 AM, said:

any chance you can be talked into adding yet another screen display, this one showing multiple columns containing only car number and slack/buff status?

I am not enthusiastic about the idea of adding another page, because I believe that all the Forces information is relevant. I think separating one element of the Forces information onto a separate page and displaying it for all cars, whilst not doing the same for the rest of the Forces information is not solving the "larger" problem.

I know that the Activity Event window can have scroll bars displayed if the amount of information in the window exceeds a certain amount, so it might be possible to add scroll bars (or perhaps PgUp and PgDwn functionality) to the HUD window as well. But a developer who has a better understanding of the graphics code of OR would need to take this task on.

Perhaps somebody would like to add this request to the Roadmap?

So for the time being, unless we get another developer offering to look at the scroll bars functionality, I believe the only viable option to implement is the "Short/Long" option.

Genma Saotome, on 06 August 2018 - 08:18 AM, said:

A negative value should be reserved for pushing cars, don't you think?

Whilst I can understand (and agree to a certain extent) what you are saying, the sign is only a convention for users to use as a frame of reference. Regardless of whether it is +ve or -ve, is probably not a major issue, provided the user knows what the convention represents.

However, it would be possible for me, for HUD display purposes only, to change the sign of the value (and hence the convention), however this would require broader community agreement, as most users are probably used to the current convention. It would also require a community volunteer to review the Manual and make changes to all relevant references to match the new convention.

[steamer_ctn]

With OR release #4168, wind resistance has been added. Additionally the slack indication has been re-instated.

Wind Resistance

The default Davis resistance formula is only valid for train operation in STILL air. At high train speeds, and especially for Very Fast trains the impact of wind can be quite significant, and special consideration is required when designing rolling stock, etc. If wind is present, then the impact of drag forces on the train will vary, and be in addition to the values calculated in the default (or still air) conditions.

The wind resistance in OR is modeled by the following two components:

• Wind Drag Resistance – If a train is heading into a headwind then the train will experience greater resistance to movement, similarly if the train has a tailwind, then the trains resistance will decrease as the wind provides a “helping hand”. As the wind swings from the head of the train to the rear resistance will decrease. When the wind is perpendicular to the train, drag impact due to the wind will be zero.

• Wind Lateral Force Resistance – When the wind blows from the side of the train, the train will be pushed against the outside track rail, thus increasing the amount of resistance experienced by the train.

To activate calculation of wind resistance, select the tickbox for "Wind dependent resistance" in the Simulation TAB of the options menu. As wind only becomes significant at higher train speeds, the wind resistance calculation only commences once the train speed exceeds 5 mph.

The amount of wind resistance that the train is experiencing is shown in the FORCES INFORMATION HUD. (see attached screenshot) The current wind conditions are also shown in the HUD, and include the Wind speed and direction, train direction, and the resulting vectors for the combined train and wind speed. The value in the Friction column is the default still air conditions as calculated by the Davis formula.
It should be noted that OR calculates the Wind Drag resistance as a difference compared to the still air Davis C value, and hence it is possible for values in the Wind column to go negative on occasions. This is most likely when the wind is blowing from the rear of the train, ie the ResWind direction is greater then 90^o degrees, and hence the wind is actually aiding the train movement, and in effect reducing the amount of still air resistance.

The wind model has been adjusted in the following way:

i) Update speed - 1 sec
ii) Wind direction will always be within +/- 45^o degrees of the randomly selected default value selected at startup
iii) Wind speed is limited to approx 10mph at the moment. (It is hoped that the wind model can be further developed to align with different weather patterns, and perhaps other wind conditions, such as stronger winds or gales can be modeled. Though it should be noted that a number of railways restricted operations when the wind speed exceeded 55 mph. This hopefully will be taken on by another developer)

The Wind Resistance model will use default information, such as the width and height of the stock from the Size statement, so by default it is not necessary to add any additional parameters for its operation. However for those who like to customise, the following parameters can be inputted via the WAG file or section.

ORTSWagonFrontalArea - The frontal cross sectional area of the wagon. The default units are in ft^2, so if entering metres, include the Units of Measure.

ORTSDavisDragConstant - OR by default uses the standard Davis Drag constants. If alternate drag constants are used in calculating the still air resistance, then it might be worthwhile inputting these values.

Slack Indication Re-Implementation
Slack indication has bee re-implemented into the FORCES INFORMATION HUD. Some additional information has also be included that hopefully will be of value (pending code correction - see below).

There are three columns of information associated with the coupler as follows:

i) Coupler (1st) - shows the coupler force.
ii) Coupler (2nd) - shows whether the coupler is a Rigid or Flexible coupler (Denoted by R or F). The second piece of information in this column is an indication of the state of the coupler which can assume one of these states - Pull, Push, xxxx (overloaded), - (null state).
iii) Slack - shows the amount of slack in the coupler The only changes implemented in this patch are to make the indication visible again.

Whilst reviewing the code for the indications I noticed that the couplers appear to default to Rigid couplers regardless of whether or not that is required by the use of the CouplingHasRigidConnection, hence the addition of the indication to show whether OR is using a R or F coupler. As far as I can tell it appears to be an issue in reading the value from the WAG file. I have engaged with another developer to seek some guidance as to why it is not working. I suspect that this bug has been in OR for a long period of time.

If anybody is able to get an F indication in the coupler, then I would be interested.

Thanks

Attached thumbnail(s)

• 

[James Ross]

steamer_ctn, on 05 August 2018 - 11:47 PM, said:

If no one is able to look at the scroll option, then perhaps a work around would be to have a "Short/Long Train Display" check box in the options menu. In the SHORT mode the display would show every car in the train, as is currently the case. For LONG trains, the display would display, say every 3rd car.

It should be possible to make the display show the first and last N cars, where N is the maximum you can fit at once on the screen. That covers many of the use-cases of seeing the whole train, right?

I should be able to squeeze this in if nobody else can.

Scrolling would be nice but is likely more work than reward given this is meant to be a debug area.

steamer_ctn, on 05 August 2018 - 11:47 PM, said:

The addition of the "Short/Long Train Display" check box is not my preferred option, as I personally believe that we have far too many options in the options menu, however it depends the alternatives that are available and the support that it gets.

Definitely agree on the number of options thing. :/

steamer_ctn, on 06 August 2018 - 11:29 PM, said:

I know that the Activity Event window can have scroll bars displayed if the amount of information in the window exceeds a certain amount, so it might be possible to add scroll bars (or perhaps PgUp and PgDwn functionality) to the HUD window as well. But a developer who has a better understanding of the graphics code of OR would need to take this task on.

Unfortunately the HUD is not a "normal" window, it's instead just a load of text being drawn on screen (roughly).

steamer_ctn, on 06 August 2018 - 11:29 PM, said:

Perhaps somebody would like to add this request to the Roadmap?

It is currently the most-voted "Not planned at this time" item on our roadmap (because of the aforementioned cost/benefit). :/

steamer_ctn, on 06 August 2018 - 11:29 PM, said:

However, it would be possible for me, for HUD display purposes only, to change the sign of the value (and hence the convention), however this would require broader community agreement, as most users are probably used to the current convention. It would also require a community volunteer to review the Manual and make changes to all relevant references to match the new convention.

I would suggest that the most useful form for all the data on the HUD is to be corrected for any flipping, so that e.g. force numbers are always the same sign if they're in the same direction relative to the train (not car). That does mean that a bunch of values will need to be "flipped" (multiplied by -1) if the car is flipped, but this does not need any changes to the actual physics - they should continue use whatever is best for them, and the HUD adjusts them to suit the user.

[James Ross]

steamer_ctn, on 09 August 2018 - 12:14 AM, said:

ORTSWagonFrontalArea - The frontal cross sectional area of the wagon. The default units are in ft^2, so if entering metres, include the Units of Measure.

We really need to add a better area unit to the parser. I'd be much happier with requiring units than assuming non-SI. :(

[Genma Saotome]

Quote

ORTSWagonFrontalArea - The frontal cross sectional area of the wagon. The default units are in ft^2, so if entering metres, include the Units of Measure.

Please do not do this. Please do two parameters, one for height and one for width.

The reason for this is there is ample data in North America that provides height and width of rolling stock in integer feet and (usually integer but sometimes fractional) inches. Calculating area in, say, square feet becomes ((Hft*12 + (H-in/12) * (Lft*12 + (L-in/12))/144. To ask us to do that math when the computer can do the math too -- and always be correct -- is an imposition.

The necessary programming is trivial -- a handful of lines at most -- but asking everyone to do the math themselves, for all of their cars and locomotives, is really a bit much.

So please do ORTSWagonHeight() and ORTSWagonwidth() and allow values to be submitted as (nnft nnin). Everywhere else in the world that uses sensible units of measure can deal with this just as easily, but we are stuck with the way things are documented.

[R H Steele]

Genma Saotome, on 09 August 2018 - 10:26 AM, said:

...
So please do ORTSWagonHeight() and ORTSWagonwidth() and allow values to be submitted as (nnft nnin). Everywhere else in the world that uses sensible units of measure can deal with this just as easily, but we are stuck with the way things are documented.

In agreement with Dave on this aspect.

With this exception - preference for the use of metric UoM for distance.

Currently, manual states that the default UoM for distance is meters, and the size parameter in most wag files I've seen is also in meters.

Why add a different default just for this specific code. Better to keep some consistency and precision.
To quote "is trivial" to change "nnft nnin" to meters in decimal form.

[Genma Saotome]

Gerry, the default can be metric everywhere as far as I am concerned but IMO every measurement should accept an alternative UoM -- as they presently do. This was discussed and resolved within the OR team many years ago: You get to record your values using the UoM you are most familiar with, period. IMO it was a good decision and there is no need to revisit the issue.

[R H Steele]

Genma Saotome, on 09 August 2018 - 12:55 PM, said:

Gerry, the default can be metric everywhere as far as I am concerned but IMO every measurement should accept an alternative UoM -- as they presently do. This was discussed and resolved within the OR team many years ago: You get to record your values using the UoM you are most familiar with, period. IMO it was a good decision and there is no need to revisit the issue.

I think we are talking at cross purposes, I thought you wished for the default to be changed to nnft nnin, that is obviously NOT what you were saying.I am happy with the decision made years ago to have a default but accept many other UoM, provided they are expressed - that's very sensible.

[Genma Saotome]

R H Steele, on 09 August 2018 - 12:59 PM, said:

I think we are talking at cross purposes, I thought you wished for the default to be changed to nnft nnin....

Oh, well, if I gave that impression I am sorry for it. My intention for such matters never strays from the established metric units as the default.

Our particular problem is the documentation we have to work from isn't metric, the computation of area or volume using those units is awkward, and unfortunately how we would record the data in a singe field is also awkward. A long time ago I argued you should never couple two values in one field (the old Friction() parameter is a prime example) because it makes it more difficult to get at any one portion of the whole; And so I argued for Feet() and Inches() -- two parameters. The OR team thought I was nuts. And what we get to use now is ParameterName (nn ft nn in). As long as that is the answer in other places it shou8ld also be available for anything new that asks for Length() and Width().

[steamer_ctn]

James Ross, on 09 August 2018 - 09:16 AM, said:

It should be possible to make the display show the first and last N cars, where N is the maximum you can fit at once on the screen. That covers many of the use-cases of seeing the whole train, right?

I should be able to squeeze this in if nobody else can.

I assume that if the number of cars doesn't exceed the capacity of the screen resolution then all the cars will be shown. If it does exceed the capacity, how would it drop out cars in order to show the last ones?

In principle, I would be comfortable with this approach.

If others are in agreement, then I am also happy for you to adjust the HUD as appropriate.

James Ross, on 09 August 2018 - 09:22 AM, said:

We really need to add a better area unit to the parser. I'd be much happier with requiring units than assuming non-SI. :(

By convention I would prefer all users to include UoMs rather then relying on default values, ie ideally no parameter should be unitless.

Sadly because of legacy issues it is hard to enforce this in the code without causing problems with existing WAG/ENG files.

Perhaps in the future, a parser can be created that users can use to parse their WAG and ENG files, ie it reads the files, prompts the user for any corrections, and then saves the new improved version instead of the older one.

Genma Saotome, on 09 August 2018 - 10:26 AM, said:

Please do not do this. Please do two parameters, one for height and one for width.

.............................................................

So please do ORTSWagonHeight() and ORTSWagonwidth() and allow values to be submitted as (nnft nnin). Everywhere else in the world that uses sensible units of measure can deal with this just as easily, but we are stuck with the way things are documented.

By default the ORTSWagonFrontalArea is not required as OR calculates the frontal area from the Size (width x height) statement already in the WAG file. However this approach produces a standard box shaped frontal area.

However not all cross sectional shapes are a standard box shape, and so this parameter was added to allow interested users (ones who are prepared to do the maths) to enter a "more accurate" area figure then the value calculated by default.

For example the standard Davis equations suggest the frontal area might look like the shape shown in the attached picture. Similarly a steam locomotive may have a predominantly round profile.

The area parameter allows more flexibility in the calculation of complex shapes, which just using a width x height will not allow.

As a clarity note for the other discussions on UoM, the parameter can be in either standard metric or imperial area measures, provided the UoM are specified.

Attached thumbnail(s)

•