[Csantucci]

At the moment in the braking HUD only the main reservoir and compressor data for the player locomotive are shown. This small improvement displays in separate lines such data for all player train locos, as shown here below.

I have prepared this function to check if all locos in a consist contribute to put air in the train airpipe.
This picture, related to a train with two leading locomotives and two locos on the back of the train, shows an apparently good news and a bad news:
- the main res pressure of both leading locos decreases and their compressor starts when needed recharging the main res
- this does not occur for both trailing locos (of same type).

After some investigation, I found following comment in method FindLeadLocomotives of Train.cs

//================================================================================================//
/// <summary>
/// Find lead locomotive
/// <\summary>

// FindLeadLocomotives stores the index of a single locomotive, or alternatively multiple locomotives, such as
// in the case of MU'd diesel units, the "first" and "last" values enclose the group of locomotives where the
// lead locomotive (the player driven one) resides. Within this group both the main reservoir pressure and the
// engine brake pipe pressure will be propagated. It only identifies multiple units when coupled directly together,
// for example a double headed steam locomotive will most often have a tender separating the two locomotives,
// so the second locomotive will not be identified, nor will a locomotive added at the rear of the train.


So with an explicit decision locomotives grouped together with the player locomotive have the main reservoir propagated, while locomotives isolated from the player locomotive don't have it. This is correct because there is no direct connection of the brake pipe linking the main brake reservoirs, however is it correct that this means also that such isolated locomotives don't participate into braking the train and participate only in providing traction to the train?

Blueprint here: https://blueprints.l...a-for-all-locos

[ATW]

Isolated locomotives (MU signal off) don't provide power in traction or dynamics but can provide air. Locomotives turned off completely don't provide even air compressors an act just like a car in the consists.

[copperpen]

Locomotives cut into the train as DPU, or helpers at the end should be adding traction and braking. As OR is as yet unable to properly emulate DPU, all locomotives in a consist should be seen and operate in the same way as the player, unless the locomotive is actually turned off, engine not running.

[ATW]

Would it be hard to make a difference between Helper, Trail an DPU mode with just qualifying eng parameter on/off feature of what a unit is good for? In game with car operations, click the unit an select whether it's a DPU remote or helper by clicking what mode it's in? I tend to when making a setout with a DPU is simulate in ORTS setout mode by clicking the DPU remote or trail units by Toggle MU Connection on/off where it won't power up unless I Toggle MU it back on. Same for climbing hills cresting a grade I toggle off my trail MU units but turn off my leader (since toggle leader off kills all throttle power commands for all) an start letting my DPU units push an do the job reducing breaking into two since front tons add more force to the draft system while descending.

The point would be Helper Mode treats Train Line as like a trailing car with no main res power helping to set or release because the helper crew just helps with power an dynamic braking by voice radio command breifings from head end and head end is in control of the automatic brake valve, where DPU mode uses it's power providing Main Res air an BP to set or release brakes to a point the head end power sends air back an DPU sends air up toward headend to a point they meet between train speeding process because they are synchronized linked following signal control commands by controller of remote being the engineer via button or handle.

We yet have not come across locomotives to have Handbrakes apply an release or see even cars hand brakes stuck slipping being dragged BTW.

[steamer_ctn]

Firstly, I have built a view of the different multiple unit operation modes based upon some of the comments provided in this thread and research that I have done.

I suspect that it still needs some checking and confirmation, but hopefully it helps to distinguish between the different modes and what functions may apply. So any relevant feedback is welcome.

As has been suggested the main points seem to be around the following:
i) Contribution of the compressor and main reservoir on a trailing unit to the train brake system (when does it apply?)
ii) Is it possible to apply and release the train brakes in different sections of the train? (Typically only in the DPC option?)
iii) How would OR differentiate and switch between the different options?

Does the dynamic braking already work across multiple units?

Ideally switching between the modes should be on the basis of operational requirements, not locomotive specifications such as those included in the ENG file.

Two possible ways of switching modes in line with the above statement might be as follows:
i) As the consist file documents a trains makeup, perhaps a new parameter could be included in it.
or alternatively
ii) As an option in the F9 operations menu, thus it can be set on a locomotive by locomotive basis.

The other question to be answered is, what is the default mode? It may need to be different for steam and diesel / electric locomotives.

Attached thumbnail(s)

• 

[ATW]

That's a good view of the modes. I would say the default would be how it runs currently now unless changed in game. Different modes or even difficulty options like yet to be made like simple comtrols, normal, pro etc can be all with a click of a key or how one likes to start loading the SIM process in the options.

Other view in mind in connection with your chart modes would be: Real life on a starting terminal, crews have paper work an rules to go by, some special requirements on routes to go by, must make changes as needed or required, inspect to see if requirements or satisfaction pass. So my view in writing would be have different options, modes, meet requirements where changes can be made by engineer based on assignments or orders based on locations. Let's start out with examples of start modes.

Simple Controls: Simple power an Braking operations.

Normal: Everything loads an starts out default an all running where no changes or tests have to be made unless decided. Good for trains an assignments where your just handed a Train or change crews being an example of switching control or taking over an AI or are basically running an ready.

Pro: Everything on your train as well as loose consists starts out being off, tied down an cut out where no locomotives are running, hand brakes of engines are on. Engineer has to inspect, set up the modes an requirements of unit's 1 by 1 such as cutting in/out the options of that unit by F9 selection or a separate alternate tab for locomotive only unit control or even cab switching. MSTS Bin as an example had switching cab options where you forgot or purposely set the independent brake to your last option set made them stayed stuck if you didn't release it before switching to another unit.

Basic options an checks I speek of for unit's with addition to the Modes in that nice view chart post above come in example of even things I an others may want to see implemented: Cut in-on/out-off options of Dynamics, Hand brakes, traction an power % control a selected trail mode unit can produce (Will unit use normal throttle % as set by leader, use throttle notch numbers as set in eng or be limited to a reduction % of choosing.), auto start/stop, manual or automatic sand etc.

This would go well for hostling switching power or securing a train parked unattended even with remained options set for switching control where AI can't change it an move for sure unless we take control back an turn on?

[Genma Saotome]

steamer_ctn, on 15 August 2015 - 08:32 PM, said:

Ideally switching between the modes should be on the basis of operational requirements, not locomotive specifications such as those included in the ENG file.

Peter, the choice on where to put the parameters to enable these very good ideas will be the set of Activity files or the Consist file. IMO using the Activity files is the better choice from a logical & flexibility point of view (n.b., which of the several activity files is TBD, including possibly creation of a new file specific to this purpose)

The inhibition to using the Activity files is simply that they have not yet been put to such a use but if you open the door to consider why those files might be useful what comes in is not only any starting conditions for locomotives but also a variety of transitory conditions for cars as well -- names for consignees and lading and the lading weight to name a few. Once considered (IMO) the more sense it makes to put many of the initial variable states for any given .wag and .eng into the activity file and reserve the original .con, .wag, and .eng files for the least likely variable states and all of the defaults. Such an approach makes the .wag, .eng. and .con files expressly re-usable as-was-distributed in all situations (i.e., no need to make n copies of everything to handle n different situations) and moves the variations to the files inherently designed for unique behavior -- the .Activity files.

The alternative -- using consist files -- is reasonable but then will cause a proliferation of nearly identical consist files being setup to handle variation. Being able to choose the right one could easily become quite problematic. Even if you create lash-up consists (just the locomotives -- in itself a very good idea) it still presents the problem of which lash-up has the variant you want... still a bit of a problem then.

I do hope you will give serious consideration to this suggestion as it comes closest to providing universal, standardized content files w/o reducing variation in-game. It's logical and it can be easily explained. If you object, please consider the lashup consist idea -- just locomotives so the original .con file remains as-is -- and as a set ideally suited to the ideas in your published table. The ideas I had about cars can wait until their time comes.

[Csantucci]

With release x.3222 now compressor state and MainRes pressure is shown for all consist locos.

[ATW]

Just upgraded to 3222 an now I'm getting a urgent bug being all my BP lines are in NaN an with every 2 cars at a time the BC sets up while the others become 0.

None ORTS Brake Parameters make BPipe go into the thousands an infinite highs or just negative hundreds.

[Csantucci]

I don't get this problem. Can you post what consist you use and the .eng and .wag files you use?
Do you use a FRED wagon or something similar?

[ATW]

Funny you mentioned about the FRED/EOTD, I get the NaN BP problem at start an than remove it in a consist editor load it in the sim for where my BP numbers are in negative hundreds an thousands. But cure for now is I have to at the start with no EOTD Fred is initialize with shift / an than brakes act normal set an released.

[Csantucci]

So can you give me info about the consist you use, and can you attach an .eng and .wag file that causes the problem, and can you tell me where I can download a FRED causing the problem?

[ATW]

It happens on a lot of consists of collections free an payware but I can point to you some packs from SLI an free downloads from T-S like the default replacement packs by Erick Cantu.

[ATW]

After doing some more experimenting, it seams to be car shapes with no wheels or bogies in the shapes possibly. EOT Fred's don't have wheels or bogies. So it could be shapes that don't have bogies an wheels where brake systems calculate feet from wheels to the next set of wheels an bogies? Some articulates have this problem an some cars with mix lengths after the next car appear to be doing this when some cars have different Brake Force, application and release rate values.

Edit at 4pm Pacific: Could this be something with X3221 perhaps?

[Csantucci]

I have reverted the patch of x3221 and am studying a better solution. ATW, thank you for having pointed to this.