[Eldorado.Railroad]

Files such as:

6a6ddd17b868349a1fcfed6b3998f180.dat
b07238e00af4e1ad1f389723e86ef4dc.dat

are deposited in the user directory Load Cache for Open Rails. But I often find it leads to a load error that requires me to retry a start for runactivity from the menu program. The actual error message is not descriptive from runactivty. This occurs after a simple edit/save of an .eng file, where I am tweaking some value and restarting runactivity. Since there is a lag in changes being physically written to disk either by windows/disk drive hardware it seem as if runactivity is trying to use parameters in the above mentioned .dat files in the Load Cache directory.

I have found that erasing the Load Cache directory and the .dat files in it assures that runactivity will not abort. This of course defeats the purpose of Load Cache.
This has been a problem for some time...many months and releases. A definite showstopper on this side of the screen. I have written a small script that erases this directory on an ongoing basis, but that is just a workaround for the problem/bug.

Anybody else have this problem?

[James Ross]

Eldorado.Railroad, on 06 April 2015 - 01:39 PM, said:

Files such as:

6a6ddd17b868349a1fcfed6b3998f180.dat
b07238e00af4e1ad1f389723e86ef4dc.dat

are deposited in the user directory Load Cache for Open Rails. But I often find it leads to a load error that requires me to retry a start for runactivity from the menu program. The actual error message is not descriptive from runactivty.

This seems like an unlikely cause, since the only thing affected by the contents of the Load Cache files is the progress bar during loadings. Nothing else uses it - it's not caching any of the content data or configuration at all.

The lag in things being written to disk will never be visible to applications unless they ask for unusual access modes (such as non-cached reading) and OR doesn't do that (I'm not even sure it's available without P/Invoke), so I doubt that is related too.

I'd like to see the error message in any case.

The fact you have written a script to "fix" your problem and not told anyone is a little disappointing, since if there is an actual bug we can fix here we may no longer have time to investigate and fix it.

[Eldorado.Railroad]

From 06 April 2015 - 02:39 PM:

The fact you have written a script to "fix" your problem and not told anyone is a little disappointing, since if there is an actual bug we can fix here we may no longer have time to investigate and fix it.

Aye...there's the rub. There are so many things to do for all of us and time being so limited that nor you nor I have the resources to solve them all. In my case, I was testing particle emissions and memory problems related to the camera remaining stationary on a given tile when many AI trains run through that tile. Having runactivity abort for no apparent reason with a less than descriptive message was a bit more than I could handle all at once. :-( James, sometimes resources run out for the extreme testers like myself and I have to prioritize what bugs I will tell you about and work with you to resolve. You do not always have the time or energy to look into the bugs that I post either, so I do ration things a bit depending on the amount of activity I see from the developer. :-)

All my script does is erase the Load Cache directory before running runactivity, since it is at THAT stage that runactivity can abort as indicated in the OP. Whether this is because multiple disc accesses occurs that unplugs runactivity is another question. I will create another post with the screen dump of the error message created.

Regards for all the hard work and effort...really! I hope the same latitude is held for me.

[James Ross]

Sorry, yes, I do understand the limited resources thing. I think it's that you wrote a script, which is some time/effort, but didn't post anything.

Anyway, I'm much most interested in what the startup exception is, as I don't yet see how the load cache can be related to things not starting. :p