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