Clarification on Error Message

tupuluruk

TRS 2006 / TRS 2004
In one of the routes I have created, when I try to enter the Drive Mode, the following Error Message appears :

A non-fatal script error occurred

Thread Exception ER ArrayOutOfBounds, line 81, file
Stack dump:
function $void@TramCrossing::MapSettings(), line -1
function $void@TramCrossing::SetProperties(Soup), line 178

Continue Abort

Can some one throw some light as to how to over come this ?

Thanx in advance
 
You have a faulty asset in the route. Try to find the culprit and either fix it or delete it from the route.
 
Zwabberaar,

Thanks for immediate reply. I got the defective asset deleted ( though I had to struggle a lot to find the asset ) and it now works fine.

Thanx again
 
Please bear with me as I reopen this older thread to pass along a point of information.

After working for a fairly long time with a session (TRS 2006) and using a certain log wagon as one of the assets with no problems, I suddenly began getting the same type of Thread Exception that Tupuruluk did when I opened the session. I found the defective wagon and eliminated it from wherever I had used it. That solved the problem.

Then I deleted the wagon with CMP, then downloaded it again. After the new download, the wagon again worked without error.

So, the wagon got corrupted in some way while I was working on the session. Don't know how what I was doing did the corrupting, but just in case, here is the situation when the corruption occurred:

I had been working with a route consisting of 3 merged routes and so each time I made a change, like adding a trackmark to the route, I encountered what somebody in another thread says is an Auran bug, namely, I had to save a new route with a new name. Pretty soon, I had a bunch of big routes saved up, and so I deleted some of the earlier versions.

As soon as I had deleted preceding versions, the thread exception showed up when I next opened the session in the then current version.

Maybe somebody can explain what happened, but this might help somebody else deal with an ER type thread exception without losing the use of a good asset.

Last but not least, thanks to Zwabberaar for telling us what to do about an ER ArrayOutOfBounds type of Thread Exception.

Dick
 
Correction!

I stand corrected.:o

After reinstalling the log wagon - 50 ft ATSF log wagon, the roster name for which begins with Logs..., I found that it was causing the black fault screen to appear when I started the session.

I opened if for editing and found that there were three illegal tags, Number_High, Number_Low, and Number_Prefix. As I have done with all other illegal tags that I've come across, I deleted them and their arguments from the config file.

After doing that, CMP showed this asset as being without faults.

But, when I next opened the session, the same thread exception was back! And these log wagons were responsible.

When I re-edited the config file and restored the 3 illegal tags and their values, CMP again showed the asset as being faulty and the black fault screen appeared again when opening the session, but there was no thread exception.

Don't remember editing this config file before, but I must have and must have done it at the time I deleted old map versions. While working with it this time, I had two versions, so deleted the oldest one. There was no effect on the current version or on the session.

So, it's a choice between the black fault screen and a thread exception. I opt for the black screen.

Any comments?

Dick
 
Last edited:
So, it's a choice between the black fault screen and a thread exception. I opt for the black screen.
Unfortunately it's not always going to be that simple. I can't comment on your particular issue except to say that whilst these tags may be illegal they are almost certainly required by the asset script. If there is no update available then the only ways to solve the issue are to leave it alone and accept the black screen (which is irritating but does no harm) or to delete it altogether.

In the case of the first post in the thread the assets (which are mine) are not faulty but they require a particular naming convention to be used if they are to work correctly. The likely cause of the exception is that the user had accidentally got this wrong.

So when you say 'Last but not least, thanks to Zwabberaar for telling us what to do about an ER ArrayOutOfBounds type of Thread Exception.' its a bit like a doctor curing a headache by prescribing decapitation. ;)
 
Last edited:
andio6 - I don't understand your comment. And I wasn't clear about the problem asset. It's formal listing is

Logs 50ft ATSF empty with cjlear as author, and KUID2:62941:16309:4

When I used the term illegal, I meant in the sense that the CMP flags the asset with a red exclamation point and explains the error as 'The tag <name> is not permitted within this container...' -- and gives the name of the section of code in which it appears.

Apparently, the three tags I removed were indeed required by the script, and CMP had mistakenly identified them as errors. I've done a good bit of editing of this type, and this is the first time I've removed an "illegal" tag and gotten a thread exception error because of it.

While it does not appear that this problem asset is actually yours, I'm interested about your comment on naming conventions. I was setting up a session and simply placing these logging cars on the track in a logging camp. Doing such, I have no control over a naming convention as far as I know. I'd welcome being educated on that.

Dick
 
CMP marks any tags which it doesn't recognise as illegal. Often these are incorrectly spelled or meaningless and in those cases it generally does no harm to simply delete them.

However it is sometimes necessary for script writers to add new tags to config.txt to provide information for their scripts. From TRS2006 onwards there is a recognised format for these and CMP allows tags which follow that format without complaint.

The problem arises with older assets like Charlie Lear's wagons which have custom tags which don't comply with CMP's requirements but are nevertheless needed for the scripts to work. As you have found out you can't delete these unless you want script errors and you can't keep them without upsetting CMP. So unless you are able to edit the script files you are stuffed.

The comment about naming conventions only applies to the asset that was mentioned in the first post in the thread, not to the wagons you are having problems with. Sorry if I've confused you :-)
 
Thanks for the clear explanation, Andi06 - I can see the logic of what you say about the relation of the CMP to any individual asset. There have to be exceptions to the rules (but not to threads!!) Please excuse the pun.:hehe:

I'm prety thick between the ears, and I misunderstood which asset you were talking about when you mentioned a naming convention with the point that the user can get it wrong.

Looking back at the first thread, I see that the asset at issue was a tram crossing. From my limited experience with route building, the user would simply pick that tram crossing out of a list of assets that are available in the user's Local file. How would the naming convention enter into it?

Not trying to be argumentative, but, as a user, I want to understand how I could get a naming convention wrong when setting up a map - or any other asset.

Thanks for your help -
Dick
 
Excuse me for my delayed reaction, I have not loggin in for quite some time because of other commitments.

As mononlaf points out, the asset I have been referring to was a tram crossing. As I have no idea about scripting I have just included the asset without having any idea about the naming convention etc and it was giving the error message. And finally I just deleted the asset and it worked fine. Of course with the asset included also the route worked fine except for the error message.

My intention while raising the point in the forum was to know the reason and andi06 has given the reasons.
 
There's an option to not have the black screen show. I think it's in CMP settings. There's an easy if not altogether wise solution to the problem;)
Mick Berg.
 
Back
Top