[steamer_ctn]

mbm_OR, on 14 August 2018 - 02:53 AM, said:

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.

I think that this seems to be a good addition to address the issue displaying extra lines on the HUD.

A couple of questions.

What does the None function do?

How does one switch back to "normal" HUD operation (and get rid of the scroll menu)?

If supported this could be committed as part of this blueprint.

Thanks for your work on this.

[Duke]

Great, now is the HUD information scrollable.
It`s appear complete automatic and goes away if it is not required.

:good2:

I found little Problems:

• some tender shows not coupling Force information by F in the HUD - I searching why not all tenders
  
• diesel engine shows ever F even for R with CouplingHasRididConnection 1
  
• electric engine shows ever R even for F with CouplingHasRididConnection 0

Attached thumbnail(s)

• 

[hroch]

Hello,

Good work Mauricio.

When a steam locomotive is selected, Scroll control is not displayed. It only appears when it is switched to the HUD dispatcher. The Hud dispatcher works only in the right / left moving. The screen does not work. Scroll control do not work in the other HUDs.

[copperpen]

If CouplingHasRigidConnection (0) is used on any car or locomotive the Forces HUD will show F, same as not having the line there.

If CouplingHasRigidConnection (1) or CouplingHasRigidConnection() is used there will be an R shown on the Forces HUD page.

There is no distinction yet between Automatic, Bar or Chain.

[mbm_OR]

Quote

steamer_ctn: What does the None function do? ?

None function is not more required.
With this new version, the window scrolls interactivity, it's more friendly for the user.

Quote

steamer_ctn: How does one switch back to "normal" HUD operation (and get rid of the scroll menu)?

Please, try this new code.

Quote

Duke: It`s appear complete automatic and goes away if it is not required.?

Thanks to test it.

Quote

hroch: The Hud dispatcher works only in the right / left moving.

Fixed. For Dispatcher information the vertical and horizontal scroll now work.

About Locomotive Information and Brake Information, it remains a job in progress.
Only, Force Information and Dispatcher Information are ready to use.

Thanks for the feedback.

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

[hroch]

Mauricio

When I start OR with a steam locomotive OR crashes into Windows.
 OpenRailsLog.txt (17.99K)
Number of downloads: 509

[mbm_OR]

hroch, on 18 August 2018 - 05:16 AM, said:

When I start OR with a steam locomotive OR crashes into Windows.

Sorry, a file was missing in the zip.

Attached is the new zip file.
30/08/2018. Deleted by new code.

[steamer_ctn]

After re-installing the coupler information in the HUD, curiosity got the better of me (and you know what happened to the curious cat), and I decided to have a closer look at the coupler code.

Firstly, in OR only the following parameters are used to define a coupler (which may not be an issue as such, but needs to be understood for clarity of definition):

i) couplinghasrigidconnection
ii) Stiffness
iii) Break
iv) R0

NB: The coupler type statement, ie whether it is a Chain, Bar, or Automatic coupler etc is not considered. This could be included in the code to prevent non-matched wagons and cars from coupling, however I suspect that it would cause some issues with poorly defined legacy Wagon files.

Secondly, I suspect that some of the "default" limits are too low, and hence this is restricting some of the slack movement, and general coupler operation.

Thirdly, it also appears that only one coupler is being used from the WAG file, so hence where two couplers are defined, only the second (or coupler last to be read in the file) is being used. This may not be an issue for some wagons were the couplers are the same at each end, however steam locomotives which have a BAR coupler and a Chain/Automatic coupler will only have either the BAR or the C/A coupler depending upon which one is defined last in the WAG file.

So I have decided to address some of the above issues. At this stage I will not be changing the underlying coupler forces calculation code as it is quite complex, and I still don't fully understand it.

So as a consequence, I have done a small update to the use of the Break information parameter which has the following form - Break ( x y ), where

x = the "Proof" force of the coupler. It appears that this value is a guaranteed value below which the coupler will not fail. Operating over this limit may cause stresses in the coupler, but it should not fail or break until the next limit is reached. Information will be displayed ("O/L") in the FORCES INFORMATION HUD if this value is exceeded. This value appears to be somewhere between 50 - 60% of the ultimate coupler force.

y = Ultimate Coupler force. The force that will cause the coupler to break. The player will be advised that the coupler has been broken, and information will also be displayed in the HUD ("xxx").

NOTE: It should be remembered that the breaking force of the "coupler" will be the smaller of the force required to break the metal coupler, or the force to pull the coupler off the car. Thus couplers mounted on wooden cars would typically require smaller forces to "break" the coupler.


The "Break Couplers" option needs to be selected in the Options Menu for Couplers to be broken.

In Appendix A of this document are some examples of typical Coupler Forces.

Thus for example from the above document, a Coach Drawhook (Drop Head Buckeye) would be defined as follows:

Break ( 0.3e6N 0.75e6N )

Patch #4180 now has the above changes.

[longiron]

Peter,
Thanks for the detective work. I know on my steam locomotives - two different coupler definitions are used for exactly the reason you highlighted.

[steamer_ctn]

In #4182 some modifications have been made to the operation of the R0 parameter of the coupler definition.

The R0 parameter has the following form,

R0 ( x y )

where

x = the "rest" position of the coupler. Ideally this value should be equal to zero, however this value also appears to have an impact on the spacing of cars when they are at rest, so small values of up to 150mm (15cm) can be inputted into this parameter

y = the maximum travel of the coupler.

The maximum travel of the coupler will vary between different coupler types. For example, couplers manufactured to AAR specifications (Such as the type F) will have a maximum travel of around 4.5" ( 115 mm ). Screw couplers may only have a movement of an inch or so. Some research will be required to determine the relevant parameters for each coupler type.

To see the impact of this change, run a train on level track (CTN test route for example) initially, and apply small applications of throttle. Once moving try putting throttle to zero, and then slowly apply engine brake.

Make sure that the R0 and Break parameters in the stock under test have been set to realistic values.

[Genma Saotome]

Peter, many thanks for digging into this topic.

WRT r0(), a couple of questions:

• If x is the position of the coupler at rest is it a safe assumption that is where the model shows the coupler -- hence a value of zero?
  
• If y is the maximum travel allowed does the program treat it as a plus/minus range?

IIRC Damping() was used in MSTS to create a spring effect (sometimes people used values that created a too lively spring that would never settle down). Might you take a bit of time and experiment with that? It might be quite relevant to the larger train forces topic w/ specific regard to run-in forces.

Last, what's the purpose of Buffers() and is that used in OR??

[steamer_ctn]

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

If x is the position of the coupler at rest is it a safe assumption that is where the model shows the coupler -- hence a value of zero?

Setting x at zero is what I believe is the ideal setting. However it will depend upon how the modeller has defined the model in the size statement, etc. For example, depending upon the coupler type, it may need to extend beyond the wagon shape a bit.

So some experimentation will be required.

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

If y is the maximum travel allowed does the program treat it as a plus/minus range?

Yes.

The one challenge that I see, will be that the coupler does not actually move with slack movement (independent of the cars), and hence depending upon the current amount of slack, the couplers of two cars may either overlap, or have a gap between them.

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

IIRC Damping() was used in MSTS to create a spring effect (sometimes people used values that created a too lively spring that would never settle down). Might you take a bit of time and experiment with that? It might be quite relevant to the larger train forces topic w/ specific regard to run-in forces.

Currently the Damping parameter are not read and used by OR.

As far as doing any major changes to the coupling code, I am not inclined at this moment to do so, as I don't fully understand the logic used in it. I have attempted to seek clarification from the original developer to understand the model that they have defined, so we will see what happens.

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

Last, what's the purpose of Buffers() and is that used in OR??

Buffers were not used in MSTS (according to the MSTS Docs) and are not used in OR.

As I understand it, couplers have two states, ie tension (pulling) and compression (pushing). I would suspect that the behaviour would be different in each coupler state, and that the buffers would more influence the compression state. At the moment OR appears to treat both states the same, with one being a positive state and the other being a negative state.

[Genma Saotome]

steamer_ctn, on 23 August 2018 - 08:57 PM, said:

In Appendix A of this document are some examples of typical Coupler Forces.

This fails to open correctly for me (I see pages 1 and 2 but the rest never display).

[mbm_OR]

Now Locomotive information is ready.
About, Brake Information, it remains a job in progress.

Some screenshots about Locomotive information:
All locomotives.

Diesel loco.

Steam loco Car 3.

Steam loco Car 5.

Page right scroll.


Attached test file for x4185.
31/08/2018. Deleted, by new code.

Regards,
Mauricio.

[Genma Saotome]

I tried V4185 a few minutes ago, a simple test on level ground of a reverse movement to take up the slack, around 60 cars. I allowed the locomotives to move for about 5 seconds and then throttled down.

What I noticed was the coupler force bounced from zero to 12k fpds (a bit more than 16kN) on some cars; most were around 7-8k fpds (9.5kN - 10,kN) and back again on all cars. I watched this for about 2 minutes and there was an almost imperceptible movement back and forth in the cars for the entire time.

From a game performance issue there were a lot of unnecessary calculations going on as the train speed was zero. I suppose at zero speed extra calculations are a don't care. From a user point of view it's very likely to also be a non-issue (assuming your r0() values are tight)... it you don't look carefully you won't notice the cars moving back and forth. OTOH, if your r0() values are not tight (e.g. cushioned underframe cars) the back and forth could be very noticeable.

From a physics point of view, clearly the damping function isn't there (we all knew this beforehand).

Obviously real railroad cars do stop... the question I suppose then is this: Is there a simple, temporary solution that can be implemented until such time Damping() is properly figured out and coded? Something effectively akin to a calculus limit, perhaps tied to low speed, perhaps tied to low force?

Q: Does positive rolling resistance have an effect upon push-in coupler forces? Does it take into account the effect of no slack in the attached car(s) located in the direction of the push?