[Csantucci]

Thanks Serana.
Here is how I see it.
Beneral principles: TCSs are composed by an earth subsystem and an on board subsystem. These subsystems should have a clearly distinct implementation. The earth subsystem should run on the multiplayer server computer, while the on board subsystems should run on the remote player train computers (except maybe for some mirroring functions of the earth subsystem).

Now coming to what is available now (as far as I am able to see): what is available now is a script API which derives states and parameters from the existing earth subsystem (signals, speedposts etc.) and passes them to the script, which performs on board subsystem functions (to do this the scripts gives also feedbacks to the API, but they concern only on board functions, like displays, sound, commands to loco braking and power equipment). As far as I can see there is NO feedback from the script and the script API towards the existing earth subsystem (signals, speedposts). So in practice there is no real earth subsystem implemented in script API and scripts.
In this situation, under the condition that the earth subsystem info needed by the API is available also on client computers, I don't see conceptual problems in running the actual script API and the actual scripts on client computers. If there are such problems, I would be thankful towards someone describing a specific case or function generating a problem.

[jtr1962]

Matej Pacha, on 23 March 2014 - 11:14 PM, said:

Well, if you are interrested, there is a document of future ORTS physics structure - the blocks could be well scripted, I guess.

And that answers a question I've been meaning to ask for a long time-namely will OR eventually support multiple voltages (which in the real world often mean difference tractive force parameters for each voltage)? Apparently with that structure it will be possible. It will require some additions to the TDB in order to define what voltage(s), if any, is present on a particular section of track. Note that I used voltage(s) because there is at least one real world railroad where two voltages are present on the same section of track. Metro North has some trackage with both 750 VDC third rail and 12.5 kV catenary.

[Serana]

The problem is if you modify the format of the TDB file, when you edit the route with MSTS, it will delete everything that is OR-specific.
So voltage sections, transponders, etc. will have to wait until we have an OR route editor.

Edit : Ok, I found an interesting key for the circuit breaker.
Is anyone against the use of the O key (O and Shift+O) for it ?
Of course, on steam locomotives, this key will still be use for Injector 2. It's only for electric and diesel locomotives.

[Serana]

Besides the choice of a key, I'm currently thinking about another thing.

We like modularity... what do you think about putting a circuit breaker and pantograph interface in the scripting API ? :rotfl:
The default behaviour would be the current behaviour.
People will be able to code the behaviour of the circuit breaker of their locomotives.

[gpz]

In fact the whole cabview control together with the assigned keys should be scriptable, with an independent script of the TCS, in a long term. The current fixed control set will never fit all locomotives of the world.

So I think en event has to be defined for CB on and off, and also a state variable must be available for the locomotive. Also a simple fixed keyboard control must be defined, e.g. for the "O" key to switch it on/off, without any additional bells and whistles.

The exact handling of this must be defined in the future cabcontrol script, where all the standard cabcontrol keys must be able to be overridden, and their working logic could also be customized. So for example one could program the pantograph keys to elevate pantograph depending on direction, and pantographs could be elevated only in case the CB was already switched on, and so on.

So there shouldn't be more fixed options added to the eng file to control how different cab functions behave. I believe this is also the way RailWorks is going.

[Serana]

Well, in most cases, it's the circuit breaker that can't be closed if the pantograph isn't raised for safety reasons : if the voltage changes and you forgot to select the correct voltage, you'll send 25000V AC in a 1500V DC circuit... let's say that if the circuit breaker is closed before the voltage is present, some components will burn.

For the CabControl API... I would even say that, if a CabControl script is present, it is not an override we should do but a complete definition of the "Control" part of the keymap.
The creators should have two possibilities :
1) They can say : "I need this generic command, please use the default key." (For example, "I want the generic train brake increase command.")
2) Or they can say : "I need this specific command I defined, give me this key." (For example, "I want to use my completely useless command, I need Ctrl+X key.")
That way, the "Control" key list displayed in the Help menu in RunActivity will be shorter and with no superfluous commands.

I guess I can start to write the Circuit Breaker and Pantograph interface.

Can I also begin to write a CabControl interface that will only contain pantograph and circuit breaker commands for now ? Or should I use the existing class ?

Edit : And yes, in TS2014 (RailWorks), the keymap is defined for each locomotive.

[gpz]

Serana, on 25 March 2014 - 05:36 AM, said:

Can I also begin to write a CabControl interface that will only contain pantograph and circuit breaker commands for now ? Or should I use the existing class ?

Edit : And yes, in TS2014 (RailWorks), the keymap is defined for each locomotive.

I would say this kind of stuff should go to a different class to the TrainControlSystem, since it would be a different script with different commands used.

[Serana]

I agree with you, and I would say the same for the "Circuit breaker and Pantograph" interface.

[Matej Pacha]

Serana, on 25 March 2014 - 05:36 AM, said:

Well, in most cases, it's the circuit breaker that can't be closed if the pantograph isn't raised for safety reasons : if the voltage changes and you forgot to select the correct voltage, you'll send 25000V AC in a 1500V DC circuit... let's say that if the circuit breaker is closed before the voltage is present, some components will burn.

This is not generic for single voltage locomotives. For these types, the circuit breaker is the main protection and should be ready to break before the pantograph touches the line. But since there is a discussion on scripting, we should leave this kind of questins for later discussion.

I like the concept of key-map deffinition for each type of locomotive. Anyway, before we start programming any control algorithms, the physics code - I mean the Update() method - is a mess. I'd like to have a finite state machine or something similar to control at least Init-ReadyOff-ReadyOn-Running-Error states. It would be probably easier to do some scripting on this FSM and to fill in some additional logic with panthos and CB...

Cheers,
Matej

[roeter]

Serana, on 25 March 2014 - 05:36 AM, said:

Well, in most cases, it's the circuit breaker that can't be closed if the pantograph isn't raised for safety reasons : if the voltage changes and you forgot to select the correct voltage, you'll send 25000V AC in a 1500V DC circuit... let's say that if the circuit breaker is closed before the voltage is present, some components will burn.

:D
Actually, the other way round (put 1500DC into an AC circuit) is a lot worse. Most AC components cannot cope very well with DC power, and what really is a problem : AC circuitbreakers cannot cut out DC currents. This is because the AC breakers generally work on the '0-passage' of the AC current to perform the break, and DC ofcourse has no '0-passage'.
For many years, the border-station at Venlo (between Netherlands and Germany) had none-switchable power on the plaform-lines for the through trains - 15000V AC for the platform for trains heading for Germany, 1500V DC for the trains heading into the Netherlands. No multi-current engines were in use at the time. Practice was that engines would cut-off power and lower pantograph as they came into the station, and were then detached and pulled off by a diesel shunter. It did, ofcourse, happen once or twice that the driver forgot to cut the power or, out of habit, raised the pantograph again once he had stopped. When this happened to Dutch (1500V DC) engines, they suffered damage to the main transformers but the fuses cut off the power and damage was limited. It once happened to a German engine (15000V AC) - neither fuses nor circuit breaker could cut off the DC power, and the power had to switched off the overhead - by that time, all electronics in the engine were burnt out.

Regards,
Rob Roeterdink