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