One last appeal to N3V
- Thread starter sniper297
- Start date
shaneturner12
Tutorial Creator
I'm also having trouble understanding the relevance as well, but it does make me wonder what differences there is between the two tests (the one at Auran/N3V QA and the one on sniper297's system).
Shane
EDIT: I'm currently testing the route/session in question, and have noticed that there are several missing 523: kuids, which I am wondering if these are speedtrees.
Shane
EDIT: I'm currently testing the route/session in question, and have noticed that there are several missing 523: kuids, which I am wondering if these are speedtrees.
Last edited:
Not quite sure that I see the relevance
chris
Two very different aircraft, performance characteristics, stall speeds and maybe angles of attack, etc. Though I'm not sure how that plays into things either, since hardware differences shouldn't matter in the case of high-level application bugs like what Sniper is describing. Perhaps more detail is needed.
How many missing 523 KUIDs you get are dependent on the connection glitches, some days content manager shows a KUID2 replacement available for download, other days it shows it as an unknown KUID. None are speedtrees, I never used any. The first class download station is running a lot better these days than it was a few months ago, I don't get nearly as many issues with content listed on the black pages for more than 48 hours not showing up in content manager, nor do I get that "invalid username or password" 3 or 4 times a week, so it's a lot more reliable now.
Hardware issue? Dunno. Main reason I bought TS2009 in the first place was because my Pentium D 2.8ghz isn't good enough for TS2010 or TS12, I was hoping to get better framerates with TS2009. Forlorn hope.
2009 calls for Pentium 4 2.2ghz, I have Pentium D 2.8ghz dual core.
2009 calls for 64mb 3D video card, I have 512mb Nvidia 8500GT.
2009 calls for 1gb RAM, I have 2gb Crucial Ballistix.
But I can duplicate the session crash every time, install any of the Chicago Metro sessions into a new copy of TS2009 build 44653 and try to edit the session rules and it crashes to desktop.
bellz,<kuid:66277:80002>
Load Passengers,<kuid2:192081:5:2>
pantz,<kuid:66277:80004>
Schedule Library,<kuid2:192081:12:4>
Trigger Multiple Signals,<kuid2:116387:26:1>
Some of those should download automatically for the end user since I manually added them to the KUID table for the route itself, even tho the route doesn't need them, the idea being if the route gets the rules and scripts I won't have to remember to manually add them to the KUID table for every new session I create. Problem is trying to figure out which rules are needed and not built in, which takes us back to the basic question - why can't surveyor be programmed to read the session rules and driver commands to add that stuff to the KUID table?
Hardware issue? Dunno. Main reason I bought TS2009 in the first place was because my Pentium D 2.8ghz isn't good enough for TS2010 or TS12, I was hoping to get better framerates with TS2009. Forlorn hope.
2009 calls for Pentium 4 2.2ghz, I have Pentium D 2.8ghz dual core.
2009 calls for 64mb 3D video card, I have 512mb Nvidia 8500GT.
2009 calls for 1gb RAM, I have 2gb Crucial Ballistix.
But I can duplicate the session crash every time, install any of the Chicago Metro sessions into a new copy of TS2009 build 44653 and try to edit the session rules and it crashes to desktop.
bellz,<kuid:66277:80002>
Load Passengers,<kuid2:192081:5:2>
pantz,<kuid:66277:80004>
Schedule Library,<kuid2:192081:12:4>
Trigger Multiple Signals,<kuid2:116387:26:1>
Some of those should download automatically for the end user since I manually added them to the KUID table for the route itself, even tho the route doesn't need them, the idea being if the route gets the rules and scripts I won't have to remember to manually add them to the KUID table for every new session I create. Problem is trying to figure out which rules are needed and not built in, which takes us back to the basic question - why can't surveyor be programmed to read the session rules and driver commands to add that stuff to the KUID table?
shaneturner12
Tutorial Creator
I know what you mean - at least with portals, you can use the Portal Dependencies rule I mentioned further up.
Perhaps this is another of the SP4 bugs (if it's TS2009 SP4 that is having trouble)
Shane
Perhaps this is another of the SP4 bugs (if it's TS2009 SP4 that is having trouble)
Shane
None of it would load at all in TS2009 SP3 or earlier, and all the TS2009 versions up to and including SP3 have other bugs that make it unusable for me;
http://forums.auran.com/trainz/showpost.php?p=897419&postcount=2
Those cars are listed for TS2009, but the attachments are all cattywampus in every TS2009 build except SP4.
Again tho, anyone trying to duplicate this no cheating allowed - a n00b downloading into a new fresh virgin copy of TS2009 SP4 will not have the above listed rules installed, so no fair downloading bellz and pantz before testing.
Other stuff (side topics), TS2009 SP4 is the only one I get this exact program crash with, TS2010 and TS12 on my system usually throw script errors from missing session rules, but they rarely crash from that alone. Moot point anyway, if it was programmed to automatically add session rules to the KUID table there wouldn't be any missing session rules in the first place.
http://forums.auran.com/trainz/showpost.php?p=897419&postcount=2
Those cars are listed for TS2009, but the attachments are all cattywampus in every TS2009 build except SP4.
Again tho, anyone trying to duplicate this no cheating allowed - a n00b downloading into a new fresh virgin copy of TS2009 SP4 will not have the above listed rules installed, so no fair downloading bellz and pantz before testing.
Other stuff (side topics), TS2009 SP4 is the only one I get this exact program crash with, TS2010 and TS12 on my system usually throw script errors from missing session rules, but they rarely crash from that alone. Moot point anyway, if it was programmed to automatically add session rules to the KUID table there wouldn't be any missing session rules in the first place.
No problem. The reason I did it that way is so when he creates new routes or sessions he has his own author KUID number. The eventual goal was to get another copy of TS12 registered in his name so we could do multiplayer together, but without better hardware for both of us or a drastic overhaul of the game engine to make it run smoother on lower spec hardware, I can't see the point of spending more money on it.
Almost off topic, but when trying to counter the TS10 ground-texture bug by manually editing the kuid table to include textures known to be missing from the list testers found the these assets added manually either didn't download or downloaded unreliably. Seems your experience is duplicating this. The only goof-proof fix we found was to pack the missing assets in the route cdp or supply them as a separate download. CM consults something more than just the kuid table when downloading content.
Those 'kuid:523' assets are industrial structures built-in in TS10 but are not in TS09SP4. These seem not to have made the DLS 'old-built-in' list or at best they download unreliably, certainly my testers never got them to install. I used several on EK3 and again I supply them as a separate cdp for 09 users on the basis that TS10 and TS09SP4 are supposed to be more-or-less the same thing. Because of the DLS issue with these assets I haven't used them since, which is a shame as they are pretty good content.
I guess this is one advantage of distributing from a third party site, I can work around with fixes like the 'separate cdp' thing or including third-party assets in the route cdp. Neither will work with DLS distribution...
Andy
Last edited:
I did have something similar with a custom ground texture, it did not add itself to the KUID table for some reason. Opened the route for edit and painted more of the same texture and saved, that time it did add itself to the KUID table. Compared to the session rules problem that's more like a minor glitch than a major bug, the worst that happens is the end user gets a blank grid where the texture should be, and if he's told to download the texture it's all fixed.
This is not unique to the DLS tho, I get it on some 3rd party websites as well - and it always boils down to improper testing procedures. New guy downloads a trainset or route, gets a bunch of unknown KUIDs or a crash, nobody can figure out why because they all have the SD40 bogey-gray from other models they downloaded previously, or already had Trigger Multiple Signals installed from 3 years ago. The only correct way to test these things is to pretend you're a brand new user, import the model into a fresh install of the game that has absolutely nothing but the default content that came with the game, and see if it works in that version. That's the only way to find out if it will have missing dependencies or unknown KUIDs, if you test in your everyday play copy it might work fine because one of the dependencies is something you downloaded or imported from another version years ago and forgot you had it. I assume the N3V QA people know enough to test in a virgin copy of the game to ensure they're testing under actual battle conditions, but if they can't duplicate any of these problems perhaps that's a wrong assumption.
This is not unique to the DLS tho, I get it on some 3rd party websites as well - and it always boils down to improper testing procedures. New guy downloads a trainset or route, gets a bunch of unknown KUIDs or a crash, nobody can figure out why because they all have the SD40 bogey-gray from other models they downloaded previously, or already had Trigger Multiple Signals installed from 3 years ago. The only correct way to test these things is to pretend you're a brand new user, import the model into a fresh install of the game that has absolutely nothing but the default content that came with the game, and see if it works in that version. That's the only way to find out if it will have missing dependencies or unknown KUIDs, if you test in your everyday play copy it might work fine because one of the dependencies is something you downloaded or imported from another version years ago and forgot you had it. I assume the N3V QA people know enough to test in a virgin copy of the game to ensure they're testing under actual battle conditions, but if they can't duplicate any of these problems perhaps that's a wrong assumption.
Last edited:
Relevance
Just popped into my head, sorry if it seemed irrelevant. My point, if there was one, is that replicating a problem necessarily involves replicating the environment in which it happened (or happens). It's not reasonable to expect N3V to maintain (or be able to create for diagnostic purposes) every possible supported build of the game, and it speaks well of the company that they attempted the experiment with an available build/environment.
"CND" (Could Not Duplicate, not the organization that invented the peace symbol) is a timeless source of both levity and irritation between operations (users) and maintenance (help desk).
Not quite sure that I see the relevance
chris
Just popped into my head, sorry if it seemed irrelevant. My point, if there was one, is that replicating a problem necessarily involves replicating the environment in which it happened (or happens). It's not reasonable to expect N3V to maintain (or be able to create for diagnostic purposes) every possible supported build of the game, and it speaks well of the company that they attempted the experiment with an available build/environment.
"CND" (Could Not Duplicate, not the organization that invented the peace symbol) is a timeless source of both levity and irritation between operations (users) and maintenance (help desk).
Kinda like the spitting sputtering popping backfiring engine that smooths out and runs like a Swiss watch as soon as you turn the last corner heading to the mechanic. :hehe: Could be relevant tho, one MSTS gripe driving everyone crazy back in 2003 was a route that caused crashes for some users and not others - turned out the problem was a steel mill someone created with a 1024x1024 texture, the common denominator was 32mb or lower video cards, everyone who did not have the problem had a 64mb video card. If the user has a problem on minimum system specs, testing on nuclear powered Alienware might just overpower the problem so it doesn't duplicate.
With computers it's called the tech-effect. The problems go away when the technician walks to the desktop. It happens all the time at work!
I remember the MSTS bug. I had one of those 32MB video cards back then.
John
CM checks the TAD dependencies list if the asset is local, or the DLS's dependency list if the asset is on the DLS. In both cases, the dependency list is formed from the item's config.txt file and includes both the explicit list of dependencies and also a scan of other KUIDs which appear in the config file.
chris
OFF TOPIC
Apologies, this is OT but it matters!
TS10 does not save all ground textures used on a route to the kuid table. Kuid:123:456 is identified as an omitted ground texture. kuid:123:456 is known to be a DLS dependency and is manually added to the route's kuid table. CM still does NOT download that texture, or at the very least it does not download for all testers every time. It seemed like the simple fix so we tried it. We tried it lots. We failed.
More or less back on-topic: All my route testing and all testing by my principle tester is performed on virgin installs of the appropriate Trainz version, so the 'already got it' goof doesn't happen. There is NO other way to adequately test a route, specially when identifying hard-to-get or otherwise troublesome content
Andy...
Apologies, this is OT but it matters!
TS10 does not save all ground textures used on a route to the kuid table. Kuid:123:456 is identified as an omitted ground texture. kuid:123:456 is known to be a DLS dependency and is manually added to the route's kuid table. CM still does NOT download that texture, or at the very least it does not download for all testers every time. It seemed like the simple fix so we tried it. We tried it lots. We failed.
More or less back on-topic: All my route testing and all testing by my principle tester is performed on virgin installs of the appropriate Trainz version, so the 'already got it' goof doesn't happen. There is NO other way to adequately test a route, specially when identifying hard-to-get or otherwise troublesome content
Andy...
Last edited:
I don't remember the specifics, but I believe that you are correct and that this issue was found and fixed in one of the TS12 patches.
If you're manually patching the config.txt file's kuid-table to work around the issue, you'll need to make sure that any changes are made *before* the content is uploaded to the DLS.
.. virgin installs of the appropriate Trainz version, so the 'already got it' goof doesn't happen. There is NO other way to adequately test a route, specially when identifying hard-to-get or otherwise troublesome content
Absolutely. Our QA guys spend a lot of time performing clean installs for this very reason. There are just too many assumptions that can go wrong if you try and test with existing installs, even if you think you've done everything by the book.
chris
Apologies Snipe, but I have tried to get Chris' attention on this issue several times and failed, I'm not missing this opportunity!
It was. I know it is more-or-less N3V policy to not patch an 'old' product, but this glitch/bug/whatever is a fundamental error in TS10 and it should be fixed. The TS12 'fix' does at least give us a fool-proof means of generating a list of ground textures missed by TS10. Load a TS10 route in a virgin TS12 install, get all dependencies then 'Save As' in 12. This will generate a Missing Assets list which neatly identifies all DLS and 3rd Party ground textures missed in the TS10 save. Quick and easy, assuming you are happy to accept that TS12 is the ONLY check for a fundamental error in TS10!
Obviously. The example given was a new route and pre-existing DLS ground textures. The manually patched route config's kuid table still does not yield a fool-proof download of the added ground texture assets. This fact is what led me to the conclusion that CM consults 'something' in addition to the route config's kuid table.
There is no book
Andy...
It was. I know it is more-or-less N3V policy to not patch an 'old' product, but this glitch/bug/whatever is a fundamental error in TS10 and it should be fixed. The TS12 'fix' does at least give us a fool-proof means of generating a list of ground textures missed by TS10. Load a TS10 route in a virgin TS12 install, get all dependencies then 'Save As' in 12. This will generate a Missing Assets list which neatly identifies all DLS and 3rd Party ground textures missed in the TS10 save. Quick and easy, assuming you are happy to accept that TS12 is the ONLY check for a fundamental error in TS10!
Obviously. The example given was a new route and pre-existing DLS ground textures. The manually patched route config's kuid table still does not yield a fool-proof download of the added ground texture assets. This fact is what led me to the conclusion that CM consults 'something' in addition to the route config's kuid table.
There is no book
Andy...
Not really, it's just resource-intensive. If we feel that the benefits of a patch outweighs the cost, we'll do it. The only time that we'll definitively avoid patching is if the product is end-of-support.
It doesn't. Neither CM nor the DLS are capable of looking inside the route files themselves. They just blindly trust the config.txt file.
chris
