[Genma Saotome]

steamer_ctn, on 09 August 2018 - 02:41 PM, said:

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.

Actual Size represents the bounding box so any inconsequential protrusion, such as an old style vertical brake wheel would greatly expand the area.

steamer_ctn, on 09 August 2018 - 02:41 PM, said:

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.

Ok... understood. A counter proposal then: Add these fields:

• BodyWidth ( ) a.k.a. MaxWidth
  
• BodyHeight ( ) a.k.a. Height to Eaves
  
• MaxHeight ( )
  
• WidthAtMaxHeight ( )
  
• RailToSideSill ( )
  
• WidthOfTrucks ( )

and compute this:
FrontalArea = (RailToSideSill * WidthOfTrucks) + (BodyWidth * BodyHeight) + (((WidthAtMaxHeight/2) * (MaxHeight - BodyHeight)) + (((MaxWidth/2) - (WidthAtMaxHeight/2) * (MaxHeight - BodyHeight)) * 2))


In simple English that's area of the trucks plus area of the car body plus area under the running board/fans/clerestory plus area from car side to the previous point I described. If the computation of the roof profile is insufficient then a bit of rethinking on what to call another parameter to describe the side to vertical protrusion will tighten it up nicely.



That's what is needed to get a reasonably accurate frontal profile for Davis. Any 3d modeller can do the measurements in his software and fill in the blanks. It gets OR that much closer to calculating Davis A, b, and C for the end user, it gives you exactly what you want, and it relieves everyone from having to do what you yourself describe as an obstacle: a willingness to do the maths. And if you look at that formula for long enough you'll want to be using a spreadsheet to compute it. IMO that is asking too much -- and that is also what you need to do in order to get the right value out of fcalc.

Common guys, give us end users a break -- that is a lot of work; computers are really good at doing that sort of work.
\
Just to be clear Peter, I'm not trying to discourage or dismiss your objective as described, it's fine. I'm trying to leverage the opportunity it represents to nudge the OR software towards also doing the right thing WRT Davis.

[steamer_ctn]

Genma Saotome, on 09 August 2018 - 06:49 PM, said:

Ok... understood. A counter proposal then: Add these fields:

• BodyWidth ( ) a.k.a. MaxWidth
• BodyHeight ( ) a.k.a. Height to Eaves
• MaxHeight ( )
• WidthAtMaxHeight ( )
• RailToSideSill ( )
• WidthOfTrucks ( )

The profile attached merely showed how the Davis cross sectional area was to be calculated. Wagons and locomotives have many different profiles (see attached for some more examples).
To cater for all these different shapes, and others, it will be necessary to increase the complexity of the code, and the number of inputs required.

Genma Saotome, on 09 August 2018 - 06:49 PM, said:

Common guys, give us end users a break -- that is a lot of work; computers are really good at doing that sort of work.

However humans are more adaptive then computers (hopefully), so they are in a better position to adjust for any different shape profile. OR would need to cater for all different shapes.

Using the Area allows the user to cutomise and provides ultimate flexibility for any different profile without huge amounts of extra code to cater for the different profiles.

Genma Saotome, on 09 August 2018 - 06:49 PM, said:

Just to be clear Peter, I'm not trying to discourage or dismiss your objective as described, it's fine. I'm trying to leverage the opportunity it represents to nudge the OR software towards also doing the right thing WRT Davis.

Fair enough, but sometimes it needs to be recognised that it is sometimes more expedient to allow calculations outside of OR. This gives the user ultimate flexibility without locking them into one or two different shape profiles.

Attached thumbnail(s)

• 
• 
• 
• 

[copperpen]

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

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

Hi Peter

I am currently running the old TA ESE set and all of the passenger cars are showing F while the loco and tender are showing R, both loco and tender have the rigid statement while the passenger cars do not. Loco and tender have two couplers one of which is Bar, while the cars only have one coupler statement.

[steamer_ctn]

copperpen, on 10 August 2018 - 07:56 AM, said:

I am currently running the old TA ESE set and all of the passenger cars are showing F while the loco and tender are showing R, both loco and tender have the rigid statement while the passenger cars do not. Loco and tender have two couplers one of which is Bar, while the cars only have one coupler statement.

Thanks for the feedback.

Are you able to run a few MSTS default consists, say some of the US stock, and let me know if it all appears ok? In particular, a consist with us2hoppercar in it?

Thanks

[copperpen]

steamer_ctn, on 10 August 2018 - 03:14 PM, said:

Thanks for the feedback.

Are you able to run a few MSTS default consists, say some of the US stock, and let me know if it all appears ok? In particular, a consist with us2hoppercar in it?

Thanks

First thing I did was make sure that no freight stock had the rigid statement in the wag file. All consists tested showed an F as did all locomotives used. I then introduced the line CouplingHasRigidConnection (0) into the Dash9 eng file, this showed an F against the coupler. Then I changed it to CouplingHasRigidConnection (1) and the Dash9 showed an R against the coupler. From this it looks like the code is working as it should.

[Genma Saotome]

steamer_ctn, on 10 August 2018 - 01:23 AM, said:

... but sometimes it needs to be recognised that it is sometimes more expedient to allow calculations outside of OR. This gives the user ultimate flexibility without locking them into one or two different shape profiles.

No sense in arguing over whose "one concept" is better when it's possible to do both. Given the reality of shapes and the relative capabilities of users to upgrade their rolling stock I see it makes good sense to have a user provide frontal area -- just as you have suggested -- however anyone comes up with the number. But you can also provide for the elementary data for those that can provide it. Keep in mind that the vast majority of North American rolling stock has this cross section:


A big cube, a small triangle (sometimes an arch), and a smaller cube above the rails -- all in feet and inches and translated to ft^2. That shouldn't be too hard to specify. Add the relevant other data, such as what kind of car is it really and the .wag file can provide everything needed to calculate Davis A, B, and C for all three versions of the formula.

[steamer_ctn]

copperpen, on 11 August 2018 - 03:16 AM, said:

First thing I did was make sure that no freight stock had the rigid statement in the wag file. All consists tested showed an F as did all locomotives used. I then introduced the line CouplingHasRigidConnection (0) into the Dash9 eng file, this showed an F against the coupler. Then I changed it to CouplingHasRigidConnection (1) and the Dash9 showed an R against the coupler. From this it looks like the code is working as it should.

Thanks for that.

Sorry to be a pain, but can you also try it with the us2freightcar1 wagon, and see if you can change the coupling type.

There is a default consist with two D9 and 20 x us2freightcar1 wagons.

Just see if you can swap the coupler types.

Thanks

[steamer_ctn]

steamer_ctn, on 11 August 2018 - 01:51 PM, said:

Sorry to be a pain, but can you also try it with the us2freightcar1 wagon, and see if you can change the coupling type.

Please disregard this request, as feared I have identified an issue on my side.

Thanks for the feedback anyway, as it helped me to identify the issue.

[steamer_ctn]

In #4170 some changes have been made to the curve speed dependency. The main change is to remove the overly restrictive breaking of air hoses at lower speed limits.

Train speed is an important operating parameter, and drivers should pay close attention to it. For those interested in reviewing some information on the impacts of speed, this article should be studied. Note the real life fatal consequences of entering a curve at too fast a speed.

As described in the article the speed that a locomotive or wagon can travel around a curve will be principally impacted by the curve radius, superelevation of the track, and the CoG of the rolling stock. Hence not all wagons in a train will have the same speed limits.

For curves OR has the following four speed "limits":

i) Equal loading speed - this is the speed that a car can traverse a curve with all of its wheels firmly on the rails. From a physics perspective this is the optimal speed to travel around a curve. OR takes no action if the speed exceeds this value.

ii) Max Save Speed - this is a limit determined by the rolling stock characteristics, and passenger comfort. OR notifies user that this speed limit has been exceeded. Most railway companies operate up to this limit to ensure ontime running. (Previously couplers were broken if limit exceeded, this has now been removed for this limit. A notification only is provided if limit exceeded).

iii) Critical Maximum Speed - this is the maximum speed that rolling stock can travel around a curve without overturning. OR now breaks couplers if this limit is exceeded. (It should be noted that once the Equal Load Speed is exceeded, it is still possible for the wagon to derail due to wheel climb on the track - this is not currently modelled in OR)

iv) Critical Minimum Speed - this is the minimum speed that a train must be travelling to prevent it "toppling" over due to the superelevation on the curve. OR breaks couplers if this speed is not exceeded.

To have OR operate to these limits, the "Curve dependent speed limit" box needs to be selected in the Simulation TAB of the Options menu.

[mbm_OR]

Hi,
About HUDWindow, there is an issue when the HUD expanded information (Shift + F5) does not fit on the screen.
In some cases, all Force information lines are not displayed.

This proposal adds a new HUDScrollWindow that allows us a way to scroll the information adjusting the lines to be shown.
This new window (HUDScrollWindow) is displayed when necessary and allows us to select the next options:

• Page Down
  
• Page Up
  
• Page Left
  
• Page Right
  
• None
  
• Screen

Page Down / Page Up: Adjusts vertical lines to be displayed. Used with Consist Information, Brake Information and Force Information.

Page Left / Page Right: Adjusts the horizontal string length to be displayed. Used in Dispatcher information.

Screen. Switch between full and normal screen for expanded HUD information.

About Locomotive Information, horizontal scroll, is a work in progress.

HUDScrollWindow can be set visible with (Control + F5), only if HUDWindow (F5) is visible.

Some pictures about Dispatcher information:
Normal view:


After clicking Page Right:



The Path header ( Path(1/1) ) indicates the actual scroll page and total page.



Attached test file for x4171.
18/08/2018.Deleted, by new code.

Regards,
Mauricio