Atomic Systems

smarty2 wrote:RSC should fix the problem, however that is only possible if they are aware of the problem?

Ha!

I'm quite certain RailSimulator.com would say the only problem is people who fill their disc up with huge quantities of unofficial add-ons! Remember that all unofficial add-ons should carry the following disclaimer:
RailSimulator.com Limited does not approve or endorse this user generated content and does not accept any liability or responsibility regarding it. This user generated content has not been screened or tested by RailSimulator.com Limited. Accordingly, it may adversely affect your use of RailSimulator.com’s products.

They would say their product works fine "out of the box" and with any or all official add-ons.

I'm sorry to appear to play devil's advocate but we should face reality.

John

Carinthia wrote:

smarty2 wrote:RSC should fix the problem, however that is only possible if they are aware of the problem?

Ha!

I'm quite certain RailSimulator.com would say the only problem is people who fill their disc up with huge quantities of unofficial add-ons! Remember that all unofficial add-ons should carry the following disclaimer:
RailSimulator.com Limited does not approve or endorse this user generated content and does not accept any liability or responsibility regarding it. This user generated content has not been screened or tested by RailSimulator.com Limited. Accordingly, it may adversely affect your use of RailSimulator.com’s products.

They would say their product works fine "out of the box" and with any or all official add-ons.

I'm sorry to appear to play devil's advocate but we should face reality.

John

I was I know talking out of context to the OP's original post concerning the memory problem, that isn't a problem that is caused by the amount of "unofficial" stuff people have, rather a bug that is in the "programme".

smarty2 wrote:I was I know talking out of context to the OP's original post concerning the memory problem, that isn't a problem that is caused by the amount of "unofficial" stuff people have, rather a bug that is in the "programme".

Apologies, I misunderstood you.

John

This kuju folder problem wouldn't exist at all, if RSC would fix the reskin blueprints (because currently only one texture can be replaced with it, because it's bugged), which can be placed to external provider folders, and have much smaller "overhead" than the frequently used, very messy workaround (copying geopcdx files, modifying engine/wagon blueprints, and placing these in original folders).

peterfhayes wrote:So it looks like in the ASSETS folder we can delete .tgt, .cost, .bak, .xml and possible ace/psd if you are not into repaints.

Gary hope you can confirm that this is not the ramblings of a madman!!

I can only confirm they're not ramblings....

You can add .dds to list too.

One note of caution to anyone using the search facility in Windows Explorer:
don't forget to include the . as well as the letters; for example, using just xml will generate a results list that includes the .proxyxml files, and unless you really love the sound of silence these files are essential and shouldn't be deleted.

Carinthia wrote:the UKTrainsim Freeware Packs play a major part in this. These really need to come out of the dark ages and allow us to install only the items we want

I believe Jim changed the installation routine to allow for extraction to an alternative location, from which you could 'cherry-pick' just those assets you wanted. If I'm wrong, it's not terribly hard to use WinRAR or 7-Zip to extract the .msi package from the supplied .exe and run msiexec from a command prompt window to do the extracting to where you want bit. I'm happy to talk you through it if that's any interest to you, just drop me a PM rather than fill this pretty useful thread up with off topic stuff.

gptech wrote:I believe Jim changed the installation routine to allow for extraction to an alternative location, from which you could 'cherry-pick' just those assets you wanted. If I'm wrong, it's not terribly hard to use WinRAR or 7-Zip to extract the .msi package from the supplied .exe and run msiexec from a command prompt window to do the extracting to where you want bit. I'm happy to talk you through it if that's any interest to you, just drop me a PM rather than fill this pretty useful thread up with off topic stuff.

Thanks. I don't have a problem disposing of what I don't want but my point is that as everything is installed by default others might not have the confidence or knowledge to do so and therefore end up with this problem of an excessive number of files affecting the efficiency of their setup.

John

shanyiqua wrote:This kuju folder problem wouldn't exist at all, if RSC would fix the reskin blueprints (because currently only one texture can be replaced with it, because it's bugged), which can be placed to external provider folders, and have much smaller "overhead" than the frequently used, very messy workaround (copying geopcdx files, modifying engine/wagon blueprints, and placing these in original folders).

Even the reskin blueprints method adds a .bin file, and it's the amount of these the game is reading/loading/indexing not the size of the folder that is the crux of the matter---or at least the greater part, like Peter I believe there's something more going on, maybe even the quality of the .bin file editing.

Carinthia wrote:I don't have a problem disposing of what I don't want but my point is that as everything is installed by default others might not have the confidence or knowledge to do so and therefore end up with this problem of an excessive number of files affecting the efficiency of their setup.

Yes, i agree on that score but it's possibly a bit too much to ask for what is a free package, or rather free packages!!
Unfortunately, to get the best out of this game does entail learning a wee bit about how to use Windows etc, but that might not be such a bad thing.
Of course, the burning question is "who's going to teach those who don't know?"

There is a Microsoft Sysinternals app that could prove useful for those experiencing the KUJU folder problem and that is Process Monitor - Procmon.exe.
If someone who has had this KUJU error could run Procmom.exe in the background whilst TS2013 is running and filter on railworks.exe dynamically - when the crash occurs we should see what caused it. (export the log file which has a .pml extension.
I have run procmon.exe on my system but it shows NO errors in the log file wrt KUJU folder - all the calls to that folder are "normal" and not significant, but I don't see SBHH errors.
I have not found a single common .BIN file in either the KUJU or RSC folder that might cause a mismatch.
The other errors to look out for preceding the crash would be something like: Access Denied, Sharing Violation, Name Collision, Privilege not held, and possibly Buffer too small, Buffer overflow, Network errors (maybe) and so on.
Be aware that Procmon can be a resource hog on some occasions eg on complex routes such as WCMLN - yesterday it brought my system to its knees with a cpu load of 40% and a RAM usage of 96% when monitoring WCMLN. Nothing responded!! and I lost the log file!
I'm not game to load my KUJU folder which 3rd party addons to see if the error could be found!!
Regards
pH

Peter,

Is there a step-by-step guide somewhere to running procmon and interpreting the results?

I have a backup of my old bloated Kuju folder. I'm quite comfortable dropping it in my TS2013 installation and creating SBHHs.

Kieranread
I use a lot of sources - just give me a little time and I'll put a simple (HaHa) guide together, just for this exercise.
Will post back later.
pH

Kieranread
This is as simple as I can make it:

Process Monitor Simple:

INSTALL
Download Process monitor (.zip) from here: http://technet.microsoft.com/en-au/sysi ... 96645.aspx
extract the zip file to a folder of your choice, and right click (run as administrator) on Procmon.exe to launch the tool.

RUN
To stop or start data capture use CTRL + E or "FILE capture Events"
Do this BEFORE starting TS 2013
Minimise to Task Bar
Start TS 2013 as normal run the scenario as usual
Wait until it crashes (note time exactly)
Maximise Process Monitor

STOP DATA CAPTURE
Stop Data Capture – CTRL + E again

FILTER
Now we need to Filter the Results
You can filter information in two ways. I will describe only one method, as to me it’s the simplest:
Select FILTER\FILTER from the menu
• Select “Process Name” from the Column list box
• Select “is” from the Relation list box
• Type “Railworks.exe” in the Value text box
• Select “Include” from the Action list box
• Click on the Add button
• Click on Apply and OK
Now, we know we are NOT looking (INITIALLY – will put back later) for a registry issue so look at the data list and right click on any of the following and choose "EXCLUDE":
RegOpenKey”, RIGHT click “Exclude”, and click “Operation”.
Repeat this process for the other registry values:
RegQueryValue,
RegCloseKey, and
RegEnumValue.
RegSetInfokey and do this for any value prefixed reg

We can filter these back in later if needed.
This filter is not definitive later down the track I will refine it further but at the moment it gives the info we are after. Removing some of the filters removes all of the data and that's not good, eg all the Windows entries!! The antivirus entries should be checked to make sure they are not the culprit.

Now only entries pertaining to Railworks.exe will be displayed.
Now Select "FILE" and SAVE and choose the path and name that you want saved it will be saved as a pml file that process monitor can identify.

DATA ANALYSIS
Now let us look at the data:
Knowing the time of the crash scroll to the bottom of the data (which is where the crash which will take some time and note any error message(s) at the error and note this/those down.
We also need to look at the ASSETS\KUJU\RAILSIMULATOR entries
Select EDIT then FIND and type in the box and type in Assets\kuju\railsimulator and press find.
Scroll down these entries – there will be a lot – Looking in the RESULT Column for the entries
Access Denied,
Sharing Violation,
Name Collision,
Privilege not held,
(and possibly Buffer too small, Buffer overflow, Network errors (maybe) and so on.)
Any other entries are usually not significant.

When you reach the last entry in this block use FIND\FIND\FIND NEXT to start the next search and repeat until the end of the file.

Note any of the above errors and what they pertain to.

If you have time, check all the entries in the RESULTS column for the errors listed above.

It is time consuming and tedious but I wanted to include all possible errors and did not want to filter out stuff that might be useful.

I would hope that we will see a definitive error that is causing the problem – if not we’ll bring back the registry entries only and analyse them.

NOTE: On some routes Procmon and TS2013 use a lot of RAM and may bring the process to a halt so choose a route that is not too complex if possible.
Get back to me if there is anything you are not sure of.
pH

gptech wrote:Even the reskin blueprints method adds a .bin file, and it's the amount of these the game is reading/loading/indexing not the size of the folder that is the crux of the matter---or at least the greater part, like Peter I believe there's something more going on, maybe even the quality of the .bin file editing.

Reskin blueprint bin files are much smaller than the original blueprints, also the geopcdx file of the original is re-used, and not a new geopcdx is loaded for every reskin(and no need to be included with the reskin), and the reskin files can be moved to external provider product directories, so the kuju/railsimulator asset reskins don't need to be in kuju/railsimulator folders, but can be placed in the reskin developer's own provider/product folder.

shanyiqua wrote:Reskin blueprint bin files are much smaller than the original blueprints, also the geopcdx file of the original is re-used, and not a new geopcdx is loaded for every reskin

True, but the problem isn't the size of any file, or files; it's the referencing of files to be indexed/loaded/whatever and even though a new shape file isn't needed the existing one is again referenced. Whilst I agree that any reduction in the load on the game will only help, the reskin blueprint route doesn't take that much weight off. Has anyone managed to get a reskin blueprint to deal with more than a single texture change?---if not it's of little use for locos with multiple textures (body, cab, and roof for example) that need changing to poprtray a particular livery.

Clearing the 'junk' files out of any folder, not just the Kuju/Railsimulator one, will not make a huge difference to how the game runs---good housekeeping though and I'm all for tidy installations. The size of the Kuju/Railsimulator folder, as has been pointed out many times in discussions about this issue, is not the problem: we only look at the size as that's the most readily seen attribute in Windows Explorer to indicate where a problem may lie.
As a rough and ready, and certainly flawed experiment....



would be expected ro result in an immediate crash if it was purely the size of this, or any, particular folder. This is not the case though, as being a flawed experiment the bloat is caused by 30GB + of video files in there. Of course these files aren't recognised at all by the game, so repeating the exercise with a file type that is (.TgPcDx) yields the same results. I've neither the time nor the inclination to try it with a bunch of edited .bin files to reflect the new location of the files, but even though the experiment is flawed, and not proof of anything, it indicates that the size of the folder has no bearing.

peterfhayes wrote:If someone who has had this KUJU error could run Procmom.exe in the background whilst TS2013 is running and filter on railworks.exe dynamically - when the crash occurs we should see what caused it.

I ran ProcMon.exe three times while trying to load one of my many scenarios that went to the dogs after the TS2013 update. As best I could tell by reading the point in the logs where TS dies in a SBHH, there is no clue about why this is happening. And, as far as I can tell, all of the loading from the Kuju folder completed successfully. The most consistent error I could find was in the EventViewer which all 3 times cites GameManager.dll as the faulting module (along with a bunch of other stuff I don't understand -- offsets and the like), though I doubt this is going to help us get to a universal solution for this issue.

I saved the ProcMon logs (in the program's native format), but they're all around 150MB, and I doubt anyone wants to download one of these, but if you do, let me know and I'll put them in my DropBox and send you the link.

One other thing I wanted to mention. A number of people early on in this saga of the SBHH errors suggested that these were related to multiple unnecessary provider entries in the RouteProperties.xml. In my case fixing these did not solve any of my problems. I also went through the process of hand editing ScenarioProperties.xml files to the same end -- using RW_Tools to list required assest and removing unnecessary provider entries, but this also made no difference whatsoever.

Thanks to you all for your thoughts and work on the "Kuju" problem.