CTD trying to insert command

[pwjohnson]

For a while now, on both 114800 and 117009, I've had a CTD trying to insert a command into a driver's schedule during a run. I'm surprised that I haven't seen anything about this in the forums - has anyone else had it? Or is it a known bug? It's not reproducible; it doesn't always happen, but when it does it's when there is a pop-up list of commands and I'm trying to select the command I want to insert. It is very annoying during what should have been a long run - I should have brought it up before.

Peter

 

[Christopher824]

What is the command name and/or kuid?

 

[stagecoach]

I've found that drivers don't like having their commands changed when they are in the middle of carrying out a command. It is like the script gets confused as to which command it is supposed to be doing, the original it started or the new one.

 

[pwjohnson]

@Christopher824: I don't get as far as selecting a command. I'm still moving the mouse over the list when it crashes.

@stagecoach: that's interesting. Many times I have given them a command when they're executing another one, like an autodrive, without any problem. But maybe on the odd occasion it does go wrong in the way you suggest. The only thing is, I've been doing this for decades (or so it seems), but it's only with 114800 and 117009 that it's crashed in this way.

 

[Christopher824]

@Christopher824: I don't get as far as selecting a command. I'm still moving the mouse over the list when it crashes.
...

So what is the name of the route and session? is it for every route? or just one route?

If we know what route it is we can see if it effects other people or just you. The route or session may be corrupt, or ot could be a driver rule.

Also have you checked in the content manager if any assets of the route or session has problems by right clicking the route then choose List Dependancies.

Edit: Have you done an extended database repair?

 

[pwjohnson]

Hi Christopher,

The route and session where this is happening is Dearnby V3, which is not yet on the DLS. In response to your post I tried using the Dearnby V2 route and session, which are on the DLS, and I could not make this happen, so you could well be right in suspecting that it might be peculiar to this particular route and session. That would also explain why nobody else seems to have noticed it.

There are no missing or faulty dependencies, and I have done numerous DBRs and also quite a few EDBRs since this started to happen.

Dearnby V3 does have some barges on canals being controlled by the AI, and as far as I can remember this started happening when I was working on these. The way these work is pretty weird, so I guess it is quite possible that there is something unusual going on which is affecting command processing in this way.

Since it seems I'm probably alone or nearly so in experiencing this, I will try disabling the barges while working on the rest of the session. If that works I can get by. I don't imagine it would be an easy thing to debug.

Thank you for your interest and suggestions.

Peter

 

[Christopher824]

What command are you trying to insert?

 

[pwjohnson]

As I said before, the crash occurs as I move the cursor over the list of commands, before I click on any command. It can't matter what command I was trying to select as I haven't clicked on one yet.

With regard to the barges, I have given them all waits of 2 hours before they do anything, but that has not stopped the crashes.

If you able and willing to have a closer look at this, I would very much appreciate it. If you can PM me your email I will send you the route and session.

Peter

 

[Christopher824]

I'm afraid I do not have the extra time right now, but my best guess now is either a new rule was added or a setting changed under Edit session. Sessions sometimes become hard to debug.

 

[pwjohnson]

Ok, understand. Thank you for your suggestions.

Peter

 

[JCitron]

Peter,

You may want to try the process of elimination. There's obviously something amiss here if this route crashes. I doubt it's the new beta route itself and is more related something that's broken or corrupted in some fashion. Assets can appear fine, but internally there's something so bad that they crash the program to the desktop. The only way to find the culprit or culprits is to use the process of elimination. The usual causes of this kind of crash are corrupted meshes and faulty scripts, although I've had bogus textures cause the same problem in the past.

To do this, you need to use Content Manager.

In Content Manager, find the route and then view the dependencies.

Because there's a lot of content in these routes, the only way to narrow down the culprit now is to subdivide what you've got left into smaller chunks as you narrow things down.

First, we need to sort the assets so we can disable items then enable them afterwards.

Click on Status so that all the DLS and 3rd-party (show as modified) assets are all arranged together.

Highlight all the DLS and 3rd-party assets.
Click on Content on the menu bar at the top.
Click on Disable.

This will remove these assets from the route.

Start Trainz
Load the route

Does it crash?

If no, go back to Content Manager...

Click on the first 100 disabled 3rd-party and DLS assets.
Click on Content on the menu bar again, click on enable.

Go back and load the route again.

If it doesn't crash, repeat this until it does.

At that point, you need to narrow down the culprit by disabling and enabling a fewer and fewer number until you find the asset that's causing the failure.

Once you've fixed the problem, you can go ahead and enable any remaining assets you have disabled.

 

[pwjohnson]

Hi John,

Thank you, John, for a very interesting suggestion.

I displayed all the dependencies of the session, recursively. There were about 620K of them! As you suggested, I ordered them by status and there were only 36 Modified. These were entirely my own (consists etc), and the EIT/MCM assets. I first tried with all 36 disabled - no CTD. I enabled all my assets, and a few others, leaving 11. No CTD.

Just to be sure, I enabled the remaining 11, and sure enough got CTDs. I didn't think it was sensible to cut them down any further, since these 11 are likely to be interdependent. A lot more commands were enabled with these 11, including some which I didn't think were EIT/MCM related - not sure how these were prevented from n=being available by the EIT/MCM assets being disabled.

I will contact pguy, the author of these assets.

Thanks again, John

 

[JCitron]

Well, that's good news in a way because you narrowed down the gazillion to a mere handful that are inter-related.

This deductive, or process of elimination, is tried and true and is the same method I've used for years when troubleshooting various problems whether it be a system problem as a whole or small components. When given a huge number of possibilities, the only way to find the solution is to narrow down the possible ones to the smallest number. Another good name for this method could be divide and conquer.

 

[pwjohnson]

Problem solved!

It turned out that John's elimination technique, though a very sensible suggestion, did not work in this case because although progressively reducing the 11 assets that were disabled did cause the CTDs to happen, it didn't seem to matter which assets were enabled. However, I noticed that as assets were enabled more commands appeared in the drop down list (this varied from around 10 with 11 assets disabled to around 50 with none disabled). So I did what I probably should have thought of much earlier, which was to move the cursor up (or down) through the list of the 50 or so commands, pausing on each one until its first level menu (if it had one) had been displayed before moving to the next in the list. Doing this 4 times, alternately going up and down the list, showed that each time the crash occurred with the cursor on Drive to Industry.

I deleted this command (which I wasn't using anyway) from my list of those available, and indeed there were no more crashes. Incidentally, Drive to Industry was not one of the 11 assets, or even related to them, so far as I'm aware.

Pierre Guy has looked more closely at this command, and believes that there would have been excessive processing for the quite extensive Dearnby V3 route. It seems that TRS19 couldn't cope and crashed, but he believes that TRS22 caught the problem and disabled the command but didn't crash.

My thanks to John and Pierre for their help in tracking down what was a very annoying problem.

Peter