Continuation of TRS19 SP1+ASB (Post #268 on "TRS19 SP1 Now LIVE") Jan 16 2020

deneban

User ID 71964 (2001)
Continuation of TRS19 SP1+ASB (Post #268 on "TRS19 SP1 Now LIVE") Jan 16 2020

Hi Boat,

Deleted the :5 controller, did a database rebuild, added :5 again, and no difference. Deleted & rebuilt the cache folder & no difference. Also used the ASB prefix in the search. The list comes up blank very quickly, does not appear to be waiting on anything, it makes up its mind in the blink of an eye there are no signals. I see there is a new library added in SP1 called "asyncobjectsearch.gsl" which somehow sounds applicable to searching for objects, like signals. The regular object find finds these signals no problem.

Also can you think about why the pre-existing signal assignments made from an earlier TRS19 build disappeared. And what Trainz resource supplies the signal list.

The system has not changed since the ASB's were assigned and working.

Signals-Missing.jpg

Annotation-2020-01-16-143329.png


Surprised you are getting this. It tests OK on Sabino Lake with my SP1.

Signals not showing has usually been down to a Trainz Timeout. When you assign a signal it looks at all the signals on the route. In some cases this can take too long and Trainz will shut the search down. The result is a blank return. The workaround is to use the 'Signal Search Filter'. Type in part of the name of signal you want. This reduces the amount of signals it searches and speeds it up.
You could try that and see. Maybe it depends on the speed of your system?

Oddly though SP1 seems less prone to this by my tests. It could be my new computer but even the ECML is returning all signals without the need for a filter.

Try re-installing ASB Crossover and doing a database repair?

Boat

I went to open a session with a couple of <kuid2:76656:70001:5> ASB Crossover Controllers (latest version) only to find in SP1, trains are blowing the diamonds passing through each other (aka colliding) as if the controllers were not there. Opening the controller properties revealed the controller forgot its assigned signals.

Not only that, ASB Controllers can no longer retrieve the signal list for the route (see graphic). Tried getting a signal list in Kickstarter County 2 and Lake Sebino, and same result: no signals. Adding a new named signal to the route or typing in an existing signal name had no effect. (p.s.My ASB signals are on the same layer as the controllers)
 
Last edited:
Hi Daneban,

I'm not sure how to proceed with this as its OK on my set-up. However I am seeing some issues with my ASB Turnout in SP1.

I'm going to be taking a look at that. Maybe it will shed some light onto the Crossover problem too. I don't expect a quick-fix.

Sorry I can't be of more help.

Boat
 
Hi Boat,

I disabled SLI (dual graphics card) and no difference. I also tried to slow everything down by running a simultaneous simulation, but as before, the signal dialog box comes up already satisfied there are no signals to list. Also tried versions 3 and 4. If you look at my blog, my project is basically running traffic to ASB controllers from portals, so ASB functionality is critical to it.

I am certainly at your disposal to try out any troubleshooting ideas you may have while your looking at ASB turnout.

I think the key to figure out my problem if you could think about what could remove the Controllers from knowing what their previously assigned signals were? Where is that data stored when the session is saved; and how is it retrieved; and is it re-verified when the session is reloaded?

Secondly, given that the dialog box races right to the conclusion there are no signals to list, please think about what could pass this portion of your code to blow by and terminate without listing the signals. (I am a vb.net programmer and not a C+ programmer, so it is a little difficult for me to follow):

Code:
    string[] GetPropertyElementList(string property) {
         int i,ii,ast,filtcount;
        bool miss;
         string[] asts = new string[0];
        string[] filtered = new string[0];
        string[] ExNames = new string[0];
        string name;
        Signal[] signals = World.GetSignalList();
            ExNames = Str.Tokens(exsigs,",");
            for (i = 0; i < signals.size(); i++){
                name = signals[i].GetLocalisedName();
                if (filter) {
                    int n = name.size();
                    if (n>3 and name[n-filt.size(),n] == filt or name[0,filt.size()] == filt) filtered[filtcount++] = name;
                    }
                    else {
                    filtered[filtcount++] = name;
                    }
                }
        for (i = 0; i < filtered.size(); i++){
                miss = false;
                name = filtered[i];
                for (ii = 0; ii < ExNames.size(); ii++){    
                    if (ExNames[ii] == name) miss = true;
                    }
                if (miss) continue;
                if (name and name.size()) asts[ast++] = name;
                }
        return asts;
    }
 
Last edited:
Hi Boat,

I have confirmed that this problem does not occur in a clean install of 105096. So has N3V QA .

Now for my process of elimination study...
 
Last edited:
Hi deneban,

I have been looking at some of the problems with ASB Turnout which may be shared with ASB Crossover.

It seems that there is a known problem with scripts not running in Surveyor which could explain a lot of issues when setting up. See https://forums.auran.com/trainz/showthread.php?156507-Script-anomaly-in-TRS19-SP1

However, I agree that should not effect pre-saved routes. There may be something else going on.

Signal names are saved as 'MainNames' and 'CrossNames' in GetProperties. Then restored in SetProperties.

PHP:
public void SetProperties(Soup soup) {
        inherited(soup);
        int i;
        channel = soup.GetNamedTagAsInt("channel",0);
        msize = soup.GetNamedTagAsInt("msize",0);
        csize = soup.GetNamedTagAsInt("csize",0);
        filt = soup.GetNamedTag("filt");
        filter = soup.GetNamedTagAsBool("filter",false);
        for (i = 0; i < msize; i++){
                MainNames[i] = soup.GetNamedTag("main"+i);
                }
        for (i = 0; i < csize; i++){
                CrossNames[i] = soup.GetNamedTag("cross"+i);
                }
        if (channel > 0 ) WholeName = MyName + channel; else WholeName = "OFF";
        if (filt == "") filt = "ASB";
        UpdateMain();
        UpdateCross();
        }


 public Soup GetProperties(void) {
           Soup soup = inherited();
        int i;
        soup.SetNamedTag("channel",channel);
        soup.SetNamedTag("msize",MainNames.size());
        soup.SetNamedTag("csize",CrossNames.size());
        soup.SetNamedTag("filt",filt);
        soup.SetNamedTag("filter",filter);
        for (i = 0; i < MainNames.size(); i++){
                soup.SetNamedTag("main"+i,MainNames[i]);
                }
        for (i = 0; i < CrossNames.size(); i++){
                if (CrossNames.size()) soup.SetNamedTag("cross"+i,CrossNames[i]);
                }
        return soup;
        }

'asyncobjectsearch' is the new way to search for objects. My ASB's have yet to be updated to the new methods but the old search methods although obsolete are still supported in TRS19 for the time being. The saving of signal data by their name will also have to be modified to new GameObjectId methods. So far, I have only updated ATLS to those new methods. That took me 6 months! Its a job on the list but not one I can do if Surveyor is not working as it should.

One main problem is that I wrote my ASB scripts at least 10 years ago. So I have to try and work out how it works. And if anybody tells you, you will have more spare time when you retire, don't believe them. I had more time for Trainz when I was working!

I have a strong suspicion we may have to wait for a Trainz hotfix but I'll try and look some more later in the week.

All the best,

Boat, (Mike)
 
Hi Mike,

Thanks for looking into this and following up. In the interim I can work on isolating the difference between my data folder and a pristine SP1 data folder to see whats causing the malfunction.
 
Hi Mike,

On a related matter, I am seeing my Clickety Claks are not skinning properly and have missing faces after the SP1 install.

clickety-clack.jpg
 
Hi Mike,

A minor low priority ATLS issue for you to look at in the long term.

Starting a session where all the ATLS Controllers are named seems to still trigger no-name warnings when the session starts. Here there are 3 warnings each for controllers that have names:

NoName.jpg


ATLS4.jpg

ATLS7.jpg
 
Last edited:
Hi Dene,

Yes, sorry about the Clickety Clack issue. Down to my Gmax, (or lack of them) skills. I was aware of it but since they are invisible in Driver I haven't bothered updating them.

The 'no name' warning is odd. I will look into that. It should not happen.

By the way, its difficult to tell but it looks like you are still using the old style Slaves, Slave(TF) 'kuid2:76656:500012:14'. These may soon become obsolete. I am having some odd issues with them in TRS19 SP1.
I strongly suggest you change them for the new method 'ATLS Slave Trigger TRS19' kuid2:76656:500040:1
The old Slave(TF), although using TRS19 calls is there for legacy reasons and the few crossings which need it. It still uses an invisible train which is not good.

The new style Slave '500040' is a Trigger asset so you may need to add a short piece of invisible track to put it on. A few crossings will not work with it but it should be future proof. Don't expect '500012' to work in the next version of Trainz!

Boat

PS - Did the no-name warning come on all Controllers or always just the 2 shown?
 
Last edited:
By the way, its difficult to tell but it looks like you are still using the old style Slaves, Slave(TF) 'kuid2:76656:500012:14'. These may soon become obsolete. I am having some odd issues with them in TRS19 SP1.
I strongly suggest you change them for the new method 'ATLS Slave Trigger TRS19' kuid2:76656:500040:1
The old Slave(TF), although using TRS19 calls is there for legacy reasons and the few crossings which need it. It still uses an invisible train which is not good.

The new style Slave '500040' is a Trigger asset so you may need to add a short piece of invisible track to put it on. A few crossings will not work with it but it should be future proof. Don't expect '500012' to work in the next version of Trainz!

Thanks, I see the website was updated last Winter, going to read the new docs.

PS - Did the no-name warning come on all Controllers or always just the 2 shown?
Out of 7 ATLS controllers, as many as 2 to 4 come up with the no name upon Quick Drive; also the multiple citations per controller are common. Can't find any pattern as to it behaving differently each Quick Drive.
 
Last edited:
Hi Mike,

Thanks for looking into this and following up. In the interim I can work on isolating the difference between my data folder and a pristine SP1 data folder to see whats causing the malfunction.

Hi Mike,

I found the culprit on the ASB signal listing code.

When one uses the "maximise performance" in their compatibility mode on the dev tab of Settings, somehow execution blows by your code like it wasn't there. Switching back to "Maximise Compatibility" solved the issue.

I don't see any documentation on this setting yet, the new setting dev tab is not even in the Wiki.

Perhaps this serves as a warning to recode in the long term because compatibility modes tend to fade with time.

Thanks so much for your help!

(Oh PS: Can you add an ASB Controller reset (active in Driver) on the controller or as a Driver Menu add-on next ASB update? - Thanks)
 
Last edited:
Hi Mike,

I found the culprit on the ASB signal listing code.

When one uses the "maximise performance" in their compatibility mode on the dev tab of Settings, somehow execution blows by your code like it wasn't there. Switching back to "Maximise Compatibility" solved the issue.

I don't see any documentation on this setting yet, the new setting dev tab is not even in the Wiki.

Perhaps this serves as a warning to recode in the long term because compatibility modes tend to fade with time.

Thanks so much for your help!

(Oh PS: Can you add an ASB Controller reset (active in Driver) on the controller or as a Driver Menu add-on next ASB update? - Thanks)


Oh Joy!

I must admit I didn't even test ATLS in 'Maximise Performance' Mode. ATLS has been tested in Compatibility and Streaming mode. I'm trying to update ASB Crossover for TRS19 at the moment so will check 'Performance' too.

Mike
 
Hi Mike,

Hi Mike, ...

(Oh PS: Can you add an ASB Controller reset (active in Driver) on the controller or as a Driver Menu add-on next ASB update? - Thanks)

Is there any glimmer of hope for this?

Also I responded back to your question yesterday in the first of two responses, not sure if you saw the first one.
 
Yes, saw the first one about ATLS false reportrs. Thanks, I'll look into it.
I'll see if I can do a re-set. It will need to be used only at the correct time or there will be problems!

Still stuggling to convert ASB Crossover to all the new TRS19 calls yet. It will be a while!

Mike
 
Yes, saw the first one about ATLS false reportrs. Thanks, I'll look into it.
I'll see if I can do a re-set. It will need to be used only at the correct time or there will be problems!Mike

Hi Mike,

Re: ASB -- Maybe re-set was too strong of a word, it only needs to set the main signals to green (when both sides are stuck on red) and clear the trigger status. Its ok if there is an initial collision when this proposed feature is used in getting things back to normal.

Re: ATLS -- Some feedback - Replaced the old slave plus integral track with the new trigger slave at one crossing in my project, which outputs to 2 BNSF50 gates and your traffic stoppers. I kept the old controller, which you publish as still a viable asset. The result was continuously alarming gates, throughout the passage of the train over the triggers, even though the BNSF50 assets were configured to only annunciate when the gates are moving down and up. I believe the gates are being sent a repetitive trigger signal for the duration of the train passing over the on-rail triggers, this because there was a slight pause between the repetitions. Using the older slave with the same settings had yielded the expected gate operation (only alarm on down and up motion).

The specific configuration was as follows:
  1. 8 on-rail triggers set up for 2 way running in LCM on 2 parallel tracks (500016:13)
  2. Old stand-alone controller (500010:14) receiving trigger signals and outputting to the slave trigger (500040:1)
  3. Slave trigger placed on "AJS Track Eraser" track (2:122285:1003:2) with one gate (2:39134:102036:2) and one stopper upstream and one gate and one stopper downstream
 
I see the issue you are getting. Interestingly it seems OK set to Mode 1, (bells on close only). Also I notice that using the old Slave the gates close after a short delay. Using the new Slave the gates close straight away as soon as the lights flash.

ATLS only sends out one command at the start and a clear at the end. I think the problem is that BNSF50's script was designed to be triggered by a train on the track. With the new Slave its being triggered by script. This works the barries OK but the bells responded to a 'train enter' message. This I artificially send from teh Slave...... But its not working completely with the crossings script.

Its the best you will get short of a crossing script change. Or carry on using the old Slave until that becomes obsolete.

Sorry not better news.

Mike
 
Thanks Mike,

I certainly appreciate you taking the time to review my case in detail.

I will revert to the old slave in that case and await your revisions. Unlike you, I wasn't getting any bells at all in mode 1 of the BNSF50 crossbucks.
 
Back
Top