PDA

View Full Version : Interlocking Towers Side Effects



andi06
October 18th, 2015, 02:46 AM
On installing my script libraries I'm seeing literally hundreds of these and similar messages in the log:


! TrainzBaseSpec::CacheScripts> ** GSC> jklibrary - copy.gs(1005) : function SetDirection is obsolete in object JunctionBase.
! jklibrary.gs(1005) : function SetDirection is obsolete in object JunctionBase.
! TrainzBaseSpec::CacheScripts> ** GSC> jklibrary - copy.gs(1335) : function SetSignalState is obsolete in object Signal.
! jklibrary.gs(1335) : function SetSignalState is obsolete in object Signal.

It seems that in order to accommodate Interlocking Towers you have amended the prototypes of dozens of signal / junctionbase / crossing methods to include for Security Tokens. In every case you have also overloaded the original method to call the new one with a null token.

Do you expect the calls in my libraries to be updated to match the new prototypes? (no problem but it will be very tedious) It would mean doing exactly what you are doing (calling with a null token) but in client code. There seems to be little point in doing this but if I don't these messages will clog up the logs forever.

Bottom line is are these messages actually correct and necessary.

andi06
October 18th, 2015, 03:34 AM
In the interlocking towers demo cdp there is an unknown dependency <kuid:401543:3220>
The Interlocking Towers demo shows up on the route list but I get an immediate CTD (with crashdump) if I try to load either session for editing.

pw3r
October 18th, 2015, 11:09 PM
Do you expect the calls in my libraries to be updated to match the new prototypes? (no problem but it will be very tedious) It would mean doing exactly what you are doing (calling with a null token) but in client code. There seems to be little point in doing this but if I don't these messages will clog up the logs forever.

The Interlocking Towers implementation has added the concept of "ownership" to several key object types. Once an object is "owned" by something else (like an Interlocking Tower) any unauthorised attempt to change it's state will fail and generate a script exception. This is where the token parameter comes in. If you modify your scripts to just pass a null token all of the time then the call is guaranteed to nosily fail if the object is owned. To avoid this you'll need to add calls to test the object owner before attempting any state modification.

Terry Palmer
Programmer
N3V Games

pw3r
October 18th, 2015, 11:17 PM
In the interlocking towers demo cdp there is an unknown dependency <kuid:401543:3220>
The Interlocking Towers demo shows up on the route list but I get an immediate CTD (with crashdump) if I try to load either session for editing.

Thanks for the report, this crash has now been fixed internally. The missing dependency is the Interlocking Tower asset btw, it should be included in one of the 3 CDPs in the Interlocking-Towers zip file.

Terry Palmer
Programmer
N3V Games

andi06
October 19th, 2015, 03:49 AM
The missing dependency is the Interlocking Tower asset btw, it should be included in one of the 3 CDPs in the Interlocking-Towers zip file.
I downloaded Interlocking Tower Example.cdp (http://online.ts2009.com/mediaWiki/index.php/File:Interlocking_Tower_Example.cdp) and it doesn't seem to be included. I didn't see any other downloads.

andi06
October 19th, 2015, 04:29 AM
The Interlocking Towers implementation has added the concept of "ownership" to several key object types. Once an object is "owned" by something else (like an Interlocking Tower) any unauthorised attempt to change it's state will fail and generate a script exception. This is where the token parameter comes in. If you modify your scripts to just pass a null token all of the time then the call is guaranteed to nosily fail if the object is owned. To avoid this you'll need to add calls to test the object owner before attempting any state modification.

Yes I understand all of that, existing calls will need to be wrapped in a new test: if (!GetJunctionOwner()) SetDirection(0);

You are introducing a new parameter to SetDefaultDirection (and dozens of other methods) so that it becomes SetDirection(null,0);
These changes will involve extensive editing and will prevent my libraries from being portable between TS12 and TANE.

There are two ways that this can be done from the perspective of my code:


I can edit literally hundreds of calls in my script to add the null parameter.
I can leave my calls alone and rely on the new overloaded prototype to do the same thing:



public obsolete bool SetDirection(int dir)
{
return SetDefaultDirection(null, dir);
}

As far as I can see there is no effective difference between 1 and 2 except that my fingers and keyboard don't get worn out with method 2.

I would suggest that you don't need the warnings (presumably generated by the 'obsolete' specifier) because they are clogging up the log files and they don't actually achieve anything in any case.

pw3r
October 19th, 2015, 06:33 PM
The critical change here is that if the object is owned the call will now fail and generate a script exception, whereas previously it would almost always succeed. The warning is there to notify you of this and encourage the updating of scripts to test if the object is owned.

You're correct in that there is no functional difference between calling SetDirection(dir) and SetDirection(null, dir), but that is not the issue.

Terry Palmer
N3V Games

andi06
October 19th, 2015, 06:47 PM
OK, I can see that we are going to get along famously :)

You are stating that these two calls are safe:
if (!GetJunctionOwner()) SetDirection(0);
if (!GetJunctionOwner()) SetDirection(null,0);

and that these two calls are unsafe:
SetDirection(0);
SetDirection(null,0);

In each case the code in red is what needs to be updated. But you aren't checking for this because you can't. Instead you are looking for the code in green which has absolutely no influence over whether or not exceptions will occur. This is a complete waste of your time and ours.

WindWalkr
October 19th, 2015, 06:54 PM
I suspect that Terry's point (correct me if I'm wrong, Terry) is that the existing code looks like this:

SetDirection(0);

and is known to be NOT SAFE.

You could write code that looks like this:

if (!GetJunctionOwner()) SetDirection(0);

and be safe while getting the warning, or you could write it like this:

SetDirection(null,0);

and be unsafe while getting no warning, however you should write it like this:

if (!GetJunctionOwner()) SetDirection(null,0);

in which case you are safe and do not get the warning. Since the existing variant is "not safe, gets warning" and there is a new variant which is "safe, no warning", the warning is useful- it brings the existing (now unsafe) usage to peoples attention. It would be nice if the other two variants didn't exist, but as you say, that's not really possible.

chris

WindWalkr
October 19th, 2015, 06:56 PM
It's also worth noting that by "safe" we of course mean "instead of generating an exception, the code does nothing." Whether this is enough by itself depends on what you're trying to do. The warning and these examples do not try to solve that question. You might need to rethink your approach in some cases, or even separate your control logic from the map object in question to allow the user to have more control over which owner is going to be in effect.

chris

andi06
October 19th, 2015, 07:19 PM
I'm not misunderstanding Terry's point but my point is that I have two very large libraries which have literally hundreds of these calls - Installing one junction object generates more than 250 lines of these messages. I'm perfectly happy to edit my code to test for ownership but very unhappy to add the null parameters because it will be extremely tedious and the overloaded (obsolete) function already does everything that is neccessary to update the parameter list. This is what you describe as "safe code but with warnings".

The same situation will arise for just about every script that deals with junctions, with signals or with crossings but the error messages themselves don't even indicate what actually needs to be done.

I understand that you need to do everything you can to ensure that third party scripts are updated but there has to be a better way. At the end of the day a lot of existing scripts are going to be generating exceptions anyway so perhaps you should consider additional explanatory text in the exception dialogue which informs users that the parent asset is incompatible with towers and points script writers to a wiki page explaining the issue.

andi06
October 19th, 2015, 07:27 PM
It's also worth noting that by "safe" we of course mean "instead of generating an exception, the code does nothing." Whether this is enough by itself depends on what you're trying to do. The warning and these examples do not try to solve that question. You might need to rethink your approach in some cases, or even separate your control logic from the map object in question to allow the user to have more control over which owner is going to be in effect.
I'm not unhappy with the concept of ownership. I've asked you several times in the past for a means of establishing whether or not a train has a permit on a junction to enable multiple junctions to be safely switched together and GetJunctionOwner() seems to perform a similar function.

Key questions are to what extent your code will restore the status quo ante when it exits and whether or not my code will need to, or be able to, queue its own actions until the paths are clear. No doubt all will become clear in due course.

WindWalkr
October 19th, 2015, 07:34 PM
I'm not misunderstanding Terry's point but my point is that I have two very large libraries which have literally hundreds of these calls

Either you need to inspect every call site and determine what changes you need to make- in which case the warning is a good thing - or you don't, in which case you can just use find/replace and the warning is only costing you a few minutes of your time.



The same situation will arise for just about every script that deals with junctions, with signals or with crossings but the error messages themselves don't even indicate what actually needs to be done.

I am lead to believe that the comments on the functions in question go into it in quite some detail.



Key questions are to what extent your code will restore the status quo ante when it exits and whether or not my code will need to, or be able to, queue its own actions until the paths are clear.

I'm not sure what you mean by "exit". Short of being deleted from the map, interlocking towers do not stop functioning.

chris

andi06
October 19th, 2015, 07:48 PM
in which case you can just use find/replace and the warning is only costing you a few minutes of your time.
You underestimate - there are dozens of newly obsoleted methods in many source files.


I am lead to believe that the comments on the functions in question go into it in quite some detail.
The comments do (but most users won't ever read them), the log warnings don't (most users will never see these either). I haven't got the example route loaded and working yet so I can't comment on what the exception dialogue will say.


I'm not sure what you mean by "exit".
For 'exit' read clear and unlock a path.

WindWalkr
October 19th, 2015, 08:10 PM
You underestimate - there are dozens of newly obsoleted methods in many source files.

No, I'm happy to stick with my estimate. Either there is real work to be done, or the computer can do it for you. The latter is great when it applies, but in the former case, it's sensible to have warnings alerting you to anything that you've missed.



The comments do (but most users won't ever read them) the log warnings don't (most users will never see these either).

If someone is willing to dabble in scripting, there are a million ways they can shoot themselves in the foot. We're providing the information, but if they choose to ignore it then they will get what they get.



For 'exit' read clear and unlock a path.

It is my understanding that Interlocking Towers never release permissions on their controlled objects.

chris

andi06
October 20th, 2015, 05:35 AM
If you were doing something like this:


public obsolete bool SetDirection(int dir) {
Interface.Print("Syntax of this function has changed, ensure that code is protected (see documentation)");
return SetDirection(null,dir);
}

then I would be with you all the way, but as it stands you are just raising an unhelpful message using a mechanism which just happens to already exist.

I'm trying to be constructive here but it seems that we must agree to differ - you can put your heads back in the sand until we find some other less than useful messages.

Mick_Berg
October 22nd, 2015, 02:53 PM
Is it necessary to have SP1 to try this out? I do not use experimental builds, I just have HF2, but would love to have a look at this.
Mick

Mick_Berg
October 24th, 2015, 09:01 PM
Is it necessary to have SP1 to try this out? I do not use experimental builds, I just have HF2, but would love to have a look at this.
Mick
I got no answer so I'm bumping my question.
Also, the example cdp does not contain the Tower asset, where can I get it?
Thanks,
Mick

pguy
October 25th, 2015, 04:28 AM
Is it necessary to have SP1 to try this out? I do not use experimental builds, I just have HF2, but would love to have a look at this.
Mick

Hi Mick.

From what I have understood, Interlocking Tower use some new native code included only in SP1 and so it can't be tested with only HF2. You need to install the beta version of SP1 which has a new build level 4.3 which is required for the the new asset kind "Interlocking-tower".

In beta SP1, the delivered example interlocking tower asset is named Crowcombe-Heathfield Signal Box <kuid:401543:3220> and has the new config kind type "interlocking-tower". For me it is included in the example cdp, but may be it can only be installed under a SP1 build 4.3 Tane version. You have also two new script classes InterlockingTower and InterlockingTowerPath which are delivered as standard base script in the script directory of SP1.

Regards.
Pierre.

andi06
October 25th, 2015, 06:47 AM
For me it is included in the example cdp
I've no idea how that can be, I've downloaded the example cdp twice and it only contains a route and two sessions. However anyone who wants to get this working can create a folder containing this config.txt and install the folder into the new build, this will be enough to get the sessions working:



kuid <kuid:401543:3220>
username "Interlocking Tower"
kind "interlocking-tower"
trainz-build 4.3
mesh-table {
default0 {
lod-level 0
mesh-asset <kuid:303612:40>
mesh "crowcombe_heathfield_signal_box0.im"
auto-create 1
}
default1 {
lod-level 1
mesh-asset <kuid:303612:40>
mesh "crowcombe_heathfield_signal_box5.im"
auto-create 1
}
}
mesh-detail-level-count 2
category-class "IT"
category-era "1950s;1960s;1970s"
description "An old wooden signal tower building, circa 1950s. No custom scripting, fully configurable in T:ANE."
thumbnails {
}

andi06
October 25th, 2015, 07:11 AM
As I predicted in my earlier responses to the design document you have found it impossible to configure paths with the screen darkened in the background. You have got around this for the moment by commenting out ismodal in the Properties.txt dialog definition. This screws up several other parts of the game, specifically things like EditSession/Driver Setup and configuration of the Interlocking Tower rules :o. No doubt you can get around this and I urge you to drop this ridiculous screen darkening everywhere.

Commenting out ismodal makes the path editing box into a stay-on-top non modal window and gives us full access to route navigation. It also makes the Surveyor/Set Junction Direction button operative. This provides a much more natural way of setting a path and it also allows multi-node fixed track junctions to be toggled to any of their states with their mutexes and internal linkages respected, rather than having to set them one node at a time via a cumbersome list editing procedure. I suggest that it would be better to edit paths in this way and to have the interlocking script recalculate the forward path following a Junction,Toggled message from the map.

It might also be nice to arrange for crossings to respond to a mouse click.

There is a bit of an issue with screen space. I have a 1280 x 1024 monitor and, whilst I accept that some users will have more pixels available, I expect that this is a screen size you need to handle. When you open the property dialogue and expand it to a width large enough to see the options properly and a height large enough to view a reasonable length of path, the dialogue is using a considerable proportion of the screen. This makes using it a little unwieldy and, since the dialogue size is remembered for all objects, the next time you try to rename an object the dialogue comes up way too large. Perhaps you need to create a new dialogue just for these objects.

Mick_Berg
October 25th, 2015, 12:28 PM
Hi Mick.From what I have understood, Interlocking Tower use some new native code included only in SP1 and so it can't be tested with only HF2. You need to install the beta version of SP1 which has a new build level 4.3 which is required for the the new asset kind "Interlocking-tower".In beta SP1, the delivered example interlocking tower asset is named Crowcombe-Heathfield Signal Box and has the new config kind type "interlocking-tower". For me it is included in the example cdp, but may be it can only be installed under a SP1 build 4.3 Tane version. You have also two new script classes InterlockingTower and InterlockingTowerPath which are delivered as standard base script in the script directory of SP1.Regards.Pierre.Thanks Pierre, I suspected as much. No problem, plenty of other nonsense to deal with!Mick

geophil
October 25th, 2015, 04:34 PM
I've downloaded the example cdp twice and it only contains a route and two sessions. However anyone who wants to get this working can create a folder containing this config.txt and install the folder into the new build, this will be enough to get the sessions workingYes, the interlocking tower asset is missing in the CDP. Your config.txt solved this. Thanks a lot.

pw3r
October 25th, 2015, 08:10 PM
I've no idea how that can be, I've downloaded the example cdp twice and it only contains a route and two sessions.

I can only assume that you've managed to find the example route and session on the wiki and aren't using the test zip file distributed by Tony (which actually contains 3 cdp files). The intention is to make the tower asset builtin, so obviously it will not be included from the cdp file on the wiki.

I'd strongly suggest people stick to the instructions on the announcement thread and download and install the correct assets, but it probably won't cause any extra issues in this case. If for some reason you don't have access to that thread I can make sure the zip file gets posted in this forum somewhere as well.

Terry Palmer
N3V Games

pw3r
October 25th, 2015, 08:21 PM
As I predicted in my earlier responses to the design document you have found it impossible to configure paths with the screen darkened in the background.

As I've stated in the past, this is a planned addition, and in fact has already been done for the new build (though I've heard it is still a little buggy).


You have got around this for the moment by commenting out ismodal in the Properties.txt dialog definition.

This is guaranteed to introduce crashes. Do this at your own risk.


Commenting out ismodal makes the path editing box into a stay-on-top non modal window and gives us full access to route navigation. It also makes the Surveyor/Set Junction Direction button operative.

It may make them interactive but the editing dialog will not automatically respond to changes in the world so this is of limited usefulness. I suppose you could set a path in the world and then use the dialog to add a new path, but then you'd have to go back to the world and change all the junctions back to avoid messing up the default positions.


There is a bit of an issue with screen space. I have a 1280 x 1024 monitor and, whilst I accept that some users will have more pixels available, I expect that this is a screen size you need to handle. When you open the property dialogue and expand it to a width large enough to see the options properly and a height large enough to view a reasonable length of path, the dialogue is using a considerable proportion of the screen.

With the correct non-modal support in the new build it's also possible to quickly minimise/restore this dialog, which helps greatly with this problem. Though I'd still suggest a monitor upgrade ;)


... since the dialogue size is remembered for all objects, the next time you try to rename an object the dialogue comes up way too large. Perhaps you need to create a new dialogue just for these objects.

This is quite true and it's something that I'll be fixing for the next build.

Terry Palmer
N3V Games

andi06
October 26th, 2015, 04:33 AM
I can only assume that you've managed to find the example route and session on the wiki and aren't using the test zip file distributed by Tony (which actually contains 3 cdp files). The intention is to make the tower asset builtin, so obviously it will not be included from the cdp file on the wiki.

I'd strongly suggest people stick to the instructions on the announcement thread and download and install the correct assets, but it probably won't cause any extra issues in this case. If for some reason you don't have access to that thread I can make sure the zip file gets posted in this forum somewhere as well.
Yes, I'm talking about the file on the wiki. I don't know where the test zip was announced but I don't think that I've seen it.

andi06
October 26th, 2015, 05:08 AM
This is guaranteed to introduce crashes. Do this at your own risk.
I haven't done it at all. You have circulated the latest dev build with ismodal commented out. This means that any attempt to edit the Interlocking Tower rules in the current test build is likely to generate a CTD.


It may make them interactive but the editing dialog will not automatically respond to changes in the world so this is of limited usefulness.
Its of limited usefulness now but it wouldn't be difficult to change to work something like this:

With the dialogue open and in Edit Path mode the effect of toggling a junction would be to change its currently displayed direction, update the path spline and update the junction direction entry in the dialogue. Clicking on a junction beyond the end signal would extend the path via the selected junction. When edit mode is closed on a particular path the script restores the default direction of any junctions which have been toggled.

Since multi-node fixed track junctions now respond correctly to the Set Direction button it would be possible to set a path through slips and crossovers with a single click rather than having to open every individual junction node, work out where the node is located and edit it via the list. This would also ensure that internally conflicting paths on these objects would not be set.

I think that this would be easier, more intuitive and more immersive and all of the code to implement it is probably already in existence in some form or other.


Though I'd still suggest a monitor upgrade ;)
A bigger monitor wouldn't be a problem, a bigger study would be.

pw3r
October 26th, 2015, 07:10 PM
Yes, I'm talking about the file on the wiki. I don't know where the test zip was announced but I don't think that I've seen it.

Try this: http://dl1.n3vgames.com/Interlocking-Towers.zip

Without that file I'm kind of surprised you found the example sessions. Good to know people do read the wiki, and that writing that page was time well spent :)


I haven't done it at all. You have circulated the latest dev build with ismodal commented out. This means that any attempt to edit the Interlocking Tower rules in the current test build is likely to generate a CTD.

The latest test build has substantial native code updates to avoid these crashes. I didn't realise it had been released at the time of my writing that reply.


Its of limited usefulness now but it wouldn't be difficult to change to work something like this...

The interface we have has come about for two main reasons. The first of those is because the property dialog was modal and blocked interaction with the world. This is obviously no longer true but the more important limitation (which you've also mentioned) is that this dialog needs to take up substantial screen space to be workable. I'm not convinced that you could easily use the existing junction toggle tool to configure a path while having it on screen in it's current form. I'm also not convinced that doing so is more intuitive than keeping the path configuration in the path configuration dialog.

That said, the way the current system handles fixed track junctions is poor in a lot of circumstances. I see this as a separate issue, and I don't believe it's worth overhauling the interface to handle an asset type we'd probably prefer to phase out, especially now that we have procedural track junctions (even if they're also still somewhat of a work in progress).

Terry Palmer

andi06
October 27th, 2015, 05:49 AM
Without that file I'm kind of surprised you found the example sessions. Good to know people do read the wiki, and that writing that page was time well spent :)
Don't get too excited, not everyone will be reading it.


The latest test build has substantial native code updates to avoid these crashes. I didn't realise it had been released at the time of my writing that reply.
It sounds like you're aware of the issue but the present situation in 79091 is that you can't use the edit session dialogue unless you remove the comment from the dialogue file and condemn the trainz world to a nuclear winter :-)


The interface we have has come about for two main reasons. The first of those is because the property dialog was modal and blocked interaction with the world. This is obviously no longer true but the more important limitation (which you've also mentioned) is that this dialog needs to take up substantial screen space to be workable. I'm not convinced that you could easily use the existing junction toggle tool to configure a path while having it on screen in it's current form. I'm also not convinced that doing so is more intuitive than keeping the path configuration in the path configuration dialog.
It shouldn't be too difficult to make the dialogues a little more compact, you could use icons for the edit and delete links and you probably don't need to list the starting and ending signal names in full. In any case the dialogue can be moved aside or minimised.

If the dialogue is no longer modal and you have full access to navigation and junction controls don't you think that the average user is going to expect toggling the junction to do something meaningful if he is in path edit mode?


That said, the way the current system handles fixed track junctions is poor in a lot of circumstances. I see this as a separate issue, and I don't believe it's worth overhauling the interface to handle an asset type we'd probably prefer to phase out, especially now that we have procedural track junctions (even if they're also still somewhat of a work in progress).
At the moment procedural junctions can only handle simple points. I've not seen any statement as to if and when you plan to expand the system to include parametric diamond crossings, single and double slips or double crossovers. It will be a lot of work and it probably won't be your first priority. My fixed track junctions exist now and the code library is available for anyone else to use.

Now consider a double slip built with spline track. Your code will set the direct path through the four junctions involved but it won't automatically recognise that this is a double slip. You are relying on the user to understand that he needs to include the two junctions that are not on the direct path in order to avoid the existence of a conflicting route. So he has to include and edit four objects. Similar considerations will apply for double crossovers and for diamond crossings you have to rely on signals external to the path. That's a lot of editing even when the user fully understands what must be done.

My pre-built double slip does everything for you, graphically and in terms of coding. The Surveyor/Set Direction button sends a UserRequestToggle to the slip and the slip responds by moving to its next state and updating its levers and blades - it will never set conflicting internal paths and all related signals will update correctly as a side-effect. All that you need to do is to save the states of all four object nodes into the path specification.

On the other hand trying to set these objects up by editing the child nodes individually will be painful in the extreme and highly prone to error.

Setting paths interactively by toggling the junctions on the map can take care of this automatically. If you choose not to make this change can you please find some other way of dealing with my objects as a whole within the edit path dialogue.

andi06
October 27th, 2015, 06:12 AM
You might also consider:
1. Toggling the junctions from the dialogue to edit the path.
2. Using graphic icons for possible paths/states as an alternative to editing a list.

838

pguy
October 27th, 2015, 11:18 AM
Hi.

I agree with Andi that it would be easier for junction state to toggle between all available states ( left - right for 2 state junction / left - forward - right for 3 state junction ) than to select the state in a list.
two reasons for that :

- first, there are more 2 state junctions than 3 state junctions on routes, and there you change the target state with one click instead of one click to make appear the list, one click to select the target state and one click to confirm and close the list dialog ( so 1 click instead of 3 clicks )
- secondly, because for 3 state junctions you may need to click twice to toggle to the correct state, but 2 clicks are still quicker than the 3 clicks needed with the list.

Yes. You may think we are a bit lazy, but most of the current existing path rule (mutton's, brummfondel's, ... ) uses circular state toggling to set junction direction and when you have tested both methods, clearly you prefer toggling several times than selecting the target state in a list.

But that's only my opinion.

By the way, we have a little problem with these discussions about Interlocking Tower in this forum, as there are some threads in the Pionneer Council section (visible by only Pioneer Council members and not by trainzdev section member ) and we have this thread in trainzdev section (visible by everybody but limited to trainzdev member for discussion and so Pioneer council member can't react to post here ... ).
For future remarks or discussion on Interlocking Towers feature, should I use the pioneer council threads or the trainzdev thread to post the information ? or both, but I don't like the idea to make twice the same post ...

Regards.

Pierre.

andi06
October 27th, 2015, 11:55 AM
- first, there are more 2 state junctions than 3 state junctions on routes, and there you change the target state with one click instead of one click to make appear the list, one click to select the target state and one click to confirm and close the list dialog ( so 1 click instead of 3 clicks )

And if you were to count clicks for a fixed track double slip it would be a maximum of 3 clicks instead of 12. :)


By the way, we have a little problem with these discussions about Interlocking Tower in this forum, as there are some threads in the Pionneer Council section (visible by only Pioneer Council members and not by trainzdev section member ) and we have this thread in trainzdev section (visible by everybody but limited to trainzdev member for discussion and so Pioneer council member can't react to post here ... ).

Which would explain why I couldn't find the sample asset. It also occurs to me that Trainzdev members who are not also Pioneer Council members will not have seen the design documentation.

andi06
October 28th, 2015, 12:56 PM
Build 79135:

1. Object Outside Path Bug
It doesn't seem to be possible to add a fixed track junction as an 'Object Outside Path'. The external object selection list correctly lists all four nodes separately, but selecting any one of them adds only the base SceneryWithTrack object to the list and offers only one node for edit (who knows which one). Attempting to add another node from those which are still listed has no effect.

2. Signal Aspects
The Edit Path dialogue only seems to be able to recognise stop and go. Even if Proceed Right is actually showing on the map the dialogue shows Proceed. And surely the exit signals should be set to Automatic rather than Proceed.

andi06
October 29th, 2015, 01:57 PM
Build 79135 seems to have fixed the issues with Edit Session which is good news. As a side effect the fact that all Property Editor windows are no longer modal is a huge improvement - sincere thanks.

I've set up my own mini-route to have a play.

844

In the screenshot I've set up the junctions to define the path in red and then opened the Tower Dialogue and selected the start signal to save the path. This is actually far, far easier than trying to use the Tower dialogue itself to define a Path.

However if I then define a second path (marked in yellow) and open it in the Path Editor we have a situation where the game screen is showing whatever the Surveyor defaults are set to and the Path Editor is showing something entirely different (which in this case conflicts at every location). Edits to the path made in the Path Editor are not reflected in the game screen and vice versa.

This couldn't be more confusing.

The game screen and Path Editor really need to be kept in step and showing the same information until the Tower dialogue is closed, at which point the Surveyor defaults can be restored.

Are we going to be able to define a different path spline, possibly via a tag in the Tower config? - this one has all the subtlety of a bull in a china shop and obscures important detail like point blade directions.

andi06
October 31st, 2015, 06:07 AM
Bug 1
1. Define a path and add a couple of signals external to the path. Save the dialogue.
2. Delete the signals.
3. Reopen the tower dialogue, the path will be orange.
4. Edit the path and try to remove the missing signals, you will not be able to do so but you will generate script exceptions.
There is no easy way out of this short of deleting the entire path :).

Bug 2
The path selection UI is sometimes being shown at inappropriate times, such as here when a train has just completed a path and is travelling away from the tower area.

850

Note also that the last two signals are showing Proceed. This seems to be the default aspect for any signal on a path, irrespective of track layout. Shouldn't the path selection dialogue default to Stop or Automatic?

Application
With a combination of your tower script and my fixed track diamond crossings it is possible to set up an entirely automatic junction which will control its own signals and even derail the trains when a SPAD occurs.

849

andi06
October 31st, 2015, 07:22 AM
Bug
On return from a QuickDrive session including an interlocking tower, attempting to select a signal (in order to move it) provokes an immediate CTD.

I have a crashdump and map for this.

andi06
October 31st, 2015, 08:35 AM
Bug
Delete an Interlocking Tower asset from a session and then try to save the session, result is an instant CTD.

The more I play with this the more potential I can see but it needs work, and not just debugging.

The path editor is truly awful.

Keep an open mind and try setting up the same paths using my Signal Box asset <kuid:122285:75001> (which does exactly the same thing without the benefit of native code alterations and without messing up the signals) Having done that tell me that your path editor is fit for purpose.

You also need to review what the script is doing with signalling.

In the screenshot below I've set up two paths, one from A to C and one from B to C, using the default options in every case.
The train in the distance has used the path B-C, cleared the tower area and stopped.
The train in the foreground is just about to enter the path A-C.

851

Take a look at the state of the signalling and run for cover.

I'm going to get something to eat and watch the rugby, you can continue your policy of ignoring my input.

pguy
October 31st, 2015, 01:18 PM
Hi Andi and Terry (I hope you will see these posts as Tony has advised us to post technical remarks on Interlocking Towers in the trainzdev forum ... ).

About the GUI, I would be less severe than Andi. You will find below the links to 4 screen hardcopy of 1 : N3V SP1 Interlocking Tower, 2 : Another rule from me derived from Brummfondel's path rule and from early specs of Interlocking towers, 3 : Andi06's JK signal box on the same path (entry path from a double track to a multi platform passenger station route - that's only an example ... ) and 4 : Brummfondel's largely used path rule from TRS2004. I think looking and comparing these 4 images is quite interesting making some common display and some specific ones.

image 1 : https://www.dropbox.com/s/h7gsnh7dpyhmw3b/Interlocking%20Tower%20GUI%20Example%201.png?dl=0
image 2 : https://www.dropbox.com/s/63x0cy9hyevszne/Enhanced%20Interlocking%20Tower%20GUI%20Example%20 2.png?dl=0
image 3 : https://www.dropbox.com/s/16dfkg4ss9ln4vk/JK%20Signal%20Box%20GUI%20-%20Example%203.png?dl=0
image 4 : https://www.dropbox.com/s/6xpy8npte35f4z5/Brummfondel%27s%20path%20rule%20-%20example%204.png?dl=0

They have all their advantages and their disadvantages.

What I like in Brummfondel's rule, in N3V interlocking tower implementation, and sorry ... in my own implementation is the idea to have a start point (here a signal) and to follow the track discovering trackside objects along the path until an exit object ( a signal for N3V - any object in Brummfondel's ).
What I like in Andi's signal box implementation and also in Brummfondel's implementation is to use icons to toggle junctions and signals.
What I like in N3V Interlocking Implementation is to have a non modal dialog window and with a large screen you can see behind the dialog the path drawn in the surveyor window that helps's to verify the path is correct.

Because what is important in the GUI : it is to be easily able to verify the path you define is the one you want or that you have done a mistake on one junction direction. That's the key point.
Displaying the intermediate objects name on a path has no utility for the path definition, but in the GUI it helps the path creator user to check he is on the right path. If he wants do define a path to platform 1 and it is displayed that the current path arrives to some platform 4, he will know he has done a mistake. And with a few clicks and junctions toggle he will find the right path to define.

But I agree that for junctions direction and signal states an icon is better than some text and takes less size in the dialog, and ... does not need translation for foreigners ...

But Terry should not be surprised as it was what I have commented when a few months ago we reviewed the initials specifications in the Pioneer Council thread. And I remember he wrote me that some of my ideas might be implemented if there was some others people asking for the same thing. The only problem is that currently I have only seen Andi and me looking and giving our opinion on some in depth implantation details. I hope there are more than two Trainzers interested in future Interlocking Tower details, but I understand that for N3V it may be difficult to make their opinion from only two people.

Never mind, even if you like or not the current interface, the current good thing (and I hope it will not change) is that the implementation is opened and that it is quite easy to implement your own customer interlocking towers by subclassing both the interlocking tower and interlocking path classes.
It would be a pity to still have several interlocking towers as we have currently the opportunity to converge to a common one, but if people wants several GUI designs or several specific implementation that may be the right path to satisfy every one.

Outside the GUI interface, there are also a few technical problem I have identified :

- I don't really understand the interest to be able to enforce a signal state for the exit signal. As after you may have consist, I don't see how you can program a end signal to something else that automatic.

- There is currently a problem when you have train taking two successive paths from signal A to signal B, and then from signal B to signal C. When it request the second path, there is a script programmed error : Trains requesting a path while being on a conflicting path. The current system identifies that the second start signal is the same object as the exit first path signal and so rejects the request. The problem is that this situation is quite common in at least passenger stations where the incoming train will follow a path from some where to a platform in the station with the exit signal being the signal at the end of the platform. And of course this signal is also the starting signal for the path to go out of the platform station.
Of course I can put an invisible signal just a few meter before the signal at the end of the platform to have an end signal for the first path distinct from the start signal of the second path, but I don't like too much this trick. What would be nice would be to consider that for the same train a request for a path starting at the same signal than the end signal of the current train path is a valid request ...

I believe that there is also missing a driver command to cancel all the owned paths for the current train. This should be usefull when a train arrives at a platform and will leave in the reverse direction.

I have also tried to create and delete some paths under surveyor from another rule. What is surprising is that you can create and add your own path from script but you can't delete it. I may understand that you lock these functions to surveyor mode and do not authorize in driver mode to change some interlocking definitions, but I don't understand why in surveyor mode it should be limited to the standard interface and not opened to scripted rules.

That will be all for today. Hope this helps. I continue testing and trying some automated operations using interlocking towers.
By the way, I have still a question : I am using beta sp1 79029 on my mac. Is it the same functionality level than the last PC build ? Or would it be better that I wait I wait for a new beta for Mac in some weeks ...

Regards.
Pierre.

andi06
November 1st, 2015, 12:09 PM
What I like in N3V Interlocking Implementation is to have a non modal dialog window and with a large screen you can see behind the dialog the path drawn in the surveyor window that helps's to verify the path is correct.
All property editors have become non modal as a result of these changes. This is a big improvement because you can now see the game screen properly and you can also minimise the property editor while you change something else on the map and then come back to it later.


I hope there are more than two Trainzers interested in future Interlocking Tower details, but I understand that for N3V it may be difficult to make their opinion from only two people.
Since posting rights are restricted here perhaps any beta testers who have any relevant comments would send them to me via a PM, I will arrange to post them in this thread.


I don't really understand the interest to be able to enforce a signal state for the exit signal. As after you may have consist, I don't see how you can program a end signal to something else that automatic.
I think that, except in very special cases, signalling should probably be left to its own devices. There would seem to be little point in setting up signals of the right type in all the right places and then over-ruling them with potentially incorrect aspects.


There is currently a problem when you have train taking two successive paths from signal A to signal B, and then from signal B to signal C. When it request the second path, there is a script programmed error : Trains requesting a path while being on a conflicting path. The current system identifies that the second start signal is the same object as the exit first path signal and so rejects the request. The problem is that this situation is quite common in at least passenger stations where the incoming train will follow a path from some where to a platform in the station with the exit signal being the signal at the end of the platform. And of course this signal is also the starting signal for the path to go out of the platform station.
In cases like these and other end-of-track scenarios a train may stop within the path and reverse direction without ever clearing it while still needing to leave by a different route. Perhaps it could be solved by allowing some other object to act as an end-of-path, possibly a special trigger marker, and making it clear that there should be empty track beyond any defined path. Or else simply define the path as clear when a train clears the last object before the end signal.

As far as the editor is concerned I would suggest the following behaviour:


When the path editor is opened it should create a temporary array containing the IDs and current states of all of its included objects.
When any object is added to any path it is also added to this array.
When a path is opened for editing the path should be displayed on the game screen by changing the state of its objects to match the state of the dialogue and drawing the path marker spline.
When an object state is changed, either via the dialogue or by toggling junctions on the map, the game screen, the dialogue and the marker spline should all be updated to reflect the changes.
When the path dialogue closes, its data is saved and the temporary array used to reset the map to its original defaults.

Irrespective of how the Path Editor HTML is organised, this would have several advantages:


It would be absolutely clear to the user what route is being set and what the state of the included objects would be.
There would be much less need to look up the names of objects in order to select them from lists.
Scripted junction objects could be changed using their own interface and their state reflected in the dialog without the need for the path script to understand the junction scripts.

Mick_Berg
November 1st, 2015, 03:52 PM
Bug
Delete an Interlocking Tower asset from a session and then try to save the session, result is an instant CTD.

The more I play with this the more potential I can see but it needs work, and not just debugging.

The path editor is truly awful.

Keep an open mind and try setting up the same paths using my Signal Box asset <kuid:122285:75001> (which does exactly the same thing without the benefit of native code alterations and without messing up the signals) Having done that tell me that your path editor is fit for purpose.

You also need to review what the script is doing with signalling.



I tried to download your signal box and got this error;
- Alias mesh 'node0.im' not found in latest version of dependency <kuid:122285:79000> (<kuid2:122285:79000:3>)

Mick

andi06
November 1st, 2015, 04:22 PM
There is an error in config.txt, the entry for template1 in the mesh-table should look like this:


template1 {
mesh "node0.im"
mesh-asset <kuid:122285:79012>
auto-create 1
att "a.origin"
att-parent "default"
}

Mick_Berg
November 1st, 2015, 04:30 PM
There is an error in config.txt, the entry for template1 in the mesh-table should look like this:


template1 {
mesh "node0.im"
mesh-asset <kuid:122285:79012>
auto-create 1
att "a.origin"
att-parent "default"
}

OK, will fix.
Thanks,
Mick

andi06
November 2nd, 2015, 07:17 AM
For what it's worth, I would also advocate use of icons. Haven't done much beyond basics with ITs, but I can see some paths being extended long ways, esp thru shared lines. Icons would serve better here. Point to experience with Custom HUDs (Tr12 and before anyway), where icons ease monitoring over long schedules.

Auto naming paths
Its fine to create a name based on start and end signals as you are doing. However automatically renaming the path when either of these signals is changed will become an irritant. For example in a station throat paths are likely to be named Platform 1, Platform 2 etc and users will not thank you for altering these without asking.

pguy
November 2nd, 2015, 08:58 AM
Hi.

About path naming, what I would suggest is that the path naming adjustment to entry/exit signal should be limited to the first path edition (in fact the creation process which is also the first path edition) and also to the first rename on the path. So when you create a path, the name will be adjusted. If you rename it, it will stop adjusting and keep the renamed name you have chosen. And if you stop editing, it will also keep the current name with entry/exit signal at end of first edition.
This may look a bit more complicated (not so complicated to program ...) but it should bring both advantages to have some auto adjustment at creation and no longer changing the names without a user rename action later.

Regards.
Pierre.

JCitron
November 2nd, 2015, 12:00 PM
Hi.

About path naming, what I would suggest is that the path naming adjustment to entry/exit signal should be limited to the first path edition (in fact the creation process which is also the first path edition) and also to the first rename on the path. So when you create a path, the name will be adjusted. If you rename it, it will stop adjusting and keep the renamed name you have chosen. And if you stop editing, it will also keep the current name with entry/exit signal at end of first edition.
This may look a bit more complicated (not so complicated to program ...) but it should bring both advantages to have some auto adjustment at creation and no longer changing the names without a user rename action later.

Regards.
Pierre.

I agree this would make things easier for many people where they implement the towers for simple crossovers and diamond level-crossings. When it comes to stations, however, they would want, I'm sure to name their paths to whatever platform they are setting them up to such as track 1/platform 1, and so on.

John

pw3r
November 4th, 2015, 06:29 PM
Hi everyone,

Sorry for the long delay between posts, we've had various other things to work on and have been waiting for feedback from all sources to see what is and isn't working with SP1. I'm hoping to get into some bug fixing for the towers later today but it looks like I need more information on most of them. I would greatly appreciate it if you can reply here with extra information where required. Once I've sorted out the bugs I'll post again in relation to the design questions (hopefully today, but we'll have to see how things pan out).

Firstly, thanks for the bug reports with external objects not working correctly for fixed track, and not being removable if missing. I can easily reproduce those here and will hopefully fix them later today.



2. Signal Aspects
The Edit Path dialogue only seems to be able to recognise stop and go. Even if Proceed Right is actually showing on the map the dialogue shows Proceed.

I'm not sure I know what you mean here but I'm able to get the path edit interface to show any aspect supported by the signal, both as an option in the state list and the selected state in the dialog itself. Can you elaborate?


The path selection UI is sometimes being shown at inappropriate times, such as here when a train has just completed a path and is travelling away from the tower area.

I'm not able to tell from the information given what the steps might be to get it to show incorrectly. Can you provide a diagram of the movements perhaps? That is, assuming this is reliably reproducible. To be clear, the selection dialog should show at any point where a train enters the area of an entry signal (1km track search). No consideration is given to whether a train has already left a path, or is on another path with a different entry signal. The selection dialog should only be shown when moving toward the signal though, and when that signal is facing the train in question.


On return from a QuickDrive session including an interlocking tower, attempting to select a signal (in order to move it) provokes an immediate CTD.

I can't reproduce this. It's quite possible we've already fixed it but crash dumps should always be forwarded on by following the steps here (https://support.trainzportal.com/index.php?/Knowledgebase/Article/View/80/0/guide-to-submitting-a-crash-report-tane-sp1-beta).

I'll also be looking into the auto-naming semantics for the paths to make sure we prevent wiping of player-entered names when editing paths, and will be changing the default state for path entry signals to Automatic. Thanks for the feedback there.

Terry Palmer
Programmer
N3V Games

andi06
November 4th, 2015, 07:21 PM
I'm not sure I know what you mean here but I'm able to get the path edit interface to show any aspect supported by the signal, both as an option in the state list and the selected state in the dialog itself. Can you elaborate?
857
Given the layout above I have set the path in Surveyor and then opened the tower dialogue and pointed it at my start signal (A-Start)
As you can see the start Signal is showing Proceed-Right but the path editor is detecting Proceed.
Also the last signal (B-End) is showing Caution and the path editor is detecting Proceed, which can never be right because the signal after that is the end of the line.

True I can set any aspect which the signal supports, but shouldn't detection get it right without my help?

There is something else going on here which I've just noticed. On return from a path editing session spline junction levers are showing a mouse-over message 'Manual control is disabled for this junction lever' but the lever itself can still be operated. Fixed track junctions however are not responding to the Surveyor/Set Direction button and if I use the property dialogue to switch them I am provoking exceptions. Surely we should have manual control of all junctions in Surveyor - how else can we set or edit their default directions.



The path selection UI is sometimes being shown at inappropriate times,
Not happening at the moment - I will keep my eyes open.


I can't reproduce this. It's quite possible we've already fixed it but crash dumps should always be forwarded on by following the steps here (https://support.trainzportal.com/index.php?/Knowledgebase/Article/View/80/0/guide-to-submitting-a-crash-report-tane-sp1-beta).
Still happening in 79199.
I'm driving a path manually in Quickdrive, stopping the train and calling Main Menu/Exit Driver.
On getting back to Surveyor selecting a signal gives me a CTD.
I have a crashdump which I will send in.
If you need the map let me know via here.

pw3r
November 4th, 2015, 08:15 PM
Given the layout above I have set the path in Surveyor and then opened the tower dialogue and pointed it at my start signal (A-Start)
As you can see the start Signal is showing Proceed-Right but the path editor is detecting Proceed.
Also the last signal (B-End) is showing Caution and the path editor is detecting Proceed, which can never be right because the signal after that is the end of the line.

The path is not active, so there's no bug here. Sounds like a reiteration of the design suggestions mentioned elsewhere so I'll leave further comment for that discussion (hopefully in a few hours, unless something pops up).



There is something else going on here which I've just noticed. On return from a path editing session spline junction levers are showing a mouse-over message 'Manual control is disabled for this junction lever' but the lever itself can still be operated. Fixed track junctions however are not responding to the Surveyor/Set Direction button and if I use the property dialogue to switch them I am provoking exceptions. Surely we should have manual control of all junctions in Surveyor - how else can we set or edit their default directions.

I can't reproduce this one either. The tower should never take ownership of objects in Surveyor so I can't see how it would happen. If you can provide any extra steps that would be great.

There has been one signal ownership crash fix since 79199 so it's possible that's what you are hitting, but submit the crash dump anyway.

Terry Palmer

pw3r
November 5th, 2015, 12:35 AM
Afternoon all, I've made several fixes for the bugs identified in this thread which should be in the next SP1 beta build, so look forward to that.

Beyond that, I'll address a couple of questions here first, then make another post to open up the discussion for the design of the path creation/edit interface.


Are we going to be able to define a different path spline, possibly via a tag in the Tower config? - this one has all the subtlety of a bull in a china shop and obscures important detail like point blade directions.

I don't mind the current splines but I am all for hearing (or seeing) recommendations of how they might be improved. If someone out there can create better spline assets to replace the current defaults then I'll happily update them (and do my best to make sure our artist isn't too offended in the process ;))

That said, there are no plans to have this set from a config tag, and personally I think these should be standardised so I'm not in favour of adding one. It is possible to customise them per-tower but you'd currently have to do it in script.


I have also tried to create and delete some paths under surveyor from another rule. What is surprising is that you can create and add your own path from script but you can't delete it.

I'm not sure what you might be looking at there, as we provide no direct interface to either add a path from script or delete one (i.e, no InterlockingTower.AddPath() function). That said I can see one fairly obvious/safe way to do both, and a fairly dodgy way to also do both. I don't imagine either will be blocked but I think the process will generally be "frowned upon" as we don't want to encourage a situation where there are a dozen different interfaces for path creation out there. Especially if their support varies based on which Interlocking Tower asset you use, or worse yet which signals, or which session rules.


I believe that there is also missing a driver command to cancel all the owned paths for the current train. This should be usefull when a train arrives at a platform and will leave in the reverse direction.

This should be entirely automatic, within the currently supported actions. Requiring this to be a separate Driver Command basically means that the Driver/Tower AI is failing at it's job. The obvious limitation here is that you cannot cancel a path while the train is still occupying it, so the driver would either need to have left the path by the time they stop at the platform, or will need to drive forward out of it before they can reverse back down.

This is a known and intentional limitation but if people think it's too restrictive then I'm open to ideas of how to remove it without adding to the risk of derailment, etc. My thinking is that we would want to force the train in question to be completely stationary and not on top of any path objects, at a bare minimum. Any movement from the train before the path cancellation/activation cycle completes would then likely need to throw both paths into panic mode, along with any conflicting paths, if not the entire tower.

Terry

pguy
November 5th, 2015, 04:09 AM
...
I'm not sure what you might be looking at there, as we provide no direct interface to either add a path from script or delete one (i.e, no InterlockingTower.AddPath() function). That said I can see one fairly obvious/safe way to do both, and a fairly dodgy way to also do both. I don't imagine either will be blocked but I think the process will generally be "frowned upon" as we don't want to encourage a situation where there are a dozen different interfaces for path creation out there. Especially if their support varies based on which Interlocking Tower asset you use, or worse yet which signals, or which session rules.
...
Terry

Hi Terry.

Well, in fact when you announced Tane and Interlocking tower stretch goal, I had a new centralized path routing rule nearly finished (and now finished and working) , but as Interlocking Tower were coming I decided not to release it (current status private and not uploaded to DLS) and wait to see how to adapt it to the new context.

The main difference with your Interlocking Tower is that this centralized rule has been initially designed for creating a path route through several stations, sidings, and other stop points and a lot of kilometers. With the availability of Interlocking Tower it should evolve to become more a tool to define and create a succession of several path in several local area interlocking tower. It has a GUI interface to define the global route quite similar to your path GUI interface : the two main difference is that it displays for all the objects along the path route its distance from the start of the path route to help the creator to understand how long is its path route, and it also displays the trackmark and industries/stations along the path to help the path route creator to also understand where he is going.

What I was trying to do was to keep this rule with its current interface (quite so similar to your path GUI interface, that people won't be disturbed) and having a link in this path route interface to generate for all Interlocking Tower Entry signal along the route the corresponding path in the Interlocking tower. For example, if I have a global path route between two far away destinations crossing let say 6 interlocking area, then with a simple click it will generate the 6 or more paths needed in each interlocking tower area. And that's the reason why I am looking on how to create a path in an Interlocking Tower from a script rule. That's of course is only done under surveyor, and is currently possible, I think using a clean and safe way, by calling your CreatePath() function in the InterlockingTower object, and then creating the adequate InterlockingObjects to add to the returned empty path.
But when later I need to edit the path route ou delete its definition, then I may need also to come back to my underneath local paths in each local interlocking tower to either edit the path (quite simple to reload the new interlocking objects definition) or to delete it and ... that where I was surprised that if you have the CreatePath public interface, you don't have its counterpart a DeletePath public interface (of course only available in Surveyor mode).

But that's not very important, because to solve this problem, I have already created my own InterlockingTower object by subclassing yours and writing the needed DeletePath as an extension provided by the new EnhancedInterlockingTower subclass of your own InterlockingTower.
I really appreciate the open interface of your objects, as I see that much of the problems I find with the standard InterlockingTower can be easily solved by subclassing the standard objects and either writing in the new class some extensions or rewriting a procedure to override the standard one (and of course calling the inherited one to benefits from all what has been already written).
If I post currently some wishes, that not because we are now near Christmast, but because I believe that these enhancements can also benefits to standard users if implemented in the standard interlocking tower as I already know I can do the work needed in my own third party rules and driver commands.

I think that the main question about all these suggestions (mines, Andys, other's, ... ) is to find the limit between something of general interest and much needed for the standard Interlocking Tower and common users, or if it is a more specific needed behavior that interest only a small community of advanced users and that should be implemented in third party enhanced interlocking towers using subclassing techniques.

I should also congratulate Terry and the Interlocking Tower development team about the quality of their code : I have looked deeper in it, and I have found that the code is clean, easy to understand with or without comments and I should say that I am now retired after 33 years of software development in the electricity generation industry and that most of the programmers I had in my successive teams were not so good to deliver such a clean code ... so congratulations for that. It helps subclassing and only implementing the adds needed ...

Regards.
Pierre.

pguy
November 5th, 2015, 05:01 AM
...
This should be entirely automatic, within the currently supported actions. Requiring this to be a separate Driver Command basically means that the Driver/Tower AI is failing at it's job. The obvious limitation here is that you cannot cancel a path while the train is still occupying it, so the driver would either need to have left the path by the time they stop at the platform, or will need to drive forward out of it before they can reverse back down.

This is a known and intentional limitation but if people think it's too restrictive then I'm open to ideas of how to remove it without adding to the risk of derailment, etc. My thinking is that we would want to force the train in question to be completely stationary and not on top of any path objects, at a bare minimum. Any movement from the train before the path cancellation/activation cycle completes would then likely need to throw both paths into panic mode, along with any conflicting paths, if not the entire tower.

Terry

Hi again Terry. This time about the problem of a train reversing at station.

I have done a little schema to help understand my concern. Sorry for the child quality of my drawing, but I am not good at all at drawing ...

860
On the schema, you have a dual track route arriving at a station. My train, driving on left (like in France), will encounter signal S1, junction J1 right, and arrive a the station platform. It will then reverse direction, and return back through signal S4, junction J1 left, junction J2 left and next signal on the main track.

To protect this via Interlocking Tower I define a first path Entry signal S1, junction J1 right, exist signal S2 (at the end of the platform). After reversing, I will use another path with Entry signal S4, junction J1 left, Junction J2 left and exit signal the next signal on the main track.

The problem is that when the train stops at the station, it does not have finished its path as it will never go across signal S2 (exit signal) as it will reverse before. And the second path starting in the reverse direction at S4 will never be accepted as it has a conflicting junction at J1.

To enable this type of operation, what I was thinking was to have a driver command to cancel the current path just before or after the train has reversed direction, as it will never go behind S2. But that may be not the correct solution.
I can also put an invisible signal at the beginning of the platform to be used as the exit signal for the first path, but I don't like too much the idea of adding some invisible trackside objects to solve a problem. It looks more like a dirty trick to overcome a true problem.
The best, but may be a bit difficult to implement, would be to consider a path where the last junction has been passed but not the exit signal as a special case, where for the train in this special situation a request for a new path will be accepted and will cancel the first path ...

I am interested Terry in how you think we deal with such a situation in a clean way.

I believe my situation will be often encountered at interchange passenger stations, where to protect trains arriving and leaving the stations you will have arriving paths to the platforms with in general the exit signal at the end of the platform. And those signals at the end of the platform are also in general the entry signals for leaving paths from the station.

Hope theses explanations make my problem more clear.

*** EDIT ***

There is also another way to solve the problem : it would be to introduce an additional clear path option which would "Clear path after last junction". In such a path with this clear after last junction option, the interlocking tower will return all the path objects to their return state when the last vehicle in the train has left the junction (when the message "Junction,Leave" is sent from the lat junction to the train). With that option the initial path is closed when the train arrives to the station, and so it can obtain the second path after reversing.

This option may have also its interest when the exit signal is too near the last junction. in such a case (that should not exist in real life ?) the last junction may be liberated after passing the exit signal and it is better to liberate the path only after the last junction is liberated than earlier ...


Regards.
Pierre.

andi06
November 5th, 2015, 09:11 AM
I don't mind the current splines but I am all for hearing (or seeing) recommendations of how they might be improved.
It was a purely practical comment. The current splines prevent you from seeing the junction blades or the junction node numbers on my scripted objects. I will knock something up.


The obvious limitation here is that you cannot cancel a path while the train is still occupying it, so the driver would either need to have left the path by the time they stop at the platform, or will need to drive forward out of it before they can reverse back down.
That's all vey well unless the path end signal is also the end of a track - you can't ever clear the path in that case and it will be quite a common case. The obvious answer (to me at any rate) is not to allow a path to terminate at end-of-track.

Signals
Perhaps I'm misunderstanding what you are doing here but I would have thought that if the map is properly signalled all signals should be on automatic all of the time except for the start signal, which you should be keeping at red if the path ahead is occupied. If you accept the default assignments you end up with the situation shown in the picture in this post. (http://forums.auran.com/trainz/showthread.php?123689-Interlocking-Towers-Side-Effects&p=1454045#post1454045)

andi06
November 5th, 2015, 09:23 AM
http://forums.auran.com/trainz/images/misc/quote_icon.png Originally Posted by andi06 http://forums.auran.com/trainz/images/buttons/viewpost-right.png (http://forums.auran.com/trainz/showthread.php?p=1455329#post1455329)

There is something else going on here which I've just noticed. On return from a path editing session spline junction levers are showing a mouse-over message 'Manual control is disabled for this junction lever' but the lever itself can still be operated. Fixed track junctions however are not responding to the Surveyor/Set Direction button and if I use the property dialogue to switch them I am provoking exceptions. Surely we should have manual control of all junctions in Surveyor - how else can we set or edit their default directions.

I can't reproduce this one either. The tower should never take ownership of objects in Surveyor so I can't see how it would happen. If you can provide any extra steps that would be great.
Opening the same map in Surveyor for a fresh session the tower is still taking ownership in Surveyor.

Furthermore if I delete the tower and try to save I get a CTD.

Re-opening after the crash provokes a DB rebuild and the tower is still there. I will try to re-create this with a new map tonight.

[Edit: I can't reproduce this myself at the moment. That is I can't get it to happen on a new map and I can't stop it happening on the old one. Someone else did post elsewhere with a similar problem though]

andi06
November 5th, 2015, 06:14 PM
I'm not seeing Junction,Toggled when a Tower changes a junction state, are you suppressing it in these cases?

Without this message, or a substitute, I have no way of updating the blades and levers on my scripted junctions. I can't see any messages from the Tower system that I could sensibly intercept for this purpose.

pw3r
November 5th, 2015, 06:32 PM
That's of course is only done under surveyor, and is currently possible, I think using a clean and safe way, by calling your CreatePath() function in the InterlockingTower object, and then creating the adequate InterlockingObjects to add to the returned empty path.

It's very important to point out that the CreatePath() function does not add a path to the tower, and nor should it. CreatePath merely creates and initialises a path, then returns it. CreatePath() is nothing more than a standardised location to create an InterlockingTowerPath so that custom tower scripts can create a custom path implementation (e.g. a 3rd party scripter would override CreatePath to instead create CustomInterlockingTowerPath).

It is not intended to add paths to the tower, and if it were modified to do so (in a custom tower implementation) then that tower would likely break under some scenarios (ending up with useless/unused paths internally).


But when later I need to edit the path route ou delete its definition, then I may need also to come back to my underneath local paths in each local interlocking tower to either edit the path (quite simple to reload the new interlocking objects definition) or to delete it and ... that where I was surprised that if you have the CreatePath public interface, you don't have its counterpart a DeletePath public interface (of course only available in Surveyor mode).

The safer method I was referring to to add/delete paths would be to use InterlockingTower.GetTowerPaths(). Due to the way Trainz script works with arrays, this function is returning the internal path array by reference. I.e. The returned array isn't a copy, and can therefore be modified to affect the tower itself.

The dodgy/unsafe method I was talking about would be to exploit the SetProperties function, but this definitely makes for less clean code and is probably more likely to introduce compatibility problems.


But that's not very important, because to solve this problem, I have already created my own InterlockingTower object by subclassing yours and writing the needed DeletePath as an extension provided by the new EnhancedInterlockingTower subclass of your own InterlockingTower.

This is exactly the sort of thing I'd like to avoid, as it creates the situation where to use your rule the player must use your towers (or at least towers that support your interface). This does two things, it confused players (e.g. "Why does this tower work with this rule when this one doesn't?"), and it fragments the community (e.g. "I don't like Pierre's rule, I'm not going to have my tower support it").

I'll open the tower script up today and improve the comments on CreatePath to make it's usage clearer. I'll probably also add AddPath and RemovePath functions. If only as an effort to avoid the issues mentioned above as not everyone will realise you can exploit the array reference as mentioned, and even those that do will probably agree that it's not the nicest approach.

Terry

pw3r
November 5th, 2015, 08:04 PM
That's all vey well unless the path end signal is also the end of a track - you can't ever clear the path in that case and it will be quite a common case. The obvious answer (to me at any rate) is not to allow a path to terminate at end-of-track.

You're quite right, and it's also similar to the problem that Pierre has been describing with conflicting paths around stations, and to an extent even the justification for allowing forced green signals at the end of paths.

One thing I will say is that just because a session uses Interlocking Towers, doesn't mean that you need to create paths for every possible track destination or every stretch of track. It is entirely expected that a route which fully supports Interlocking Towers will have large sections of track that are not under the control of any tower. Such sections will either use the existing signalling system (main lines away from any junctions being the obvious example here, as the towers add no benefit to such track), or may be entirely unsignalled (a small yard for example, which may have a forced green exit signal to allow trains into it).

Having a path which leads a player down a dead end stretch from which they cannot return may seem like it has no use, but if that's the point where the session ends then it's quite possible people will want to do it. So really this is just a session design question.



The best, but may be a bit difficult to implement, would be to consider a path where the last junction has been passed but not the exit signal as a special case, where for the train in this special situation a request for a new path will be accepted and will cancel the first path ...

I'm not in favour of special cases like this. They're too confusing for the player/session-creator to understand, and difficult to maintain in script as well. I would much rather create a single safe way to cancel a path while it is occupied (as described earlier).


Opening the same map in Surveyor for a fresh session the tower is still taking ownership in Surveyor.

Furthermore if I delete the tower and try to save I get a CTD.

I suspect what's happening here is an old bug, which should not be an issue for newly created sessions. What will have happened is that at some point (due to a bug) the tower will have taken ownership of objects within Surveyor, and then that route has been saved. So now, all of the objects are saving/loading that ownership into the route/session. Newly created routes/sessions should hopefully not exhibit the problem.

Thank you for the explanation though, as I think you've just accidentally provided the necessary information that was missing in order for us to reproduce that crash.


I'm not seeing Junction,Toggled when a Tower changes a junction state, are you suppressing it in these cases?

Without this message, or a substitute, I have no way of updating the blades and levers on my scripted junctions. I can't see any messages from the Tower system that I could sensibly intercept for this purpose.

We're not suppressing it and it should be firing in this case. I've had a quick look here and it seems to be working fine, both for class Junction, and the scenery with track junctions.

Terry

S301
November 6th, 2015, 04:02 AM
I have a small one that may be necessary to get the signalling at Lilydale to function with interlocking (Without it, it would not be possible to use the interlocking towers as it will lock junctions that aren't part of the interlocking)

There are a great many 'disc' type signals at Lilydale. The function of these is to indicate that the junctions (points) are set, and will be set to 'proceed' even if the track ahead is occupied (as in the case of sidings in a goods yard, you need to be able to enter these tracks to collect, or drop off, wagons).

Could we have an object that marks the 'end' of a track circuit block, rather than a signal, so as to support this. Or some way to set a signal as 'shunt', and then use a junction as the 'end' (so set the turnouts up to a certain point beyond the signal). I would prefer to not have to use an invisible signal in the middle of the yard. :)

This may give some more explanation of what I'm looking at: http://www.signaldiagramsandphotos.com/mywebpages/vr/Metropolitan/53'19.GIF

It's the diagram for the prototype, and the signalling is set out exactly the same as this, except for a 'clone' of signal '7' on the track marked 'No 3'. Take a look at the signal marked '2' at the left hand end of the diagram, and you'll see a small 'disc' signal with the text 'From Main Line to No 3 or 4'. Basically this signal tells the driver that the junctions from the mainline up to the last 'double slip' (the one that leads to either no 3 or 4 roads) are set. That last double slip is controlled by levers next to the junctions, and hence isn't part of the interlocking. However, in TANE, the interlocking is extending beyond this location to the next available signal. So instead of setting up just the 4 necessary paths into the station, I have to setup potentially 9 paths to just enter the yard, since 'No 3' doesn't have any signals until you reach the buffers for each track that is accessible from it.

As above, my other option is to add an invisible signal immediately after the junction that for 'No 2 road'. However, I would prefer to not have to add invisible signals (as I've been repeatedly told that this shouldn't be done) :)

EDIT: Another thought, could we use the 'reverse' side of an existing signal to mark the end of the track block?

To give an idea of one of the similar 'issues' I'm facing on this route is pathing out of the station yard.

http://www.zecrail.com/files/tane/TANE%202015-11-06%2020-31-46-36.jpg

This is through some pretty horrible pointwork (from a players point of view), and hence the interlocking tower makes it super easy. However, the next signal (in this case) is a long way off at the entry to the next major yard. The interlocking shouldn't apply to this distance, as the next interlocking tower would be controlling the signal that the current path 'ends' at. The yellow arrow indicates the 'distant' signal (literally the outer limit controlled by this interlocking tower), and the red arrow indicates the 'home' signal for trains arriving into the yard (heading towards the camera in this view).

Heading the other direction out of the yard, the interlocking is taking control of a set of points outside of the yard (they aren't protected by any signals, and aren't controlled by any 'interlocking tower' type setups - in reality they were unlocked using the train staff/token, so didn't need to have any signals since only one train could use that track section at a time), and is then taking control of the signal at the next station (which again would be under the control of that station's interlocking). If we ignore the next station's signal, and just look at the path to leave Lilydale (heading south west/toward Mooroolbark), I need to setup a minimum of 25 paths for trains to be able to leave. This is 1 path for each of the 5 tracks in Lilydale that can access the mainline (we'll ignore the 3 dead end sidings here - they'd need further paths as well though), with a path for the mainline to Mooroolbark + a path for each of the dead end sidings at Cave Hill quarry (which aren't even part of the interlocking, but that this system will take control of anyway).

In the end, unless your station has a 'departure' or 'starting' signal, it's not going to be possible to setup a path to leave the station... :(


Regards
Zec

andi06
November 6th, 2015, 07:16 AM
http://forums.auran.com/trainz/images/misc/quote_icon.png Originally Posted by pguy http://forums.auran.com/trainz/images/buttons/viewpost-right.png (http://forums.auran.com/trainz/showthread.php?p=1455436#post1455436)

The best, but may be a bit difficult to implement, would be to consider a path where the last junction has been passed but not the exit signal as a special case, where for the train in this special situation a request for a new path will be accepted and will cancel the first path ...

I'm not in favour of special cases like this. They're too confusing for the player/session-creator to understand, and difficult to maintain in script as well. I would much rather create a single safe way to cancel a path while it is occupied (as described earlier).

I think that it is wrong to consider this as a special case at all, consider this:

862
Once the train has reached the position shown in the screenshot the Tower should no longer have an interest and the path should be considered clear. Nothing that happens on the path can possibly affect the aspect of DS1 and at this point there is no reason why the Tower should not allocate another train on a path through J1 to DS2. There is also no reason why the train in the shot shouldn't turn around and use a path through J1 in the opposite direction, assuming that it is signalled and properly defined.

DS1 might be required in order to visualise a path and to give it an initial name but it has no real functional reason to be included in the actual path specification and having it there is the root cause of these issues. You might include it as an additional 'path_destination' field in the path data record but ignore it in practice.

If the functional path array ends at J1 all of these end-of-track problems will go away, and it also becomes possible to use DS1 as the starting signal of another forward path without having to deal with any conflicts.

pguy
November 6th, 2015, 08:31 AM
I think that it is wrong to consider this as a special case at all, consider this:

862
Once the train has reached the position shown in the screenshot the Tower should no longer have an interest and the path should be considered clear. Nothing that happens on the path can possibly affect the aspect of DS1 and at this point there is no reason why the Tower should not allocate another train on a path through J1 to DS2. There is also no reason why the train in the shot shouldn't turn around and use a path through J1 in the opposite direction, assuming that it is signalled and properly defined.

DS1 might be required in order to visualise a path and to give it an initial name but it has no real functional reason to be included in the actual path specification and having it there is the root cause of these issues. You might include it as an additional 'path_destination' field in the path data record but ignore it in practice.

If the functional path array ends at J1 all of these end-of-track problems will go away, and it also becomes possible to use DS1 as the starting signal of another forward path without having to deal with any conflicts.

I think there is 3 ways to solve the above problem, and other problems of the same type I raised or Zec (S301) has also raised :

- the first one, is to accept that a path can end also at a junction and not only at an exit signal. This means to add in the GUI the "end here" link on all the junctions items and not only on signals. And I don't think it has much other consequence as it does not change anything to the rest of the logic in the path. The path will be still cleared when the last object, in that case the last junction is leaved from.

- the second one, is to keep going from signal to signal, but to introduce a new clear method of type "Clear after last junction". That will have the same behavior than the previous case, but you will have a dummy exit signal, not really used, but owned and you can enforce its signal state while the path is taken by a train.

- the last one, is to change nothing and have a driver command capable of releasing the current path though it is not complete. No change to the interlocking tower, except supporting this new driver command. And if session creator can easily add this driver command to their AI scheduled train, you will need to explain to manually driven train that when the stop and reverse they need to execute this driver command by inserting it in the order bar. Or you will need to add something in the hud buttons that you can click to cancel the current path.

I think I have listed the 3 solutions in my preference order. I leave Andi and others react to give also their preference or to propose other solution. But there is something sure, we need at least that one of this solution is implemented to make operations like above work.

Regards.
Pierre.

pguy
November 6th, 2015, 08:55 AM
...
This is exactly the sort of thing I'd like to avoid, as it creates the situation where to use your rule the player must use your towers (or at least towers that support your interface). This does two things, it confused players (e.g. "Why does this tower work with this rule when this one doesn't?"), and it fragments the community (e.g. "I don't like Pierre's rule, I'm not going to have my tower support it").

I'll open the tower script up today and improve the comments on CreatePath to make it's usage clearer. I'll probably also add AddPath and RemovePath functions. If only as an effort to avoid the issues mentioned above as not everyone will realise you can exploit the array reference as mentioned, and even those that do will probably agree that it's not the nicest approach.

Terry

Hi Terry.
I totaly understand the need for new third party rule using interlocking tower functionalities to take care of supporting both standard interlocking tower and custom interlocking tower to avoid confusion and fragmenting the community and I will be very vigilant in my future rules to this point.
This said, I still believe many trainzers ask for some easy solution to schedule timetabled trains along some global path on a route, and that a solution can be brought by developing some third party tool in a session rule that will generates the interlocking paths needed and will also at run time be a listener to choose the right path for the timetabled train when they arrive to one of the interlocking tower path generated.
And if you accept to include in the tower public interface an addPath and removePath function, I think we will have all what's needed to develop some nice and cool rules above the interlocking towers for global path routing with local interlocking path generation.

Regards.
Pierre.

andi06
November 6th, 2015, 05:43 PM
It was a purely practical comment. The current splines prevent you from seeing the junction blades or the junction node numbers on my scripted objects. I will knock something up.
How about something like this, which also gives you the path direction and makes it possible to see the junction blades and other indicators.

863

Found Junction,Toggled by the way, the object I was using to look for it doesn't respond to the message. :o

@Pierre: I would favour terminating all paths at the final junction/non-signal object because I believe it could be used in all situations and would be reasonably intuitive.

JCitron
November 6th, 2015, 09:12 PM
I've been a quiet observer in this thread, like many other overly technical scripting ones due to my lack of experience and didn't want to take the subject off topic like a kid interrupting a meeting and saying "I like pizza!". I also wanted to see the direction the "experts" in this stuff were going before I stumbled in with something.

But looking at this from a user's perspective, I can see that, the Interlocking Towers are a great idea but the implementation is poor. They are really overly complicated for what they do, and a new Trainz user will definitely be put off by them. As they stand now, they should be listed under an advanced assets tab - to be used only by expert route builders.

The interface should be unified to work like the other Trainz user interfaces for setting up sessions and drivers, industries, freight commodities and so on. Instead of putting everything in one blob of text, how about implementing a more click to add-type interface which uses the mini-map? The user can simply click on the first signal, the last signal, and a path is set. Once the paths are set, the user then can configure them in the IT interface, which should have icons to represent the paths and signals.

Now the paths bring up another situation which bothered me and probably will annoy others. The created paths should remain on the track until the IT interface is closed. The current implementation, where they disappear once created, is confusing because the user may not remember which path was set already, and then will have to click through the list and then build a mental list or write stuff down on a piece of scrap paper to keep track of the junctions, signals, and their names. The present interface is okay for a couple of crossovers or for protecting a diamond crossing, but this can become quite complex it the towers are setup to control a passenger terminal or large goods yard with multiple sidings, through tracks, an engine terminal, bad order track (broken wagons are put there for repair later), ready tracks, and the rest of the storage tracks. Perhaps the yards are smaller elsewhere, but here in the US, mostly in the Midwest, there are some really large and very complex yards such as the North Platte, Nebraska (NE).

http://visitnorthplatte.com/attraction/union-pacific-bailey-yard/

or may some of the larger yards in the Greater Chicago area such as Blue Island, Proviso and others.

http://wikimapia.org/#lang=en&lat=41.634626&lon=-87.646866&z=14&m=b

Looking at these maps, I think that no one could implement these as the current interface stands, or if they do it would be a feat similar to running a marathon as it would be very prone to errors and other problems as the paths are set. I get quite fatigued thinking about this!

Path settings and junction settings could be shown by icon. A reversed junction (switch), meaning one that's been set off the main line either right or left, and could be indicated by a left or right junction icon. The image could be similar to what we have now in the old HP Custom HUD.

So I thank you for letting me put in my 2-cents here. Hopefully some of these things can be taken into consideration and make this something that everyone including the expert route and session builders can enjoy.

John

Dap
November 6th, 2015, 10:15 PM
As above, my other option is to add an invisible signal immediately after the junction that for 'No 2 road'. However, I would prefer to not have to add invisible signals (as I've been repeatedly told that this shouldn't be done) :)

EDIT: Another thought, could we use the 'reverse' side of an existing signal to mark the end of the track block?


I mentioned this same idea - using the 'reverse side' of an existing signal to mark the end of a track block (in a post on the Pioneer Council forum). That is how is done on the prototype. Why would we not use it in Trainz? For a simple grade crossing or diamond, one of the most basic track diagram for an interlocking tower in the US, it makes a lot of sense. And it must be the end of the train, not the locomotive that releases the block. In my testing of a diamond, the end of the train always released the block on one track of the diamond, but always the locomotive released the block on the other track.

I'd also like to see a switch on the Interlocking Tower build panel in Surveyor that will turn on and off the graphic yellow line that shows the route. If each route that is created had this switch, it would make it a lot easier to check your work and make sure that you have done what you thought you did.

David

pguy
November 6th, 2015, 11:25 PM
Hi John.

For a standard Trainz session user ( not a session creator nor a script writer ) there is something important that Interlocking Tower brings : AI driver trains and manually driver train will now follow the path defined and will no longer maunder through an unattended siding or elsewhere. I think that we were many to complain about the poor efficiency of the previous AI engine and so we should be very happy to have now some standard tool from N3V to define some paths and to have an AI engine that will choose and follow then the right path without wondering about if there is not a raccourci through a siding or industry plant ... And all our technical discussions to improve the GUI and optimize the work to define a path may overshadow that Tane SP1 should be the first trainz implementation where, with some help, AI trains will no longer divagate ...

Yes that means some work, and sometimes not so easy, when creating sessions to define the right path before taking its benefit. But what is very nice in the underneath implementation is that the standard AI driver commands DriveTo, NavigateTo, DriveToTrackmark, NavigatoToTrackmark, ... and in fact any driver commands that uses the underlying standard script navigation interface will benefit from interlocking tower path without any change. For example my driver commands DriveTo/NavigateToStation will benefits from Interlocking Tower without any change and I did not expect it would be so easy ...

For those interested, at the low level, N3V AI has not changed : the initial standard command will build a list of successive junctions, trackmarks, ... in fact all intermediate destination to go through to reach the target destination, and ... with the same usual pitfalls ... But what is smart in the Interlocking implementation implementation is that when the AI train arrives at an interlocking tower entry signal, if there are several paths available from this entry signal, the path manager will look in details to these initials intermediate destination and will find and choose between all the paths the path that enables to reach the next target destination and then the AI will follow the choosen path even if it has nothing common with the initial AI choice. Interlocking path management has been designed to use the initial and sometimes crazy AI information but with a very efficient method to choose paths taking care of the AI target destination but dynamically dropping the errors in the initial AI choices.

I have done several tests as only a user of the system, and it is a true pleasure to see the trains with the same AI driver command than before, follow now finally the path you define and you can change in surveyor in the tower, instead of its proper instinct which was mainly the shortest way on the route with a privilege for going left at the junctions ... through sidings, industries and whatever you will find as a a raccourci ...

And I think there is also another benefit not visible for standard users : to enable Interlocking Tower, N3V has made a few modifications and enhancement to existing script interface and has added a few ones. A few weeks ago, in another thread I complained that there was a missing interface to retrieve the AI default route, to look at it and enhance it for some easy timetabled route. For the needs of Interlocking, these missing interfaces are now available in scripts and this opens the opportunity to build above AI and Interlocking some cool rules tomorrow. From what I have seen, we can work to be able from a starting point and a destination point on the route, to ask the standard AI to return us its first routing proposition, then we can look at it in details, identify the interlocking areas where we will pass and finally generates the driver commands needed when we are outside interlocking area and rely on the interlocking towers when we are inside interlocking area to avoid the old AI pitfalls. And you need to define paths only when it is needed, not on everywhere on the route.

There is still a lot of work to do, but I believe that we have now the bricks to build some cool rules to build easy timetabled schedule for trains with only few information needed from the end user. Less information to give for the end user, a lot of work to implement this for rule scriptures, but ... that's fine : that's what I like in Trainz and i am now retired for 2 years and so have more time to design and implement a few more cool rules for the community.

And everything we can enhance in the Interlocking GUI will help, so that is why current technical discussions on how to enhance initial implantation is important.

Sorry for having be a bit long.

Regards.
Pierre.

Dap
November 7th, 2015, 12:11 AM
Pierre,

I'm not seeing the same results. On testing trains on a small route with a grade crossing, at times, if an AI train had to wait to get access through the interlocking tower, it would start to back-up and look for another route. I think AI still needs some fixes, such as no backing. AI needs to learn that waiting for a green signal is not a reason to back-up and look for another route if it is on a well designed route and in a well designed session.

David

PS: sounds like you are enjoying retirement ! ! ! Looking forward to seeing more of your cool stuff.

andi06
November 7th, 2015, 06:48 AM
http://forums.auran.com/trainz/images/misc/quote_icon.png Originally Posted by andi06 http://forums.auran.com/trainz/images/buttons/viewpost-right.png (http://forums.auran.com/trainz/showthread.php?p=1455329#post1455329)
There is something else going on here which I've just noticed. On return from a path editing session spline junction levers are showing a mouse-over message 'Manual control is disabled for this junction lever' but the lever itself can still be operated. Fixed track junctions however are not responding to the Surveyor/Set Direction button and if I use the property dialogue to switch them I am provoking exceptions. Surely we should have manual control of all junctions in Surveyor - how else can we set or edit their default directions.


I can't reproduce this one either. The tower should never take ownership of objects in Surveyor so I can't see how it would happen. If you can provide any extra steps that would be great.
I can now reproduce this at will but I can't pin down the exact point at which the problem is occurring.

1. New map, place a fixed track double crossover, a tower object, track, train and signals.
2. Define a couple of paths through the object.
3. Go to quickdrive and drive manually through the paths.
4. On return to Surveyor the FT junction is now permanently 'owned', even when the route is exited and re-loaded.

andi06
November 7th, 2015, 06:52 AM
Bug

866867

Your track searches are not correctly recognising trackside objects placed on top of SWTs.

In the first example there is a signal between two child junctions, in the second there are point motors (simple scenery-trackside objects) placed adjacent to the nodes.

If any of these objects are present when an attempt is made to define a path, the attempt fails with 'Track Loop Detected'. If they are placed afterwards the path acquires an error state as shown in the shots.

pw3r
November 9th, 2015, 02:40 AM
Hi everyone, just a few more quick progress updates.


Now the paths bring up another situation which bothered me and probably will annoy others. The created paths should remain on the track until the IT interface is closed.


I'd also like to see a switch on the Interlocking Tower build panel in Surveyor that will turn on and off the graphic yellow line that shows the route. If each route that is created had this switch, it would make it a lot easier to check your work and make sure that you have done what you thought you did.

Having all of the path visualisations always active is obviously going to make it very difficult to see what one is doing in edit mode, but this is otherwise a great idea. I've added individual buttons on each of the paths, along with a quick "show/hide all path displays" link. This should make it much easier to get an overview of the paths configured on the tower.


I can now reproduce this at will but I can't pin down the exact point at which the problem is occurring.
...

Thanks for the extra information. I've now managed to reproduce and fix this issue.


Your track searches are not correctly recognising trackside objects placed on top of SWTs.

Also fixed for the next build, thank you.

In terms of the path conflict/clearing issues my preference is certainly either or both of:


A method to allow path deactivation while occupied.
Allowing path termination at a non-signal object or back-facing signal.

Option 1 would solve Pierre's reversing train problem but would require an extra interface so isn't ideal (I still think a Driver Command for this purpose is too obtuse). I don't believe it would solve Zec's example though, as we would still need to keep any conflicting paths inactive for safety reasons. Option 2 with a back-facing signal would seem to be the safest and most logical solution as it ensures that the path is still safe, preventing entry back onto the cleared path. Allowing path termination at a junction (or any other non-signal object) does not come with this same safety guarantee, and in fact if the train reversed back over the cleared junction it could derail IRL.

Furthermore, if we restricted the path edit interface to only showing this final back-facing signal (i.e. not all back-facing signals) it only adds one more line to the path definition table, keeping it from becoming too long and unwieldy.

Terry Palmer
N3V Games

andi06
November 9th, 2015, 10:35 AM
Back facing signals sounds fine in general. The only situation that this may not cover is an end-of-track siding condition with no signalling in the reverse direction.

Minor Bug
In the attached you can see that despite plenty of width the HTML is chopping off the child index values. Perhaps you should put the index at the front as in:
[1] Double Crossover .....

871

Junction Configurations
Pierre seems to have a handle on the wider uses of the system so I've been looking in detail at how it deals with some common track configurations. I'm basing most of this on SWT objects but many of the comments apply to the same thing built in spline track.

For a double crossover there are three valid overall configurations: Using the numbers on the screenshot these are 1-3 [/], 0 -2 [\] and 1-2 + 0-3 [||].

The configuration [||] should allow two simultaneous paths to be allocated but I can't get this to happen in Driver either with splines or with an SWT. It may be due to the system still being a little flaky or, in the case of the SWT it may be because both path definitions include all four nodes. I can't see why you are doing this since the path 1-2 only actually involves nodes 1 and 2. It may be necessary to include the other nodes as Objects Outside Path but there is no need to have them on the path itself.

In addition to this I don't see why you are listing the nodes in numerical order rather than the order in which they are encountered in the path itself. Doing this just adds to the difficulty for the user in working out what is happening.

I've looked at your code in as much detail as I can and I simply can't see any reason why it can't accommodate my scripted objects or any other objects which have surveyor based scripted relationships (such as linked junctions) Instead of sending SetDirection(1) to the junction you just need to send UserRequestToggle(1), listen for Junction,Toggled to check for side effects and update the editor accordingly.

If you were doing this a user setting a path starting at Node 1 would be able to switch the entire object between [||] and [/] by clicking once the link for node 1. As things stand there is a considerable amount of headscratching to establich which node is which before directions can be selected.

Lastly, for a spline based configuration and assuming that the path 1-2 is set, the user might want to add 0 and 3 as Objects Outside Path to ensure that the state [||] would be selected. If this were to be done would that prevent the Tower from simultaneously allocating the path 0-3?

pguy
November 9th, 2015, 09:43 PM
...

In terms of the path conflict/clearing issues my preference is certainly either or both of:



A method to allow path deactivation while occupied.
Allowing path termination at a non-signal object or back-facing signal.


Option 1 would solve Pierre's reversing train problem but would require an extra interface so isn't ideal (I still think a Driver Command for this purpose is too obtuse). I don't believe it would solve Zec's example though, as we would still need to keep any conflicting paths inactive for safety reasons. Option 2 with a back-facing signal would seem to be the safest and most logical solution as it ensures that the path is still safe, preventing entry back onto the cleared path. Allowing path termination at a junction (or any other non-signal object) does not come with this same safety guarantee, and in fact if the train reversed back over the cleared junction it could derail IRL.

Furthermore, if we restricted the path edit interface to only showing this final back-facing signal (i.e. not all back-facing signals) it only adds one more line to the path definition table, keeping it from becoming too long and unwieldy.

Terry Palmer
N3V Games

Hi Terry and other readers.
I clearly understand that you want to find some solutions to the problems I raised inside InterlockingTowers and paths themselves without any outside commands or other solution. To fulfill this target, I think there is something missing in the current tower and paths class which is to know if in its progression a train has reached and leave the last junction before the exit signal.

Why we need this indicator ?

When a train has reached and left the last junction, if for any reason you have to cancel the path, it no longer matters that when canceling a path you restore junctions and signals to their previous states. As the train as passed the last junction, restoring the previous state junction will have no consequence on it and for the signals, as generally they will return to automatic state the signals will detect the train position and will display the correct signal state needed. And even if you restore an enforced signal state, as it was enforced it does not matter. So this indicator has for me a great interest : it tells that a train has sufficiently progressed along its path to a situation where cancelling a path is safe.

There are several usage for this SafeForCancel state : first if the train reverses and request a new path, you can check this indicator and if it is true then you can examine the new path request and if it is fine, you just cancel the previous path and assign the new one. If the indicator is false, you reject the new path request. And this solves the reversing problem I raised.

It solves also two other problems I now identify but I have not already posted in this thread about.

The second one is quite the same as the reversing problem. The train stops a the platform with an exit signal at the end of the platform and then leaves forward (no reversing) but need to set a new path for leaving the platform in the same interlocking tower. Currently, the system does not accept that a new path have an entry signal which is the same signal as another path exit signal. In this situation, the paths definitions are accepted, but at run time the two path are considered as conflicting because they have a common signal though two successive path with the end signal of the first path being the entry signal of the second path is not really conflicting. And this is also a quite common situation, where you will use an InterlockingTower to protect a station traffic incoming and outgoing and often incoming path to some platform will have an exit signal at the end of the platform being the start signal of the outgoing path ...

If you have the SafeForCancel indicator implemented, then it will be set to true when the train arrives at the platform leaving the last incoming path junction before the platform, and as the indicator is set you can accept a new request to go forward using the second path starting at the previous path end signal. Again, when the SafeForCancel indicator is set, on a new path request you can accept the new request and cancel the unfinished previous one.

There is also another benefit of such an indicator which is to help solve a common user error that may occurred. I have done this error and believe many others can do it. If you place your exit signal too short after your last path junction, if you have a very long train consist, you may have a situation where the train reaches and passes the exit signal while the last train vehicle has not already left the last junction. and what currently happens if you make this mistake : as the exit signal is reached and passed, the InterlockingTower clears the exit signal and cancel the path, the junctions returns to their previous direction and if the last junction returns to another previous direction than currently the path direction that was set, you change the junction direction with a vehicle on it and your train derails ...

And this SafeForCancel indicator can also help in this case. As the last junction has not been left, the indicator will be false, and when there will be the attempt to clear the exit signal, by looking to this indicator you can see it is too early to cancel the path and return the junctions to their original state, and you will defer canceling the path. And later when the last vehicle will leave the last junction, the message leave from the junction will be trapped, and the UpdatePathState handler will retry to clear the exit signal and this time with success. This indicator is a usefull help not to clear the path too early.

I also think this SafeForCancel indicator is not too complicated to compute : it should be set to false when a path is established. And in the junction leave message processing, you only need to check if it is the last junction inside the path, and if it is the case you just set this indicator to true in the adequate AttemptPathObjectClear handler post processing.

And with this indicator you have an elegant solution for at least the three problems raised above.

Sorry for having been so long. I hope I have been a bit persuasive and not too heavy on this topic. Of course, you can also use the other solution with finishing the path with a back signal as an exit object, but you still need the SafeForCancel indicator to check you don't reach the exit back signal before you left the last junction. And why not offer both solutions : path with either exit signal or exit back signal, and with a SafeForCancel public indicator to avoid releasing the path too early and to enable auto-path cancel on a new path request. This time you solve all the problems, except the Andi's end of track siding with no signaling in the reverse direction. But Andi, that's surely exist but is it a good signaling practice ?

Regards.
Pierre.

pw3r
November 9th, 2015, 10:21 PM
Minor Bug
In the attached you can see that despite plenty of width the HTML is chopping off the child index values. Perhaps you should put the index at the front as in:
[1] Double Crossover .....


This is true, but the same is also true of other path objects with long names, and that's even more of a problem. Moving the fixed track junction index may 'solve' the problem, but the items are printed in order so it's not adding any new information anyway. In the current internal build the full name is also shown in the mouseover tooltip, I'm not sure if that's the case in the current beta.


The configuration [||] should allow two simultaneous paths to be allocated but I can't get this to happen in Driver either with splines or with an SWT. It may be due to the system still being a little flaky or, in the case of the SWT it may be because both path definitions include all four nodes. I can't see why you are doing this since the path 1-2 only actually involves nodes 1 and 2. It may be necessary to include the other nodes as Objects Outside Path but there is no need to have them on the path itself.


Lastly, for a spline based configuration and assuming that the path 1-2 is set, the user might want to add 0 and 3 as Objects Outside Path to ensure that the state [||] would be selected. If this were to be done would that prevent the Tower from simultaneously allocating the path 0-3?

Thanks for the observation. You're quite right that this problem existed both for normal junctions and fixed track junctions, and there was no reason for either. I've improved the checking for path conflicts to allow both paths to be active simultaneously, you should see this fix in the next beta build.

Terry

pw3r
November 9th, 2015, 11:49 PM
When a train has reached and left the last junction, if for any reason you have to cancel the path, it no longer matters that when canceling a path you restore junctions and signals to their previous states. As the train as passed the last junction, restoring the previous state junction will have no consequence on it and for the signals, as generally they will return to automatic state the signals will detect the train position and will display the correct signal state needed.

This is not true, as nothing in any of these systems prevents the train from reversing backwards down the track. Consider the following simple case:

http://forums.auran.com/trainz/attachment.php?attachmentid=878&stc=1

Imagine an Interlocking Tower path from Signal 1 to Signal 2, which clearly includes a 'final junction', Junction 1. In your scenario you would allow the path to be cancelled while occupied provided the train had cleared Junction 1. This could flip the junction state, allowing that train to stop and reverse backwards down a potentially unsignalled line to god-knows-where. You may argue that a signal placed before or after the junction could easily prevent this, but it is not the job of Interlocking Towers to scrutinise your signalling set-up.


Currently, the system does not accept that a new path have an entry signal which is the same signal as another path exit signal. In this situation, the paths definitions are accepted, but at run time the two path are considered as conflicting because they have a common signal though two successive path with the end signal of the first path being the entry signal of the second path is not really conflicting.

This was nothing more than an omission in the conflicting path tests, and one that has already been addressed. Such configurations will work correctly in the next beta (see my last post above).


If you place your exit signal too short after your last path junction, if you have a very long train consist, you may have a situation where the train reaches and passes the exit signal while the last train vehicle has not already left the last junction. and what currently happens if you make this mistake : as the exit signal is reached and passed, the InterlockingTower clears the exit signal and cancel the path, the junctions returns to their previous direction and if the last junction returns to another previous direction than currently the path direction that was set, you change the junction direction with a vehicle on it and your train derails ...

This is clearly a bug. Thank you for brining it to my attention, I'll address this immediately but I'm not sure if the fix will make it into the next beta.

Terry

pguy
November 10th, 2015, 04:10 AM
This is not true, as nothing in any of these systems prevents the train from reversing backwards down the track. Consider the following simple case:

Imagine an Interlocking Tower path from Signal 1 to Signal 2, which clearly includes a 'final junction', Junction 1. In your scenario you would allow the path to be cancelled while occupied provided the train had cleared Junction 1. This could flip the junction state, allowing that train to stop and reverse backwards down a potentially unsignalled line to god-knows-where. You may argue that a signal placed before or after the junction could easily prevent this, but it is not the job of Interlocking Towers to scrutinise your signalling set-up.

Terry

I understand now that in your design the path is bi-directional : as long as the train owns the path, it can go forward or backward along the path set. Sorry, but in my own mind a path was uni-directional and so when you had left a junction you never go back in it. But that's a question of design and choices and I fully respect that N3V's made some choice that are not the ones I am used to.
I have still a difficulty in your approach to understand what is then the meaning of the "CLEAR_ON_DRIVE" path clear methods. In my understanding, when you choose the CLEAR_ON_DRIVE method, the junctions returns to their initial state as soon as the train has left the junction, and so ... I don't see in this case the possibility for reversing or going backward, but I may have misunderstood what is CLEAR_ON_DRIVE clear method ...


This was nothing more than an omission in the conflicting path tests, and one that has already been addressed. Such configurations will work correctly in the next beta (see my last post above).


That's really good news as in my sessions I have a lot of trains that follows successive paths where the end signal is very often the start signal on the next path, and in station it is always the case with an incoming path followed by an outgoing path ...


This is clearly a bug. Thank you for bringing it to my attention, I'll address this immediately but I'm not sure if the fix will make it into the next beta.


You are welcome. All what I test, try, think and sometimes in another way are only to help to have better standard Interlocking Tower in the final release. And every TrainzDev people are doing the same in their own preferred Trainz area ... Mine is more in automated and AI operations so I am very interested in having some nice and efficient Interlocking tower.

So from what all we have discussed, the only thing that remains is about reversing at a station to take another path, and the solution would be to have the initial path have as exit object a back signal at the beginning of the platform, so that the path is cleared when the train stops at the platform. And then it can reverse direction, and leave the station using another path. Well if it is implemented this way, I believe it can answer most of the reversing cases needed for my transit operations ...

As Mac Tane build are quite always a bit delayed after the PC version, I believe I should see many enhancement in Interlocking Towers are in the next Mac beta SP1 build, when it will be available ...

Regards.
Pierre.

andi06
November 10th, 2015, 04:18 AM
This is true, but the same is also true of other path objects with long names, and that's even more of a problem. Moving the fixed track junction index may 'solve' the problem, but the items are printed in order so it's not adding any new information anyway. In the current internal build the full name is also shown in the mouseover tooltip, I'm not sure if that's the case in the current beta.
A tooltip solves the identification issue.

However I still think that printing the child nodes in the order in which they are encountered in the path (rather than numeric order as now) would be of enormous assistance in helping the user to sort out which node is which.

pw3r
November 11th, 2015, 12:47 AM
I understand now that in your design the path is bi-directional : as long as the train owns the path, it can go forward or backward along the path set. Sorry, but in my own mind a path was uni-directional and so when you had left a junction you never go back in it. But that's a question of design and choices and I fully respect that N3V's made some choice that are not the ones I am used to.

The path is neither bidirectional or unidirectional by design. It does have an explicit direction, and it is my expectation that paths will mostly be driven from start to finish in that one direction, but it is not something you can guarantee and there is no reason to assume that is what a session creator will always want. There's also the AI to consider, which may decide to turn around at any given point it thinks it found a shorter path.


I have still a difficulty in your approach to understand what is then the meaning of the "CLEAR_ON_DRIVE" path clear methods. In my understanding, when you choose the CLEAR_ON_DRIVE method, the junctions returns to their initial state as soon as the train has left the junction, and so ... I don't see in this case the possibility for reversing or going backward, but I may have misunderstood what is CLEAR_ON_DRIVE clear method ...

No, that's exactly right. It's there because that's how some Interlocking/Signal towers work in the real world, so we provide the option for that behaviour. If you wanted to use such a tower in your session then it would be up to you to also employ additional methods to prevent backward travel (which I assume would include extra signalling/signage/instruction, more fine grained AI commands, track direction markers, etc.

Terry

andi06
November 11th, 2015, 09:44 AM
It seems that all signals are now being automatically named by the game (tag autoname 1) Would it also be possible to automatically add surveyor-name-label 1? This would make identification of signals a lot easier from inside the path editor.

Dap
November 11th, 2015, 12:04 PM
. . . There's also the AI to consider, which may decide to turn around at any given point it thinks it found a shorter path.


With all this enhanced signaling and routing control, there should be some way to turn off the AI's urge to turn around and look for a shorter path. I've always found this characteristic of AI to be a pain in the behind!

David

JCitron
November 11th, 2015, 12:30 PM
With all this enhanced signaling and routing control, there should be some way to turn off the AI's urge to turn around and look for a shorter path. I've always found this characteristic of AI to be a pain in the behind!

David

Yes! An AI driver's thinking, as if they really have a mind and can think, I've waited long enough so I'll try another route and go tie everything up on the other end of the mainline.

And... The other painfully stupid thing they do is check junctions to see if they're free which causes signals to jump from red to green, red to green, and the levers to keep flipping. I think this is the cause of some of the derailments we see all too often because this might catch another train that's crossing over that junction to catch the points in the wrong position.

John

pguy
November 11th, 2015, 12:50 PM
... There's also the AI to consider, which may decide to turn around at any given point it thinks it found a shorter path. ...
Terry

As you can see in the previous posts, that is not the most popular thing the AI can do as it is not at all prototypal. I know that N3V is reluctant to change some defaults because it can break some existing sessions, but I think that if we had in the Train game object class a public flag to enable/disable AI going backward when it waits at a signal and a driver command to set/reset this flag it would be a great enhancement as session creators would be able to choose the AI behavior they want about going backward or not when the train is stuck ... And of course the default would be the current behavior not to brake any existing session, but for new session session creators can make another choice ...

Regards.
Pierre.

andi06
November 24th, 2015, 07:04 AM
Now in Build 79551
Bug ???

I'm working on updated scripting for UK Colour Light Signals. These scripts now play entirely by the rules and seem to work more or less correctly when used in conjunction with Interlocking Towers. However one of my colleagues who is testing these assets has seen these exception screens.

897898

One of these signals <kuid2:122285:82013:1> is implicated. However this script doesn't have a ModuleInit handler and is not calling SetSignalStateEx directly (with or without a null Security Token) The exception seems to be in the Tower Script. Any idea what is going on here?

andi06
November 24th, 2015, 07:32 AM
I was hoping to be able to make a positive comment here for a change.

Thank you for adding labelling to the signals and changing junction setting from a list to a toggle, these are worthwhile improvements, but I still don't understand just why you think it is OK for the path editor to take up quite so much screen space when the text font is so small and spidery and the dialogue is still chopping off crucial information. No doubt Pierre will comment that using words rather than symbols for direction indication doesn't help non english speakers.

The dialogue is now just about usable for really simple layouts with spline junctions but it still falls apart totally for SceneryWithTrack junctions.

899

For this double crossover the objects which should be in the path definition are:

1. AJS Sig 4A BR Post Std LHS 32
2. Protrack Double Crossover 10 x 3.5 1 junction 1
3. Protrack Double Crossover 10 x 3.5 1 junction 2 (which is a trailing junction)
4. AJS Sig 4A BR Post Std LHS 17

Would you please explain why:

1. You are throwing in two junction nodes which are not in the path being set.
2. You are still chopping off the child node index numbers.
3. Your spline indicator is still obscuring both the blade directions and the node index indicators on the junction objects.

Similarly with a double slip:

900

Would you please explain just how any normal human would be able to sort this mess out?