[Csantucci]

I've just inserted a small modification to the TCS code, increasing to 48 the maximum amount of generic TCS commands available. The modification should now be present in the Unstable release. Trellobox https://trello.com/c...of-tcs-commands .

[gpz]

 Csantucci, on 15 October 2020 - 11:12 AM, said:

I attach here the script lines where I use the Locomotive() hook. I wonder if they are all covered with this new interface.
UseOfLocomotive.txt
Anyhow, as already written, I'll keep the hook in OR NewYear MG and am still not convinced of the need to remove it.

As I see, your uses are not even for the Locomotive class itself, but jumping over to the Train class. Most of them are for finding out some signalling information that the current interface doesn't cover, many of them going into deep querying into the Track Circuit Sections, using also the internal route data. None of these have any reasonable right to exist in a script. Something such programmed is no longer a "script", rather it is an internal part of the OpenRails. But the code is spreaded to 100-1000 places, so noone is able to fix them if something changes inside the OpenRails internal code. You are not building this script for the future, rather just for the near present. Do you think this "script" will remain compatible in 2 years timeframe? What about 10 years timeframe? Or more...

You must also be aware of that the Train class became such a mess over the time, so it is the primary subject of a refactoring and splitting up to 5-10 pieces. How can you reason with an argument that you don't foresee any changes here in the future? Anyway, nobody can calculate the exact probability of a change, especially given that a change anywhere can potentially break the script outsourced internal code. But the exact probability doesn't even matter, because there IS a probability, despite of that no technical aspect denies us creating an interface with ZERO probability. By the way, this is the basic principle of a scripting interface: The interface functions must be designed in a way that they are guaranteed to remain compatible over time. Let me quote your own words again from the first page of this thread:

 Csantucci, on 04 February 2020 - 07:24 AM, said:

These hooks can't create problems neither to the scripts nor to the OR code, because (...) if the (...) setup will be changed, the since long time existing (...).cs script won't be changed, and the (...).cs script I'm publishing won't be changed. What will have to be changed is the code of the script hooks in TrainControlSystem.cs, but this really is a minor task in redoing the (...) setup: it's enough to see how few code lines are used for such script setup.

Just think about your own reasoning, in contrast how the current "interface" looks like.

[Csantucci]

Peter,
the concept I expressed on Februarh 4th is evidently correct: using hooks hides what is behind them. However between February 4th and March 31st, which is the date where I created the Locomotive() handle, I was confronted with so many needs (by myself and others) to add new, sometimes quite particular, hooks, that I considered more important not to fill the code with a plethora of hooks, some of them used only in particular cases.
By the way I don't permit myself to say that parts of the OR code are a mess; by the way I'm not eager to spend my time in refactoring working things and prefer to write new features. Apparently I have a different character than you.
Anyhow I see that here I am in minority on my position, and therefore I made the proposal to generate the deprecate log line.
I also generated and tested a patch with the additional handles I need to avoid the Locomotive() handle in the TCS scripts I wrote, and here it is
 New_TCS_handles.zip (2.98K)
Number of downloads: 407
The most part of the additional handles is related to signals, and they are all needed. I have the intention to add these to the Unstable release and they should remain also after your refactoring, minor changes apart if reasonable.
As already said, Locomotive() will anyhow remain in OR NewYear MG.

[gpz]

 Csantucci, on 18 October 2020 - 10:21 AM, said:

the concept I expressed on Februarh 4th is evidently correct: using hooks hides what is behind them. However between February 4th and March 31st, which is the date where I created the Locomotive() handle, I was confronted with so many needs (by myself and others) to add new, sometimes quite particular, hooks, that I considered more important not to fill the code with a plethora of hooks, some of them used only in particular cases.

With little thinking the needs can be fulfilled with general functions connecting to the internal databases, and leaving the particularities to the script. A good example of this is the "DoesNextNormalSignalHaveTwoAspects() and the two aspects of each head are STOP and ( CLEAR_2 or CLEAR_1 or RESTRICTING)" function. You should just generally provide the list of available aspects from the interface, and leave the special searching in the list to the script...

 Csantucci, on 18 October 2020 - 10:21 AM, said:

By the way I don't permit myself to say that parts of the OR code are a mess; by the way I'm not eager to spend my time in refactoring working things and prefer to write new features. Apparently I have a different character than you.

Why? Nothing dishonored is in that. It is a natural progress, that a code is written in functionality bearing in mind first, and then making it more and more structured, with rewritings and refactorings, mergings. All this is for keeping the long-term maintainability in mind. Preferably even the first published version of a code piece should have at least a little structuring and sensible connection and integration with the rest of the code. For example I very much dislike the style of a new feature programming, where one copies a hundred lines of code to a new function and modifies some lines in it to fulfill his needs. Instead of adding his mods to the original function, even though if he would have to test the original feature for avoiding degradation. IMO actually this copying is the thing that is dishonorable, because this doesn't respect the successor programmers trying to add further features or maintain the code, it is short-sighted. And OpenRails has a lot of places where such code-copies appear. Also there are a lot of other places where several not closely related functions are just grouped to a class (e.g. the Train). Nothing new in this, these types of codes are "mess". Why to be ashamed saying this? Generally saying, not specifically to you, going forward with adding new functions without perceiving this, leads to less and less maintainable code, also passing over the less-enjoyable part of the work to the others. And this is why adding new functions should always be done in a structured, well thought-over way.

 Csantucci, on 18 October 2020 - 10:21 AM, said:

As already said, Locomotive() will anyhow remain in OR NewYear MG.

Originally I didn't want to comment on this, but as you are dropping this "bomb" on me multiple times now, it looks like you are awaiting some answer from me. I think this wildcard sentence is the thing that you should not permit yourself, because it actually sounds quite arrogant, because with this you are saying you are not respecting anyone's arguments trying to discuss how OpenRails should progress. Seems to me you use this to weigh down anybody you disagree with, and from the forum history I see that it is also a good tool to deteriorate your relationship with anyone. But keep it in OR NewYear MG, I don't care. (Which btw is at least in 70-80% percent based on my own work. :) ) The future is yours anyway, because you are willing to put more work into OpenRails, than me for example.

[Serana]

On my side, I use the Locomotive function in two locations:


1) In order to get the DriverClosingOrder of the CircuitBreaker, which will be fixed with this future PR: https://github.com/S...-battery-switch
This PR is the addition of the master key, battery switch and other power supply related things.
I still have to make some changes (a renaming of DieselElectricPowerSupply to DieselPowerSupply and some refactoring using generics for the PowerSupply class in order to simplify a bit the power supply classes).
These power supply classes will be really useful when creating scripted pantograph selectors and power limit selectors... and also for dual mode locomotives/multiple units.

2) In order to release the speed limit precisely after a turnout (I am using the FrontTDBTraveller).
I currently don't know how to integrate this in the TCS interface.

[gpz]

 Serana, on 20 October 2020 - 04:01 AM, said:

2) In order to release the speed limit precisely after a turnout (I am using the FrontTDBTraveller).
I currently don't know how to integrate this in the TCS interface.

Isn't it enough to look at the distance to the next diverging switch, and when that becomes about zero, you know the train is on it. And then you have to just measure the travelled distance from there. Is there anything more special involved here?

[Csantucci]

 gpz, on 20 October 2020 - 01:48 AM, said:

But keep it in OR NewYear MG, I don't care. (Which btw is at least in 70-80% percent based on my own work. :) )

Yes, the MG porting is surely based on more than 80% on your work, and I am crediting and appreciating it :)

I have created a PR for the new handles I have proposed in my last post.
These handles are:

        /// Features of next generic signal. Not for NORMAL signals
        /// string: signal type (DISTANCE etc.)
        /// int: position of signal in the signal sequence along the train route, starting from train front; 0 for first signal;
        /// float: max testing distance
        /// </summary>
        public Func<string, int, float, SignalFeatures> NextGenericSignalFeatures;
        /// <summary>

SignalFeatures is

    public struct SignalFeatures
    {
        public string MainHeadSignalTypeName;
        public Aspect Aspect;
        public float DistanceM;
    }

What I missed is the possibility to get the name of the main signal head for INFO signals; I'm using INFO signals to emulate beacons, and the main head signal name is a way to determine what beacon type is emulated. I tried to generalise the approach with this function.
Also the management of NORMAL signals could be added to this.

        /// Trigger generic sound event
        /// </summary>
        public Action<Event> TriggerGenericSound;
        /// <summary>

This allows to trigger any sound event, as the 8 sound event reserved for TCS are not always sufficient (8 generic sound events have been already added).

       /// Train direction.
        /// </summary>
        public Func<Direction> CurrentTrainMUDirection;
        /// <summary>

I've added this, because I'm not sure that the train direction always coincides with the player locomotive direction (flips, rear cabs, shunting and so on).

As already written, these additions cover my actual needs for the Locomotive() handle.

I'm already using these handles in a script I'm finishing for a different, touch screen based DMI, but if there are improvement proposals to these handles I'm still on time to modify them.
They are now present in U2020.10.20-1237.

Trello box: https://trello.com/c...nd-sound-events

[Csantucci]

I put here the link https://github.com/o...nrails/pull/293 to the conversation related to the above PR, so that maybe also someone else can comment.

[Csantucci]

I have published a new script pack for our national TCS system; this is a version with an on board unit based on a touch screen DMI, that can support also ETCS (which I didn't implement). I've already used these http://www.elvastowe...post__p__263860 script hooks in alternative to the locomotive hook.
Here a picture

This DMI is also used in newer HST, both of Trenitalia and of Italo.
In my download page the SCMT pack and the SCMT demo activity pack include what is needed to try this. A monitor with a medium-high horizontal resolution (indicatively 1600 or higher) is needed to read the output messages. OR NewYear MG rev. 79 or higher and Unstable release U2020.10.24-0721 or more recent are needed.

[Csantucci]

A new PR has been presented which enables the TCS script to access:
- pantograph state (both read and write)
- throttle percent (read)
- current elevation percent.