No worries. This is good news.

I will compare the two and try to find what is likely a missing file so that the download will work on its own. But for now, a good workaround in a problem like this is to do as you did and copy/replace Resource from the original fileset.

Thanks.

Orazio, since this error in your .dmp file occurs in the load font function, what do you show in start.ini for this value?

startFontIniFile = fonts.ini

“I want to try recreating Orazio’s error on one of my kids’ 64 bit machines. I think I will install VS and run debug mode, hoping for similar error to isolate to the actual code line.”

Orazio, got VS installed, along with the full source, on one of them yesterday. I will proceed to play around and try to recreate your issue while in debug mod…[Read more]

I had a work project obligation that sucked much of my time, but I was able to complete and ready for beta testing one day before deadline. As such, I should be able to resume carving out a bit of personal time for this. Apologize for the unforeseen hiatus, but duty called 🙂

I want to try recreating Orazio’s error on one of my kids’ 64 bit…[Read more]

Ah, good. If it’s correct in the ERAS2Test files, I most likely included the same corrections in ERAS2.Patch as well. ERAS2.Patch being strictly files to be used for fixing various issues with the standard game compilation.

I may have edited those wrong, I’d have to check. But I remember I found that there were entries that didn’t exist (like you did) and may have inadvertently adjusted them to what they ‘should be’ and messed it up the same way it was already messed up, LOL.

Also, I think the fontload crash was misleading. I’ve taken further look and I think (but…[Read more]

Well, I ran the file in debug mode and found the function in the render .dll where the mishap occurs. It’s FontLoad, and a subsequent waitforobject call that crashed. Unfortunately, since I can’t replicate the problem, I don’t exactly know why this would occur, so I’m a bit stuck in figuring a resolution for it at the moment.

Nice. I don’t think much has changed…sure, there are more people these days than ‘back in the day’, but here’s a story from only a few months ago:

A buddy and I scheduled a trip to a river near the coast, to of course, target some winter steelhead. I drove to his house, parked my rig, and we headed out there in the early morning (still dark)…[Read more]

First, yeah, I borrowed the hotkey commands for the fleet from GOF and that is actually in my “patch” files for running under the original compilation, too. Thought I had mentioned that, but perhaps not. It also means that upon adopting the new patch files, then loading a game, sometimes the character can’t move at all, and all one has to do is…[Read more]

First, yeah, I borrowed the hotkey commands for the fleet from GOF and that is actually in my “patch” files for running under the original compilation, too. Thought I had mentioned that, but perhaps not. It also means that upon adopting the new patch files, then loading a game, sometimes the character can’t move at all, and all one has to do is…[Read more]

I think I already know the major problem; the asm part of of the .sha files can no longer be assembled. In Dx8, the declarations were apparently not fully implemented yet, but in Dx9, they are and some declarations are required in the asm portion of the code read in to assemble. But those .sha files do not declare the registers and the ‘assemble…[Read more]

Game loads now. Mangled though. Not sure why, but some Dx9 function calls fail in places where supposedly no code change was needed. There are some programs that didn’t require change at all according to migration notes. Oh well. Getting closer.

Notice the dx9 references in ProcExplorer 🙂

Don’t know…though I did notice that the worldmap routines look for _palm models and won’t find any. Though not finding any doesn’t affect the game, as it just passes them by, but logs it anyway. As for ‘fireplace’, I’ve seen that before in the stock game and I think it’s really just ‘a place where fire might be’…like in battle boarding. I…[Read more]

Uh oh, Orazio. Turns out there’s a slight issue. That .dmp file is 64 bit, and I guess you have to run a 32 bit task manager to dump the file from a 32 bit process/program for me to get one that is debuggable.

I found this:

32-bit task manager under C:WindowsSysWOW64taskmgr.exe. We can use this and select “Create Dump File” for 32-bit process.…

[Read more]

Yes, I need the file so I can load it in the debug feature within Visual Studio, along with the symbol .lib files used to create the .exe/.dll. Then it will identify the functions where the crash happened.

It’s fine to PM a link, but my understanding is that .dmp files will only contain sensitive information if the app itself contains features…[Read more]

Go ahead with the camera…fisheye was becoming a bit grating for me, LOL.

Unfortunately, what I’ve noticed with some crashes is that they are often in unexpected and unhandled situations, so you don’t see them in a log because the code wasn’t implementing a check/output to log in case of bad info. This is where the .dmp files will come in…[Read more]

I did try both a new game and entering ship cabin on another computer, running Win 8, but could not produce the problem.

I’m betting your graphics card and/or machine is probably better and smarter than the dumb, mediocre machines we have, but our dumb ones work fine, LOL.

If you can get that .dmp file, it might help me figure it out.

Oh, and while you’re at it…you should also enable DUMP files on your machine, or keep it open on a crash and use task manager to create one. If you have a crash, upload and link the .dmp file so I can try to track down the problems. I compiled with debug info, so I can at least get the function symbols and know what function within the .dll is…[Read more]

My goal was to make testing it relatively simple, and negate the need for someone to duplicate the large set of RESOURCE files/models/etc. One just needs to extract preserving the file structure into a new folder, and all the module, Program and INI stuff it needs resides in its own dir, but then just point a few of those start.ini paths to the…[Read more]

That texture degradation setting is copied from my original ERAS2 settings and was due to my system’s performance problem when trying to open chests. If your system doesn’t need that, you can certainly change it.

As for the problem, enable crash dumps for your OS.

If newer:…[Read more]