[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.