Consist placement causing editor to crash

[OldProf]

It isn't often that I turn to pre-made consists when writing scenarios, but sometimes the convenience bug leads me astray. Lately, however, whenever I try to place a pre-made consist in the scenario editor, even one of my own, the program immediately gives up the ghost, leaving me with one of those supremely irritating DMP file messages.

Begin rant: Honestly, RSC admitted well over a year ago that not even they are capable of reading DMP files, so why on earth can't they just "dump" them from the program's code and give us some possibly practical information about what the heck has caused the crash? End rant: we now return to the matter at hand and apologize for any inconvenience.

What was that? Did you see that, too?

I've had this problem while writing and editing scenarios on various routes and have taken the usual actions after each (well, okay, not every one): cache verification, extermination of blueprints.pak files, check for pom-something files (of the which I have positively never found none), followed by another crash whenever I try to place a consist .

Someone please tell me there's a way out of this mess.

[buzz456]

My experience with that situation in that something is fubar in the scenario and the only way I have found to fix that is to delete the offender and then re-acquire it in total. I just had that on a HSC situation last week and that fixed the problem.

[OldProf]

My experience with that situation in that something is fubar in the scenario and the only way I have found to fix that is to delete the offender and then re-acquire it in total. I just had that on a HSC situation last week and that fixed the problem.

Interesting suggestion, but this happens when I'm editing my own scenario. Perhaps I should package it, delete it, and reinstall it? (Pretty Byzantine, but not any more so than many things we seem to have to do with the scenario editor.)

[buzz456]

It might well be something in the route. I might not have been clear. I saved the scenario deleted and re-installed the route and that fixed it.

[OldProf]

It might well be something in the route. I might not have been clear. I saved the scenario deleted and re-installed the route and that fixed it.

Yes, that makes more sense.

[peterhayes]

Tom
I don't want to confuse you but IMO the crashes caused by the editor are due to all or some of the following:
The Virtual Address Space (VAS) by using the editor it causes the VAS to become fragmented and the contiguous space to become less. WRT the latter if TS2015 cannot find just 1 MB of contiguous space to load into at a particular address then it will crash. (For a 32-bit program running under a 64-bit OS the MAXIMUM value of the VAS is 4GB. In a 32-bit OS this drops to 2GB unless you use the /3G switch which increases it to 3GB).

As you are using the editor a mismatch may occur ie you are inadvertently sending a call to a memory address in the RAM, to code that is in the VAS but not yet in the RAM.

Due to the way that the editor works it may interfere with the desktop heap and you can get desktop heap exhaustion. Basically there are several desktop heaps and

If any one of the desktop heaps becomes too full, allocations within that desktop will fail. If the cumulative heap size of all the desktops approaches the total size of session view space, then new desktops cannot be created within that session. Both of the failure scenarios described above depend on two factors: the total size of session view space, and the size of each desktop heap allocation.

To overcome this you can increase the desktop heap size and that may fix the problem. This MS KB describes how to do it: http://support.microsoft.com/kb/126962/.

How can I stop the VAS from defragmenting - well in a 32-bit OS it can be done but its a bit more tricky in 64-bit Windows as there are no clear parameters to work on - I have been successful using this registry hack but IMO it can be tricky. It involves changing the registry value for the HeapDecommitFreeBlockThreshold and again I stress there are no guidelines for 64-bit OS so it is by changing a value and see if it works. This is how to do it Ref: http://support.microsoft.com/kb/315407 and http://technet.microsoft.com/en-us/libr ... v=exchg.65).aspx. Basically it stops the VAS from fragmenting. I have tried a figure of decimal 524,288 (512MB) = Hex 0x80000 without ill effects but they may vary PC to PC.
Note: Be aware that in Windows 7, the system already uses the low-fragmentation heap (LFH) as needed to service memory allocation requests, and so this tweak may be less effective in certain circumstances. I have no experience with this hack in Windows 8.

Why does this happen? IMO it is the way that a 32-bit app like TS2015 interacts with the VAS. It may well improve if UE4 operates on a 64-bit OS which is likely if you look at the new DTG fishing game.

Can this be fixed - No! The above hacks may or may not help.

Sorry this very technical.
pH

[OldProf]

Peter, I really do appreciate the time and effort you are willing to expend to explain how computers work (or don't, mostly), but all of that is really wasted on an ignoramus such as myself. My inner child is still that kid who could disassemble almost anything but never put it back together in anything resembling working order.

Before starting a fresh editing session yesterday, I rebooted my computer and launched LogMate before TS2015. I then opened the scenario editor and called up the scenario that has led to so many crashes lately, which is for the VNHRR route. Here's the full text of the LogMate report after the inevitable crash:
=====================================================
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : Kuju, RailSimulatorCore
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: Cameras\EditCamera001.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : RSC, Class87Pack01
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: PreLoad\Class47LL Engine.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : RSC, Class87Pack01
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : RWA , Lakeside
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: RailVehicles\Diesel\RS-1\RWA\Engine\Alco_RS-1_001.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : RWA , Lakeside
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_ICWg_IC
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: Personenw\Apmz\IC-Apmz.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_ICWg_IC
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_ORot
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: Elloks\BR151-144\BR151_DynNum.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_ORot
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR323
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: DieselLoks\BR323\BR323.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR323
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_BlBe
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: Elloks\BR151-BlBe\BR151_DynNum.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_BlBe
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_AGruen
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: Elloks\BR151-Gruen\BR151_DynNum.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_AGruen
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_VRot
Trace cBlueprintLibrary.cpp : 448 = Blueprint set not found for: Elloks\BR151-156\BR151_DynNum.xml
Trace cBlueprintLibrary.cpp : 417 = Blueprint set not found : virtualRailroads, vR_BR151_VRot
Trace cRailSimSoundSystem.cpp : 534 = Sample Kuju\RailSimulatorUS\Audio\Ambient\US\Point\Amb_P_Builder.dav has a 'smpl' chunk defined in the wave file but no sample loops defined.
This is not an error, but is it as intended?
===========================================================================

Some comments: although I have not checked everything that TS could not find, I'm reasonably sure that all of it is included in my installation. But why was TS even looking for most of those items, since the brief editing session asked only for the VNHRR route and its included rolling stock? Thinking about your explanation of what amounts in my simple view of searching the wrong virtual toy chest, why would TS look for Legos if the task at hand involves an Erector set? Finally, I find ironically humorous the final question asked by LogMate (and to whom or what this question might be addressed): "This is not an error, but is it as intended?" Did our current Congress design this program or did this program design our current Congress?

Yesterday, I used the Utilities program to painstakingly uninstall every trace I could find of anything related to the VNHRR, after saving my current scenario projects in an RWP package. This morning, I'm going to reinstall VNHRR and my scenarios and give this another try. After which, I may just buy a copy of the infamous Rock Simulator.

[Chacal]

This situation makes me think that you could have a problem with your scenario or route loading some unneeded assets. This being due to extraneous provider/asset pairs in a blueprint.

I suggest you have a look at Bob Latimer's tutorials on our web site, in the "troubleshooting railworks" section.