[disc]

I think it would be the best to call external C# TCS classes. example:

public class MyTcs : ORTSTcs
{
public override void TcsUpdate(int frametime)
{
// runs in every frame
}
public override void OnPassForwardSignalItem () {} //runs when a signal item passed forwards (signal, transponder, etc)
public override void OnPassBackwardSignalItem () {} //same as above but backwards
}
And from this class there are some methods can be accessesed, like:
float GetTrainSpeed()
int GetNextSignalItemDistance(int lookahead) (no lookahead parameter means next signal, 1 means the next signal after the next)
Aspect (new data structure) GetNextSignalItemAspect(int lookahead)
float(speed) GetBrakeCurve(int targetdistance)
SetDynamicBrakePercentage(float)
SetTrainBrakePercentage(float)
SetThrottlePercentage(float)
PlaySoundOnce(filename) //play oneshot sound
Sound PlaySoundLooped (filename) //loop sound until stop sound is invoked on it returns an object(Sound) that represents the loop.
StopLoopSound(Sound sound)
ShowGeometry(nodename) //Show a node of cabview model (aiming on 3D cab)
HideGeometry(nodename) //hide a node
Animation PlayAnim(animation name) //play an animation returns Animation object that represents the current animation.
PauseAnim (Animation animation) //pause animation
StopAnim(Animation animation) //stops and resets the animation.

So something like this ;)
Just a very fast sketch not a specification, just to show how am i imagine. Of course this has the drawback that it's hard for those who are not programmers, but more flexible for those who can use it than a fixed instruction set.

[roeter]

It is not possible to 'just' have an external class definition + code outside the main executable. To work properly, it would have to be compiled and linked into the main *.exe just as any other code. That is just the same as hardcoded TCS, and that, as has been clearly stated, is no option.
The OR.exe file will NOT contain route-related code.

If you think it is necessary to have some kind of code mechanism apart from the set of parameters, you should be thinking along the lines of the sigscr.dat file - a parsed syntax file. If the same syntax would be used as for sigscr.dat - with just different external variables and fixed definitions (along the line of the SIGASP* variables), it would not be so hard to implement. That would keep route-related items where they belong : with the route.

Regards,

Rob Roeterdink

[James Ross]

roeter, on 01 November 2013 - 11:05 AM, said:

It is not possible to 'just' have an external class definition + code outside the main executable. To work properly, it would have to be compiled and linked into the main *.exe just as any other code. That is just the same as hardcoded TCS, and that, as has been clearly stated, is no option.

Actually, it's quite possible. Both in compiled (.dll) and source (.cs) formats. That said, I would urge caution to using either approach and generally favour a custom script format (like sigscr).

[disc]

roeter, on 01 November 2013 - 11:05 AM, said:

That would keep route-related items where they belong : with the route.

These scripts/configurations shouldn't be route related, but locomotive related... As there are locomotives with various TCS. See for example the ES64F4/ES64U4 locomotives. These have various configurations, some have italian TCS+PZB+LZB+Integra+ETCS, other variant have PZB+LZB+Mirel+EVM+ETCS, and there is another variant. And these systems can be different on different parts of the same route. For example there are parts with PZB, other parts with LZB, or ETCS and another one if the country borders crossed in that route.

I still say that a decent scripting possiblity would be the best. Railworks/TS has a quite "dumb" game, but awesome things could be achieved by it's lua script support (even if there are very few LUA calls can be used, and LUA is IMHO is the worst of worst scripting languages), like fully working PZB/LZB, cold start sequence, multiple headlight modes (dim signal,signal, dim headlight, headlight, shunt lights, warning light), pantograph configuration (even 4 pantographs), engine physics modifications like manual field weakening shunt switches, etc.
With decent scripting possibilities, the content developers wouldn't be limited by the core program features/ it isn't needed to code everything into the core program. I don't have problem with custom scripts, but i thought scripting with simple C# would be the easiest to implement, while having wide feature set, and another problem is, custom scripts need some editor, and debug support.

[gpz]

I cannot even imagine how to make a program like ORTS to be scriptable, so I cannot start modifying the code to achieve this goal without some initial work by the experienced programmers. But I really like Carlo's fixed function approach. Looks like it was thought over carefully. And for this one I have ideas how to start creating program code.

One thing I miss from Carlo's proposal is the TCS states (or modes). Even a single system can work differently in particular conditions. Just one simple example: ETCS can be switched to shunting mode, but I think other national systems also have this possibility, which modifies the system's response to events. E.g. at shunting there is no SPAD checked, but exceeding 40 km/h results an emergency stop. And there are even more states should be able to be used, which are switched automatically between, based on different conditions. E.g. vigilance alarm time can be shorter when approaching to a restrictive signal than of to a clear. (And in prior case, in my country, the count of possibilities clearing the alarm without automatic brake response is maximized in 2.) Also there are states based on the speed of the locomotive.

Just an ask to Carlo: It would be good to write an example .tcs file for an existing real world tcs, to be able to understand easier how it supposed to work exactly. I'm sure you already prepared one. :sign_thanks: And one more small technical proposal: You might upload the document to Google Docs, so there would be no need for anyone to download it, but everyone could see the most recent version of document just by one click.

[roeter]

This first reaction to the proposal deals with just one part - use of signals as transponders.
The test which is described in the document, using the Bernina pass route, is invalid.
It so happens that the Bernina route does not use stand-alone 'INFO' type signals, so obviously adding these did not affect the existing signalling. Just as obvious, though, is that if the test is performed on a route which does use stand-alone 'INFO' signals, the result would be quite the reverse.
'INFO' signals are just the same as any other type - they can be set to a state, and this state can be queried by any other signal. Many routes use 'INFO' signals just like this. For instance, the Horseshoe pass route uses stand-alone 'INFO' signals to define the required aspect for diverging routes. The signals are placed on (all) lines beyond a junction, with state set to reflect the required aspect, and the signals ahead of the junction enquire the state of the next 'INFO' to determine their aspect. This is not only done by the signals immediately in front of the junction, but also by those further back up the line to set the required approach aspect. Clearly, if you set a 'transponder' INFO signal anywhere between these signals and the junction, the intended working is lost.
As the almost endless variety in signal scripting means that there will always be routes which use any of the other signalling types in a similar manner, it is not possible to use any signal type for an additional function without causing problems somewhere.
So, using signals as transponders is not an option.
The only way out of this is if we were to decide that routes no longer need to be compatible for running under MSTS. We could then define an 'alternative' sigcfg.dat, which OR would use rather than the MSTS sigcfg.dat. But I don't think we are ready for that yet, and anyway, this is not the place and time where such a decision should be made.
Unless someone comes up with another idea in which transponders could be defined, we will have to concentrate on continouos systems for now.

Regards,
Rob Roeterdink

[roeter]

disc, on 01 November 2013 - 01:17 PM, said:

These scripts/configurations shouldn't be route related, but locomotive related... As there are locomotives with various TCS.

That locomotives can have multiple systems doesn't mean a thing - so could routes. What is more, just as in real life, only the system that is installed on (part of) the route would be active.
A further drawback of having the complete definition with the engine is that it would have to be added to each and every engine which is to run on that route and has the equipment installed. This would lead to the same 'copying madness' as with cabviews and soundfiles. The files would have to be distributed with each engine, as one never can be sure the user allready has an engine available with such files. Some users can sort this out and use references, but certainly not all.

Another point in this is that routes which have the same TCS system may have different signal scripts, requirinq different adaptations for the TCS system. That would be difficult to catch in engine-related files.

In my view, route-related files determine how the system is working, i.e. what information is send, when it is send etc., in relation to the signalling system.
Engine-related files (or perhaps cabview-related rather than engine-related) then deal with how this info is displayed.

Regards,
Rob Roeterdink

[roeter]

The more I come to think of it, the more the idea of using scripting start to appeal to me.
The point raised by GPZ above that the systems can be in different states only improve the case for scripting : use of 'if' statements in a script is obviously a lot easier than trying to catch that in sets of parameters.

Just a set of 'loose' remarks on scripting.

• Scripting has the advantage over actual C# routines that it allows 'shielding' of the program and program variables.
  There is no need for the creator of the script to have insight in the actual location and use of routines and variables required for the process. That is handled by the script environment.
  Just as in the signal scripting, general functions and variables could be defined as 'external', and pre-defined names (equivalent to the SIGASP* variables) could be defined. This would lower the threshold for writing scripts, while also protecting the integrity of the program as the script can only make use of and work on variables which it is intended to use.
  
  
• Normal debugging has it's limitations when it comes to problems in the signalling processing. Remember that you cannot just 'stop' the program in the routine where you think the problem is - that routine is probably called by all those hundreds of other signals at each update!
  To overcome this problem, the signal process - including the sigscr parser - has extensive build-in 'debug' facilities, in the shape of print-out dumps which create text-files with all required information, selectable per signal(s) if required.
  These dumps are activated using compiler switches.
  This has proven a very usefull way of debugging the signal process, and used extensively whenever I am looking into a problem. Most problems are solved using these dumps rather than actual debugging.
  My suggestion would be that all specific code for TCS systems would have similar dumps build into them.
  
  
• If for scripting we stick to the same syntax as used in sigscr.dat (obviously with different variables and functions), the existing sigscr parser could be used.
  Whether we just extend this with the TCS functions, or whether the present class is made into a 'parent' and two 'children' are then derived from this, is something that can be decided as we go along.
  As I did actually write the present sigscr parser, I think I still know a bit of how it works ...

Regards,
Rob Roeterdink

[James Ross]

roeter, on 02 November 2013 - 03:30 AM, said:

• Scripting has the advantage over actual C# routines that it allows 'shielding' of the program and program variables.
  There is no need for the creator of the script to have insight in the actual location and use of routines and variables required for the process. That is handled by the script environment

For the C# library (.dll) approach, this might be about correct (unless you use AppDomains, but they're a bit of a hammer), but for C# source-style scripting this isn't true. Just as in a normal C# source file you can only access what you import with 'using', in a script file the imported/available methods can be controlled. One way to do this is to insert the source inside a template:

using System;
using ORTS.Scripting.Api;
// Etc.

namespace ORTS.Scripting.Script {
    // Insert source file here.
}

Compiling like that would prevent the script from, for example, importing other namespaces and they'd only be able to use the API we give them (not importing "System.Reflection" would also be a good limitation). Examples of this already exist, too.

I'm not necessarily advocating we do this, but please don't keep dismissing it. :)

[Csantucci]

I'm happy my document has triggered discussion.
Some points:
- to Peter: yes, TCS modes management is something missing in my proposal, but I wanted to come out soon with a document covering at least TCS "standard" operation; I will think about adding TCS modes management;
- where should the TCS configuration or script data reside: loco or route? I have already given my answer to that in my document: in reality there is an infrastructure subsystem and an on-board subsystem: keeping them together in a simulation package has a sense only if there are no drawbacks. If there are drawbacks in keeping everything on the route folders or everything on the loco folders, one has to follow reality, and split also the TCS definition and implementation in two parts, as I have a bit tried to do in my document.
- configuration or script data: in my opinion configuration is easier to perform by content developers, and I tried to develop a well-founded configuration structure to demonstrate that it can be a quite powerful tool; if however a script solution will be chosen, then in my opinion the script language should be a close twin of the sigscr language: as it can be foreseen that a good number of content developers will develop both signalling systems and TCSs, pls. let them use two similar languages and don't constrain them to learn two very different ones. There would be also advantages if sooner or later a "contamination" between the two languages will take place. So, if a script solution is chosen, I'm for Rob's proposal on that.
- emulation of transponders: I see Rob's point. These are my points:
a ) development of ORTS TCS without transponder emulation is a crippled development, considering how widespread transponders are; therefore, a solution for now or for tomorrow has to be found already now, to avoid the risk of throwing away work
b ) I don't know how often arrangements like the one Rob described about the Horseshoe curve are present in the MSTS routes; if it doesn't happen often, similarly as some MSTS routes don't work on ORTS without modifications, I don't see a terrible problem if some MSTS routes can't be straigntforwardly upgraded to manage a transponder-based TCS; one must also take into account that such upgrade anyhow requires working with the RE and the signal files, and this work can also include restudying use of signals; for such routes moreover there can be a solution I already indicated in my document if in general such transponders are at a more or less fixed distance before or after signals or speedposts.
So better have the "INFO" solution for a nice set of routes rather than no solution at all.
c ) however I will make some other test on fiddling on signal and speedpost files to find out if there is a solution that overcomes Rob's problem.