[railguy]

Setting the loose locomotive particles to zero certainly beats the way that it was. I just looked and the loose consist locos are no longer pouring out smoke. That said, I hope that this will be considered only a temporary solution. Loose consist locomotives are still not emitting sound until they are coupled up to a player train. In the US, at least, prototype diesel locomotives are almost never shut down if outside ambient temperatures are below freezing. Even with AESS, locomotives will often have to start up and idle at any outside temperature if any one of a number of other operating parameters (main reservoir air pressure, engine temperature, etc.) fall out of an acceptable range. So, having loose consist locomotives dead and quiet is not prototypical most of the time.

Thanks to you for at least solving the full throttle loose consist smoke problem for the time being. Better to have no smoke than a supposedly idling locomotive looking like it's at full throttle.

[gpz]

A temporary solution usually lessens the chance that someone will feel necessary in the future to develop a proper one.

[edwardk]

The question of the day is what fix is proper? If you check MSTS, you will find that the loose locomotives are the same way. They become active when the player train attaches to them so in this sense, the fix is proper. Looking ahead is another manner. To set up an activity so that you can decide what locomotive will be running and what won't will require more items to be in place. This of course leads to the question of what is prototypical. For as many locomotives that are left running, there will be just as many that will not be running so if I was able to set them up to run, all would have to run.

Edward K.

[edwardk]

 Eldorado.Railroad, on 09 February 2015 - 03:19 PM, said:

Edward,

I will give this a try later tonight, I just hope that a wait point bug (another recent thread with Rob Roeter at the helm!) will not clobber my test activities. Big thanks for your effort on this bug.

Could you explain exactly what is mean't by this (maybe a an example consist?):
"At this time it would be bit more difficult to have a number of static locomotives with the exhaust indicating as running and shutdown."

Steve

Steve,

The fix right now is actually the way MSTS works. The static locomotives become active when the player train attaches to them. Unfortunately, if I was able to set them up to run, all would have to run. To choose what will run and what won't is the future of OR since this is something that could be set up via a new and improved activity editor.

Edward K.

[gpz]

I'm not saying the solution is temporary, just it came down from your words. :thumbup3: Maybe the definition for the "proper handling" could be that the existing state variables in the code set properly, to reflect the real state, otherwise the future developer may not know why his code doesn't work. I'm just speaking without checking the actual patch, so no offense intended.

[copperpen]

In MSTS all static engines have idle level smoke and sound, unless there are more than a few present, in which case all sound is shut off, even the player. Only if a static is setup in the eng as a wag will there be no smoke or sound.

[railguy]

copperpen is correct about how MSTS handles loose consists. They smoke at idle rate and the sound is at idle rate. The way the activity designer can have "dead" locomotives in a yard is to make a "dead" wagon locomotive in, say, Route Riter and then use it in the loose consist. The only issue there is a dead wagon locomotive always stays that way, even if a player train picks it up. The statement that OR has treated loose consist locomotives the way MSTS does is incorrect.

[roeter]

First : the patch has a flaw in it which may cause a crash (as I just found out).
When an AI train is removed, the Train variable for all cars is set to null. Because the viewer may have already 'captured' that car for display, it can happen that car.Train == null, so testing for car.Train.Traintype will cause a crash.

Second : why is the state 'poweron' not used? Surely an engine which has power switched off (so poweron == false) should not emit smoke (if it does, better call the firebrigade). This would be independent of Traintype.
This would help to make this solution more general, for in particular in timetable mode, trains can switch power on and off depending on the required actions. For instance, timetable mode allows trains to be 'stabled' before the first or inbetween duties, and during this time the power is switched off. These trains are not classified as 'STATIC'. At present, power is switched back on 2 mins. before required (re)start.

I suppose this would not work for steam engines, but then steam engines do not 'suddenly' switch power on when another engine is attached, so the present solution does not work for steam engines, anyway.

Regards,
Rob Roeterdink

[edwardk]

 roeter, on 10 February 2015 - 08:30 AM, said:

First : the patch has a flaw in it which may cause a crash (as I just found out).
When an AI train is removed, the Train variable for all cars is set to null. Because the viewer may have already 'captured' that car for display, it can happen that car.Train == null, so testing for car.Train.Traintype will cause a crash.

Second : why is the state 'poweron' not used? Surely an engine which has power switched off (so poweron == false) should not emit smoke (if it does, better call the firebrigade). This would be independent of Traintype.
This would help to make this solution more general, for in particular in timetable mode, trains can switch power on and off depending on the required actions. For instance, timetable mode allows trains to be 'stabled' before the first or inbetween duties, and during this time the power is switched off. These trains are not classified as 'STATIC'. At present, power is switched back on 2 mins. before required (re)start.

I suppose this would not work for steam engines, but then steam engines do not 'suddenly' switch power on when another engine is attached, so the present solution does not work for steam engines, anyway.

Regards,
Rob Roeterdink

There were a number of options that I have been trying to look into. For starters, the poweron command has no affect on the static diesel locomotives. I know it sounds odd since under the MSTSDieselLocomotive constructor, poweron is set to true. Many versions ago, the DieselEngines class was put into use. Before this, both the player train and static locomotives shared the exhaust issue so the DieselEngines class is for the player train.

Edit: Its possible the AI trains are using the DieselEngines class.

Regarding the crashing, Carlos found out about this and corrected this so the crashing you experienced should have been solved. Please let me know if the fix did not solve all crashing issues.

Edward K.

[edwardk]

 gpz, on 10 February 2015 - 03:31 AM, said:

I'm not saying the solution is temporary, just it came down from your words. :) Maybe the definition for the "proper handling" could be that the existing state variables in the code set properly, to reflect the real state, otherwise the future developer may not know why his code doesn't work. I'm just speaking without checking the actual patch, so no offense intended.

No problems. I came home from work tired and with a headache so my brain was not operating as it should.