One last appeal to N3V

sniper297

Coconut God
I bought TS2009 a couple weeks ago, and after installing and patching to SP4 I tried to get my route into it.

13562060.jpg


According to the label, that route and session should work out of the box, no assembly required, for anyone who has TS2009 SP4. It don't. First problem was the route dependencies, some of the assets built in to TS2010 are either faulty when downloaded into TS2009, or even unknown KUIDs. After cloning and fiddling with the route for a week I finally got the clone to load into TS2009, but none of the sessions would load, script errors in driver commands. Trying to edit any of them resulted in the program crashing with the send/don't send error message.

Finally figured out the problem today -
bellz,<kuid:66277:80002>

That's it, one missing script screws up the whole session so badly it crashes the program. So why didn't it download automatically with the session if the session requires it? Not in the KUID table for the session. Why is it not in the KUID table?

http://forums.auran.com/trainz/showthread.php?t=73464

One story is it's the fault of the script/rule author, he was supposed to add some kind of tag to it that would make it automatically add itself to the KUID table. The other story I got was no special tag is needed, any rule or script required by the session is supposed to add itself to the KUID table so it downloads automatically if the end user doesn't have it already installed.

Whatever the truth is, it's not working, and needs to be fixed. I open the config.txt to manually add a rule to the KUID table and that works, but if I edit the session at any time after manually adding it, surveyor decides it's not needed and deletes it from the KUID table.

Surveyor in a session should consult both the portals spawning trains and the session rules and driver commands list so that anything needed by the session is added to the KUID table, otherwise the whole idea of the download helper is a meaningless joke. If you want clueless newbies buying Trainz and finding it easy to use so they recommend it to their friends, you need to fix these things so it IS easy to use instead of constantly blaming content creators for problems caused by the creation tools.
 
I may be able to offer some help on that one.

The Portal Dependencies rule is supposed to add the required commands used in portals (trains,drivers, even driver commands)

Shane
 
The unknown KUIDs part may be do to the fact that the dependencies are located on a third party site, and are not known to the DLS. A lot of those are great content and well worth the search for them. Most third party groups are glad to help when looking for these dependencies if you make a post listing them.

Cheers

AJ
 
If TS2010 and TS12 are considered third party websites, that's true.

Unknown Location: <kuid:523:1142>
Unknown Location: <kuid:523:1169>
Unknown Location: <kuid2:98966:24985:4>

Built into TS2010 and TS12, unknown location in TS2009 SP4.
 
If TS2010 and TS12 are considered third party websites, that's true.

Unknown Location: <kuid:523:1142>
Unknown Location: <kuid:523:1169>
Unknown Location: <kuid2:98966:24985:4>

Built into TS2010 and TS12, unknown location in TS2009 SP4.

TS2010 built-in content is only intended for TS2010 users, not TS2009 users.

chris
 
I knew this was going into a program loop

"TS2010 built-in content is only intended for TS2010 users, not TS2009 users."

Then a route created in TS2010 with TS2010 built in content should not be labeled as TS2009 SP4/TS2010, see the picture in the first post. I didn't label the route as TS2009 SP4 compatible, your bot did.
 
The ability to load TS2010 content was specifically intended for regular content. A route built in TS2010 will almost always have TS2010 only content in it (particularly speed trees), and as such is unlikely to work in TS2009 SP4.

On the other hand, TS2009 SP4 will generally be able to use content that was built for TS2010 SP3 (except SpeedTree assets!). Or, more, it means that TS2009 SP4 users can make content to the same specs as TS2010 SP3.

This is useful, since TS2010 introduced the seasonal assets system. In this, the content using this system can be used in both versions (unless the build number is set higher than this!), allowing more content to use this without restricting it to TS2010+ users :)

It also introduced some support for the 'layers' system from TS2010, again allowing routes to be used (ignoring missing dependencies). If a created so desired, they could build the route using only TS2009 content (replacing TS2010 assets during testing...), and hence have a TS2010 spec route that also functions in TS2009.
 
Then a route created in TS2010 with TS2010 built in content should not be labeled as TS2009 SP4/TS2010, see the picture in the first post. I didn't label the route as TS2009 SP4 compatible, your bot did.

The DLS doesn't make any guarantees about dependencies. They may be for a newer version of Trainz, may not be available on the DLS, or may not even exist.

All the DLS is telling you is that the asset in question is compatible with TS2009 SP4 and TS2010, which it is.

chris
 
"as such is unlikely to work in TS2009 SP4." Then the label on the download station shouldn't SAY TS2009 SP4, should it?

Anyway back to the main topic, create a session with rules or scripts that are not built in, those are needed for the session to work properly, why don't they automatically get added to the KUID table like any other dependency required by the session? Let me rephrase that since I already know why, it's not programmed to check session rules and portals. The question is why can't it be reprogrammed to check the session rules and commands at least, if not what's programmed to spawn from the portals? All that information IS stored in the session data itself, it just needs something to extract it and add it to the KUID table for the session.
 
"All the DLS is telling you is that the asset in question is compatible with TS2009 SP4"

How can you call it "compatible" if it's missing dependencies that the end user has no way to download?
 
As above, this is to allow any asset with a build number for TS2010 SP3 to run in TS2009 SP4.

It is possible to create a route in TS2010 SP3 that will work in TS2009 SP4, so long as you don't use items that are only available in TS2010 SP3.

How can you call it "compatible" if it's missing dependencies that the end user has no way to download?

These are two very different things. I can give you a TS2009 SP4 route that has missing dependencies from one of the add-on packs (these can't be downloaded without an extra purchase, same as TS2010...). Same as I can give you a TS2010 SP3 route that uses only TS2009 SP4 content... When we say compatible, in terms of Trainz versions, it is purely on the 'code' side. What gets used on the layout is a completely different matter, and is entirely up to the route builder.

Compatibility with TS2009 SP4 is not guarantee of having access to all of the assets. For a route, this will actually run with missing assets (track will be replaced with a placeholder, and other objects are simply ignored). This can leave you with a less than ideal looking layout, however it will run, and hence is compatible...

As earlier, the idea is that TS2009 SP4 and TS2010 SP3 can have access to the same content, using the same functions (mainly the seasonal content!). It's not so much intended for routes, however the ability is there if desired. It just needs to be remembered that a route built for TS2010 may have missing dependencies...
 
"All the DLS is telling you is that the asset in question is compatible with TS2009 SP4"

How can you call it "compatible" if it's missing dependencies that the end user has no way to download?

The route itself is compatible and will load in the specified products. We do not make any guarantees about the dependencies and never have done.

It's like me selling you a car but not the petrol. I can guarantee you the car is in good condition, but if you don't put any petrol in it then that's not really my problem. The car itself is fine, but its usefulness to you may be dependant on other factors.

chris
 
Well, we obviously have different definitions of "compatible", the one I go by;

Capable of orderly, efficient integration and operation with other elements in a system with no modification or conversion required.

Again you're placing the onus on the content creator, if I hadn't bought TS2009 how could I possibly know when creating the route which assets are unknown KUIDs in TS2009, and more importantly which ones can be downloaded but are flagged as faulty in TS2009? That's another issue, 3rd party content distributed as "built in" gets bypassed by the error checker, it really should be updated and repaired before it's packaged with the new Trainz version. When I first patched 2009 to SP4 my route wouldn't load in surveyor without crashing the program, none of the sessions would load in surveyor or driver without crashing. I had to clone the route in TS2010, compare all the unknown KUIDs and faulty assets and assets with unknown or faulty subdependencies, delete all those manually from the route before I could get it to load in TS2009 at all. And of course figure out which session rules and scripts and commands were needed but not built in, since those aren't in the KUID table for the session you can't just right click and view dependencies because they're not listed as dependencies because they're not in the KUID table! :'( Someone has a thread going about hosting on the DLS versus 3rd party websites, to me the whole point of hosting on the DLS is for ease and simplicity - this is neither easy or simple.
 
Again you're placing the onus on the content creator,...

Well, yes and no.

We're providing a service. We could provide more. We could provide less. We're not forcing the "content creator" to do anything at all, but if you want to use our service then there are certain steps that you may wish to take.

We do work towards making things easier for everyone involved, but we can't make the kind of sweeping changes that you're talking about without aggravating large segments of our community. For example, to do what you're asking would require banning third-party download sites since in order to check all dependencies, we'd have to be hosting those dependencies on the DLS.


..it really should be updated and repaired before it's packaged with the new Trainz version.

Generally speaking, it is. We only turn off error-checking for the final release builds, because it's too slow to run error checking of ~8GB of content at installation time on the end user's machine.

Things do slip through the gaps, but that's the exception rather than the rule.


When I first patched 2009 to SP4 my route wouldn't load in surveyor without crashing the program...

If you find an asset which reproducibly crashes Trainz, we'd love to hear about it.

chris
 
if a driver command or rule is missing from a session it will crash trainz.

i think possibly driver assets too if something tries to interact with a specific one, but i cant remember for certain if its a crash to desktop or a session breaking assertion.
 
Last edited:
if a driver command or rule is missing from a session it will crash trainz.

i think possibly driver assets too if something tries to interact with a specific one, but i cant remember for certain if its a crash to desktop or a session breaking assertion.

I don't think this is correct. If you strongly believe this to be the case then please set up a test asset that we can use to repro the behaviour.

chris
 
It certainly crashes TS2009 SP4, see the original post - crashed to desktop with the send/don't send error message every time I tried to edit the session until I got all the rules including Bellz - which is not actually used in the session, but it's checked on in driver commands, and that alone is enough to crash TS2009 if it's not installed.

Honestly, you can check this out yourself - start with a virgin copy of TS2009 patched to SP4, download;

Chicago Metro V2 GRAND 2040,<kuid:522774:100423>
Chicago Metro 2.2,<kuid2:522774:100023:2>

And see what you get.

As for faulty assets crashing TS2009;

CNR Ash Conveyor (Stratford),<kuid2:87145:28053:1>

Built into TS2010, not built into TS2009, but downloadable - and faulty.

Error: Attachment point animated-mesh (load) in 'queues\ash_in_out' was not found.

Delete that one and the route will load in TS2009 surveyor without crashing, when it's installed trying to load the route causes TS2009 to crash to desktop.
 
Honestly, you can check this out yourself - start with a virgin copy of TS2009 patched to SP4, download;

..

Delete that one and the route will load in TS2009 surveyor without crashing, when it's installed trying to load the route causes TS2009 to crash to desktop.

Sorry to say that I asked our QA to try the above steps, and they report that they're not able to repro any crashes. (They were testing with build 44653.)

kind regards,

chris
 
"Could Not Duplicate"

"When I throttle back my F-86 with half flaps, it stalls."

"We throttled back with half flaps on our F-100 and it didn't stall. Could not duplicate problem."
 
Back
Top