TRS22PE upgrader "dabbling toes" user report for DEVS

[anathoth71]

I am a 20year Trainz veteran and purchased TRS22PE to tryout and compare with TANE SP3, my current ride. I am very impressed with most of TRS22PE, and I think the new features like UDS can be adjusted to, and including Classic Surveyor alongside Surveyor 2.0 was a great idea. My computer is getting on now, it's 8 or 9 years old (i5 6400@2.7, 16GB RAM, GTX 750 TI, Windows10, SSD) but TRS22 runs far better graphically than TANE, at low graphic settings anyway which is fine with me because I am an operations guy, not a screenshot guy. So generally I am extremely impressed with it.

To test it out I brought over a test route of reasonable size, base session and all required assets which I repaired as required. I built up a new TRS22PE base session including AI trains for the route and started driving and let the AI do their driving too.

Some issues did crop up - there are enough tech issues to prevent me from migrating to TRS22PE completely right now. I am hoping a future patch will repair a few of the issues I discovered which I will briefly summarise here:

1. The DRIVER SETUP session rule is not treated as the highest authority when TRS22PE loads a session for driving. The result is a fusion of what I desire for the session, and what TRS22PE would do by itself, resulting in all manner of unwanted results with AI trains, and way more drivers than desired.

2. Derailments of AI trains are happening excessively, even when the Quickdrive rule is used to set derailments to NONE. I narrowed a lot of this down to a section of track that had come out "mangled" after moving my test route to TRS22PE. I spotfixed the mangled trackage with little improvement. So I deleted and relaid the whole track section of a couple of miles which cured the problem on that stretch. But AI derailments are still occurring at other random locations around the route at a frequency that is much too great.

3. Also, I cannot use the Driver module for more that 2 hours before I get a hang. Not a CTD, just a hang which freezes the game completely. I'm not an IT guy, but this seems to indicate a memory problem for me so I always check the Windows Task Manager, and following these hangs it always shows figures of around 2900mb of ram being used by TRS22PE, at 33% of mem capacity. I run Trainz without running any other memory sucking applications, and only 34 background processes.
Granted, this could be something unique to my particular computer setup, but I don't know for sure.


------------------------

So all up I'm very impressed with TRS22PE. It usually isn't my style to buy a recent release because they usually need some stability work, but this edition seems very stable even on my old computer, save for the problems outlined above.

So good work overall N3V, if you can fix these things with a patch then I'm in boots and all.

Kind Regards
A71

 

[pware]

A71. Your review was well considered and presented. If only more were written this way, regardless of the final verdict of the author.

I do all my development work using Trainz Plus and use TRS22PE as a test bed. My copy of TRS22PE only contains assets that are Built-in and Installed from DLS - no payware or third-party assets. That way when I transfer a test route to TRS22PE and it installs without any missing assets that cannot be found on the DLS then I know it will run on any Trainz Plus or TRS22PE system without the user having to play the "hunt the missing assets" game.

I have not experienced any of the problems listed in your review. This is NOT to say that they do not exist - they could be caused by differences in hardware, installed assets or other factors.

This point interests me.

1. The DRIVER SETUP session rule is not treated as the highest authority when TRS22PE loads a session for driving. The result is a fusion of what I desire for the session, and what TRS22PE would do by itself, resulting in all manner of unwanted results with AI trains, and way more drivers than desired.

All the rules shown in the Session Editor that are positioned flush against the left margin (no indent or at Level 0 if you prefer) are all executed simultaneously, although some will take longer to execute than others. Thus there is no way to give one rule a "higher authority" than others. Placing a rule higher up the list, for example, will make no difference.

On the issue of "way more drivers than desired" make sure that the check box Generate new drivers for empty trains found at the bottom of the driver list is checked OFF. My current session under test in TRS22PE has 30 drivers all assigned to their locos with no extra or unassigned drivers despite having more than 30 locos available in the session.

 

[ajrf]

2. Derailments of AI trains are happening excessively, even when the Quickdrive rule is used to set derailments to NONE. I narrowed a lot of this down to a section of track that had come out "mangled" after moving my test route to TRS22PE. I spotfixed the mangled trackage with little improvement. So I deleted and relaid the whole track section of a couple of miles which cured the problem on that stretch. But AI derailments are still occurring at other random locations around the route at a frequency that is much too great.

Does this happen when you load a session or do they derail because of speeding (which AFAIK is rare)? Thanks.

 

[anathoth71]

A71. Your review was well considered and presented. If only more were written this way, regardless of the final verdict of the author.

I do all my development work using Trainz Plus and use TRS22PE as a test bed. My copy of TRS22PE only contains assets that are Built-in and Installed from DLS - no payware or third-party assets. That way when I transfer a test route to TRS22PE and it installs without any missing assets that cannot be found on the DLS then I know it will run on any Trainz Plus or TRS22PE system without the user having to play the "hunt the missing assets" game.

I have not experienced any of the problems listed in your review. This is NOT to say that they do not exist - they could be caused by differences in hardware, installed assets or other factors.

This point interests me.



All the rules shown in the Session Editor that are positioned flush against the left margin (no indent or at Level 0 if you prefer) are all executed simultaneously, although some will take longer to execute than others. Thus there is no way to give one rule a "higher authority" than others. Placing a rule higher up the list, for example, will make no difference.

On the issue of "way more drivers than desired" make sure that the check box Generate new drivers for empty trains found at the bottom of the driver list is checked OFF. My current session under test in TRS22PE has 30 drivers all assigned to their locos with no extra or unassigned drivers despite having more than 30 locos available in the session.

Hi pware, nice to chat again !
Yes I tried different combinations of the checkboxes at the bottom of the Driver Setup Rule. What I found was that Trainz would "remember" previous setups in the session somehow. For example I found AI drivers assigned to the 2nd or 3rd loco in a multi engined consist when those locos were previously the lead loco in the consist. The only setup that works consistently is to use those checkboxes to nuke all drivers out of existence, which requires me manually starting all AI trains after Driver session startup. It is a workaround that works but is time consuming. As always, this might be caused locally somehow, I'm not expert enough to determine that. I tried configuring drivers using the Driver Schedule Rule to start AI drivers, but this was not reliable either, with confused driver allocations continuing.

Hah, all these years I thought the vertical order of the Session Rules was important - thanks for the correction.

As a general question, is there a patch being built up that might be coming at some point down the line?

 

[anathoth71]

Does this happen when you load a session or do they derail because of speeding (which AFAIK is rare)? Thanks.

Neither, my AI trains that derail can be going at high or low speed, curves or straights. But now that you mention it and I've thought about it a bit, I can't recall a derailment while the AI train is driving an uphill section. It's a mountain pass route and all derailments that I can remember have occurred travelling away from the summit - downhill. Maybe there is a clue there, something in the physics calcs maybe. Though how this plays into the NONE setting for derailments in Quickdrive is something for the devs I guess.

 

[JCitron]

I haven't had any issues with that, maybe my procedure is different than yours. I remove all the extra drivers prior to setting the checkboxes up then save the session.

 

[wreeder]

I expect at least one more update to TRS22PE to apply a couple of bug fixes that were added to Trainz Plus beta releases. The important one to me is the fix for the sparkling trees.

 

[pware]

As a general question, is there a patch being built up that might be coming at some point down the line?

I expect at least one more update to TRS22PE to apply a couple of bug fixes that were added to Trainz Plus beta releases.

The Trainz Plus beta stream had its third (? I may have lost count) update just a day or two ago. This one without the Assertion messages which, I suspect, means that the final Release Candidate could be close.

 

[anathoth71]

UPDATE - Derailments completely eliminated !

When I first started my initial test drive in TRS22PE after fixing "broken" sections of track as described in the OP above, I set the base session up the way I used to in TANE. i.e. with portals generating AI trains at regular intervals and AI drivers getting their route instructions automatically using the COPY COMMANDS FROM command/SCHEDULE LIBRARY rule. Using this technique, I got a lot of AI derailments. My own train I was driving never derailed on good track. It was always AI drivers, and only while driving downhill.

So I changed my approach to setting up the AI trains and it cured the derailments immediately and completely as follows:
Now I do not use portals at all to generate AI trains. Instead, at a time of my choosing I switch from Driver mode to Classic Surveyor Mode, unlock the session layer, and manually add a consist on the portal exit track instead of allowing the portal to generate it. I DO NOT SAVE ANYTHING WHILE IN CLASSIC SURVEYOR MODE! Then I return to Driver mode and delete the AI driver that the program generated for the newly placed train, and manually create a new driver of my choice from the driver list and assign him/her to that new train. Then I "enter" that locomotive and manually command the driver to COPY COMMANDS FROM the SCHEDULE LIBRARY it's correct AI schedule. Once the AI driver has satisfactorily begun the schedule, I go back to my own train and do a normal and simple session save while in Driver mode to save the new AI train I just added.

Using these procedures reduces automation, basically creating a bit more work by manualising the creation of AI trains - but not one AI train created this way derailed. So it is worth the effort in my book. Also, avoiding saving anything while placing trains in Surveyor mode doesn't mess up the original base session that the driving session started with.

------
I'm not an IT guy, but a suspicious mind might once again conclude that the derailment problem is somehow linked to how the program-generated AI drivers behave in TRS22PE. Because AI drivers created and placed in their trains by the User never derail - at least in my experience so far.

I hope I explained this with sufficient clarity !

 

[JCitron]

I've had no issues with AI trains coming out of full-size portals, however the small Portal Basic is troublesome. After replacing those on my routes, I no longer have the "blind consists" barreling down the track at full speed with no commands causing derailments and other mayhem.

One of the things I've always done is give the driver commands a chance to load before proceeding. Once a consist exits a portal, I put in a 20 second Wait... command once the commands are loaded so that the AI sits there prior to proceeding. Allowing the commands to settle in and load has prevented many issues I've noticed.

 

[anathoth71]

Hi John, yes a wait of at least 10 seconds works for me and is standard practice. Am currently migrating routes/base sessions from TANE to TRS22PE, and the portals are generating straight off the bat, to my amazement. Will do further testing and report further again "soon".