Some configuration settings for Passenger Stations not saved in TRS22.

[FootplatePhil]

I'm hoping someone can help me work out a problem I am having with AJS Station configuration. I use AJS Station 1x50s <kuid2:122285:3330:21> and AJS Station Library <kuid2:122285:3499:23> in TRS2019 without any issues. However when I import my TRS19 route into TRS22 the station configuration data is lost, and the parameters (ie, Peak Periods, Departure Rate, Initial Count, Platform Length) revert to their default values. Even when I correct the parameters in TRS22 and save, and save the session and route, the parameters are not saved. In TRS22 the configuration panel has an additional section which does not appear in TRS2019 (although the KUIDs are the same). I have tried playing around with the new dialogue parameters as well, with no luck. I also tried deleting a station, and and then replacing it. The parameters were still not saved.

Any suggestions welcome. Is this a known issue? I couldn't see anything when I did a search.

Edit: title changed to reflect further developments

 

[wilts747]

When migrating from TRS2019 to TRS22 I had to review the parameters of every individual AJS Station (and a pile of other things) but not actually change any of them as they were all as they had been in TRA2019. They just seemed to be 'stuck' and closing the settings window seemed to reset them. Peter

 

[stagecoach]

Are you just opening the route for edit? I believe all that information is saved in the session not the route.

 

[FootplatePhil]

Yes, the settings are stored with the session. I would usually just save the session after changing the station config. While trying to get the configs working in TRS22 I have tried saving in session, route, and session and route. After each save, when I get back into the station dialogue, the settings have reverted to the defaults.

 

[FootplatePhil]

When migrating from TRS2019 to TRS22 I had to review the parameters of every individual AJS Station (and a pile of other things) but not actually change any of them as they were all as they had been in TRA2019. They just seemed to be 'stuck' and closing the settings window seemed to reset them. Peter

That doesn't work for me.

 

[stagecoach]

Are you opening just the route for edit or are you going via edit session?

 

[FootplatePhil]

Are you opening just the route for edit or are you going via edit session?

Edit Session

 

[FootplatePhil]

I have made some further attempts. I have found that changes to 'Platform Height', 'Platform Length' and 'Initial Count' DO stick across a session save/exit/open. Changes to 'Platform Type', 'Peak Periods', 'Departure Rate' do not stick.

 

[pcas1986]

I have made some further attempts. I have found that changes to 'Platform Height', 'Platform Length' and 'Initial Count' DO stick across a session save/exit/open. Changes to 'Platform Type', 'Peak Periods', 'Departure Rate' do not stick.

I've been tracing through the code trying to work out where these values (properties) are saved and retrieved in the session data. The first group mentioned above are managed by Andi's code (stationajs.gs). The others (Platform type, etc) are managed by one of N3V's code libraries. I can debug Andi's code but it is much more difficult with N3V's code.

I do have have older versions of Trainz installed so I might just replicate my route and session test to check it worked in those versions. There have been a lot of changes to Trainzscript built-in libraries since Trainz Build 4.5 and the latest TS22 version had some changes to industries. I wonder if that is relevant.

 

[FootplatePhil]

I've been tracing through the code trying to work out where these values (properties) are saved and retrieved in the session data. The first group mentioned above are managed by Andi's code (stationajs.gs). The others (Platform type, etc) are managed by one of N3V's code libraries. I can debug Andi's code but it is much more difficult with N3V's code.

I do have have older versions of Trainz installed so I might just replicate my route and session test to check it worked in those versions. There have been a lot of changes to Trainzscript built-in libraries since Trainz Build 4.5 and the latest TS22 version had some changes to industries. I wonder if that is relevant.

Thanks for the update Paul. The station appears to work fine in Build 4.9.

 

[pcas1986]

I've done some more digging using a cloned version of N3V's genericpassengerstation.gs and passengerstationinfo.gs. In TS19 I can see the function calls working to load the session soup and it shows the values I had previously saved. In TS22 it does not and uses the default values as mentioned before. The data that does get saved and retrieved correctly is that controlled by Andi's station library and the station itself.

I tried to compare the TS19 and TS22 versions of the N3V scripts but there so many changes that my special comparison tool had trouble finding matches that made sense.

In my view this isn't something the CRG should repair since the issue may well be in N3V's script libraries code. We could, perhaps, change Andi's code to save that data but, without going into detail, I think that might be unreliable.

My recommendation is to raise a bug report but I do wonder if any of that data actually means anything. For example, does it mean anything for a session script if a station is small, large or standard?

 

[FootplatePhil]

I've done some more digging using a cloned version of N3V's genericpassengerstation.gs and passengerstationinfo.gs. In TS19 I can see the function calls working to load the session soup and it shows the values I had previously saved. In TS22 it does not and uses the default values as mentioned before. The data that does get saved and retrieved correctly is that controlled by Andi's station library and the station itself.

I tried to compare the TS19 and TS22 versions of the N3V scripts but there so many changes that my special comparison tool had trouble finding matches that made sense.

In my view this isn't something the CRG should repair since the issue may well be in N3V's script libraries code. We could, perhaps, change Andi's code to save that data but, without going into detail, I think that might be unreliable.

My recommendation is to raise a bug report but I do wonder if any of that data actually means anything. For example, does it mean anything for a session script if a station is small, large or standard?

OK. I have raised a ticket. Thanks for your efforts investigating this. With regards station size, although I have never verified it my understanding is that that determines the number of passengers that get off at a station.

 

[FootplatePhil]

An update: The problem I thought was an issue with 'AJS Station' turns out to be more wide spread, and does appear to be an underlying NV3 issue as pcas1986 suggested. I have been trying to find a basic station I can use as a replacement so that I can move forward with my route, but every station I try has its 'Peak Departure Rate' resetting itself to 120. This occurs in other routes besides my own, including the supplied routes I have installed (Healesville, and Bairnsdale to Orbost). It occurs in both TRS22 retail, and TRS22 Beta. Other stations I have tried include <kuid2:30501:22005:5> Station Basic, <kuid2:75377:100505:1> Station Basic 40m, <kuid2:61119:28101:2> Station A2 250ft, <kuid2:103475:28035:1> VR Platform 60m x 10m 1t.

Here is a screen shot taken during testing with "VR Platform 60m x 10m 1t". Initial Passengers and Peaking Departing Passengers were set to 0, then saved. Both route and session were saved, and the session started and allowed to run for 20 minutes, by which time the waiting passengers has built up to those seen in the image.

NB: I have update the thread title to reflect my more recent understanding of the issue.

 

[KotangaGirl]

I've been using the late clam1952's versions of of AJS invisible stations for some of my smaller stations and halts and so far they've been working reliably in TRS22 build 119451 and keeping their settings.

 

[FootplatePhil]

I've been using the late clam1952's versions of of AJS invisible stations for some of my smaller stations and halts and so far they've been working reliably in TRS22 build 119451 and keeping their settings.

That's interesting, thanks for feeding back. I have 3 installations of TRS22, and the AJS stations (and others) don't save the departure rate in in any of the installations.

I would be interested to hear other users experiences.

 

[p-dehnert]

The settings of the stations (like all properties) are saved with the session.

Peter

 

[FootplatePhil]

The settings of the stations (like all properties) are saved with the session.

Peter

Yes. Except when that save process is not working.

 

[boleyd]

I wonder if that save process is common to other items. It would explain a lot of several very odd behaviors.

 

[EHE]

It's been a while since the last post in this thread.

I'm experiencing the same problems as described: 120 people up to their waists on literally every platform on the route (TRS22 build 123801, all stations in the session layer). No matter what invisible station I try, nothing helps.

Are there any developments on this subject?
Does anyone have any tips on how to change this?
Or should we just accept this and learn to deal with it?

I'm very curious if the participants in this thread are the only ones with this problem, or are there more people who suffer from it?

Eric

 

[JCitron]

Eric, there are issues with the old Andi06 invisible stations not saving their settings.

You could try moving the stations to the route-layer and not the session-layer and see if that helps. For the most part, hardware such as stations should be on the route and not the session-layer.