[gpz]

Serana, on 09 May 2014 - 12:21 AM, said:

For the PBL2 brake controller, the overload (that's the French word translated) is a quick release with a maximum pressure of 5.4 bar instead of 5 bar normally.
It is used when the locomotive is coupled in order to ensure that all command reservoir valves of the train are in the recharging position.
Is it this behaviour that is called suppression ?

(Reminder : the command reservoir is the reference for the brake distributor : the difference between the pressure of the command reservoir and the brake pipe is used in order to command a pressure in the brake cylinder.

BTW, I'll read its code, but I believe the brake distributor is called wrongly triple valve in OR. It's similar but doesn't have the same behaviour : the triple valve can't release the brake partially. Only the brake distributor can do this.

After reading about it, it seems that these are not the same indeed. I read that the most used english term is "overcharge".

You may rename the varible if you know it is wrong. There is currently no brake system maintainer in OR team, you seem to have the most knowledge among the members. :sweatingbullets:

[markus_GE]

And lets not forget about the speed in the HUD. When doing switching, I frequently use the HUD as an external indication for the cab view dials and displays, when outside the cab. If running an route with imperial units, and being shown km/h, it would rather be a hassle to keep to speed limits.

BTW, the official SI unit to measure speed with would be meters per second, not kilometers per hour, since the basic SI units of distance and time are not km and hours, but meters and seconds. And I don´t think anybody would like to read 27.777777777777777777777777777777777777777777777 for a 100 km/h limit :sweatingbullets:


Anyway, regarding the new UI and what to take to it from the (standard, non-extended) HUD, that is visible on startup: EVERYTHING related to the train (IE, spare the version number and maybe time (not sure on that), and FPS. Anything else, take it).

Cheers, Markus

PS: Don´t ask about my bad mood today - Today was maths finals day!

[gpz]

I opened a new topic for HUD, discussion about that can go there.

markus_GE, on 09 May 2014 - 06:12 AM, said:

BTW, the official SI unit to measure speed with would be meters per second, not kilometers per hour, since the basic SI units of distance and time are not km and hours, but meters and seconds. And I don´t think anybody would like to read 27.777777777777777777777777777777777777777777777 for a 100 km/h limit

It was already solved years ago in OpenRails. :sweatingbullets:

[markus_GE]

I know it won´t display floating point number with a decimal part so long, yet 27.7 as a speed limit would look somewhat... you know :sweatingbullets:

Cheers, Markus

PS: Don´t ask about my bad mood today - Today was maths finals day!

[gpz]

markus_GE, on 09 May 2014 - 06:41 AM, said:

I know it won´t display floating point number with a decimal part so long, yet 27.7 as a speed limit would look somewhat... you know :sweatingbullets:

It's not the decimal precision, the whole problem you are talking about was solved years ago.

[markus_GE]

Hm... then I´m stuck what you´re talking about ;)

Cheers, Markus

[Serana]

gpz, on 09 May 2014 - 04:03 AM, said:

After reading about it, it seems that these are not the same indeed. I read that the most used english term is "overcharge".

You may rename the varible if you know it is wrong. There is currently no brake system maintainer in OR team, you seem to have the most knowledge among the members. :rofl:

I've searched on the internet about the word you found. Seems like it's the correct one. I'll rename it for my next version.

And the main experience I have in the brake system is because I worked on the model of a French metro : the NeoVAL of Siemens. I recoded a big part of its brake system (the pneumatic part).
For the UIC brake system operation, I use a French website created by an Alstom engineer, most of the time.
But I really like to work on the rolling stock (because of what I did at Siemens) and the signalling (because that's my current job :bravo: ).
So maybe you can assign me as the brake system maintainer... but I will be very likely to code some other things for other systems (mainly on the rolling stock (such as the circuit breaker) and things on the ground that use electricity (I would love to be able to put substations along the track and to be able to decrease the voltage of the overhead wire during the acceleration of my train :oldstry: )).

gpz, on 08 May 2014 - 10:22 PM, said:

Serana, one more thing I dislike about the new braking API, which I haven't noticed before for whatever reason, is the GetStatus() method. In my opinion it shouldn't return strings, because (beyond that this form of handling looks kinda primitive) they are unlocalizable, and the strings are also redundant, since the same strings (except the emergency push-button and emerg. tcs) are already available in their localized form in MSTSNotch.GetName(). (Your script's "Overload" might be the same as MSTSNotchType.Suppression, isn't it?)

These two enumerations should be "merged" somehow by a new enum IMHO, and both the script's GetStatus() and the MSTSNotch.GetName() should end up using this common enum, and only the main program code should decode it to a string. (I haven't investigated this issue in details just started thinking on it...)

I will move the MSTSNotchType enum in the ORTS.Scripting.Api namespace (otherwise, we won't be able to use it in the scripts) and rename it to ControllerState (if we add the TCS values, they won't be notch types any more).

I will also add a dictionary that will contain the strings. In the keys, there will be the ControllerState values.
The GetStatus of the script will return a ControllerState value.
The GetStatus of BrakeController will return the string associated to the state using the dictionary.

gpz, on 09 May 2014 - 01:09 AM, said:

And sorry for arguing continuously, but I found one more thing. I think it is also a mistake to "outsource" the SetRDPercent. We cannot require from 3rd-party script developers to handle RailDriver correctly, considering that many of them haven't even seen one. So I think this should go back to main code too.

What is worse is that some generic functions in MSTSLocomotive use "RD specific" function : SetTrainBrakePercent, for example, uses SetRDPercent of BrakeController !
I will rename those SetRDPercent functions to SetPercent because they might be useful for other things some day.
On the notch controller side, it's weird that the code of SetRDPercent is not using the SetValue function. I would have done something like "find the associated value" and then "use SetValue".
Since it's probable that we may have new input devices, maybe we should find some way to create an input device plug-in interface. That way, all Rail Driver related code will be in a plug-in.

[gpz]

I agree with what you write here! :sign_thanks:

One more thing: I see now the train brake and engine brake can be controlled by the API. I think also the dynamic brake should be able to be controlled, there should be a function for that as well. Many times the train brake and dynamic brake is bundled. Also the functions should be available the decision is made upon, what type of brake is to be applied automatically. Like speed... What do you think?

[Serana]

First, you have to know that there's 4 possibilities :

• No dynamic brake
  
• Dynamic brake combined with throttle (example : TGV)
  
• Dynamic brake combined with train brake (example : ICE 3)
  
• Dynamic brake combined with both (example : Class 395 and Z 22500)
  
• Dynamic brake separated (used on some German locomotives, I believe)

And I don't think there's a parameter in the ENG file that allows us to cover all of these cases (I know there's one that combines the throttle and the dynamic brake).

Quote

Also the functions should be available the decision is made upon, what type of brake is to be applied automatically. Like speed...

Can you explain this part of your message ?

[gpz]

I assume, the API should be general enough to cover all train brake controller types. If so, then it should cover those train brake controllers too, which use dynamic brakes. Often, when the brake controller is moved, parallelly (or at some locomotives and controller positions at high speeds exclusively) the dynamic brake is applied too.

The last sentence I worded wrongly, was referencing to this "bundled" operation: At some locomotives the speed determines how the dynamic brake should be used when the brake controller is moved.

(It is not thought out thoroughly, just came into my mind, and wanted to ask your opinion.)