[steamer_ctn]

Last year some work on adding additional train forces to the OR model was undertaken.

As a result of this work the following features were added:
i) wind resistance
ii) resistance of helper locomotives could be compensated
ii) HUD scroll feature was developed by Mauricio

This work identified some potential work that was needed to add some additional features to couplers to allow a more realistic representation of slack along the train.

It is proposed to now revisit the coupler forces along the lines described in the above referenced thread.

A supporting blueprint will be raised.

Thanks

[Genma Saotome]

Please don't enable this feature via the opinion screen. Put the choice in the .wag and .eng files. That may include something as basic as as a new parameter of OR_Physics ( advanced | basic ) where the value therein sets the expectation of what data to look for.

Everything put into the options tabs becomes lost to the end users and eventually to the programmers too -- IOW the options menu enforces a one-size-fits-all policy. MSTS was designed from the start to put choice into the data files. For the most part OR as followed that. Please keep it that way.

[copperpen]

My problem with couplers at the moment is that there is only one very simple coupler with no recognition of different types, and even adds a coupler where one is not wanted.

[dforrest]

copperpen, on 22 April 2019 - 05:08 AM, said:

My problem with couplers at the moment is that there is only one very simple coupler with no recognition of different types, and even adds a coupler where one is not wanted.

I also have that problem.

[dajones]

copperpen, on 22 April 2019 - 05:08 AM, said:

My problem with couplers at the moment is that there is only one very simple coupler with no recognition of different types, and even adds a coupler where one is not wanted.

As far as I know, there is no code to prevent trains from telescoping each other. So if two trains are close enough to push against each other they must be coupled to prevent telescoping. If you want to prevent trains from coupling due to mismatched couplers, then some other code will be needed to keep them apart (assuming that you don't want the activity to just end).

Doug

[copperpen]

Doug


I can live with the one coupler fits all system in OR, we can even dispense with the coupler type in the eng/wag file, but I absolutely hate the part where a coupler is added when one is not wanted. There are activities that use an invisocar that has no coupling to carry a scenic item appropriate to the activity. MSTS passes through or over the car, Open rails picks it up and it goes along for the ride. If the train in OR would pass through with no coupling present, that is ideal and then opens up activity making where all kinds of things can be made. With a bit of imaginative coding one could then even add a fuel point for an activity such as a coal and water point for a steam locomotive running on the modern day network.


There are a number of activities on the Cascades & North western route that make use of these kind of items, but cannot be used because of the addition of a coupling by the code.

[darwins]

With non-automatic couplings, such as chain couplings, then vehicles can be "buffered up" but are not coupled together until the coupling is physically coupled.
This would be useful for loose shunting, fly shunting and hump shunting, mentioned in another thread. (How do you do hump shunting with automatic couplers?)
In the simulator this would need to be a keyboard command in the same way that a command is needed to connect air brake hoses and open the cocks.

This also makes me think of the question of coupling together unfitted wagons. In this case there would be no brake pipes to connect or cocks to open.

In the advanced coupler description it says once written the parameters should be able to model other coupling types such as chain couplings.

I can see that vehicles coupled together with screw couplings depend entirely or almost entirely on the elastic / damping forces of the side buffers, so that this would be similar to the behaviour of an automatic coupler, although on curves this acts differently on the inside and outside of the curve, so not sure what the net effect at the coupling is.

For loose coupled vehicles as gaps are left between buffers then there is free movement of vehicles during acceleration until the couplings are tight, then differently in deceleration there is free movement initially until the buffers come into contact and then the buffer forces come into play - which could be very harsh, particularly in the case of dumb buffers on early vehicles.

Probably is the same model for all, just thinking on paper here... but I would certainly need someone else to work out standard sets of parameters for me.

[longiron]

slack action between cars is an extremely important element of train physics. My recommendation is that it should be simulated as accurately as possible. Especially in the steam era, creating and then taking out slack in a train was critical to starting and stopping heavy trains.

[R H Steele]

All have made important points:
Simulation of slack action is important. New Coupler code - affecting eng and wag files, (Not in Options)
Just as important to me is the point copperpen brings up -- adding a coupler where one is not wanted....this is not a good situation - the ability to use invisiocars would open up possibilities and make Or compatible with a whole lot of activities that use these.

[dforrest]

We also have the "bar" coupling which, in my experience with MSTS, is used for a coupling between a loco and its tender, and other similar instances, which cannot be disconnected during normal operation. It should not be able to be disconnected or connected while the consist is in operation and any attempt to do this should fail.

[cjakeman]

longiron, on 22 April 2019 - 09:01 AM, said:

slack action between cars is an extremely important element of train physics. My recommendation is that it should be simulated as accurately as possible. Especially in the steam era, creating and then taking out slack in a train was critical to starting and stopping heavy trains.

I think this is where Peter (steamer_ctn) aims to start. There's some smart code in there already just waiting to be put to use.

[Fablok]

https://www.youtube....h?v=IidlrYtK0bo

:)

[Genma Saotome]

Well clearly there is a great need for a number of features (I'll add to list creation of modeled named parts CouplerA and CouplerB that actually have draft and buff movement)... but the problem with all of them is basic: (1)Peter is talking about something else, (2)there are no other coders around to do any of the things we've suggested, (3)like all developers, Peter volunteers his time which means he normally works only on the things he is interested in working on.

So either than throwing up our hands and walking away frustrated is there anything that can be said about what Peter is doing that he should take into consideration?

For myself, what comes to mind is insisting that (1) whatever parameters of coupler performance are needed are put into .wags and .engs as ordinary parameters (the alternative is to bury them in the code where no user can alter values) and (2) the structure of the parameter list in .wags and .wags does not bind disparate objects together, which is to say adhesion and couplers are disparate objects.

In practical terms that means not all advanced couplers are Type F; That some .wags or .engs can be set up for advanced couplers while others are not; and that if the simulated draft and buff movements are too great or too small that adjustments to those factors (or any others) can be made by end users.

[R H Steele]

Genma Saotome, on 22 April 2019 - 10:54 AM, said:

...what comes to mind is insisting that (1) whatever parameters of coupler performance are needed are put into .wags and .engs as ordinary parameters (the alternative is to bury them in the code where no user can alter values) and (2) the structure of the parameter list in .wags and .wags does not bind disparate objects together, which is to say adhesion and couplers are disparate objects...

yep http://www.elvastower.com/forums/public/style_emoticons/default/I-Agree.gif

[longiron]

I realize that programmers only contribute what interests them. I would appeal they consider achieving something like this: https://www.youtube....h?v=k9GNi7Yt3rs
And the physics parameters controlling the behavior is part of the wag or eng file, not a global parameter.