Application - Xethik

[Zini]

Weird. The problem you mentioned is likely the result of a runtime misconfiguration. The build is probably okay. Are you sure, that you went through exactly the same steps when running 0.26.0 as with your self-build binary? Have you tried to run your self-build binary again, after you had run 0.26.0. Also, what do your openmw.cfg files look like?

[Xethik]

Hey Zini. I agree, it's a runtime thing, but a very strange one at that. I should have updated before I nodded off for the night, but I was able to make some progress. The news isn't great, but maybe I'm just completely wrong.

I'll update and then answer questions. Hopefully.

I rebuilt the project and was able to get past the vector offset nonsense. After that, I had some issues regarding ContainerStoreIterators. See the attached file "callstack.txt" for the callstack there. This is the exact line I was running into issues on. (Containerstore.cpp in the mwworld, function call addImpl).

Code: Select all

case Type_Clothing: clothes.mList.push_back (*ptr.get<ESM::Clothing>()); it = ContainerStoreIterator(this, --clothes.mList.end()); break;

So, when it was doing the it = ContainerStoreIterator portion of the code, it was crashing. Since the assignment operator was not overriden, it should function fine. Apparently, this is a "bug" in the VC100 standard libraries.

http://connect.microsoft.com/VisualStud ... ils/577672

So, to test this, I rewrote the code to look something more like this...

Code: Select all

case Type_Clothing: clothes.mList.push_back (*ptr.get<ESM::Clothing>()); return ContainerStoreIterator(this, --clothes.mList.end()); break;

and this fixed the issue at this point. However, later in the code, similar iterator assignments are made and my code breaks again. So now I at least know what the issue is (for the most part) and will hopefully come up with a workaround.

I'm actually unable to install VS2012 for some really awfully dumb reasons, so I'm going to look into either a) doing local changes for a workaround or b) see if there is something I can do more directly regarding my Visual Studios.

My release 0.26 and personal build openmw binaries are using the same openmw.cfg and such files, so I'll attach those, too. Is that normal?

I'm able to switch between release .26 and self built binaries. I can even mix-match what directory I run them in. It doesn't change the errors or cause new ones. The errors are strictly in the .exes, not the libs they call. Not sure if that's good or bad.


EDIT: I decided to see what would happen if I did an assignment operator override for ContainerStoreIterator and just did a cout << "test" << endl; I can confirm that by doing this, I get to at least almost game launch, at which point it crashes because I did horrible horrible things to the actual code. But, maybe I can come up with something clever for the override and fix all of this. I'm not entirely sure how the ContainerStore/ContainerStoreIterator code is written, but I'm a bit confused on what each of the iterators is for. Does each ContainerStoreIterator only deal with one type of objects?

[Zini]

The iterator problems you describe are odd. I haven't heard any of the Windows developers report them and while we don't have many of them, that would surely have shown up. Or is that indeed a problem with the MSVC version? Can anyone comment on that?

Also, please note that we will most likely move to C++11 as soon as the next OGRE version is released. We haven't looked at the situation for a while, but chance are good that MSVC 2010 won't be able to build OpenMW at all after that.

My release 0.26 and personal build openmw binaries are using the same openmw.cfg and such files, so I'll attach those, too. Is that normal?

The user openmw.cfg file is the same. Assuming you have run the 0.26.0 installer, that one should have a unique global openmw.cfg file, but since local and global oopenmw.cfg file are the same on Windows, if you copy the self-build executable into the 0.26.0 directory (or the other way around), the files would indeed be re-used.

That openmw.cfg file is a total mess. Looks like somehow the local/global files got mixed together. However if that is the file in the local/global location (alongside the executable on Windows) and the user openmw.cfg file isn't messed up too, it should still work.

[Xethik]

I definitely need to figure out how I'm going to get VS2012, then. Problem is, Windows (for whatever reason) needs to put 6+ GB on my bootdrive. After installing Windows alone, I don't even have that much. It's honestly idiotic that I can't put these files on my non-SSD, but I can't find a work around.

This problem appears to only be when compiling using VC10. I suspect a lot of people are using VC11 or even VC8, though maybe I'm wrong.

About the openmw.cfg. I have one of these files in the same directory as the exe, but they don't seem to be updated ever. Instead, I've been pulling the one out of Documents\My Games\openmw\, the same place the logs are stored. This seems to be the cfg being read, too, as it is the one my command line mentions on launch. Is this not normal?

Here is the openmw.cfg in the same folder as the exe.

[Ace (SWE)]

For some reason I don't think it's VC10 that's the fault, all of my OpenMW buids have been done with that.
Getting x64 builds done was a true hell though, fixing up Ogre for 64-bit windows builds took ages what with all of the dependencies, many of which didn't have proper windows builds set up.

I'd be happy to try and help you resolve this, but I've been pretty damn busy and sick lately, so not sure how much help I can be.

[Xethik]

Hm... Alright then. Strange. Are you running service package 1 on your VS2010? I remember mentioning to you on IRC that MyGUI claimed to need Service pack 1. Apparently, that wasn't the issue I was running into. Perhaps this is related to that, though.

[Xethik]

Update:
I managed to rewrite some of the code so that it would at least make progess, but now I'm getting RTTI errors. Seems like this is happening somewhere in the Ogre code, maybe Bullet. trace.cpp has an issue with this line:

const btBoxShape *shape = dynamic_cast<btBoxShape*>(actor->getCollisionShape());

I guess I didn't compile my Bullet or Ogre with RTTI and it's complaining. Going to see if I can get around that.

[Xethik]

Another update:

After a bunch of random changes, I was able to get the debug.exe working. It runs at a super slow frame-rate, but acceptable enough to test things out for character creation. I wasn't actually able to get a working release exe which is... odd, but I was able to get it working enough.

I think from this point on, I'll either be working under Linux or 32-bit. Thanks for the help everyone. If anyone trips up with a 64 bit system environment, perhaps my failures will help them.

[Ace (SWE)]

Believe me, setting up a 64-bit build for OpenMW on Windows is a lot of work. 32-bit builds on the other hand are surprisingly easy to do as all of those libraries already exist in compiled form.

Either way, good luck with your development.

[Xethik]

The problem has been solved. The reasoning is EXCEEDINGLY stupid, but if you're curious, it comes down to this.

In my debug build, this line was being parsed this way.

Code: Select all

Ogre::Matrix4 mat4(Ogre::Matrix4::IDENTITY);

mat4 is an object of the Matrix4 class that is copied from IDENTITY.

In release build, it was a bit different.
mat4 is a function that returns an Ogre::Matrix4.


So yeah. That was fun figuring out. Real fun.