OpenMW 0.29.0

[cc9cii]

With hacked size with a binary editor I can get to the load screen:


But notice the malformed cell name:


The save game doesn't actually load

I will need someone with a bit more experience to help me with this I think.

[Zini]

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

What the fuck? That is a Windows line ending, right? carriage return (13=0x0d) followed by a line feed (10=0x0a). Seems like chris was right with this guess. But why is that happening and why only in one place?

[cc9cii]

Actually that sequence is littered throughout the save file (which is probably why it doesn't load). Is there a good savefile I can try? I don't want to create a linux VM just to get a savefile made. (well, maybe later)

I guess I'll start stepping through this:

Code: Select all

    void ESMWriter::startSubRecord(const std::string& name)
    {
        writeName(name);
        RecordData rec;
        rec.name = name;
        rec.position = mStream->tellp();
        rec.size = 0;
        writeT<int>(0); // Size goes here
        mRecords.push_back(rec);

        assert(mRecords.back().size == 0);
    }

[Zini]

Can't provide you with a saved game file, because I have the German version of MW, which is incompatible with whatever version you have (assuming the most likely case that it is not the German version).

Anyway, you say the sequence is littered throughout the file. Does it affect all string records? If not, can we get a list of some good string record types and a list of some bad record types? Maybe there is a pattern.

[scrawl]

Edit: right, damn localisations. Nevermind then.

[gus]

whooops forgot to mention I also open the file in binary mode, but as it didn't fixed anything, I forgot. I guess it was a combination of multiple bugs then

around line 188 of statemanagerimp.cpp:

Code: Select all

std::ofstream stream (slot->mPath.string().c_str(),std::ios::binary);

instead of

Code: Select all

std::ofstream stream (slot->mPath.string().c_str();

[Zini]

Found something: In esmwriter.hpp:

Code: Select all

        struct RecordData
        {
            std::string name;
            std::streampos position;
            size_t size;
        };

And then in esmwriter.cpp, ESMWriter::endRecord:

Code: Select all

        write (reinterpret_cast<const char*> (&rec.size), sizeof(int));

The size of size_t is usually not equal the size of an int on the 64 bit system.

[cc9cii]

I don't see a pattern. There are some topics ("TOPI") with "0D0A0000" as the size while other topics are fine.

The one with odd size has string "ackground" which I've never seen in years of playing morrowind. So it doesn't seem to be consistent.

I'll keep looking.

[cc9cii]

Found something: In esmwriter.hpp:

Code: Select all

        struct RecordData
        {
            std::string name;
            std::streampos position;
            size_t size;
        };

And then in esmwriter.cpp, ESMWriter::endRecord:

Code: Select all

        write (reinterpret_cast<const char*> (&rec.size), sizeof(int));

The size of size_t is usually not equal the size of an int on the 64 bit system.

I think I had that changed in my debug version only (I think gus suggested it?), I'll try building a release version and re-try.

[Zini]

Edit: Wrote nonsense.