[Gary54]

 midneguy, on 14 September 2014 - 09:42 AM, said:

Gary - thanks for the additional comments about your experience with this, because my experience has been a little different actually. I've seen the NaNmph suddenly effect an AI train both early in an activity, and also quite a ways into an activity as well. Additionally, I've seen it effect multiple consists, but not all at the same time...

I also wondered if there might be something about a consist itself that would make this happen, since I first saw this while I was trying to run activities set in the 1980's or so. I've been running another activity sense, all "modern day" and I haven't seen the NaNmph AI consist freeze happen yet - though the activity has much less AI activity in it than the ones I was trying previously...

Glad to help in any way that I can. I suspect that my observation regarding the timing of the NaNmph problem is a bit biased; I have a tendency to start the AI trains very early. I would say that there are two or three consists that show the greatest frequency of disappearing. It's to the point that I avoid them now.

I am running all modern era activities. In fact, I model consists from my own observations or videos others have made.

I continue to believe that it has something to do with the consist(s), but trying to decipher the cause seems difficult at best.

Gary

[vince]

Hi Gary,

One way to eliminate a consist as the cause would be using Conbuilder or Route_Riter to check them for errors.

Best,
vince

[Gary54]

Hi Vince,

The real perplexing thing about this issue is that I normally run the activity through both Conbuilder and Route Riter to try to eliminate any problems that may exist. Though an engine or two (or three) may have a bit of a sound problem, I never see trouble with the consists. However, I may swap out engines in the troublesome consists to see if that has any impact.

Gary

[midneguy]

Though I don't have or use Conbuilder, I do use RouteRiter religiously and all of the stock, consists, and activities I have on the Orin Line - Powder River Coal route come through all the RR checks with a clean bill of health.

I've been doing some additional experiments, but unfortunately without any positive results to report... I went through and manually examined all the consists and rolling stock .wag / .eng files to make sure there wasn't anything amiss in any of the various parameters - which did lead to me finding a number of minor things that needed cleaned up. With this completed I tried running some of the activities again, but still got the NaNmph appearing on some of the AI trains. So, next idea - take out the first AI consist which appears only a few minutes into the activity and see if it was causing a problem - unfortunately later consists suffered from the NaNmph problem again. So, another idea - one activity I tried seemed to run without this happening, which was an activity with light AI traffic and NO loose consists anywhere on the route. So, I went into a problem activity and deleted out all of the loose consists while restoring the AI traffic back to the original state. Once again, after about 30 minutes into the activity run, AI trains started suffering the NaNmph problem. And again, like I've been observing the AI trains are actually still there in the sim though they are frozen in place and not moving - and the wheels have all disappeared from all the locomotives and cars in the affected consist... http://www.elvastower.com/forums/public/style_emoticons/default/wallbash.gif

The behavior of this happening continues to be somewhat random as well. Different consists may or not go NaNmph from one run of the activity to the next, and the times that it does happen for different consists varies also - the result being that when the problem starts to show up it's always at a different time and different consists being affected at that given moment.

This is really a bummer as I don't really have any ideas of anything else to try to troubleshoot this at the moment - but it's making me suspicious that maybe it's not consist related after all? It's truly a bummer nothing appears to show up in the log that documents AI trains getting frozen like that and any potential reason... http://www.elvastower.com/forums/public/style_emoticons/default/sad.gif

[midneguy]

HMMM...... Well, I think I have to eat my words somewhat from my previous post http://www.elvastower.com/forums/public/style_emoticons/default/lol.gif

I did think of something else to try shortly after I wrote my previous comments... And the idea I had was to swap out all the consists in the "problem" activity with the simplest ones I could. So, instead of full trains, every consist running in the activity, including the player, I set to use a simple pair of locomotives only. Testing this in the sim, the activity ran like I would have expected - no AI trains becoming frozen at all, though it was a little strange meeting multiple pairs of locomotives just like mine running around with no trains behind them lol.

OK... finally progress, and what appears to be confirmation that the consists were indeed the source of the trouble. So, to expand on this I now added back in a single coal train consist made up of Diesels West locomotives and coal hoppers. I chose those since I would assume they were "right" and should be error free. I did this for all of the AI consists except for one which would appear a little more than an hour into the activity, and after about 6 other AI train services started to run. Again, the activity ran great with no consists becoming frozen and losing their wheels. EXCEPT - when the consist I didn't alter appeared, it ran for a minute or two and then froze with the NaNmph speed designation. Jumping to the train in the sim confirmed that the wheels disappeared from beneath the entire train and it was just sitting there.

So... it would appear that this problem can very well be caused by the stock being used in the AI consists. A lot of the consists I have in this route utilize fairly old and dated stock, which for the purposes of meeting trains at speed on the main isn't really an issue. But, it would appear that some of these cars have issues, and I would suspect it's with the models themselves rather than the .wag files to go with them. This occurred to me after some more thought because of the disappearing wheels issue that was seen on some narrow gauge rolling stock which had hierarchy issues in the models themselves.

Now I'll be curious to examine the stock in the AI train that failed this last time around and see if it has hierarchy issues or not. At the very least I thought some might find this report interesting <_<

[midneguy]

AND... one last note for the evening I think lol.

Yes - it appears that the hierarchy of the hopper car shape files is the source of the problem with the "problem" consist from my last run... Examining these hoppers in Shapeviewer confirms that the "MAIN" group at the top of the hierarchy is instead named "FREIGHT", with each of the bogies parented to this incorrectly named "FREIGHT" group.

This brings to mind a question now... Is this something that OR could perhaps be made more forgiving of? That is, if a shape file has the correct structure like in a case such as this, could it go ahead and interpret it as "MAIN" instead? Of course this wouldn't work for incorrectly named BOGIE groups, since there would be no way to know which they should be... but for relatively simple problems like this might a solution be possible? http://www.elvastower.com/forums/public/style_emoticons/default/book2.gif

[Gary54]

Very encouraging results; many thanks for your efforts on this issue. I need to check this with some of the offending consists that I have been having trouble with.

Gary

[midneguy]

If the naming convention of the hierarchy is really to blame for this problem, then what I've just observed is pretty alarming... I examined all of the rolling stock in this particular route installation, and I counted 20+ names being used for the top of the hierarchy other than "MAIN" as it should be. In all of these cases the hierarchy was structurally correct, that is to say that the Bogies were both parented to a "top level" group like they should be, but that top level group could have any number of different names. That's an awful lot of shape files to fix - which includes both payware and freeware models from what I saw...

[Gary54]

I, too, see a variety of names in the Shapeviewer hierarchy other than "MAIN;" the examples include freeware and payware stock. I wonder if a single misnamed car is enough to cause a consist to disappear or freeze, or is it more a threshold number of misnamed cars. I've never had this problem running MSTS; perhaps this is another example of MSTS' penchant for ignoring problems (e.g., issues with signaling described in other threads).

[midneguy]

Gary,

I seem to have confirmed that the hierarchy naming was the cause, at least in version 2477 which is the last I tested last night. I went through the rolling stock (except the locomotives) and edited the shape files so that the top name in the hierarchies (matrices) was renamed to MAIN rather than the other various names. Re-running the problem activity everything went perfectly until about an hour in which was a huge improvement over the previous times. When I examined the AI Consist that did finally stall, I discovered that the locomotives assigned to it had the same name issue - and therefore must have caused the consist to freeze. All the other consist that froze before though, ran normally for the first time since I noticed this issue.