OpenMW 0.29.0

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Post Reply
User avatar
Greendogo
Posts: 1467
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.29.0

Post by Greendogo »

ACE's nightly builds are only from the "Master" branch, so none of your fixes are included in the latest one, Zini (and won't be included in any subsequent build). Could someone build openmw-29 for Windows. Ace?

Zini, what is this supposed to fix? The corrupt save bug, or the crash on save bug?

Edit: On an unrelated note, while looking for a crash log to look at, I saw several "OGRE EXCEPTION"s mentioned in my ogre.log, for anyone who finds it interesting:
Spoiler: Show
Top
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenMW 0.29.0

Post by cc9cii »

I've got a local build of "Master" plus the suggested fixes on this thread (windows x64). If required I can re-build 0.29+fixes and test again. (in 3 hours or so)
Top
User avatar
Greendogo
Posts: 1467
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.29.0

Post by Greendogo »

I'm running 32-bit windows, so 64-bit wouldn't work for me.
Top
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenMW 0.29.0

Post by cc9cii »

Progress report.

Testing with one savefile created outside Census Office. The file is called "0", which in itself looks sus already, and it is located in ...\Documents\My Games\openmw\saves\0\. This directory name is also a little sus, did we mean to have a directory "0" created?

In MWGui::MainMenu:

Code: Select all

        if (MWBase::Environment::get().getStateManager()->characterBegin()!=
            MWBase::Environment::get().getStateManager()->characterEnd())
            buttons.push_back("loadgame");
The value of mCharacterManager.mPath seen inside the debugger is

Code: Select all

"d:\\Users\\Dad\\Documents\\My Games\\openmw/saves"
Note the forward slash just before "saves". mCharacters has size=0, so the game does not bother to render the "loadgame" button.


At this point I'm not sure if it is my boost build (which is 1.55.0 git branch last updated 12/11/2013) which is causing the pathname issue (if it is indeed the issue).

EDIT: doesn't appear to be the issue. I tried using make_preferred() to get the path string correct (and confirmed in the debugger) but still the size of mCharacters is 0.
Last edited by cc9cii on 21 Feb 2014, 10:09, edited 1 time in total.
Top
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: OpenMW 0.29.0

Post by Zini »

All paths are correct. This is definitely not a problem with paths or saved game file management. Either the ESM reader or the writer or code that is using one of these is broken.
Top
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenMW 0.29.0

Post by cc9cii »

Zini, shouldn't mCharacters be non-zero if there is a file in the right location?

What is a normal savefile name, anyway?
Top
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: OpenMW 0.29.0

Post by Zini »

Okay, let me explain. At startup OpenMW runs through all the saved game files and peeks into each of it for some meta-information. If the process of peeking fails OpenMW assumes the file is broken and ignores it. If all files of a character fail to load the entire character is ignored. And if there are no characters with a valid saved game file, you won't get a "Load" button in the main menu, because there is nothing to load.
Top
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenMW 0.29.0

Post by cc9cii »

Ok, which module does the initial scanning? I had assumed that ESMReader was used to look at the savefile. I'll put some breakpoints to see what is going on.

Edit: openRaw() caught it. I'll step through and report back.
Last edited by cc9cii on 21 Feb 2014, 10:25, edited 1 time in total.
Top
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: OpenMW 0.29.0

Post by Zini »

That is correct. ESMReader is used for the scanning. The particular instance of the ESMReader is created in MWState::Character::addSlot.
Top
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenMW 0.29.0

Post by cc9cii »

It is failing while checking mInGameTime:

Code: Select all

// Get the next subrecord name and check if it matches the parameter
void ESMReader::getSubNameIs(const char* name)
{
    getSubName();
    if (mCtx.subName != name)
        fail(
                "Expected subrecord " + std::string(name) + " but got "
                        + mCtx.subName.toString());
}
The debugger has these values for mCtx.subName ("TSTM" expected):

Code: Select all

-		name	0x00000000001cdf94 "—:ƒº...	char[4]
		[0]	-105 '—'	char
		[1]	58 ':'	char
		[2]	-125 'ƒ'	char
		[3]	-70 'º'	char
I'll hack a file with a hex editor to see if we can get past that.

EDIT: TSTM exists, but looks like wrong offset. Hmmm... I'm not so good at adding up numbers :( Can't tell if the code is using wrong offset to read it in, or the save file is bad

Got it. ESM::SaveGame::load()

Code: Select all

    mPlayerName = esm.getHNString("PLNA");
    esm.getHNOT (mPlayerLevel, "PLLE");
    mPlayerClass = esm.getHNString("PLCL");
    mPlayerCell = esm.getHNString("PLCE");
    esm.getHNT (mInGameTime, "TSTM", 16);
size of mPlayerCell is 2573, way past the next subrecord which is only 10 characters away

Code: Select all

		[size]	2573	unsigned __int64
		[capacity]	2575	unsigned __int64
		[0]	0 '\0'	char
		[1]	101 'e'	char
		[2]	121 'y'	char
		[3]	100 'd'	char
		[4]	97 'a'	char
		[5]	32 ' '	char
		[6]	78 'N'	char
		[7]	101 'e'	char
		[8]	101 'e'	char
		[9]	110 'n'	char
		[10]	84 'T'	char
		[11]	83 'S'	char
		[12]	84 'T'	char
		[13]	77 'M'	char
But that cell name is truncated - where is 'S' character?

Anyway, the file has 0D 0A (hex 0A0D is 2573 decimal) which means Windows is reading 2 bytes rather than one

getT(mCtx.leftSub); in ESMReader::getSubHeader() is returning a large number. I'm having trouble getting my head around the template code.

Code: Select all

struct ESM_Context
{
  std::string filename;
  uint32_t leftRec, leftSub;
  size_t leftFile;
  NAME recName, subName;
  // When working with multiple esX files, we will generate lists of all files that
  //  actually contribute to a specific cell. Therefore, we need to store the index
  //  of the file belonging to this contest. See CellStore::(list/load)refs for details.
  int index;
So, the size is meant to be 4 bytes. That means for some reason we have a corrupted savefile. Time to step through the save process.

Still not sure why the cell name is incorrect.
Top
Post Reply

Return to “Organisation and Planning”