That also means that a reinstall is needed - one should never force-close the patching process.
The likely reason for the slow behaviour happens if your antivirus software is still running, or if you have a lot of content installed.
Shane
Let me add to that, anti-malware programs such as
Malwarebytes Anti-Malware and system maintenance utilities like
Advance System Care also these days branch out and monitor files in the background. So get in the habit of disabling all those process cycle wasters when doing a build and shut down the browser and all it's background processes. Give the foreground process (Hot Fix) as many free resources as possible without having stuff steal cycles. Probably worth disconnecting your internet service feed as well. And shutting down file indexing, printer and other quick launchers, almost everything in the lower right corner of the task bar (Windows XP); newer Windows moved things around, especially W7 & W8.
Just a thought here Shane, since content and the base system upgrade are interdependent wouldn't it make more sense to run a second naked install without any content, patch that, then get the old new content imported in smaller chunks. Seems to me that a lot of man-hours could be saved by orphaning the 'old' trial, (move the install 'local root' folder to a new name), Fresh Install with SP's and Patches, then selectively bring in the content into a Stabilized Software system. It also eliminates a lot of anxiety as you can see and evaluate the CM at each stage as it brings in chunks of local content...
not wait around nervously uncertain whether things will work out.
The virtue of this is guys, as Shane knows, you don't actually break the integrity of the old install, or even move or otherwise affect it's files...
you simply just use it as a safe backup by severing the registry's knowledge of it's existence because you renamed it. You can always then reverse the severing. The general process of being hyper-safe is found here:
TRS2012WBE#How_to_proceed which I wrote up last week to give guidance on one of the TRS2012 problems boards, but only suggested to one individual by PM. I'd been meaning to ask you to critique it Shane, so I'm asking! The Wikibook page end is step by step how to safeguard even the registry keys and how to edit it. Where that might come in, is forcing the system to allow two flavors of TRS2012 to sit on the HDD side by side as runnable programs. (Keeping your content current between one or the other is your job! Use date stamps and learn to copy folder to folder.) It is in this case, unecessary unless you want to assure having two different versions which could run. If we're lucky, you could just add a second version in a new directory (folder) as detailed below. Some registry keys (called 'Hkeys') will be mixed since both installs use the same .exe file names. (more below on that)
The real power is in renaming the old about to be replaced version to say 'TRS2012-SP1HF1' and reinstalling to the same old folder name 'TRS2012' (which is no longer there!). Everything in TRS2012-SP1HF1 is invisible to the registry, save perhaps to indexing software. All the paths and indexes point to the new TRS2012. The old version is however now not fully functional, though running directly from each exe except the launcher will mostly work. Jcitron always runs from ...\bin\ContentManager.exe because it then ignores registry indexed lookups,
knowing where it is from the fact it's directly loaded from the ...\bin\ pathspec. (I don't know about Surveyor or Driver in that direct launch mode.) The launcher (the exe pointed to by your desktop shortcut) feeds the CM the path from the registry... one correct, one incorrect relative to the older install.
Overall, what this technique does guys is breaks the registry's knowledge of the renamed folder -- keeping the data safe. It's also very speedy, since you are merely renaming a folder name (indexed drives will take a few moments longer--they'll likely index all the files in the folder recording their new pathspecs). If the new install doesn't work out, you can reverse the process and orphan the new one by renaming that versions folder to 'TRS2012-SP1HF2' and renaming 'TRS2012-SP1HF1' back to 'TRS2012', and for which, all the registry keys will still be functional.
Alternatively, if the installer allows it (I can't test it yet) you might be able to install a clean fresh version to that same name: 'TRS2012-SP1HF2' -- which name also has the virtue of giving you a 'version state menomic' at a glance.
If someone has a lot of extra HDD space, you can test this by renaming the folder, then copying the whole contents to the current folder name (reestablishing the registry validity), then try the fresh install to the suggested 'TRS2012-SP1HF2' name with each SP and HF in succession.
If the installer is stubborn, it kills that second copy in TRS2012 but the first (moved by renaming) is still safe in 'TRS2012-SP1HF1'. If it works, both TRS2012 (SP1HF1) and the new TRS2012SP1HF2 will function... with the caveat, the name Contentmanager.exe is common to both, so you will be best advised to use John's (Jcitron here abouts) direct launch method from /bin or get Shane's tool.
Later you could use the technique on the Wikibook page to rename the one folder you're keeping and are happy with
anything you like. Any such juggling allows a clean install and rebuild, so you can evaluate it stage by stage, but renaming the current root folder is comparatively safer, for you aren't gambling the installer won't be stubborn about the destination folder--the new version local root. Your content is not risked either, but backed up in a known state.
Above I'd presumed above some of the canned content can be used to test your various concerns; if not, and you want to see a specific problem on your own creations, before you do any of this... you can identify specific content and which route you want to test by monitoring date stamps: e.g. open surveyor, plant a tree, alter a session by adding a 1 second wait, save both. Repeat as needed for each session on the route. Open troublesome assets for edit, recommit, updating the date stamps. I'd do that with one more thing--a route you wouldn't mind not having on the new system for a while. THAT name & Kuid can be used to verify to yourself CM is looking at the right data set, for it is a couple of folders you will not copy to the temp folders and then import to the newly installed ...HF2 version. Data shows in CM, CM looking at the old directory. Data not shows in CM, CM looking at the new folder and data. Regardless of that bit of pre-planned safe guarding... When you've got your 'I want to test these' list exhausted, Quit Trainz all the way, wait a few minutes for it to finish processing, then 'Advanced search' for dates modified in the last day. Write down the files and their paths which changed, or take and save a screenshot or three. That's all folder paths you'll want to copy to your first temp folder -- content you've listed to import and test--working smart, not hard. (see next below)
Overall, a fresh install simplifies the build to manageable chunks, you can sub-divide the task by dispersing the local content to several other folders; I would leave the base data alone (it has time stamps, and you may recalling working on such and such ten days ago, or whatever), and selectively copy parts to a set of newly created temp folders off the Auran/N3V mother root folder (all my Trainz are off/in C:\Auran which is where I save any such content to be safe guarded as well, so I have a C:\Auran\libraries and C:\Auran\local as backups) to upload in CM in such chunks. A folder to folder copy is a fast operation. Feeding CM in smaller lots should speed things up as it validates content. Right now, from the above, it appears to be trying to be doing all that in one fell swoop. Oh, my setup also opens each folder in a seperate process rather than mucking around with the Explorer, I can and usually do have ten to twenty things open at once for direct access. Makes dragging and dropping far easier, and that goes double for copying and pasting. // Frank