Problems with Dearnby route

pwjohnson

Member
I've been trying to get this amazingly detailed route and session going (route <kuid:304444:101412>, session <kuid:304444:101428>). I've tried under various TRS19 builds (100240, 105096, 106618, 109170) without success (with similar though different errors). With various builds I have had red bug messages for
1. 166471:100647 BR 13T conflat a weathered
2. 122285:508:23 AJS superscript code library
3. -16:2025 missing driver
4. Mesh object 359841:80098 DMT UK self build restricted traffic zone 25 TRC
5. 648132:100763:1 BR std tender Limed Green
6. 84609:50154:1 blue pullman_DBMF

I can probably fix 1, 3, 5 and 6 by tinkering with the consists emitted by the portals, but I also get numerous (a hundred a more after 15 or so minutes) of 4 which I have no idea how to fix - is it something to do with level crossings?

Also in 106618 there seemed to be no trains emitted by portals, though there were a couple of consists wandering around with no driver! I've also had a few CTDs, and everything locked up for several seconds. In this build there was also a missing dependency <kuid:523:10723431>; if this is a missing driver then I can probably change that.

I can't find any forum entries with these problems. Is there really nobody else who's trying to run this incredibly impressive route? Or has everyone else quietly solved the problems themselves without recourse to the forums? Any light which can be thrown on this would be greatly appreciated.

Peter
 
Peter - sorry to hear about these problems. I don't recall anyone experiencing anything similar in the past. The Dearnby routes we're all designed in TANE and I'm wondering if these problems are down to TRS19. Have you tried running it in TANE?
 
Neville - thanks for your response. I haven't tried running under TANE. I'll try it tomorrow and report back.

Peter
 
I installed the same route and session to TANE SP4 105766. There were these faulty dependencies:
- 4 signals <kuid2:218467:4630/4554/4544/4522:1> which I reverted to original and that seemed to be OK (this may be something to do with me using them a long time ago!)
- DriverEric -25:1253 which had build number 4.6
- Global Consist Lib <kuid2:61392:4010:5> which had script errors
I ran the session for almost an hour. There were no red bugs!
But it did seem that there were not many portal trains emitted. I know they're emitted randomly, but the only ones I saw in that time were
Nick (twice), Geoff, Bald, Christian, Eric, Marc, Hentis, Andrea and Thomas. There was also a light engine (7258), emitted twice from SE DoS (no driver).
At the end Thomas with the blue Pullman had been at DoS P1, trying to get to NE DoS portal, but for some reason he backed up instead and got stuck. At this point everything almost locked up, although the CPU and graphics card meters were not showing high usage, so I had to stop.

I imagine that at least some of these problems may be associated with the faulty consist library. And it may also be that whatever I had been playing with under TANE before I moved to TRS19 was having a bad effect. I guess the way to get it working under TANE would be to reinstall TANE. But I'd really like to get it working with TRS19. Is there anything you can suggest that I can do to get there?

Thanks, Peter
 
Installed in TRS19 with no problems......a few assets had to be reverted but after that, no problems.
 
Thank you gawpo50 - so either you already have something good on your system, or I have something bad on all my versions of TRS19! I'll fiddle around a bit, perhaps install a shiny new version of TRS19. The main thing which I don't know what to do about is item 4 of my first post - I've not consciously done or installed anything which might have caused that. If anyone has any ideas, do pls let me know.
 
Peter - my technical knowledge is quite limited in this sort of area and so I'm not really able to suggest anty clever solutions. All I can add is that there seem to have been thousands of downloads which haven't experienced these problems, which implies that unfortunately it's something at your end. In my own case I CDP'd the route from TANE to TRS19 successfully. Just regarding trains getting stuck, I think this will happen from time to time. Because of the random portal generation every trainspotter session is different and so conflicts can't be ruled out. The route should reach full population after about an hour.
I hope you manage to get things running in the end.
 
So loaded the session in TRS19 and it crashed to Desktop. Getting same problem in the latest version as well, even when trying to edit route. Something common to all versions that TRS19 doesn't like?
 
Clam1952,
I've edited the session in TRS19 version 109037 and found myself looking at the desktop as well. But, when I loaded up the saved session, after starting the game and waiting for the database repair, it worked, although there were two missing dependencies, listed as unknown to Neville_Hill:

<kuid:304444:103439>
<kuid:304444:103441>

The modified session seemed to run just fine without those two assets though.

I hope you get things sorted as this is simply an amazing session for an equally amazing route.

When I start the regular trainspotting session (from DLS), I get a large box labeled AJS Superscript Code, and I have a small red bug on the lower right. I've no idea what I am supposed to do with the Superscript Code, and if I click on the small red bug, I see a Session Logs box. Again, no clue on what to do with that either.

When I minimize both, the session runs very nicely, and it is amazing to watch all the trains coming in and interacting. Unfortunately, it overwhelms my computer after about a half an hour and the session turns into a slide show.

I'm wondering if adding time to the portal consists being randomly generated would at least slow down the numerous consists and give me more than a half hour of amazing enjoyment.

As for the difficulties noted by PwJohnson, I haven't seen any of those.

Heinrich505
 
I hadn't actually tried the Dearnby routes in TRS19 as concentrating on my Lynton and Barnstaple WIP. The routes were fine in TANE

There are general problems with superscript which is becoming incompatible and various things have stopped working or been deprecated presumably by N3V,
If there's a debug feature in the config of assets with superscript errors it might be an idea to remove it wont fix anything but may stop the messages.

I've trying to track the CTD problem in the log however the log isn't recording anything relating to the route or session.
 
It's interesting that clam1952 is getting a CTD. I also had some of these, though not immeediately as you did. I'll be very interested to see whether you can find out why.

Meanwhile, I started looking at TRC crossings, about which I knew nothing. Item 4 of my first post was the most troublesome; after 15-30 minutes these were coming faster than I could get rid of them. I found the trc website at https://sites.google.com/site/trcv2english/ and there, under item 7 there is a section on English Materials, where user scottish (his userid is the one that my error messages referred to) has created some objects. Under scenery objects there is the comment: "Please note : for now, the scenery objects aren't compatible with Trainz 2019 when on 'stream objects' mode".

I don't know what "stream objects" mode is, but could this be a clue as to why some of us are finding trouble with TRS19?
 
PwJohnson,
While doing the trainspotting, and/or just riding on the floorplates of various engines, I've seen that some crossings work just fine, and others are not working. Off the top of my head, it seemed that crossings were having trouble more as the route became more populated, maybe around the 30 minute mark. I can't be certain on that though. It is incredible how many things are all happening at once.

I have not had a CTD when running the session, but things all seem to freeze up after around 30 to 45 minutes, due to the number of trains that have spawned onto the route. I'm sure a more robust computer would solve that problem, but funding that enterprise is not possible for the time being. :(

Heinrich505
 
Got it working after three more CTD's by ticking all the debugging stuff which was a bit, weird ran the session for half an hour closed it unticked all the debugging stuff and started it again, no CTD, ran it for a hour and had a good look round.
Confirm some crossing gate are remaining shut, the ones with the DMT thingy, showing as a problem in the log as well. And the Superscript errors, got rid of that by clicking on the A B icons at the top and clicking the minus and red bug didn't appear, again a bit odd.
Strange pauses in the game for up to a minute, sound continues and Trains stop dead then carry on.
Noticed a few bald patches where the grid was showing which would probably indicate a ground texture problem.
Tried on second PC no CTD initially but crashed after 20 minutes, the stopping problem still happening.
 
Clam1952,
There are quite a few TRC assets used in the route. One of the suggestions in the other thread was to delete the TRC trigger, and then re-download as "download this version." Since the TRC trigger is built-in, per the CM, then the delete option is not available, unless there is some other way that I'm not aware of.

I'm more interested in why the trains freeze for sometimes as long as a minute (or longer), while everything else is still functioning. I would think that if my computer was overwhelmed from processing all the trains on the route, then the freeze would be for everything, trains, sounds, etc. As I'm somewhat of a dinosaur when it comes to computers, I may be wrong on this.

Heinrich505
 
Clam1952,
There are quite a few TRC assets used in the route. One of the suggestions in the other thread was to delete the TRC trigger, and then re-download as "download this version." Since the TRC trigger is built-in, per the CM, then the delete option is not available, unless there is some other way that I'm not aware of.

I'm more interested in why the trains freeze for sometimes as long as a minute (or longer), while everything else is still functioning. I would think that if my computer was overwhelmed from processing all the trains on the route, then the freeze would be for everything, trains, sounds, etc. As I'm somewhat of a dinosaur when it comes to computers, I may be wrong on this.

Heinrich505

Crossing fixed by deleting v16 and replacing with 15.

The Pauses appear to coincide with File dmtrtz1.gs, Line 26, ER_ThreadError followed by a stack dump in the log, I'm running the trainspotter session at the moment currently its stuck, seems to pause for longer and longer as time progresses. might have totally locked up this time although the sound is still working. bold and colours so you can see what I'm on about in the log.
Sample from log below, this happens every time the locos get stuck

Code:
[B]; <NULL> File dmtrtz1.gs, Line 26, ER_ThreadError[/B]
[COLOR=#ff0000][B]; <NULL> Stack Dump...[/B][/COLOR]
; <NULL> function $void@ct::ManageObject(Message), line -1
; <NULL> GameObject::Sniff> Target object is null (file gs.gs)
; <NULL> GameObject::Sniff> Target object is null (file gs.gs)
; <NULL> GameObject::Sniff> Target object is null (file gs.gs)
; <NULL> GameObject::Sniff> Target object is null (file gs.gs)
[B]; <NULL> File dmtrtz1.gs, Line 26, ER_ThreadError[/B]
[B];[COLOR=#ff0000] <NULL> Stack Dump...[/COLOR][/B]
; <NULL> function $void@ct::ManageObject(Message), line -1
; <NULL> 1 queued router messages cleared for 0112 'consist_7', message Train.GetJunctionTrackPermit, Timeout
; <NULL> GSRouter::Done(), 4 outstanding node(s)
? <NULL> MeshResource::LoadResource> <kuid2:116296:42442:4> | arc:fld:$(original)/hash-E0||kuid2 116296 42442 4.tzarc|
? <NULL> Loading mesh gw_pannier_interior.im
! <NULL> VE166: 29 combined chunks (of 29 source) in .im file: 
; <NULL> GSRouter::Done(), 4 outstanding node(s)
? <NULL> MeshResource::LoadResource> <kuid2:116296:42442:4> | arc:fld:$(original)/hash-E0||kuid2 116296 42442 4.tzarc|
? <NULL> Loading mesh gw_pannier_interior.im
! <NULL> VE166: 29 combined chunks (of 29 source) in .im file: 
; <NULL> Interface.Print> 'Greg - Waiting for track clearance'
[B]; <NULL> File dmtrtz1.gs, Line 26, ER_ThreadError[/B]
[B][COLOR=#ff0000]; <NULL> Stack Dump...[/COLOR][/B]
; <NULL> function $void@ct::ManageObject(Message), line -1
; <NULL> Interface.Print> 'Andrea is stuck and is awaiting new instructions'
; <NULL> Interface.Print> 'Andrea - Waiting for track clearance'
; <NULL> Interface.Print> 'Gerd - Waiting for track clearance'
; <NULL> 1 queued router messages cleared for 15798 'consist_512', message Train.GetJunctionTrackPermit, Timeout
; <NULL> 1 queued router messages cleared for 15798 'consist_512', message Train.GetJunctionTrackPermit, Timeout
[B]; <NULL> File dmtrtz1.gs, Line 26, ER_ThreadError[/B]
[COLOR=#ff0000][B]; <NULL> Stack Dump...[/B][/COLOR]

Finally unstuck after 15 minutes so ended the session as only moving a few meters now between pauses, the session had been running for over an hour and a half.

I haven't touched any code since the last century so I'll leave someone else to suggest where we go from here!

Nearly forgot to mention, those crossings don't open until the loco is nearly touching the gate and it's an instant open shut no sign of animation, not sure if that's supposed to be correct, I suspect not.
 
Last edited:
Clam1952,
That appears to be a good catch on the log. I'd say there is a definite correlation (how's that for scientific lingo...:)) between that file and the stack dump. I noticed that the time of the pauses increased each time they happened, just as you noted. In order to exit, I would have to time my mouse clicks on the exit session for when the pause was over, as the menu was frozen during pauses too.

Thanks for exploring this further. Hopefully someone has a fix, as the route and session are absolutely top notch.

Heinrich505
 
Heinrich,

I just replied to your PM but the screen gives me no clue as to whether this reply actually got sent to you or not. Could you have a look?

Regards,
Lataxe
 
First, thanks to clam1952 and heinrich505 for moving this thread along.

I have been trying to eliminate errors, so I have deleted all instances of
- BR 13T Conflat A Weathered
- BR standard tender lined green early crest
- BR standard tender lined black early crest
and replaced driver Ian (build 2.9) with Zdenka (!).
(I should also have deleted the blue Pullman_DBMF_CAR_F but forgot.)

I did 3 runs of the TRAINSPOTTER session, modified as above and no longer faulty, on build 106618. The only runtime errors now (apart from a couple of blue Pullman ones) are the AJS Superscript error, at the start of the run, and the DMT level crossing errors.

The DMT errors started after about 10 minutes. They seemed to occur in batches of 50-100, then a minute or more gap, then the next batch. Perhaps each level crossing usage produces a large number of errors?

The lockups began after 42, 42 and 48 minutes for the 3 runs (differences because the portal emissions are random, though interestingly these times are still quite similar). To start with the lockups were just a few seconds, but they quickly became minutes, at which point I stopped the run. I was surprised to see that the CPU usage remained at 40-50% (i7-5820K processor at 4.4 GHz) during the lockups, and no single core seemed to be stuck at 100%. The GPU (GTX970) also remained at around 40%, apart from just one time (out of dozens of lockups) when it went to 100%, although this time didn't exactly correspond with the period of the lockup! There was no noticeable disk activity.

This does suggest that heinrich might be disappointed, to say the least, if he upgraded his system and found that he still had the same lockups!

From looking at the log, malc suggested that the DMT errors might be connected to the lockups. I understand that, though I would observe that I must have had 1000 or so errors before the lockups started, but that doesn't prove that they're not connected. However, I'm conscious that all I've done is to bypass problems rather than solving them, so I don't know whether I'm going to invest the effort to try to bypass the DMT problems. It would be much better for the DMT issues to be *solved* by someone who understands them, then we could see whether there was also another lockup problem. This is such a fabulous route that it would be a great pity if it became unavailable.

Peter
 
Last edited:
Back
Top