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

[ATW]

Realistic operations for coupler forces are indeed how slack performs whether your in cab or riding outside on a car or even on rear with lot of slack vs how your engineer controls the slack. Some are comfortable smooth an some are hard no air discomforting that some freight can be randomly jostled causing a bad leaning car. Example leaning on a curve with tilt on an slamming hard on slack can make the effected car stay tilted even on straight rail as if it was curve speeds exceeded.

If one indeed wants real slack action we need to feel the impact with some bobbling slack vibration based on performance of engineer. I sometimes like how PTC Autopilot handles slack on my train with planning ahead vs a bad engineer that throttles off too quick with no minimum air before throttling down.

But primary importance is wag/eng setups an not menu options because tons, springiness for bogies, stretch/bunch limits, coupler damping etc have their own characters based on build. Have too many strong dynamic brakes (especially tapered) online an not cutout can be a dangerous buff loading issue.

[steamer_ctn]

Thanks for the feedback.

I will be focusing on the physics first.

Given that there appears to be a fair amount of interest in this topic, I would be interested in a small group of testers to work with me in developing some of this functionality. It will require some effort to set up suitable stock, some research, and train running to test changes.

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

If the recognition of different couplers was added, then I suspect that we would need to cater for people who want to honor the differences, and not be able to couple different couplers together, and also those people who just want to run trains, and don't care what couplers are on their wagons, they just want to be able to couple potentially different coupler types together.

If there is a desire to not use an option setting, how would both of these two options be allowed? I personally don't believe that it is practical to try and capture this desire in a ENG or WAG file configuration, as it is a more "global" setting.

Thanks

[Genma Saotome]

I'd be happy to do some testin gfor you.

WRT the questions you raised, first, from the beginning there was a basic assumption that the product was a simulator, not a game. On several occasions this question was re-opened and the conclusion was always the same -- it's a simulator. At one point the matter of it being an advanced simulator might be hard on people w/ very old equipment was raised. The conclusion was expressed sarcastically as, basically, tough shit. I'm unaware of any change to this agreement.

That's not to say consideration for gamers and people genuinely stuck we/ ancient hardware cannot or should not be considered, just that when it boils down to only an A or B choice the team should be always be moving towards creating a simulator on modern equipment.

Put all the parameters into the .wags and .engs. As an aid for those who don't care the default can be all couplings work. For the rest of us a new parameter, perhaps called OR_Coupler_Compatibility (string, string, string...), can be added where the contents take the same appearance as what is found in BrakeEquipmentType(). Whatever types of coupling names are present therein can be coupled. That puts the burden to implement on those of us who wish to and lets everyone else off the hook. For those of using an .inc file for standard brake equipment it's a one line add to convert the fleet. This approach would also enable a gradual conversion as the default is anything goes and it doesn't need anything on the option tab; the data to drive behavior is either in the .eng or .wag or it isn't. If cars coupled together are a combination of old and new, or a pair of incompatibilities, revert to the "MSTS way" for that pair.

If this approach is accepted then perhaps a request to Goku can be asking him to enforce OR_Coupler_Compatibility whenever it is found an d leave things as they are when it is missing.

[jared2982]

For use within the ENG / WAG file could we not have OR look for something such as “ORTS_Coupling (“ and if no such line is present default to the current setup?


Edit: It appears this was what Dave is basically suggesting. Sorry Dave I somehow missed your post.

[steamer_ctn]

In the OR New Year MG ver 20 release, some new code has been added to fix the following issue in preparation for further work.

Previously (and currently Mainstream OR) reads any additional coupler information from an INC file, but it adds these code blocks as additional couplers (hence it is possible to have four or more couplers on a wagon). OR only ever took "notice" of the first coupler (as was the MSTS convention of the rear coupler being read in first from the WAG file).

The new code now deletes "old" couplers, and inserts the additional couplers into the relevant coupler, so that each wagon only has two couplers now, regardless of whether additional couplers are read from an INC file. By convention, OR follows the same convention for the INC file, ie the rear coupler is always assumed to be the first coupler in the INC file, and the front coupler is always the second coupler (it appears that the front coupler is not used at this stage).