East Midlands Class 222 Units by peterdhicks Script Exception

Thanks Nikki,

I await with great anticipation. If you succeed it will fix the entire fleet of class 222 in different liveries and possibly some other assets I have in mind.

Scottish
 
NikkiA said:
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 :)
Click to expand...
Thanks for all your help in trying to get this problem solved.

Nathan
 
Napalm said:
Thanks for all your help in trying to get this problem solved.

Nathan
Click to expand...

I'd refrain from using the word 'solved' personally, these are workarounds, dirty hackish workarounds in many ways, that will simply allow trainz to run with the content.

The real solution is to finding out why certain rolling stock is returning 'null' when a consist is queried for it's vehicle list, but that might be a job for auran - we users may be able to poke around at a few possibilities, but there may be a core problem deep in the GetVehicles() function.

Personally, I'm of the mindset that errors should be headed off, so when you write a function that takes a vehicle as a parameter, if the parameter is null then you should bail out of that function at that point, as nothing you can do will result in anything good. Sadly auran's script writer and many other script writers haven't taken that route - largely due to the fact that until recently script errors were silently ignored, I suspect.
 
NikkiA said:
Personally, I'm of the mindset that errors should be headed off, so when you write a function that takes a vehicle as a parameter, if the parameter is null then you should bail out of that function at that point, as nothing you can do will result in anything good. Sadly auran's script writer and many other script writers haven't taken that route - largely due to the fact that until recently script errors were silently ignored, I suspect.
Click to expand...

I agree entirely with your sentiments. I have never programmed in C but I am proficient in Visual Basic.Net and Fortran. A good programmer will write his code to trap anything which could cause an exception and deal with this eventuality in his code.

Scottish
 
Ok, a work around for ACSLib....

In acslib.gs at line 560 we have the function that's the problem (findConnectedEnds), step one is to add a guard check for null vehicle's coming into the function:

Code: 
  void findConnectedEnds (Vehicle callingVehicle) {
    Train cvTrain = callingVehicle.GetMyTrain();
    Vehicle[] cars = cvTrain.GetVehicles();

becomes

Code: 
  void findConnectedEnds (Vehicle callingVehicle) {
    if (callingVehicle == null) return;
  
    Train cvTrain = callingVehicle.GetMyTrain();
    Vehicle[] cars = cvTrain.GetVehicles();

Step 2 is to add a guard check for null neighbours on the two couplings that are checked..

at line 582:

Code: 
    } else {
        if(wasVehicleCoupled(callingVehicle, !callingVehicle.GetDirectionRelativeToTrain(), false)) {
          // investigate vehicle in front

becomes
Code: 
   } else {
        if (cars[cvIndex-1] == null)
           return;

        if(wasVehicleCoupled(callingVehicle, !callingVehicle.GetDirectionRelativeToTrain(), false)) {
          // investigate vehicle in front

and at line 595:

Code: 
    } else {
        if(wasVehicleCoupled(callingVehicle, callingVehicle.GetDirectionRelativeToTrain(), false)) {
          // investigate vehicle behind

becomes...

Code: 
    } else {

    if (cars[cvIndex+1] == null)
       return;

        if(wasVehicleCoupled(callingVehicle, callingVehicle.GetDirectionRelativeToTrain(), false)) {
          // investigate vehicle behind

Using this I see no more exceptions from ACSLib with a E.M. 222 consist (admittably not a very prototypical consist of DMFO, MFO, MSRMB, MSO, MSO, DMSO)

In debugging this I've come to the conclusion that the base problem is a bug in the native function Train::GetVehicles() that will need to be fixed by Auran. In this particular test configuration, GetVehicles() is returning car, null, car, car, null, car, since it returns a valid vehicle for the first MSO but not the second, clearly there is nothing wrong with the MSO configuration, but something about the coupling between the MSO and DMSO is confusing trainz into corrupting the results of GetVehicles().

Putting these kind of guard conditions into scripts such as ACSLib isn't a 'bad' thing, since it reduces the impact of problems, and shouldn't in any way affect things when GetVehicles() returns data properly - well, ok, it might add a few extra CPU cycles, but not enough to be a major problem, and it's not running all the time anyway. They are, however, still a workaround to a lower level problem that needs resolving as well.

I will be reporting these findings to a helpdesk ticket.
 
Thanks Nikki,

No longer get the errors in the consist I have set up, although there is still some more underlying errors as I can't get the gang ways to show and it throws up an error when you try to edit the engines.

Never mind, maybe we will get these working as they should do one day.

Nathan
 
Thanks Nikki,

I have carried out the mods to script in your last post and can confirm that the exception shown in the asclib.gs file have gone and the full train set places without error.

However the next exception now shows as;

Thread Exception:ER_NullReference, line 37, file decouplecommand.gs
Stack dump:
function
$void@DecoupleCommand::AddCommandMenuItem(DriverCharacter,Menu), line -1

I am using TS2009 SP4 and the Decouple kuid containing the script file decouplecommand.gs is built-in kuid:-3:10082.

The code in this is;

(line37) if (vehicles[k].GetName() != "")
(line38) itemMenu.AddItem(vehicles[k].GetName(), me, "DecoupleItem", vehicles[k].GetName());

It looks like another example of a null return throwing an exception. I do hope this is the last problem and I really appreciate the time you are spending on this.

Scottish
 
Scottish said:
I do hope this is the last problem and I really appreciate the time you are spending on this.

Scottish
Click to expand...

Sadly, it won't be, these errors are littered throughout various commands, rules, and script libraries. The fix is usually the same - bail out of the function if the vehicle is 'null', but again, you probably lose some functionality of the command or library that is causing the problem - in this case, you probably can't choose the 'null' vehicles to decouple from (or couple to, since CoupleCommand will throw an exception too).

My personal experience has been that (de)CoupleCommand's exception is usually non-fatal, as is quickdrive which will also throw an exception, acslib and the one in train.gs that started this thread, are however usually fatal and block operation of the consist at all. The bottom line though is that we're just putting bandages on something that only Auran can really fix - that being that GetVehicles() is returning garbage.

If you want to fix it, it'll pretty much be the same trick as before, putting an if (vehicles[k] == null) break; before line 37.

Personally, I'm burnt out on it for today. I'll have a look at debugging why the gangways and cable packs aren't being triggered tomorrow, maybe :)
 
A Fix

I think I can save you any further work - wish I'd seen this thread earlier.

The reason the property browser won't work on these units is because the script defines the MCO, MFO, MSO, MSRMB as class Vehicle when in fact they should be class Locomotive.

This is, I think, because the config defines "engine 1" and, since TS2009, Trainz won't allow a vehicle script class with what is essentially a locomotive - or powered coach if you prefer

The fix is to open the class222.gs script file and change the line

Code: 
class class222 isclass Vehicle {
to

Code: 
class class222 isclass Locomotive {
This is essentially the same thing that stops Andi06 coaches from working in TS2010 Native, except in that case you need to change the script class from Locomotive to Vehicle.

This is about the limit of my script knowledge so apologies if I have got some of the terminology wrong.

The script fix does work however.
 
Last edited:
Thank you Stovepipe, what you posted works.

Although, just a warning for others, the L in locomotive needs to be a capital or it throws up about 200 errors.

Nathan
 
Yes just realised that myself. Post edited.

Glad you got it working.

EDIT : note that this fix also applies to adrian19's 442 5WES Wessex Units (the TSO and TSW)
 
Last edited:
This is a just note to report success.

Firstly I thank Nikki and Stovepipe for their efforts in replying to my thread. I have learned a lot about scripting from their replies.

The 222 fleet now works in native mode without showing a red button. The gangways do not work but this does not matter to me.

As part of my learning process I was curious to find out what changes to the various script files affected what errors so I firstly restored to original the ACSLib with no problem. I then restored the back-up I had made of the original train.gs file. This gave major problems because no sessions (custom or built-in) would load (after entering the loading screen with the vertical progress bar it would go back to the Driver Menu screen and would not load the session). I then also restored the original train.gsl file in the library folder but this resulted in Trainz not starting at all after pressing Start on the Start-up Loader window. After recovering from my coronary, I put back the train.gs which had been modified and train.gsl which co-existed with the modified .gs file and everything went back to normal - Phew! For some unknown reason Trainz did not like me restoring the backup copies of train.gs or train.gsl however I am happy to continue with the modified train.gs file since the changes recommended by Nikki in my opinion make the script more robust by safely trapping null returns.

I know that train.gsl is the binary compiled file produced by trainzutil from the ascii train.gs. It allowed me to modifiy the file initially but would not accept the back-up version.

Anyway, no problems now.

Thanks

Scottish
 
stovepipe said:
This is, I think, because the config defines "engine 1" and, since TS2009, Trainz won't allow a vehicle script class with what is essentially a locomotive - or powered coach if you prefer

The fix is to open the class222.gs script file and change the line
Code: 
class class222 isclass Vehicle {
to

Code: 
class class222 isclass Locomotive {
This is essentially the same thing that stops Andi06 coaches from working in TS2010 Native, except in that case you need to change the script class from Locomotive to Vehicle.
Click to expand...

I have been looking at a script exception in a different multiple unit by another creator which gives the identical error in the decouplecommand script as the 222's did before making the change you recommended. This time he has 'engine' set to zero in the config files for the intermediate coaches but sets 'isclass Locomotive' in the script. Do you think the opposite logic applies this time and that isclass should be Vehicle, or alternatively engine set to 1.

Scottish
 
A good chance it will be the same problem. If they are actually trailers rather than powered coaches, I would try changing the script and see.

There are times when the script calls the Locomotive class somewhere else and you will have to revert it back. If you then change the config to "engine 1" to match the script, it seems TS2010 Native will expect an interior to be present as well. I fixed one like this earlier today.

Which asset is it? I may have fixed it already.
 
Last edited:
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