Script Array Issue, Base Zero

I am posting this in the beta section, as it is a going forward thing. The summations in this post are my personal observations. This post deals with scripts only.

So what I found is that as Trainz builds increase, and sections of the game engine are being updated, and being fixed correctly. The problem is with assets that have been created in earlier versions were built with an invalid variable array call, which used the number one as a base, when in proper programming, it should have been zero, break.

Each asset with scripts that makes calls to the soup, if the base is offset by one, really wierd things can happen. As Trainz develops, and sections of the engine are updated, and breaks some assets depending on which section of the engine are updated.

So this will require that this is true and verified, then once it's truely identified, asset creators, or repair groups, can easily find and update the assets with scipts that break. There is no sigular build number where you can say this is the cutoff, different assets use calls that may have been updated at different times.

Here are the real life encounters that I have worked through, and identified with the issue, and were discovered during different updates;

ATLS Controller/Slave Track Object
Settings duplicates the first found track object, breaks old routes TRS22 Plus

Decouple DLX
Found the base in script was 1, changed to 0 and problem was fixed for TRS19

Copy and Paste
If a section being copied contains scenery splines with connectors, like a YARN Sidewalk, when pasted, will duplicate some splines under visible splines TRS19

And I am sure there are a lot more..

If I am correct, this could be the cause for many complaints, but as I said, it is the correct way moving forward. So if someone in Trainz programming department can confirm that this is something that they have changed/repaired, it would go along way to further the rapid development of a better Trainz world for developers and users, or at least me.

1. Acknowledgement of issue
2. Want a better Trainz platform
3. Uniformity means Reliability

If I am totally wrong here, or that I should not have posted this here, please feel free to bash me, but I believe this is the cause of a large percentage of scrippted assets that recently have broke.

I don't understand what you are getting at. It is OK to use any index reference as long as the array (I hesitate to use that term, since they are one dimensional only) is large enough to allow for the access used in the script. Are you saying that different Trainz versions access lists differently?

pitkin said:

I don't understand what you are getting at. It is OK to use any starting index as long as the array (I hesitate to use that term, since they are one dimensional only) is large enough to allow for the access used in the script. Are you saying that different Trainz versions access lists differently?

Click to expand...

IMO Wrong, math is math, if everyone is not on the same 'base' the problems will continue.. When you start with nothing it's zero. Add one it's one.

Did you know the guy that came up with the code to take a 28K modem doubled it's speed to 56K by adding a -1 to the logic, thus creating 3 states, 1, 0 and -1 (minus -1 was the third state). DC electronics, mostly it's an on or off state, but because DC electric has polarity, what happens when you reverse it, it creates a negative state.

This is a script and math issue. Again IMO

Lets say you have a consist, and I need to know the first wagon or loco depending on direction. If 0 is the base vs 1 is the base, am I picking the loco or the tender, the asset has the code written for one certian way, now the engine changes, the asset's script does not know that, and picks the tender instead of the loco.. The asset relies on the game engine script to be the same 'Every Single Time'. That's what makes asset creation easy (if you know how to program).

Let me get ahould of the engine, ill find the flaws, ive had to much to drink so to say, just another day in paradise. Please excuse me.

I don't believe that N3V have changed one of the fundamentals of Trainzscript but will believe that some don't understand it.

The CRG has had to fix very few assets because of broken code although some have been fixed to accommodate Trainzscript library updates.

What you are describing seem to me to be logic errors in the code. They don't show as validation errors but could fail in some circumstances because of exceptions for null pointers. i.e. an address, perhaps as an array index, that is pointing outside the bounds of an array.

If you find such a faulty asset and the original author cannot, or will not fix it, you can ask the CRG to have a look.

Almost everything is base zero in trainz


points in meshes
a.bog0 the first bogey
a.driver0 the first driver (that after 21 years a.driver1 does not work is another story)


arrays
the first entry of any array is Arrayname[0]


where is it not so:
trainlist, place a loco and it gets a 1 at the end of a name instead of a 0
yet often the loco is Vehicle[0]


trainzscript has hardly changed the last 20 years and where it changed,
it did not get really better
names got longer, FI GetVelocity(), GetSmoothedVelocity() or GetTrainVelocity().
instead of Find()
AsyncObjectSearchResult searchObj = World.GetNamedObjectList(AssetCategory.TrainCar, "");
totally unreadable for me.


Main thing is that whenever a change is made, older functions should still work
why? the original scripters are often gone, FI Andi, mutton, klausm etc etc
they cannot or will not update their scripts and others cant.

G.M. said:

Almost everything is base zero in trainz

Click to expand...

I like the word almost, this is what I was refferring to.

G.M. said:

arrays
the first entry of any array is Arrayname[0]

Click to expand...

In the scripts local environment, should always be true, which I know you are correct.

G.M. said:

where is it not so:
trainlist, place a loco and it gets a 1 at the end of a name instead of a 0
yet often the loco is Vehicle[0]

Click to expand...

When calling data from the soup, this is where it gets tricky. Decouple DLX works differently from TANE to TRS19 on this one with exactly what you are saying here, something changed. Not a real problem if you know up front what was changed. It took me a few weeks of fiddling around to figure it out. I think the way it is now is correct vs the way it was.

I am wondering what happened to the ATLS Controller/Slave in TRS22 is something to do with calling the trackside objects it controls, simular to what you describe with the trainlist call. Boat has said he will wait and see what comes out after the beta is done before he gets excited about it.