Trainz Plus and TRS19 Beta 113642 now available

"The copy and paste function does not work after an undo and track spines are not removed."
>>
We could not repro this issue.

Our steps:
1. Lay half a dozen track segments
2. Click Undo a few times
3. Using the Copy tool, select the area that includes the remaining track segments
4. Select Paste Mode and paste the selected area

Expected: The copied area is pasted to the new area

Actual: As expected

Please advise your steps and outcome.

Regarding the crash - I suggest disabling the dependencies and retrying to try and identify the problem assets. Assuming it doesn't crash, then re-enable groups of content until you get a crash
 
"The copy and paste function does not work after an undo and track spines are not removed."
>>
We could not repro this issue.

Our steps:
1. Lay half a dozen track segments
2. Click Undo a few times
3. Using the Copy tool, select the area that includes the remaining track segments
4. Select Paste Mode and paste the selected area

Expected: The copied area is pasted to the new area

Actual: As expected

Please advise your steps and outcome.

Regarding the crash - I suggest disabling the dependencies and retrying to try and identify the problem assets. Assuming it doesn't crash, then re-enable groups of content until you get a crash

I checked on a new board and a heavily populated area of one of my routes without any problems. Haven't had problems with splines for a while
 
No posts over the weekend - does that mean everyone reading this who has the beta installed is happy that all the bugs are either reported in this thread or fixed?

If you have a bug in the current beta build that isn't mentioned here, please submit a bug report here; n3vgames.typeform.com/to/xRdryu

We've fixed:
- handbrakes
- script exceptions causing a Save game error
- carz on escalators
 
No posts over the weekend - does that mean everyone reading this who has the beta installed is happy that all the bugs are either reported in this thread or fixed?

Or they have been watching the final day of the Olympics and the Closing Ceremony.:)
 
No posts over the weekend - does that mean everyone reading this who has the beta installed is happy that all the bugs are either reported in this thread or fixed?

If you have a bug in the current beta build that isn't mentioned here, please submit a bug report here; n3vgames.typeform.com/to/xRdryu

We've fixed:
- handbrakes
- script exceptions causing a Save game error
- carz on escalators

I've mentioned a bug about locomotive lights in the new beta, on the previous page, and got no response. I also reported it and again - no response from the team. I see by the things you've fixed, it's not there. Could you please check on this problem for me, Tony?
It's not just one locomotive, it's several. And it happened only in the current beta. I suspects it's because of this latest fix - "Headlight no longer shining in cab", which probably has something to do with the opacity of loco lights. Again, it's not just one locomotive. I sent the testing route and session with a loco to the bug report team. If needed, I can provide more kuids, they are all on DLS.
If this is not fixed, then it'll be a huge problem for, at the very least, a lot of Russian players in the next Service Pack. I really hope we can somehow manage to fix the issue here.
 
I sent a Bug Report on a "Portal/Portal Central Command" issue but that was for 113547. The same bug exists for me on 113642. Bug report was sent on 7/21/21. I received email auto-reply receipt of the report but nothing else so I don't know if it's being looked at or not. The bug was introduced in 113142 and remains in 113547 and 113642. It's reproducable. Occurs on every new session run.
 
I sent a Bug Report on a "Portal/Portal Central Command" issue but that was for 113547. The same bug exists for me on 113642. Bug report was sent on 7/21/21. I received email auto-reply receipt of the report but nothing else so I don't know if it's being looked at or not. The bug was introduced in 113142 and remains in 113547 and 113642. It's reproducable. Occurs on every new session run.
What problem are you seeing? I use the Central Portal Control <kuid2:117746:1013:9> in most of my routes and have not seen any problems in build 113642. Is this the asset you are having problems with?
 
What problem are you seeing? I use the Central Portal Control <kuid2:117746:1013:9> in most of my routes and have not seen any problems in build 113642. Is this the asset you are having problems with?

I see the problem in TRS-19 Port Zyd V2 sessions (latest route, latest sessions.) The "Portal" is set via "Central Portal Control" to emit immediately. With the latest 2-3 beta's - upon a "normal" new "Drive Session" the portal does not emit trains. However, if you "Edit Session" and immediatley go into "Driver" a train is emitted immediately as expected. This occurs every time. With a "Drive Session" no train is emited. With a start of "Edit Session" and "Drive" a train is emitted. More could be said. I've tested with my own sessions, Portal by itself, Portal with CPC setup, etc and the Zyd sessions are the only place I find this. Yet they worked perfectly in previous releases of '19 and they work perfectly in my SP2 and SP3 installs. (the exact same route and sessions.)
 
Hi everybody.

Does somebody else have some trouble with Change Direction Command (<kuid2:71155:60010:1> by _mutton_) or ChangeTrainDirection ( <kuid2:70791:9001:1> by MGalling) driver commands under build 113547.

I use recurently these commands in my EIT DemoRoute - UK1 sessions, and in previous build (111951) I can run my session for as long as 6 to 8 hours during the night with no problem, where the same route and session under build 113142 leads randomly but relatively quickly (15 mn to 1 hour) to some train stucked at a stop with a very strange situation :
the train is globally correctly oriented (1st carriage and last carriage correctly set, but the train direction is reversed for no apparent reason : train direction towards the rear carriage and not the first one though driving only foward ...).

It seems to happen after a first successfull trip in the forward direction, followed by a reverse consist operation done using either Change Direction Command or ChangeTrainDirection, followed by a correct AutoDrive to a trackmark stop (using AutoDriveToMCPathStop) and then ... when stopping at the trackmark stop the train seems to keep its orientation with the same first carriage and last carriage that when autodriving, but gets now a reversed train direction (train direction towards the rear carriage), without any turnout script call or other reverse driver command being executed ...
With this new inadequate train direction, the train no longer find the next path to follow in the forward direction and the session is broken with some stucked train after about 15 mn ... This behaviour is specific to build 113547 and do not happen in 111951.

I am now working on a copy of the session to try to simplify it to have a more easy repro case to submit to N3V, but I am interested to know if some other session developpers have run in some similar problems with sessions using these Change Direction Command (<kuid2:71155:60010:1> by _mutton_) or ChangeTrainDirection ( <kuid2:70791:9001:1> by MGalling) driver commands.

Other question to N3V team : does something has been changed to what Train.Turnaround() is doing that might cause and explain such problems or not ?

I am not very happy on how to manage this problem, as the train seems to have only half done a reverse operation (train direction has been reversed but without swapping the order of the train carriages) and I don't see for the moment any bypass method to detect the problem and undo it on the fly ...

Thanks in advance for your contributions. Have a nice day.
Pierre.
 
I see the problem in TRS-19 Port Zyd V2 sessions (latest route, latest sessions.) The "Portal" is set via "Central Portal Control" to emit immediately. With the latest 2-3 beta's - upon a "normal" new "Drive Session" the portal does not emit trains. However, if you "Edit Session" and immediatley go into "Driver" a train is emitted immediately as expected. This occurs every time. With a "Drive Session" no train is emited. With a start of "Edit Session" and "Drive" a train is emitted. More could be said. I've tested with my own sessions, Portal by itself, Portal with CPC setup, etc and the Zyd sessions are the only place I find this. Yet they worked perfectly in previous releases of '19 and they work perfectly in my SP2 and SP3 installs. (the exact same route and sessions.)
I just tested this route <kuid2:69871:3534:2> and session <kuid2:69871:3550:2> and they both seem to work OK for me. In one case I started the session by going directly to the drive session option and in the second case I went on to the session by the edit session option and then went to the drive mode. In both cases I got the train to emit immediately. Are we working with the same route/session kuids?
 
Yes, Route kuids are same. I was testing primarily with session Black Nuggets v2 <kuid2:69871:3549:2> and <kuid2:69871:3550:3>. Neither one emit upon launch and "Drive Session."

Both work as expected emitting immediately in SP3-111951 and SP2-110491 with the exact same route kuid and session kuids.

Could be very well something flaky with my install but it's odd that things work OK if I "Edit Session" and "Drive" vs simply "Drive Session"

Perhaps I'll just try a total re-install my beta copy.
 
Last edited:
Yes, Route kuids are same. I was testing primarily with session Black Nuggets v2 <kuid2:69871:3549:2> and <kuid2:69871:3550:3>. Neither one emit upon launch and "Drive Session."

Both work as expected emitting immediately in SP3-111951 and SP2-110491 with the exact same route kuid and session kuids.

Could be very well something flaky with my install but it's odd that things work OK if I "Edit Session" and "Drive" vs simply "Drive Session"

Perhaps I'll just try a total re-install my beta copy.
I just tested the Black Nuggets session and everything seems to work OK for me. The train emits as expected when I started using "Drive Session". It seems like something else is not working properly on your build. Sorry I can't provide any assistance, these kinds of things can be very frustrating.
 
I'm fine here. I normally setup my own sessions and the "Edit" "Drive" work around is easy enough. My only input on this was as plus/beta user and Tony did ask. No one else had replied to earlier posts on this and my Report wasn't replied to so I didn't know if a bug or not. I just didn't want to let a possible bug go. Zyd is my favorite payware route and I do a lot with it. I'd hate for new users to grab it and have no trains emitted while running in the sessions. I'll be interested to see what happened when I re-install the whole caboodle! Thanks for letting me know things work on your end. This only reared it's head when I updated to the latest beta. Didn't touch anything. Just did the beta update, ran Zyd, and.. no emitted trains.

UPDATE:
Downloaded and installed a new fresh plus/beta 113642. Downloaded Port Zyd and TRS-19 Port Zyd and sessions (all latest versions.) Result: Exact same problem.
- "Drive Session" launch gives no emitted trains.
- "Edit Session" and immediate switch to "Driver Mode" - Portal immediately emits trains.

moving on to other things....

0683h13: zyd portal
 
Last edited:
Thanks for the feedback - keep it coming.
I'll check up on those tasks - I know they're in the system but not sure of the status.
 
Back
Top