[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.

[Csantucci]

I believe I have found a way to overcome Rob's concern.
A transponder is now defined in sigcfg.dat as follows:

	SignalType ( "Crocodile"

		SignalFnType ( BEACON )
		SignalDrawStates ( 1
			SignalDrawState ( 0 "Nothing" )
		)
		SignalAspects ( 0 )
	)

Notice the new SignalFnType, that does not create problems to the MSTS RE.
The SignalShape remains unchanged:

_Skip(- Check beacon -)
      SignalShape (
		"MR_1276.s"
		"Crocodile_beacon"
		SignalSubObjs ( 3
					SignalSubObj ( 0
				"HEAD1" "Crocodile beacon head"
				SigSubType ( SIGNAL_HEAD )
				SigSubSType ( "Crocodile" )
			)
					SignalSubObj ( 1
				"Selection1"
				"Selection_1" 
				SigSubType ( ORTSTCS_RSC )
				SignalFlags ( OPTIONAL )
			)
					SignalSubObj ( 2
				"Selection2"
				"Selection_2"
				SigSubType ( ORTSTCS_RSCSTART )
				SignalFlags ( OPTIONAL )
			)
		)
	)

The transponders are laid down with the RE. Then by means of an editor (possibly through a macro) all .tdb references of type

		SignalItem (
			TrItemId ( 3207 )
			TrItemSData ( 3137.84 00000002 )
			TrItemRData ( 660.647 1772.93 -653.736 -5762 14668 )
			TrSignalType ( 00000000 0 5.64232 Crocodile )
		)

are modified to

		ORTSTransponderItem (
			TrItemId ( 3207 )
			TrItemSData ( 3137.84 00000002 )
			TrItemRData ( 660.647 1772.93 -653.736 -5762 14668 )
			TrSignalType ( 00000000 0 5.64232 Crocodile )
		)

That's all. MSTS overlooks these .tdb items when it manages signals, but all data needed are still there for ORTS processing.
For the sake of cleanliness the same modification can be made to the .tit file.
Again for the sake of cleanliness an analogous can be made to the world file, replacing the related

Signal (

entries with

ORTSTransponder (

entries.
An ORTS RE (when it would be ready) could of course be built so that it already allows to generate these modified files.

I would be happy if someone could test this in some further route.

[roeter]

Work it may, but it has a very serious snag - serious enough to make it unusable.
You are right in that MSTS ignores the renamed world entries. But MSTS ignores these whatever you do with MSTS - so it also ignores them in the Route Editor. This means not only that you cannot see these items in the RE, it also means that if you edit a route with such items, then on save, they will no longer be included in the world files or the tdb. So even a small edit session would ruin the integrity of the route.
What would this mean? Well, for instance, it would be necessary to place all required beacons on the route before the renaming can be done. But if the renaming has been done, and one finds that just a single beacon is missing, all renaming has to be undone again, the route edited, and all items renamed again. But worse, once the route has been delivered and the user wants to make a small change, the user has to do the same - undo the rename, edit, rename again. If not, the route becomes unplayable. I don't think that is the proper way to go.

Because of this, any solution which requires additions to any file processed by the MSTS Route Editor (world files, tbd), is out of bounds.

That leaves only two possible options :

• Additional files, processed by OR, which defines items or links etc.
  A possible solution here would be to place the transponders as normal static items, and than create links between signal and the transponder.
  Drawback here is that these files all would have to be edited manually, using info from world-files (e.g. object numbers).
  Main questionmark is if this info could be changed by MSTS when the route is edited; if so, it would require a lot of additional checking.
  
• Alternative files, processed by OR instead of the normal MSTS files.
  This would allow alternative definitions used in OR while MSTS uses the standard definitions.
  So, additional signals could be created, as type INFO (for instance) in MSTS, but defined as BEACON in the alternative OR files.
  This, however, has the serious disadvantage that it may impede the working of the route in MSTS. I am not sure if the community is ready to accept that.

Carlo, I appreciate your worries that setting up TCS without the transponders might cause problems later on. But I am worried that by setting up functions overriding the normal MSTS behaviour, after we have done all the work getting that set up, we find we have created problems which either make the whole thing useless, or we have created such a vulnerable or complex situation that problems with it will haunt us for years to come.
Given the complexity of the signalling and the enormous variety in use, we have to be very, very carefull before starting to change anything in either the structure or the behaviour.

Regards,
Rob Roeterdink

[Csantucci]

Rob,
reverting from the "ORTSTransponder" strings to the "Signal" strings to work with the RE is even a faster thing than making it the opposite direction. With an editor you simply have to do a multiple search and replace. One command. I understand that it is worse than no command. But it is very fast; moreover this solution is a clean one, because it simply adds new Item types in the .tdb and .tit file.

[roeter]

Sorry, perhaps I was not clear enough : I am not going to support changes which carry such a high risk in damaging the route's integrity.
It may be that this or that editor can do it easily or not : not every user understands the file structure, not every user may have this or that editor, and we cannot stop users from editing a route if they wish.

There is another option which could be considered - I say 'could', because this involves creation of files additional to the MSTS structure, and there has not yet been a decision if we will allready go down that path, nor on what format such files should have.

This would work as follows.

• A normal 'static' item representing the transponder is based on the track.
  
• In a file additional to the world-file, a link is created between this item and the signal to which it refers.
  This link can be based on the world-file object numbers.
  A transponder can be linked to multiple signals, a signal can be linked by multiple transponders.
  
• The location of the transponder within the trackdata is determined using the traveller.
  
• The function of the transponder, or at least the link between the transponder and it's related TCS system, could be defined in a script using the transponder file name as reference.

This system also has the advantage that is solves the problem of linking the transponder to the signal which state it reflects, something not yet addressed in your proposal.

But before this can be taken any further, a decision must be taken by the management team if and how additional files can be used.

Regards,
Rob Roeterdink

[Csantucci]

Rob,
there are also transponders that are not linked to a particular signal, but that have other functions. Moreover I don't know well how the traveller works, but I suppose it walks along the .tdb file. If the transponder is not within the .tdb file I'm not able to see how the traveller can find it.
About risks of damaging the route integrity: everyone using the MSTS RE knows that the first item damaging the route integrity is the RE itself, that is quite unsafe in this matter. So I expect that a route builder is already quite alerted on the need of backupping and so on.
About editors: every editor has a multiple search and modify feature. And also in your solution the route creator has to dig in the .w files to find signal references, and has to use an editor to create links, by the way in a quite tedious way.
About linking transponder and signals where needed: this can be done in a quite similar way as this happens now between signal and signal within the sigscr file.

Anyhow the main issue for me is that a technical solution is agreed that allows acceptable (in all senses: easy to use and flexible) TCS implementation in few time and not waiting three years. Any solution satisfying such requisites is OK to me.