norfolksouthern37
what's a normal map?
yes. that does make sense.
TS12 SP1 HF4.....validation, validation, validation..so when can I get to use the sim
- Thread starter gremlin1812
- Start date
Jonathan I have nothing but clues, no solid knowledge here. I'm looking at it as from computer processing needs and making educated guessings based on what Justin said about validation of his 200 engines and the engine spec. Assuming he's correct, then a cascading chain of validations could be triggering. That would account for such large numbers of assets swelling the lists... BUT we need N3V's conclusions... not my WAGS, no matter how likely-- I have neither the observational experience in this, nor the intimate knowledge of the underlying code. Further, I've got zero paid for items. You'd need my sons input on that aspect, but he runs Trainz so seldom it will be a long wait!
Hi Frank
I rarely wade into threads like this but I've read your posts from start to finish and I find a lot to agree with. I too get significant chunks of my Trainz time lost to 'validation lag' and I would like to see a better solution. I suspect that the underlying reason why some people have the problem and others do not is down to the amount of editing and downloading that people do. If you don't download, and don't create, then this is unlikely to be a problem that you'll experience. I have no idea what proportion of the Trainz community use the game as sold, and don't go near the DLS, but I'm sure N3V will, and this might explain why they don't appear to be too bothered about a fix. I'm not a software person- my trade is town planning (boo, hiss), but this does give me a perspective on understanding the other guy's point of view, and it seems to me that N3V are uniquely placed to understand their customer base.
Don't get me wrong, I would love to see the issue solved for those of us that experience it. However, I can fully understand why N3V's efforts are on TANE and if I'm honest I would rather see N3V focus on the good stuff that's promsed, rather than something that, for me, is a mild inconvenience (your mileage may vary).
R3
I rarely wade into threads like this but I've read your posts from start to finish and I find a lot to agree with. I too get significant chunks of my Trainz time lost to 'validation lag' and I would like to see a better solution. I suspect that the underlying reason why some people have the problem and others do not is down to the amount of editing and downloading that people do. If you don't download, and don't create, then this is unlikely to be a problem that you'll experience. I have no idea what proportion of the Trainz community use the game as sold, and don't go near the DLS, but I'm sure N3V will, and this might explain why they don't appear to be too bothered about a fix. I'm not a software person- my trade is town planning (boo, hiss), but this does give me a perspective on understanding the other guy's point of view, and it seems to me that N3V are uniquely placed to understand their customer base.
Don't get me wrong, I would love to see the issue solved for those of us that experience it. However, I can fully understand why N3V's efforts are on TANE and if I'm honest I would rather see N3V focus on the good stuff that's promsed, rather than something that, for me, is a mild inconvenience (your mileage may vary).
R3
norfolksouthern37
what's a normal map?
Yes exactly. and this is also what Chris said earlier.
Is it intended and normal behavior? Yes. This should happen anything something new or modified is introduced.
Should it happen over and over for no apparent reason? No. Something else must be going on.
I would have to look at it this way. I know it is happening to some of you, but it does not happen to all of us. I can start and restart and make changes and all of that without seeing the validation queue up, but i know that if i install new items it will happen. Now some of you say this happens on every start and takes hours to complete, and that seems like a huge problem. I dont recall anyone having this occur is beta testing though, I could be wrong. For me, it never takes as long as is being portrayed here, even when my cmp setting was committing especs and validating 12000 assets before I could use the game in any meaningful way it never took more than a few minutes. it was annoying testing scripts though because I wanted to get in test and get out and change and repeat, having to wait 10 minutes in between every time was not very productive. Once I figured out what caused it though it was easy peasy.
The moral to this story is leave Trainz and the computer both run
(The website didn't want me to post--this'll by try four to say that para set! Grrrr. Kept telling me my token had expired despite refreshing the page, reclicking the link to post id, etc. and with open edits I wasn't about to do a CTRL-F5 cache reboot! Fortunately this browser was just sleeping... )
Now before I address the 'other thing' that is likely going on, everyone think loudly about this answer: What SP or HF did TADdaemon suddenly 'become fixed' as JamesMoody put it, and start shutting down in the 5-6 seconds after quitting the runtime GUIs? (Yes, I'm thinking this is a bit of bite of the Law of Unintended Consequences--one fix driving a different adverse outcome/behavior!)
For John, it's been a month from hell, not only has his Parkinson's been particularly bad, but when he had the energy to do his route building he'd work a long while on one of his new project(s) and often loose some of that work output despite frequent backup saves-- for Trainz would crash suddenly and whilst that didn't seem to have hurt the data base ever, he began doing a lot more QDRs and system diagnostics, and so on... including weeding out suspect data (obsoletes)!
Since I now run as many as five (so far) Trainz launches at once, I've learned to trust TADdaemon after JamesMoody had pointed out the whole justification was for it to allow multitasking multi-threading (and I guess the multiplayer stuff). Least anyone misunderstand, at least three of those are locally or by shortcut launched CM's --that keeps them looking at their own database, and not referring to the Windows registry to see where to look, important that is. Neither I, nor you want CM of TS10-SP3+hf2 mucking with the data of TS12 or TS09, etc. LOL
Ditto, the surveyors/driver via launcher-loader-main menu. Launcher is run from a shortcut in a Start-menu Trainz folder, or locally, for the same reason... you want to ensure that launch is keyed on the local folder address, not mucking about in the MUIcache or RunMRU records in the registry--those are supposed to speed up app launching and locating, but assume a one of app-name situation, which I don't have with Trainz.exe in Trainz 1.3, Trainz.exe in TS2009 (three SPs in different directories), similar TS10s stepwise directories, etc. and of course, the two in TS12 folders. Trainz.exe gets a bit ambiguous as a registry title!
If anyone is tempted to reload an old Trainz and/or get bolder in running like this be warned, the joker in the deck is CDPs. Ditto for letting the shopping cart initiate a download from the TRS2004/DLS.php web DLS... those both will go whereever (to whichever Trainz version) the cdp files entry in the registry is pointed. Loading from inside CM and specifying a source directory won't give any surprises, it's double-clicking a cdp or having the shopping cart open CM that will get confused if the cdp file entry is pointing to that other Trainz version. Shane Turner has a tool to set and override that if you're interested.
(The website didn't want me to post--this'll by try four to say that para set! Grrrr. Kept telling me my token had expired despite refreshing the page, reclicking the link to post id, etc. and with open edits I wasn't about to do a CTRL-F5 cache reboot! Fortunately this browser was just sleeping... )
I don't recall anyone saying it was THAT severe. John would come closest, as I'll address below.
Now before I address the 'other thing' that is likely going on, everyone think loudly about this answer: What SP or HF did TADdaemon suddenly 'become fixed' as JamesMoody put it, and start shutting down in the 5-6 seconds after quitting the runtime GUIs? (Yes, I'm thinking this is a bit of bite of the Law of Unintended Consequences--one fix driving a different adverse outcome/behavior!)
I think after sleeping on this last night the something else going on was John had experienced several weeks of memory problems it took us a while to pin down. Most of the others above seem to have been bitten less often. Now we spend hours at a time working on speaker phone or by skype chat, and this was a big stress on him taken together with various other life problems.
For John, it's been a month from hell, not only has his Parkinson's been particularly bad, but when he had the energy to do his route building he'd work a long while on one of his new project(s) and often loose some of that work output despite frequent backup saves-- for Trainz would crash suddenly and whilst that didn't seem to have hurt the data base ever, he began doing a lot more QDRs and system diagnostics, and so on... including weeding out suspect data (obsoletes)!
So he experienced a severer sort of a snowball effect. The long validation triggered, he decided to limit the number of assets to validate, causing another validation, and exacerbated it by quitting out soon after making changes and then reentering Trainz... erroneously thinking he was 'refreshing memory' for CM... did I mention he got a bit paranoid whilst all that memory intermittentancy was cropping up and smashing him flat?
... I think he even tore his computer apart and put it back together three times and practically wore out the HDD running system diagnostics. Twice he thought he'd fixed it by finding a loose power-supply plug connector... to be wrong a day or so later. Intermittent problems are the pits to find and diagnose! Confidence goes through the floor, paranoia reigns in triumph! He went through so much testing and trial fixes that I really don't recall now how he finally figured out it was his memory, but that was two weeks ago now, and I do think he's gotten to the bottom of it, despite 'thinking that' several times before during the earlier episodes.
As described following I normally start by running CM. If I want to then run Surveyor, I launch that by shortcut and leave CM up and happy. It no longer pays to launch using CTRL-L or from the Surveyor menu because it's far better to be able to route build and use CM to look stuff up -- sort of stepping around and outside past the limitations of the Tools sorting lists. With either or both those running... all those background validations have passed me by save for those two times.
Since I now run as many as five (so far) Trainz launches at once, I've learned to trust TADdaemon after JamesMoody had pointed out the whole justification was for it to allow multitasking multi-threading (and I guess the multiplayer stuff). Least anyone misunderstand, at least three of those are locally or by shortcut launched CM's --that keeps them looking at their own database, and not referring to the Windows registry to see where to look, important that is. Neither I, nor you want CM of TS10-SP3+hf2 mucking with the data of TS12 or TS09, etc. LOL
Ditto, the surveyors/driver via launcher-loader-main menu. Launcher is run from a shortcut in a Start-menu Trainz folder, or locally, for the same reason... you want to ensure that launch is keyed on the local folder address, not mucking about in the MUIcache or RunMRU records in the registry--those are supposed to speed up app launching and locating, but assume a one of app-name situation, which I don't have with Trainz.exe in Trainz 1.3, Trainz.exe in TS2009 (three SPs in different directories), similar TS10s stepwise directories, etc. and of course, the two in TS12 folders. Trainz.exe gets a bit ambiguous as a registry title!
Lastly, I've run the CM in the same folder together twice, and suffered no ill effects and but one side-effect. That is the local search was affecting the 'prior search' when changing that about in the other CM. I'd use this one carefully, but the fact it allows one to keep a list of dependencies in one CM and explore some of the dependencies or versions under one or more of those in the other, gives me a lot of temptation to push this mode and see how far it'll take me.
If anyone is tempted to reload an old Trainz and/or get bolder in running like this be warned, the joker in the deck is CDPs. Ditto for letting the shopping cart initiate a download from the TRS2004/DLS.php web DLS... those both will go whereever (to whichever Trainz version) the cdp files entry in the registry is pointed. Loading from inside CM and specifying a source directory won't give any surprises, it's double-clicking a cdp or having the shopping cart open CM that will get confused if the cdp file entry is pointing to that other Trainz version. Shane Turner has a tool to set and override that if you're interested.
Last edited:
As Frank pointed out, I did have a memory problem, both of my own and of course on the computer too. 
I was getting some BSODs for a bit. After replacing some DIMMs, I have not had one since, though I am still a bit shell shocked and suffering from a bit of PTSD. It turned out the memory is OK, but not quite at spec for the motherboard. There is a QVR supplied by Intel and I had used some other RAM I had around. I saved about $350 at the time, thinking I was all set. Everything worked for about a year before I saw issues. A week or so ago, I replaced the RAM with a properly qualified vendor's product, and have had no problem since. Did I save anything? No. It cost me the same as it would a year ago for the memory. Shame on me for trying to save a buck or two. The other issues, such as a loose cable or two? They weren't what the problem was. They were plugged in like they should be; it was me finding stuff and getting excited, thinking I found something only to have the system crash again. Gotta love those intermittent problems and finding stuff you think fixes the issue!
I wonder too if my extreme circumstances weren't self inflicted due to my hardware problems. A BSOD and a program crash surely isn't good for the program's data even though a BSOD is supposed to protect your data from faulty computer hardware so Microsoft says. This however doesn't explain the problems others are having, and perhaps my extreme circumstances help to bring this issue into the forefront. I still consider large data validations an issue which should be looked into by N3V as they have identified some problems with the process which sure should be addressed. In my process of troubleshooting, I have come across another issue that I think needs to be addressed by N3V. As soon as I confirm this, I will notify them. I don't want to send out a false hope until our friend Shane Turner confirms what I have found first.
As far as database validations go, I downloaded a bunch o' things this morning (about 10:45 when I got up), and even removed some obsolete assets that were replaced by some updates. I had no validation occur afterwards and everything exited normally from CM. What prompted my big validation the day before? I don't know other than removing the 472 obsolete items, which I've done in the past without issue. I had downloaded stuff the previous day from some outside sites to see if I could get the problem to occur. I then received some data validations which I was told were okay. After they finished, I went into TS12 and drove a bit and poked in Surveyor. I went to bed and the next day downloaded stuff off the DLS as usual, cleaned up the 472 obsolete items, and then got hit with a massive validation which basically put me out of business as that resulted in over 9800 items needing validation before running the program. At that point I found something else to do, like watch some TV (a rare thing for me), and nodding off in my chair.
John
I was getting some BSODs for a bit. After replacing some DIMMs, I have not had one since, though I am still a bit shell shocked and suffering from a bit of PTSD. It turned out the memory is OK, but not quite at spec for the motherboard. There is a QVR supplied by Intel and I had used some other RAM I had around. I saved about $350 at the time, thinking I was all set. Everything worked for about a year before I saw issues. A week or so ago, I replaced the RAM with a properly qualified vendor's product, and have had no problem since. Did I save anything? No. It cost me the same as it would a year ago for the memory. Shame on me for trying to save a buck or two. The other issues, such as a loose cable or two? They weren't what the problem was. They were plugged in like they should be; it was me finding stuff and getting excited, thinking I found something only to have the system crash again. Gotta love those intermittent problems and finding stuff you think fixes the issue!
I wonder too if my extreme circumstances weren't self inflicted due to my hardware problems. A BSOD and a program crash surely isn't good for the program's data even though a BSOD is supposed to protect your data from faulty computer hardware so Microsoft says. This however doesn't explain the problems others are having, and perhaps my extreme circumstances help to bring this issue into the forefront. I still consider large data validations an issue which should be looked into by N3V as they have identified some problems with the process which sure should be addressed. In my process of troubleshooting, I have come across another issue that I think needs to be addressed by N3V. As soon as I confirm this, I will notify them. I don't want to send out a false hope until our friend Shane Turner confirms what I have found first.
As far as database validations go, I downloaded a bunch o' things this morning (about 10:45 when I got up), and even removed some obsolete assets that were replaced by some updates. I had no validation occur afterwards and everything exited normally from CM. What prompted my big validation the day before? I don't know other than removing the 472 obsolete items, which I've done in the past without issue. I had downloaded stuff the previous day from some outside sites to see if I could get the problem to occur. I then received some data validations which I was told were okay. After they finished, I went into TS12 and drove a bit and poked in Surveyor. I went to bed and the next day downloaded stuff off the DLS as usual, cleaned up the 472 obsolete items, and then got hit with a massive validation which basically put me out of business as that resulted in over 9800 items needing validation before running the program. At that point I found something else to do, like watch some TV (a rare thing for me), and nodding off in my chair.
John
shaneturner12
Tutorial Creator
I'm still doing quite a bit of testing myself. In terms of the issue John has mentioned, I have found a few links on that front (in Event Viewer as well), but cannot say much until I can get a clear result one way or another.
Shane
Shane
This thread terrorizes me. I am one who fiddles existing routes with lots of changes. I also am addicted to getting new stuff from the Content Manager. I had a bout of validations quite awhile ago and had to reinstall. Maybe I should go back and play with the toy trains on RailWorks until this is either fixed or becomes avoidable through procedures.
I can imagine the frustration on both sides - customer and vendor with each seeking something from the other. Neither side wants to to give up time to recreate and then test. Customers want to use the product. The vendor wants to move forward on a new product. Neither suits fixing a legacy product.
Imagine going AHa, if I change this step it will fix it. However, that step was there for a reason and that reason was there because of some other things. Pretty soon you you have an upside-down tree of interdependent logic. Have you ever watched one of those remodeling programs on TV. They almost always get into a "one thing leads to another mode" killing the budget. N3V recognizes this as a possibility. That old program is probably a mess with some parts not fully understood. If I were the boss I would say look but report back to me the scope of the changes and the probability of hurting other functions. I might just say forget it. Apologize to the masses and get back to the new project. We will recover those few customers with some freebies.
I can imagine the frustration on both sides - customer and vendor with each seeking something from the other. Neither side wants to to give up time to recreate and then test. Customers want to use the product. The vendor wants to move forward on a new product. Neither suits fixing a legacy product.
Imagine going AHa, if I change this step it will fix it. However, that step was there for a reason and that reason was there because of some other things. Pretty soon you you have an upside-down tree of interdependent logic. Have you ever watched one of those remodeling programs on TV. They almost always get into a "one thing leads to another mode" killing the budget. N3V recognizes this as a possibility. That old program is probably a mess with some parts not fully understood. If I were the boss I would say look but report back to me the scope of the changes and the probability of hurting other functions. I might just say forget it. Apologize to the masses and get back to the new project. We will recover those few customers with some freebies.
Last edited:
johnwhelan
Well-known member
The problem is intermittent and affects some users more than others. I strongly suspect the software is overly sensitive to voltage fluctuations and hardware issues. Generally speaking software does not wear out. Sometimes design decisions taken early on have a more major impact as the use and amount of data grow.
I think the issue can be addressed with a best practises type approach but it is a problem. One of my beta testers gets round it by having more than copy of Trainz installed and just moves on to the second copy if the first “locks up” which is one way of getting round the problem. Says a lot for the product reliability though when people install more than one copy in case the first locks up.
Cheerio John
Hey let's not panic here. I just discussed this with John and he's repudiated my surmise that he'd recently begun deleting the obsoletes, but has been doing so all along. However, he does admit he's been changing out of CM, waiting for TADdaemon to fully shut down, then attempts to go into surveyor after that maintenance, so because he's certain to let TADdaemon die, he's triggering this delayed validation. According to email by JamesMoody, the TADdaemon now shuts down in 5-6 seconds... .a time period chosen so people have a chance to switch directly from CM to Launcher, and beyond. I'm sure we all understand that a task goes better once started, and when uninterrupted... If you let it clear the decks, this should be a minimal impact item going forward. Like waiting for CM to fully close, we need to adapt our human behavior to get the most out of the game... Throwing rotten tomatoes at Moody for mal-communication would likely be frowned on by management... though Chris may want to give him a Gibbs Slap for not making the connection under the law of unintended consequences...
(James was actually maligning my mention of TADdaemon in a surveyor article, and misconstruing the mention as a complaint.)
John's comment is predictable. Why didn't they tell us about this change in behavior... practices. So I stand pat with the advice above. If you've been doing maintenance. Let things run for a while. If you want to run in the GUI's. Just load from the folder or a shorcut and go do your thing, CM, being a Windows application will happily run in the background, as does the TADdaemon and TrainzUtil. Unlees you are watching processes like me and John, or have TADdaemon in debug mode to watch it, you never know they're running.
ianwoodmore
Active member
Frank,
There is no danger in deleting non-BI obsoletes. CM already knows that there is a replacement asset available for it to load. In any case CM also knows what are obsolete on the DLS. It doesn't have a clue about the fault status of assets you have downloaded from external websites as its benchmark is the DLS index that it downloads when you first load Trainz. As in all things there are exceptions. If the version chain is not continuous then CM gets confused. Examples would be Snc where assets were updated for TRS2009 and started at :40. This meant that :2 through :39 were missing because they never existed. CM is then confused as to whether they are Out Of Date or Obsolete. You can't delete Builtin obsolete or out of date assets nor locked assets.
As a Repairer (not a Creator) I have done tens of thousands of deletes without any noticeable problem. Bear in mind that the status 'Obsolete' is relative to the spec that TADDAEMON is validating against. Thus in my case TS12 SP1 HF4 (TB 3.7). At TRS2009 or TS2010 some may be obsolete and others not. Two big jumps occurred where validation was significantly tightened, TB 2.9 and TB 3.4.
For every asset you download from DLS an original copy is kept permanently in the TAD Original folder. When you modify anything a copy appears in Local Folder and that is the one the game is using. So if you botch a repair or TADDAEMON has a hissy fit during Commit you can use 'revert' or is very bad 'revert to original'. You may have lost your modifications but the asset is still available.
When a large number of repairs are done at a sitting or you DL a large number, TADDAEMON most probably will re-validate. If an asset is used by many routes/sessions/assets it can take some time, and yes go have a coffee, shop, garden, houseclean, or sleep. A complete DLS is in excess of 500GB and of course it can take a while to validate. Incidently QDR and EDR are rarely used by me.
I'm a bit puzzled by JAMES comment on 5-6 secs to exit CM and jump into Game. For a start exitting CM doesn't mean TADDAEMON has finished its housekeeping. Just watch the Resource Manager CPU window. Go to bottom and you will see it takes a minimum of 60 secs greyed out before TADDAEMON and its slaves disappear from the CPU queue. I find that is the best time to go into Game.
Another thing, if you have any assets OFE you will not be able to use File/Launch Trainz without CM closing all open assets first. In repair or create mode it is probably better to exit CM and then use Launcher to Game.
There are two other things on startup.
1. Once/day Trainz backup is purged. This can be many MBs even GBs. Ensure the number of backups is as low as your work style will tolerate.. Default is 7. I find one is enough.
2. It purges the cache. Again deoending on how much work you did in CM, or how much you DLd this can take a few minutes.
I'm firmly of the opinion that many of the file copy, read error, missing kuid etc issues are caused by what you call validation lag. TADDAEMON is still busy and thus timeouts on some. Very variable but can be one or two assets affected or as many as 20. Larger batch sizes - more prevalent.
I'm currently working with Andi06, PEV, and Paul Cass on the next version of AssetX/TARDIS. No date for release. I can tell you that I have just met the 80% milestone in my testing. That is, having raised all assets from their original TB to TB 3.7 that are not locked and if you sum all CM reported errors, FD, MD and warnings (pretty extreme milestone) then 20% are defective discounting obsoletes after applying fully automated repair processes. Faulty (red icon) assets only make up a little over 5%. I'm far from finished in automating and I already know that I can achieve a much higher success rate by semi-automatic or last resort manual means. And who knows what other ingenious widgets the other three are going to invent before we release!
Frankly, I'd stop worrying about the state of legacy assets and whose fault it was or is. By the time TANE appears at end of 2014, it will be a moot point.
Bottom line - What you see now as far as legacy assets are concerned is not what will be causing you pain in eight months time. 99.5% of legacy items up to and including TB 3.6 are fixable, most of them by a click of an AssetX button and running PEVTools and TARDIS superscript.
There is no danger in deleting non-BI obsoletes. CM already knows that there is a replacement asset available for it to load. In any case CM also knows what are obsolete on the DLS. It doesn't have a clue about the fault status of assets you have downloaded from external websites as its benchmark is the DLS index that it downloads when you first load Trainz. As in all things there are exceptions. If the version chain is not continuous then CM gets confused. Examples would be Snc where assets were updated for TRS2009 and started at :40. This meant that :2 through :39 were missing because they never existed. CM is then confused as to whether they are Out Of Date or Obsolete. You can't delete Builtin obsolete or out of date assets nor locked assets.
As a Repairer (not a Creator) I have done tens of thousands of deletes without any noticeable problem. Bear in mind that the status 'Obsolete' is relative to the spec that TADDAEMON is validating against. Thus in my case TS12 SP1 HF4 (TB 3.7). At TRS2009 or TS2010 some may be obsolete and others not. Two big jumps occurred where validation was significantly tightened, TB 2.9 and TB 3.4.
For every asset you download from DLS an original copy is kept permanently in the TAD Original folder. When you modify anything a copy appears in Local Folder and that is the one the game is using. So if you botch a repair or TADDAEMON has a hissy fit during Commit you can use 'revert' or is very bad 'revert to original'. You may have lost your modifications but the asset is still available.
When a large number of repairs are done at a sitting or you DL a large number, TADDAEMON most probably will re-validate. If an asset is used by many routes/sessions/assets it can take some time, and yes go have a coffee, shop, garden, houseclean, or sleep. A complete DLS is in excess of 500GB and of course it can take a while to validate. Incidently QDR and EDR are rarely used by me.
I'm a bit puzzled by JAMES comment on 5-6 secs to exit CM and jump into Game. For a start exitting CM doesn't mean TADDAEMON has finished its housekeeping. Just watch the Resource Manager CPU window. Go to bottom and you will see it takes a minimum of 60 secs greyed out before TADDAEMON and its slaves disappear from the CPU queue. I find that is the best time to go into Game.
Another thing, if you have any assets OFE you will not be able to use File/Launch Trainz without CM closing all open assets first. In repair or create mode it is probably better to exit CM and then use Launcher to Game.
There are two other things on startup.
1. Once/day Trainz backup is purged. This can be many MBs even GBs. Ensure the number of backups is as low as your work style will tolerate.. Default is 7. I find one is enough.
2. It purges the cache. Again deoending on how much work you did in CM, or how much you DLd this can take a few minutes.
I'm firmly of the opinion that many of the file copy, read error, missing kuid etc issues are caused by what you call validation lag. TADDAEMON is still busy and thus timeouts on some. Very variable but can be one or two assets affected or as many as 20. Larger batch sizes - more prevalent.
I'm currently working with Andi06, PEV, and Paul Cass on the next version of AssetX/TARDIS. No date for release. I can tell you that I have just met the 80% milestone in my testing. That is, having raised all assets from their original TB to TB 3.7 that are not locked and if you sum all CM reported errors, FD, MD and warnings (pretty extreme milestone) then 20% are defective discounting obsoletes after applying fully automated repair processes. Faulty (red icon) assets only make up a little over 5%. I'm far from finished in automating and I already know that I can achieve a much higher success rate by semi-automatic or last resort manual means. And who knows what other ingenious widgets the other three are going to invent before we release!
Frankly, I'd stop worrying about the state of legacy assets and whose fault it was or is. By the time TANE appears at end of 2014, it will be a moot point.
Bottom line - What you see now as far as legacy assets are concerned is not what will be causing you pain in eight months time. 99.5% of legacy items up to and including TB 3.6 are fixable, most of them by a click of an AssetX button and running PEVTools and TARDIS superscript.
Last edited:
I have been buying Trainz since 2004 & after having a lot of problems with TS12 I upgraded the computer a new power unit 8g of ram 650 GT card Windows 8 sent in a few tickets was advised they are having trouble with windows 8 so uninstalled it ran on win7 for 6months same problems back to Win8. Always have to wait for "updating trainz asset database" every time game opens & more locos & other assets are disappearing every start. I have a few Australian Routes that no longer have Locos or Carriages that I can use. Even the older assets that used to run ok have been removed & the new 2.9 or better still show up red in surveyor. Consequently I have a lot of red Locos, the tenders are fine. So will this be fixed ?
shaneturner12
Tutorial Creator
The 'Updating Asset Database' message is usually caused by user error, quite often by failing to allow time for Trainz to close fully before shutting including it's background processes which can take up to 5 minutes to close, therefore there's nothing that needs fixing if that is what you are doing.
Shane
Shane
Further to what Shane has said, the reason you are seeing some assets marked red could be because once the "Updating Asset Database" has completed some assets could be reported as being faulty. These are often false and can be cleared in CM by searching for installed = true and faulty = true. Any that show up need to be selected, in small batches if there is a lot of them, then right click on the selected one(s) followed by clicking on view errors and warnings. This should clear the errors, warnings can be ignored, and your missing assets should now show up.
Thanks, I was a little paranoid on that, since the CM family has been so poor on identifying when a real apropos update was available. This is more a side effect that I went nearly 6 years w/o trying any DLs from anywhere. Given the work schedule--there was enough to learn in too little time already! I've been burned a number of times in TR06, the TCs and even TS09 by importing 'updates' that have over advanced trainz-build tag values, that in my humble experiences as a bullet-proof software writer, would be counted as intolerable bugs. N3V figures we can spend the time, I guess. ;((
Well, he was sort-of in mid-rant... given the rest of the context...
I take it to mean that the "Dwell period" -- the time it takes to self-exit (your 30+seconds) is designed to give you a chance to relaunch into the game not-using CTRL-L, but by shortcuts, as in [WIN]>All Programs>[Auran]>... or whatever,
whereas the 5-6 seconds... (is the big change...which I suspect is giving the unintended consequences of this thread--the belated validations!) THAT I infer... has the purpose of shutting down the data processing state/safeguarding the changed files.... ASAP so a power-off or reboot didn't break the data base, nor the desired validation "to be continued". I do believe that this results from one newish change (hf3???) which has minimized the angst we were seeing over busted databases and subsequent needs for EDRs or QDRs since back in April/May last year--as were listed in the earlier posts in the many pages of the TS12-SP1 thread(s). That means I further infer that quitting CM is triggering the delayed validations by 'suspending them', if you please when 'in-progress as interrupted but scheduled' as deemed necessary. That suspension and save state as well as closing the vulnerable data files is what he does in that 5-6 seconds. It would appear that John's quit out, wait, then relaunch is just asking for the worst of this.
At least, that is what I'm suspecting as noted in my last. Someone should invite Windwalkr or Moody to confirm or deny this, because at the moment, given the known differences between me and John Citron's modus operandi, and the many times he relates on skype that he's shutting down, rebooting, and so forth... I think this latent validation is one he's seen because of that change update. A defensive behavior by him, is now the problem he's seen more than most here.
whereas the 5-6 seconds... (is the big change...which I suspect is giving the unintended consequences of this thread--the belated validations!) THAT I infer... has the purpose of shutting down the data processing state/safeguarding the changed files.... ASAP so a power-off or reboot didn't break the data base, nor the desired validation "to be continued". I do believe that this results from one newish change (hf3???) which has minimized the angst we were seeing over busted databases and subsequent needs for EDRs or QDRs since back in April/May last year--as were listed in the earlier posts in the many pages of the TS12-SP1 thread(s). That means I further infer that quitting CM is triggering the delayed validations by 'suspending them', if you please when 'in-progress as interrupted but scheduled' as deemed necessary. That suspension and save state as well as closing the vulnerable data files is what he does in that 5-6 seconds. It would appear that John's quit out, wait, then relaunch is just asking for the worst of this.
At least, that is what I'm suspecting as noted in my last. Someone should invite Windwalkr or Moody to confirm or deny this, because at the moment, given the known differences between me and John Citron's modus operandi, and the many times he relates on skype that he's shutting down, rebooting, and so forth... I think this latent validation is one he's seen because of that change update. A defensive behavior by him, is now the problem he's seen more than most here.
Thanks for that, but so far I'm not fixing many things in TS12, but only before importing same. I always launch from the folder, or applicable shortcut in my Trainz sub-folder in the Start Menu. Your comments apply to TS2009-SP4 (v3.3) and TS2010-SP1 (v3.2) AND UP, though--and maybe a bit sooner even. SP3->SP4 converted the old TS2006 folder set up to the new. My oldest TS10 is an SP2 DVD release, but I believe TS2010 had the new file setup across the board. (If anyone has SP0 installed and can confirm that, please email or PM me so I can document that properly in the Wikibook! Thankz)
I see the cache purging uniformly when booting Trainz for the day. Since I tend to max out backup space, please explain the benefit of keeping such on a diet. <G>
It's been my observation that I can keep a few select 'broken' assets OFE and indeed continue to work on them on the side, when entering Surveyor/Driver via a separate launch shortcut. I'd concluded that the Database wasn't yet using the version I had OFE (using the revertable version, if it was a non-errored asset), so me taking a screenshot that way was, shall we say, very-low-risk. From my point of view, far more efficient too!
Admittedly, I was nervous the first couple times I did so, but later added more substantial changes (altering the data from this to this new format), and making repairs in a few that slipped into TS12 with such, for example. Also added Surveyor runs whilst running said CM's. As can be seen, I was asset fixing in TS10 that day... or wouldn't have six remnant open for edit folders. Sadly, I still have to navigate via a page like this to figure out why tags like 'bendy' are null search links in the N3V Wiki, I was gradually fixing errors of omission like that! [Since my editing there clearly jeopardizes the whole project, (and their self-image) someone with privileges might want to make redirects of those links to the new container formats. T'will likely help some others, like I was trying to do, don't you know. (They so abuse the potential of a wiki it drives me nuts!).] God Bless the guys that put together "Index of Tags & Containers"! (Someone make a redirect with 'and' in the title. Just stressed the poor search engine! You can tell immediately it wasn't the work of the Brew Crew... it's actually usefully informative!)
Definitely can confirm I have added assets by fresh download ongoing download off the DLS on the CM (1st launched) and then had it available shortly afterwards in Surveyor (2nd launched). Ditto the few I've repaired in TS12's CM whilst running in TS12's Surveyor too. There is a lag before they show... probably from this validation background process.
//Frank
On the Windows 8 issues, PM Jcitron and tell him I sicced you on him! He's an MS certified IT guy and runs Windows 8, and while it shames me, I still call him friend despite that lack of judgement!
What he and Shane says... that's a good trick sometimes when CM gets confused.
This disappearing assets... sounds like assets you've used have dependencies which are being invalidated for continued use because something is adding them to an obsolete-table. If you've been doing upgrades, might be fruitful to examine Date Installed if you can pin down somedate you know something turned red or missing. See if you can match up something that ways, and examine the configs for an obsolete-table. Those may not be directly (first order) indicative of an driect association, but something listed therein might lead to something else. Could go either way.
Further, I suggest taking a couple of those newly broken older large assets, bringing them up in an older version of CM and then generate a dependencies list of kuids in a comma separated form. Notepad++ (free) will let you search and replace across a newline sequence, so can be used to search and replace the text part away, generating just a list of Kuids in a matter of moments.
Take those lists back into TS12, paste them in kuid list mode, and see what is disappeared/missing. Also, Look at versions of each and so forth in both CMs. You can run both CMs at once if you launch them from the \bin folder (or an correctly written shortcut which starts in that location). There will almost have to be a pattern you can see... If I'm right, it's careless assumptions on someone's part.
Much like the <kuid:-25:series> someone at AURAN arrogantly assumed would be alright to just replace stock trees, because the replacement was latest greatest speedtrees and/or TS2009 level tech. (Like to meet that piker in a dark alley!) That it broke other things was apparently not a factor in their thinking. We see some of that with script changes too.
That's usually an lack-of-experience problem in origination as such crops up when someone lacks perspective. If you can list out a few examples of assets that were fine in version X and went broken in version Y, some of us running multiple installs can do some poking around to see what's happening. Email me the list if you like and I can take a look. I've got operational versions all the way back to Trainz 1.3, and can download to suit if needed.
The news above Shane is the five minutes has been slide around and put into the background validations (it's got a low priority, so now takes 15 minutes??? 10???) and CM proper shuts down safe in the 5-6 seconds JamesMoody cited in his email. That waiting seems to be the cause of the long validations John and others have experienced, To avoid such, let CM run, and lauch independently as I do, or launch using the CM menu (hotkey: [CTRL]-[L] so TADdaemon never feels lonely and starts the safe save ("graceful death" in some software literature) process... the validation, like the stage show,... can go on!
I'm guessing here, but that safe-shutdown procedure seems likely to be restarting the chain of what needs re-validated from scratch from the top of it's list. This makes sense if the change was to prevent people from shutting down the computer and causing data base corruption prematurely. A middle of the road process would exhaust the top of the list, at the risk of having that 'update to it's tracking records' corrupted if there were a premature shutdown. From the programmers side, there's a bit of "damned if I do this, and I'm getting damned for doing that" to this. The handling of the unpredictability of the shutdown/reboot/launch other activity is from the Trainz POV, the problem. We humans need to be more predictable and the programmers life would be far easier.
[Take that, you lot who think I only dump on the programmers! I defend them a lot. Albeit mostly verbally.] And no, I'm not saying it can't be improved, but it beats the hell out of corrupting the Database, n'est pas?
I've been experimenting with this, again, to see what kind of effects not shutting down CM has prior to loading in TS12. I have found that TS12 launches immediately because the database is already running, and there are vey few validations as of yesterday which including a trip to a Czech Trainz content site and downloading content which needed fixing and then was subsequently deleted because I didn't want to do that for what it was worth. So I'm confused. Is it because CM is running that made it better, or is it that the content wasn't already integrated into the database already so little validating needed to take place. At any rate, I will continue to load up TS12 with CM running and see what else happens.
John
Well if you added it to the index, then deleted it because of faults, the ripple effect on dependent assets would be tiny, so no big list of assets to validate against a changed asset exists to schedule.
My interpretation is that apparently the 'validation list' is identified as being a medium or low priority, the LAST part of the paperwork, so to speak for those assets. If CM is running, the priority is medium, as TADdaemon knows it doesn't have GUI servicing demands --just list manipulations, like the main pane in CM.
Hence it's presence counting down in the TADdaemon indicates nothing but the items have been earmarked to re-check or for which to do some bookkeeping. When we import, download, or install a cdp from the desktop, the transaction is in the foreground, as is the error-check validation of the item. Hence happens immediately, and we and the database feel safe--the validations for such can be presumed as medium, and I would infer you should be able to see things validate faster than when running the GUIs.
My suspicion 'on logic grounds' is the validation is the links of things referencing an item in that list of kuids--or the list of ''nn'' things affected by one given item taken ''ii'' at a time (to swear in mathspeak, so to speak). Some things affect ten other kuids, some affect two, some affect 232 assets... hence the variability we see, and why sometimes clearing one item on the list causes the 'total scheduled to check' to suddenly jump downwards. That would be one item used by a ton-a-bunch of assets. For example, 287 freight cars using that coupler you just updated and marking the new Kuid2 as part of it's dependencies.
I would also infer that an 'updated item' (which changes the folder content in the Hash-tables) where neither trainz-build tag, nor kuid/kuid2 have changed will appear to validate virtually instantly... that would represent a case where the ''list records'' for each affected item need no updates, so a null change edit... in such cases the list might vacate a big group of dependencies and the total to validate will jump down somewhat suddenly.
This assumes a table or list of dependent assets and a list of dependencies exists for each kuid (pointing at one another, so to speak), which seems a fairly safe assumption given the response time one gets asking for either of those associations in CM's RMBH drop down menu. Again logical, if the kuids didn't update those 237 listed dependent items don't need their lists of dependencies searched, and updated to reflect the new version. Assets.tdx is after all, an index file, and such lists are it's stock in trade.
Think of it this way John. CM puts items processed into 'a scheduler sub-program'. That sets up the queues and tasks TADdaemon. When you leave CM running, the scheduler is the only process running in 'CM's processor cycles' (time share) as allocated by Windows Program Manager. Whether it just returns to Windows for the next background process, or somehow stimulates TADdaemon/TrainzUtil to check another one, a few or more a bit sooner (both seem possible and/or likely), the CM cycles are either a minor time tax or an actual aid.
Meanwhile, with Surveyor running, TADdaemon will know that it's now got a high-throughput pipeline to service, this perhaps lowers the effective priority of the validation list, but since it's started, it keeps on cranking efficiently since there's nothing being added to be validated, and it's free to focus all it's processor cycles on just validating the database, whilst Surveyor is running in a read only mode and that doesn't slow down TADdaemon either.
Assuming my reasoning is reasonably accurate... the piece of this tale which still puzzles me is the BUG Behavior... THE SLOWS I've seen, you've seen quite often, and others also report. There must be some process affecting flag or prioritization which allows the validation to time share efficiently with Surveyor when CM is left running, whilst quitting out may be the worst of both worlds -- starting the validation list over and doing so with a low priority process that nonetheless causes the SLOWS. // Frank
Apologies: (I thought I'd sent an email to James Moody and a few others for their input on this yesterday morning and to James Moody as well asking for the official read on all this-- which seems to have been ignored in execution by me--I found the unsent email in the background clutter on this laptop this morning dealing with one I knew I'd paused before completing. I guess I'd gotten distracted with other work on my desktop towers, and was dithering on the answering of the other for while flattering, had it's cons as well.
Oopsie. James was the only recipient of the slimmed down version since most of the rest found it's way into the thread below somewhat later. It's about 3 am in Brisbane as I write this, so perhaps by 10 pm in London we can get N3V's reaction.)
Last edited: