[gpz]

For the comment in the code, actually the previous line does the job:

if (forsight >= list.Count) SearchTrainInfo(forsight, type);
// <CSComment> Doesn't : list.Count - 1 lead to wrong returns if forsight > 0? </CSComment>
return list[forsight < list.Count ? forsight : list.Count - 1];

The SearchTrainInfo() function extends the list to the requested "forsight". That last line is just a protection, if a too big "forsight" number was asked for, it still returns some value. I didn't want to give back a null value, since the script writer is not expected to always do null-checks on interface functions, it would be a valid expectation from him, that these functions always return something. You may be right, that it was not the best choice to just repeat the last signal (most probably a STOP) to any bigger numbers, there could have been a dummy signal object defined with aspect none, speed limit float.max, etc., and return that one. Yes, this might be a valid change.

In my code I am about to change the TrainInfo object to something like

        Train.TrainInfo TrainInfo {
            get 
            {
                if (!TrainInfoUpdatedFlag) _trainInfo = Locomotive.Train.GetTrainInfo();
                TrainInfoUpdatedFlag = true;
                return _trainInfo;
            }
        }
        Train.TrainInfo _trainInfo = new Train.TrainInfo();
        bool TrainInfoUpdatedFlag;

where the TrainInfoUpdatedFlag = false can be set in the ClearParams() function, so this way the TrainInfo is updated only once per Update() call, but for sure gets updated at the first use.

I am also about to add the collecting of the generic signals and the trailing switches to the TrainInfo. If we want long-term maintainability, or make our successor developers to understand what we've done, that is the correct solution I think. It also makes the code more clear, since the current functions are mainly just copies from the TrainInfo with slightly modified functionality. (Anyway, they are well coded functions, imho.) TrainInfo is there mainly for feeding the MSTS-style track monitor, and e.g. the ETCS track monitor is just a more advanced track monitor. So these additions naturally belong there. In long term the OR track monitor probably should also be updated to have the missing functions that other TCS system track monitors have.

[gpz]

Just a note about my original code: Probably my original SearchTrainInfo() function is also overcomplicated. I was coded it to build other List()-s of different type of objects based on hits in TrainInfo. But it is absolutely unnecessary. The simplest way is just returning directly the found TrainInfo member's properties, without additional magic... TrainInfo is the master database, that (should) contain all the necessary data. I must add the altitudes there as well...

[Csantucci]

I have introduced some of the suggestions by Peter about TrainInfo into rev. 75 of OR NewYear MG.

[YoRyan]

So, what's the status on these proposed changes? Are we doing anything to the Locomotive handle? Are we going to upstream the TrainInfo improvements?

[gpz]

I've finished with 80-90% of the coding, but only 5-10% of the testing... One may take a look on the code here on Github, but it is not worth tying to download it yet, currently it is not even in a compilable state. I am yet to figure out how to query the altitudes of different signalling elements. (I'm sorry, I have less time for coding than it would be ideal.)

The to-be-PR of this code will not contain the removal of the Locomotive handle to allow people to make the transition smooth, but that handle must be removed not later than just before the unstable-testing branch goes stable.

[Csantucci]

Peter,
Have you checked that your revised version handles the usage of all locomotive class items actually used by the TCS developers?
Apart from the work needed because of the deletion of the Locomotive handle, does your revision require other changes to the TCS scripts?

[gpz]

Hi Carlo,

By my intention it handles all classes, and I tried to cover all the use cases that came up in this thread, and that I am aware of, if I hadn't forgotten something. There's a list of variables I thought to add in the first round as built-ins at the beginning of this file. I don't think most of the existing ones need to be removed, even those I tried to give a cleaner alternative for here, because beyond the Locomotive() one neither of them makes any harm. When it will be ready, and before merge, actually a feedback from people, especially from ones familiar with scripting of other simulators, would be highly appreciated, to tell whether this approach is any better than the previous one I started years ago. Eventually it should be good enough to support scripting of not only the TCS, but also of other fancy features of a locomotive.

[cesarbl]

I am so excited with this feature!! This will finally allow me to create scripts to have more realistic controls (customized brake blending, cruise speed...) If this is approved, I think people looking for a realistic driving experience will come to OR.

With respect to signal altitudes, I only mentioned them as an example of weird usage of OR internal structures. My ETCS is still experimental and I haven't released it, so they are not a problem. I used them to show that ETCS can be used in OR with full functionality, but I don't mind if I have to set gradients to zero for a while after the Locomotive() hook is removed.

I have looked at the interface and it suits my needs, so as soon as it is merged I will remove all Locomotive() references in my script.

Some suggestions: It might be worth adding this variables: line voltage (for use by the circuit breaker, not the one shown in cabview), "TCSEmergency" and "TCSFullService". Also, save/restore functionality would be interesting for controller scripts.

[Csantucci]

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 (1.77K)
Number of downloads: 383
Anyhow, as already written, I'll keep the hook in OR NewYear MG and am still not convinced of the need to remove it.

[Csantucci]

As a compromise I propose to do as Cédric has done with SetCustomizedTCSControlString.
When a call to Locomotive() is executed, a log line is generated, stating "Locomotive() is deprecated". Of course this should be generated only at the first call, to avoid flooding the logfile.