[Genma Saotome]

Am working on the .eng and .wag files for a set of multi-part locomotives and, among other problems, have determined the air compressors on locomotives two thru four do not kick in when the air compressor in unit one starts, tho all four locomotives are understood as being MU'd in other areas of the code

MU Status (click on image to expand it for better visibility of text):


The failure to engage all of the compressors after releasing the brakes (click to expand image):


An example of the expected behavior as seen in a different set of four locomotives that are all built as one .eng per whole locomotive mesh (click to expand image):



Additional information is here.

Please advise if you wish me to open a formal bug report. Will provide relevant files as needed.

[Serana]

Seems like no air was consumed from the main reservoirs of the other locomotives. The problem is not located on the compressor side but on the air propagation side.

[Coolhand101]

It has always been this way if using 'air_single_pipe' and the engine files are separated by a wag file.

In 'air_twin_pipe', all the compressors will 'kick in' regardless of any wag file separating the engines.

I have a push pull trainset( driving trailer engine +7 wags and diesel engine ) and when the diesel loco is pushing, that compressor will not work under Air_single_pipe.

Thanks

[Genma Saotome]

It appears the software can locate the .eng units that lead the train (as seen in the first screen shot where the correct unit's are marked as MU'd). For several of those .engs there are two .wags between them. So what is the solution?

[steamer_ctn]

Coolhand101, on 27 August 2016 - 01:20 PM, said:

It has always been this way if using 'air_single_pipe' and the engine files are separated by a wag file

I think that this makes sense, as in a single pipe system, the train pipe provides the control signals for the brake operation, and mostly the main reservoirs of trailing locomotives would be isolated from the brake pipe. If they weren't isolated then they could give "funny" pressure readings behind the controlling locomotive due to them injecting air into the system.

Twin air pipe systems overcame this problem, as one pipe could be used for control purposes, and the other one to link all the reservoirs together to create a "super reservoir", without impacting on the train pipe pressures.

There are probably a number of scenarios in regards to multiple locomotive operation that could be considered:
i) Steam (especially older units) - only had single pipes, and the reservoirs on trailing locomotives would have been switched out
ii) Older diesels may not have been set up for multiple operation for brakes, and thus their reservoirs would have also been switched out.
iii) New Diesels would have been set up for multiple operation with multiple air hoses and electric control
iv) Modern Diesels appear to mostly use wireless and electronic control.

Genma Saotome, on 27 August 2016 - 07:46 PM, said:

It appears the software can locate the .eng units that lead the train (as seen in the first screen shot where the correct unit's are marked as MU'd). For several of those .engs there are two .wags between them. So what is the solution?

In normal operation, with the exception of option iv), above it would be unlikely for locomotives separated by wagons (WAG files) or tenders to operate in MU and have their reservoirs "connected". I agree that OR doesn't appear to cater for option iv) at the moment.

I think that the real question to ask is, should we use "dummy" WAG and ENG files to get around issues with articulated or multiple part locomotives? Is this solving the problem or making it more complex?

[Genma Saotome]

steamer_ctn, on 28 August 2016 - 12:25 AM, said:

I think that the real question to ask is, should we use "dummy" WAG and ENG files to get around issues with articulated or multiple part locomotives? Is this solving the problem or making it more complex?

Ideally the problem would be avoided because the modeller would have no need to create such a model but IIRC past discussion of why such models exist have not led to a solution. And in the meanwhile, we have such models.

IMO having a parameter that indicates an end is MU equipped makes sense, albeit a rather arcane feature but I think for .eng files it's a reasonable add... somebody somewhere is bound to appreciate it.

OTOH, for these pesky "odd" locomotives, the issues spill all over the place. A new class name of "PsedoEngine" or "EngineSubset" describes the beast such that the code would know what it was dealing with but then do any parameters remain applicable? I think not... seems everything could then go into the real .eng file as-if it were actually complete. But those Pseudo thingies, whatever they are called, do have to occupy space in the train... I take it that would produce all sorts of changes everywhere.

Another concept is that Lashup idea I posted some time ago -- a consist only of locomotives. Whatever is in there is understood to be working as one.

From what I've seen files for multi-part steam locomotives are often even stranger that these boxcabs.

So I don't know what to suggest here... only that the behavior of the set of files for these models is not correct.

[Genma Saotome]

steamer_ctn, on 28 August 2016 - 12:25 AM, said:

I think that the real question to ask is, should we use "dummy" WAG and ENG files to get around issues with articulated or multiple part locomotives? Is this solving the problem or making it more complex?

A late follow up... of course the long term solution is to change things so certain locomotives can be made as one shape instead of several. The later was always understood as a lousy workaround. But solving that problem in the best manner does not do anything for all of the locomotive models that were built before that better way is available.

On many occasions I have requested the OR team do something for developers that would allow us to logically combine multiple models into one operating object. Stuff like making up one freight car from meshes representing wheels, trucks, and the car body meshes -- three .s files acting as one. Might that also solve this problem? Why should the game loop care if the locomotive or rolling stock object has multiple mesh files, some of which are wheels and trucks?

[steamer_ctn]

Genma Saotome, on 05 February 2017 - 01:21 PM, said:

On many occasions I have requested the OR team do something for developers that would allow us to logically combine multiple models into one operating object. Stuff like making up one freight car from meshes representing wheels, trucks, and the car body meshes -- three .s files acting as one. Might that also solve this problem? Why should the game loop care if the locomotive or rolling stock object has multiple mesh files, some of which are wheels and trucks?

Unfortunately this is well above my coding skill at this stage, so hopefully another developer with the necessary skills will have some time to look at it sometime.

[Genma Saotome]

It's probably more complex... but it feels like it should be a whole lot like how .fa meshes are handled.

[edwardk]

steamer_ctn, on 28 August 2016 - 12:25 AM, said:

I think that this makes sense, as in a single pipe system, the train pipe provides the control signals for the brake operation, and mostly the main reservoirs of trailing locomotives would be isolated from the brake pipe. If they weren't isolated then they could give "funny" pressure readings behind the controlling locomotive due to them injecting air into the system.

Twin air pipe systems overcame this problem, as one pipe could be used for control purposes, and the other one to link all the reservoirs together to create a "super reservoir", without impacting on the train pipe pressures.

There are probably a number of scenarios in regards to multiple locomotive operation that could be considered:
i) Steam (especially older units) - only had single pipes, and the reservoirs on trailing locomotives would have been switched out
ii) Older diesels may not have been set up for multiple operation for brakes, and thus their reservoirs would have also been switched out.
iii) New Diesels would have been set up for multiple operation with multiple air hoses and electric control
iv) Modern Diesels appear to mostly use wireless and electronic control.



In normal operation, with the exception of option iv), above it would be unlikely for locomotives separated by wagons (WAG files) or tenders to operate in MU and have their reservoirs "connected". I agree that OR doesn't appear to cater for option iv) at the moment.

I think that the real question to ask is, should we use "dummy" WAG and ENG files to get around issues with articulated or multiple part locomotives? Is this solving the problem or making it more complex?

Does MSTS have the same issue? If not, then OR is missing one important brake function.

Edit: So do the locomotives found at the end of the train provide any braking help?

Edward K.