We talked about this earlier in the thread, but point taken
...
This is appreciated, however the flipside of this is that you really aren't exposed to sufficient information to diagnose such problems in many cases. Even with a debug build of the game, which runs ~10 times slower than the release versions you see, we can't necessarily pinpoint every issue without spending days looking into a mostly-reproducible problem.
For example, in this case: you can state that what you're seeing is unacceptable (fair enough) and I can point out the reasons behind it and the situations in which you should see that behaviour. You can further state that you think it's going beyond what I've said and occurring in other situations (which is where we're at now.) Beyond that, there's not a lot of information that you can give us. That's no fault of yours, and there's little we can do to improve the communications there. We need to identify the causes, and for that, we need to repro the issue in-house (or, as in this case, work more closely with specific users who are having the problem and who are willing to sacrifice some of their own time and bandwidth to help test the issue.)
I'm not saying there are no cases where you can help; of course that would be rubbish. But thinking that computer-savvy alone is enough to figure out what's going on in a black-box system is equally wrong.
cheers,
chris
Since John seems to be seeing this more regularly, and he's got both the time and a computer to kill for, why don't you rope him into helping you pin this down. For my part, I'm concerned you're missing a big part of the complaint... that this is occurring AFTER circumstances should have validated data. LONG AFTER. // Frank
Apologies for bringing in emails, but you need to know, even at the risk of thinking it's a personal attack. I'm trying to get some progress here... and save a product I love that I percieve as slipping away into oblivion.
//Frank
(Refactored from the end to get us on point...)
I'm not really sure what more information I can give you at this point. Some of you are reporting something that (as far as we can tell, from the varied and sometimes vague reports that reach us) should not be happening. That's not a dig at any of you, but there's very little meaningful information that is user-visible here, so the amount of useful data we can get from your posts is minimal. It's not something that we can currently repro in-house, so (as above) our QA lead is talking to a few people and asking them to assist us with testing.
What's being referred to here is a background validation process that only shows up in the diagnostic logs. This is the same process that is run when you use 'View Errors and Warnings', when you install new content, when you the current version of dependencies, and so on- there are many legitimate reasons for it to occur; we have no concerns at all about the messages showing up in the logs; the question is simply whether there are some cases where unnecessary validation is occurring, and if so: why?
chris
That's actually quite false--at least from my experience, the problem is when it occurs and ties your hands despite things having been recently validated. You import CDP's... it validates, and then catches some errors. (Rob Shaw (? Robin Hood?) at TPR for example has two missing texture errors in his "MoCrossing's pack" importing that zip's CDPs finds immediately. I'm sure I've seen similar validations catch other minor miscreants from a couple of other sources. THAT'S FINE, but when I do a lot of importing, I commit manually in smallish groups, spend time whittling down a backlog of error fixings in TS09 or TS10, import some of those into TS12... then if I've done a lot, do a QDR when I quit for the evening (expecting the time penalty. THAT's schedulable, so OKAY. Your background validations, likely also occuring whilst I'm fixing errors in TS09 or TS10--even in TR06, depending on what's wrong. Mostly, I keep TS12 error free and download to one of the others first, validate, then bring that content into TS12.), then next day or two or three... when I relaunch... I have to wait all over again, like the OP says, for hours. THAT's NOT ACCEPTABLE. If it was valid in TS09-SP4, and TS10-SP3b has no issue with it, why sometimes does TS12 have this 'Auto-ghost-QDR' on relaunch.
SO explain to all of us why you call that sensible and expected below... THAT'S THE FRICKIN' PROBLEM. If we expect a wait, we can plan. If we get cold-cocked like this, we get angry... perhaps even more so than when we find errors in DLS content at this late date. Another unresolved thorn that keeps rubbing salt in the wounds.
// Frank
On the technical side of things, I’ve been thinking that perhaps this is a program bug more than actual data corruption that is triggering this revalidation process. SNIP,SNIP... Unfortunately in our case, the implantation is bugged so TADaemon has a hissy fit when things don’t appear right to it.
Close, but no.
If there's regular background validation occurring for no good user-initiated reason, then there's definitely a bug.
That has nothing to do with "dirty" flags or bad data or anything else. This is probably confusion on the speaker's part between database repair and validation.
Chris
Well, that's a relief. I can't imagine it as being anything but a BUG... and a costly one, at that. I think we can all understand that finishing a download, or importing a CDP batch, or cross-importing fixed assets from another Trainz directory would likely cause a validation process--particularly if the software was shut-down in the middle of doing such a 'background task'--as you believe they are.
IS THAT possibly the ACTUAL CAUSAL factor here? And perhaps TADdaemon/TrainzUtil just aren't saving the partially processed validation properly, or correctly reinitializing when reading it (a state save) back in? Could this be an error-trap case in that re-start after interruption sequence? THew answer in John's case is absolutely not... he's far too often twitted for watching until TADdaemon has long finished in Program Manager or process explorer. That tells me the key to this is understanding what is triggering the long sequence of validations he's seeing, and which twice have burned me. Both of us have seen it after a QDR beyond any shadow of a doubt... THAT should tell you something!
But the answers to the below two cases by you disturbs me far more greatly! Hopefully, you've just confused the timing of when things are vexing us... // Frank
From my experience, this has happened after performing a database repair, whether an EDR (a very, very rare occurrence at that), or an QDR.
CASE-1:
Definitely valid cases for it to occur, and not considered a problem. // ChrisB
(Frank, EYES POPPING! MOUTH OPEN gasping for air, WHAT!!!!!???? AFTER A REPAIR, on the next CM launch!??
Why would a re-validation of a just validated data set be a design goal?)
Other times this has kicked in after adding assets from CDPs. I recently downloaded some content from Jointed Rail, and sure as shootin, I got a long dreaded data validation afterwards. I also got this after installing the Murchison update, or rather bug fix.
CASE-2:
Definitely valid cases for it to occur, and not considered a problem. // ChrisB
You're saying that in these two cases just to screw with us, aren't you? What maggoty-brained rationale would there be to revalidate a data base just validated in the foreground by an EDR or QDR. EVER???... OR do you misconstrue the case John's presenting which is the unexpected validation is occurring HOURS AFTER, DAYS AFTER...
when a validation process has already occurred. WHY A DOUBLE TIME HIT ON THE USERS??? Why would we ever perform such if we get sandbagged the next time we load into the same kind of LENGTHY unproductive wait and delay just when we expect to play and be productive? Further, I know that particular Ten year Trainzer (Jcitron) watches his processes like a Hawk and waits until well after TADdaemon leaves the processes list and is gone for several minutes RELIGIOUSLY. See, he's a bit paranoid and burnt enough by this kind of jazz that he taught me to be similarly cautious. So we both validate shutdowns in Program Manager before doing anything that would affect that process. Waiting for these spurious 6-10 hour auto-validation or auto-EDRs is not something that makes for a happy Frank, and seems far from robust.
Further, even taking the case of the CDP's and misconstruing it to the worst case, I would assume is a missing dependency or fifteen that are NOT ON THE DLS, since it's obtaining that knowledge immediately upon loading them to the
task complete API (Now that interface needs some S/W work! Can't you at least size it to show an average length whole message?). I know, I capture such into a text file... then examine any errors, disable assets if I can't fix them, and so forth. BUT, the problem is the
Spurious Validation is LONG AFTER finishing, letting CM complete, Letting TADdaemon quit... then sometime later, a day or an hour, but well after... then loading and getting the SLOWS... VALIDATION... of what hasn't been validated yet??? THAT's what's driving us buggy--and I'm skyping as I write with the guy who reports those two cases... LONG AFTER, so why do we run a QDR? Hmmmm.
// Frank
