Elvas Tower: An idea to overcome the problem of unappropriately slow brake release - Elvas Tower

Jump to content

  • 16 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

An idea to overcome the problem of unappropriately slow brake release

#1 User is offline   Csantucci 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 4,855
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 24 June 2015 - 12:01 AM

I was testing a demo activity using as player train the standard consist 2 x gp38-2.con . I noticed that after some brake releases - brake applies the brake release didn't fully release the brakes even after considerable time. I went into the .eng file and found that the GP38 has
	AirBrakesMainMaxAirPressure( 90 )
	AirBrakesCompressorRestartPressure( 87 )

while TrainBrakesControllerMaxSystemPressure( 90 ) . This set of parameters seems to me wrong.
As a comparison the Dash 9 has
	AirBrakesMainMaxAirPressure( 130 )
	AirBrakesCompressorRestartPressure( 125 )

as well as TrainBrakesControllerMaxSystemPressure( 90 ).
which works well.

So I created an "include" .eng file in a newly created OpenRails subfolder, where I corrected the two above parameters (thanks OR for allowing that).
However it is long and annoying to look for all faulty .eng files and to modify them. The alternative is only to use the brake reset command after every brake apply.

So I got the idea that it could be OR that modifies these parameters at runtime (the .eng file remains unaltered), if it finds that they are wrong.
So e.g. at trainset load time OR could test if AirBrakesCompressorRestartPressure is at least 20 above TrainBrakesControllerMaxSystemPressure and AirBrakesMainMaxAirPressure is at least 5 above AirBrakesCompressorRestartPressure, and if not, it could correct them. The possibility of manually hard-modifying the .eng file appropriately rising the two parameters would remain and in this case of course OR would not intervene with the runtime correction.
That would be a simple OR code modification. What do OR users think about this?

#2 User is offline   disc 

  • Foreman Of Engines
  • Group: Private - Open Rails Developer
  • Posts: 818
  • Joined: 07-October 12
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 24 June 2015 - 02:26 AM

What about just using realistic brake parameters?

#3 User is online   R H Steele 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,373
  • Joined: 14-March 13
  • Gender:Male
  • Location:known universe
  • Simulator:Open Rails
  • Country:

Posted 24 June 2015 - 09:57 AM

View Postdisc, on 24 June 2015 - 02:26 AM, said:

What about just using realistic brake parameters?


I think that is just what Carlos is saying....absent realistic brake parameters being present in the engine file... OR performs a couple of tests at runtime and then adjusts accordingly. Many users do not know how or do not care to adjust all the engine files... so the proposed method works for those instances.

Anyone can correct all their engine files to have realistic brake parameters... in that case OR will use what is available.

#4 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,182
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 24 June 2015 - 12:42 PM

View PostCsantucci, on 24 June 2015 - 12:01 AM, said:

So e.g. at trainset load time OR could test if AirBrakesCompressorRestartPressure is at least 20 above TrainBrakesControllerMaxSystemPressure and AirBrakesMainMaxAirPressure is at least 5 above AirBrakesCompressorRestartPressure, and if not, it could correct them. The possibility of manually hard-modifying the .eng file appropriately rising the two parameters would remain and in this case of course OR would not intervene with the runtime correction.
That would be a simple OR code modification. What do OR users think about this?

If you're confident that these are the right limits (20 and 5) and there isn't likely to be anything intentionally using "bad" values, I think we go with it. A warning to the log of course, saying e.g. "XYZ has bad value A, using value B instead". Certainly worth a try. :sweatingbullets:

#5 User is offline   Csantucci 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 4,855
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 24 June 2015 - 12:52 PM

Thanks James. I'd be happy if someone knowing what real trains are would tell us what the "right" limits are (probably different in USA and in Europe and in narrow gauge, but maybe compromise values can be found out). If I don't get an indication, I would start with the above values, that for sure are better than the faulty values.

#6 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Owner
  • Posts: 13,507
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 24 June 2015 - 03:13 PM

I'm no expert but I do know that the air pressure in the train brake line increased over time -- many decades. I would not expect to see anything above 80 PSI before the mid 1950's / early 1960's and so (just guessing) seeing 90 PSI on a GP-38 strikes me as plausible.

I found the specs for a GP-38... it used a Gardner-Denver air compressor, model WBO. All I was able to find about that model was it was a 3 stroke, water cooled device. Looking at the current GD product line the WLU and WLN models are spec'd at 170 and 213 cubic feet per minute respectively. No idea how that should be converted to PSI. FWIW the WBO compressor was also stock on EMD F7's from the early 1950's.

As for someone to tell you what's right, try Plainsman. He wrote the physics for most North American diesel locomotives. Andre (Coonskin) can probably add a few facts as well.

As for OR replacing .eng file values, I wouldn't do it. Instead, tell people to get Engmod and fix their data.

#7 User is offline   Lutz_s 

  • Fireman
  • Group: Status: Active Member
  • Posts: 162
  • Joined: 31-January 10
  • Gender:Male
  • Simulator:MSTS
  • Country:

Posted 25 June 2015 - 01:40 AM

I think it would be the right way to let OR adjust those variables. Many people just want to drive the trains and don't want to adjust variables, which worked in MSTS but not in OpenRails. Those people get quickly to the point, that OpenRails isn't working right. Here in germany the acceptance for OpenRails seems to be quite low because of such things like having to adjust each eng-file / wag-file. I can read every day in the forums of people who propagade to stay with MSTS because OR can't play activity xy or engine xy doesn't release brakes. If one answer to such problems is letting OR check two variables in an eng-file and adjust them, it should be done (of course the warning in the log should be created too).
Those people who want to tinker with the files can do it and the others who don't can drive too, that's the rightsolution.

Lutz

#8 User is online   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,182
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 25 June 2015 - 01:47 AM

To be clear, Open Rails will never modify content files unless you're explicitly editing them (e.g. in the activity editor). What we will do is log a warning and correct the value inside the game (we do this for a variety of things already).

#9 User is online   R H Steele 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,373
  • Joined: 14-March 13
  • Gender:Male
  • Location:known universe
  • Simulator:Open Rails
  • Country:

Posted 25 June 2015 - 05:51 PM

View PostGenma Saotome, on 24 June 2015 - 03:13 PM, said:

As for OR replacing .eng file values, I wouldn't do it. Instead, tell people to get Engmod and fix their data.


EngMod is getting hard to find. The link at Steam4Me brings up a "HTTP Error 404 - File or directory not found" and a search just shows torrent sites as having it for download...good luck with that.
Perhaps, UK has, it's not to be found in the library here....I looked under computer utilities.
I tried searching the library at TS, but nothing turned up, which is not unusual.

engmod20.zip in the Utilities section at TS.

#10 User is offline   Csantucci 

  • Executive Vice President
  • Group: Status: Elite Member
  • Posts: 4,855
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 26 June 2015 - 06:22 AM

Thank you to all for suggestions and support, and especially to Dave for his indications. I found engmod also at trainsim here http://www.trainsim....earchid=5078828 and downloaded it.
To perform a test I applied it to the GP38 and got AirBrakesMainMaxAirPressure raised from 90 to 140 and AirBrakesCompressorRestartPressure raised from 87 to 134, which confirms my idea. However before proceeding I have written to Bob to see what he thinks about this story.

Going a bit off topic, but not so much, I too am concerned as Lutz about how the German world judges OR. However I think that sooner or later activity builders should begin to develop activities and trainsets tested for both OR and MSTS, and even more they should take advantage of all new activity functions available only under OR, and therefore develop activities that run only with OR. I am wondering what a type of "campaign" should be undertaken towards this aim. Until the majority of people will judge OR only in terms of compatibility with MSTS, acceptance for OR won't rise enough. And I don't think there is much more possible to be done to increase compatibility.

  • 16 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users