East Midlands Class 222 Units by peterdhicks Script Exception

S

Scottish

New member
Does anybody have a fix for the script exception (red button error) on the East Midlands Class 222 MCO, MFO, MSO & MSRMB units so that they can be used in native mode in 2009 & 2010 without having to keep cancelling the red button.

I know I can use compatability mode to avoid this niggle but I prefer to use native mode for better frame rates.

I have script editing software (CONTEXT with trainzscript add-on)

The kuids are;
kuid2:116035:22236:1
kuid2:116035:22233:1
kuid2:116035:22226:1
kuid2:116035:22223:1

Thanks

Scottish
 
Last edited:
@Shane

Tread Exception: ER_NullReference, line 1366, file train.gs
Stack dump:
function $Permit[]@Train::TakePermitOnTrack(bool), line -1
function $void@Train::Init(), line 1437

'train.gs' is one of Auran's built-in script libraries.

The unit has it's own script 'class222.gs' therefore I think there must be an incorrect or missing call in this script which is causing an exception in the library script 'train.gs'.

Scottish
 
I remember seeing something on these forums regarding TakePermitOnTrack but I cannot seem to remember where it was.

I also have encountered this error in Native mode, but not in compatibility mode - perhaps there is a hidden fault with the train?

Shane
 
Hi

This error also shows when the pendolino by nexusdj and the class 91 sets by peterdhicks are placed on the track in native mode. I tried deleting the references to the script in the config file for each vehicle and the pendolino placed correctly then but the error was still there on the class 91 set. Hopefully someone has a solution to this as they are excellent models which I would love to run on the Midshire Mainline route using the SCS2006 rule but the assets will not show when placed using that rule in native mode.

Regards

Brian
 
I have noticed on the Class 222's, that if you scroll along the train very slowly in "Driver" or "Surveyor", the doors along the consist vanish, as the doors go towards the edge of the screen, I was wondering could this be a part of the fault.

Joe Airtime
 
There are a number of places in auran's scripts where there is what is called a 'chained' function call, that is, one function returns an object, and then another function is called on that object, of the form:

blah = Object.A().B();

Unfortunately, often the first function call can return 'null' to indicate failure, and this will break the second call.

In the case of the TakePermitOnTrack problem the call is made against a number of vehicles in a consist, and for some reason recent changes have made it so that some consists end up with vehicles that are 'null', and thus the function fails.

The work-around I use, is to modify train.gs to bail out of the permit-taking step if the vehicle it encounters is null. This involves changing train.gs (after making a backup) and adding at line 1366:

Code: 
                        if (v[i] == null) break;
train.gs also has another failure point in these situations, in UpdateViewDetails, that is fixed by changing line 4614 to:

Code: 
       if ((vehicles[i] != null) and (!vehicles[i].isclass(Locomotive)))
There are many more of these kind of bugs spread through the scripts folder that result in scripting crashes with these 'odd' consists. Some of these bugs have likely been there a long time, but only recently have scripting exceptions been so fatal (quite often an exception will stop scripts running on that object for the rest of the duration of the session, resulting in controls stopping working and AI failing from that point on).

Similar bugs also exist in the couplecommand and decouplecommand driver command objects, as well as many 3rd party scripts.

Now that compatibility mode is going away, these script bugs will need to be fixed or else they will render sessions inoperable.
 
Last edited:
Hi

Thanks for the information NikkiA. I have been examining scripts in notepad and they are starting to become a little clearer but as I am sure you are aware it shows no line numbers. Is there another text editor available that shows line numbers so that I can implement your fixes?

Regards

Brian
 
Ok, I've just tried the fix that Nikkia posted and now get the following error:

Error: Unable to link compiled script class.

Tried reverting to my backup Train.gs and it still doesn't work.

Nathan
 
Napalm said:
Ok, I've just tried the fix that Nikkia posted and now get the following error:

Error: Unable to link compiled script class.

Tried reverting to my backup Train.gs and it still doesn't work.

Nathan
Click to expand...

That's very strange, the fix I was talking about is to edit the system-wide train.gs that's in \ts2010\scripts\train.gs. It shouldn't involve committing/reverting anything.

The few times I've had that error message it was usually related to character encoding, and the file having some characters in it that confused trainz somehow.
 
Hmm, strange, since posting my last message it's rectified itself but now gives me a script error in game about the line I inserted at Line 1366 and also 2 script errors for the ACSLib script.

Nathan
 
Napalm said:
Hmm, strange, since posting my last message it's rectified itself but now gives me a script error in game about the line I inserted at Line 1366 and also 2 script errors for the ACSLib script.

Nathan
Click to expand...

Can you screenshot the error for line 1366 that you added (best to send it as a PM since this board doesn't allow large images) ?
 
NikkiA said:
Can you screenshot the error for line 1366 that you added (best to send it as a PM since this board doesn't allow large images) ?
Click to expand...

Ok, quick question, do you insert the new line before or after the first line of the Permit rule?

Nathan
 
Napalm said:
Ok, quick question, do you insert the new line before or after the first line of the Permit rule?

Nathan
Click to expand...


I have it right after the comment about permits may not be granted ...

ie:

Original:
Code: 
        for (i = 0; i < v.size(); i++)
        {
            // NOTE: The permit may not be granted if someone else already has it, but
            // at least we're next in line if they leave..

            Permit permit = v[i].RequestTrackPermit( v[i].GetDirectionRelativeToTrain() == direction, me );

Modified:
Code: 
        for (i = 0; i < v.size(); i++)
        {
            // NOTE: The permit may not be granted if someone else already has it, but
            // at least we're next in line if they leave..

                        if (v[i] == null) break;

            Permit permit = v[i].RequestTrackPermit( v[i].GetDirectionRelativeToTrain() == direction, me );
 
@Nikki, thanks for your help.

I have added the new line at 1366 exactly as shown on your modified example above. I also modified line 4614 (now line 4615 after adding the extra line at 1366) as you suggested. I can confirm that a single coach unit can now be placed on it's own on the track without the original error occurring.

However a new error relating to different scrips now appears when the coach is coupled to another.

Thread Exception:ER_NullReference, line 598, file acslib.gs

Stack dump:
function $void@ACSlib::findConnectedEnds(Vehicle), line-1
function $string@ACSlib::LibraryCall(string,string[], GSObject[]), line 622
function $void@class222::Init(), line 272
function $void@MeshObject::Init(Asset), line 316


ACSlib line 622 reads;

retval="LibraryCallsucceeded: ACSrecalc called with vehicle specified";


class222 line 272 reads;

AddHandler(me, "World", "ModuleInit", "VehicleDecoupleHandler");

MeshObject line 316 reads;

inherited(asset);

It appears that there are a series of script changes needed to fix to 2009 & 2010 requirements, and I don't feel I should be bothering you any further unless you are willing to continue working on the problem.

I do agree with you that script errors have now taken on an important role since as you say running in compatability mode will not be an option in the future.

Scottish
 
Scottish said:
@Nikki, thanks for your help.

I have added the new line at 1366 exactly as shown on your modified example above. I also modified line 4614 (now line 4615 after adding the extra line at 1366) as you suggested. I can confirm that a single coach unit can now be placed on it's own on the track without the original error occurring.

However a new error relating to different scrips now appears when the coach is coupled to another.
Click to expand...

I'm taking a look at the ACSLib exceptions to see if I can knock up a workaround for them, but it's taking longer than I hoped. Just wanted to let you know I'm not ignoring this thread, just won't be able to reply with the response I want to until I've finished a little debugging :)
 
You must log in or register to reply here.

Similar threads

S
Users of peterdhicks' East Midlands Class 222 trains - do not install todays updates
2
Replies
37
Views
9K
PEV
P
M
Class 222 problems
Replies
2
Views
2K
itareus
I
Back
Top