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.
OpenMW 0.29.0
Re: OpenMW 0.29.0
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?Anyway, the file has 0D 0A (hex 0A0D is 2573 decimal) which means Windows is reading 2 bytes rather than one
Re: OpenMW 0.29.0
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:
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);
}
Re: OpenMW 0.29.0
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.
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.
Re: OpenMW 0.29.0
Edit: right, damn localisations. Nevermind then.
Last edited by scrawl on 21 Feb 2014, 12:50, edited 1 time in total.
Re: OpenMW 0.29.0
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:
instead of
around line 188 of statemanagerimp.cpp:
Code: Select all
std::ofstream stream (slot->mPath.string().c_str(),std::ios::binary);
Code: Select all
std::ofstream stream (slot->mPath.string().c_str();
Re: OpenMW 0.29.0
Found something: In esmwriter.hpp:
And then in esmwriter.cpp, ESMWriter::endRecord:
The size of size_t is usually not equal the size of an int on the 64 bit system.
Code: Select all
struct RecordData
{
std::string name;
std::streampos position;
size_t size;
};
Code: Select all
write (reinterpret_cast<const char*> (&rec.size), sizeof(int));
Re: OpenMW 0.29.0
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.
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.
Re: OpenMW 0.29.0
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 wrote:Found something: In esmwriter.hpp:
And then in esmwriter.cpp, ESMWriter::endRecord:Code: Select all
struct RecordData { std::string name; std::streampos position; size_t size; };
The size of size_t is usually not equal the size of an int on the 64 bit system.Code: Select all
write (reinterpret_cast<const char*> (&rec.size), sizeof(int));