Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
-
cc9cii
- Posts: 523
- Joined: 28 Mar 2013, 04:01
Post
by cc9cii » 21 Feb 2014, 12:15
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
- Posts: 5538
- Joined: 06 Aug 2011, 15:16
Post
by Zini » 21 Feb 2014, 12:25
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
- Posts: 523
- Joined: 28 Mar 2013, 04:01
Post
by cc9cii » 21 Feb 2014, 12:35
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
- Posts: 5538
- Joined: 06 Aug 2011, 15:16
Post
by Zini » 21 Feb 2014, 12:48
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
- Posts: 2152
- Joined: 18 Feb 2012, 11:51
Post
by scrawl » 21 Feb 2014, 12:49
Edit: right, damn localisations. Nevermind then.
Last edited by
scrawl on 21 Feb 2014, 12:50, edited 1 time in total.
-
gus
- Posts: 390
- Joined: 11 Aug 2011, 15:41
Post
by gus » 21 Feb 2014, 12:49
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
- Posts: 5538
- Joined: 06 Aug 2011, 15:16
Post
by Zini » 21 Feb 2014, 12:53
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
- Posts: 523
- Joined: 28 Mar 2013, 04:01
Post
by cc9cii » 21 Feb 2014, 12:57
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
- Posts: 523
- Joined: 28 Mar 2013, 04:01
Post
by cc9cii » 21 Feb 2014, 13:00
Zini wrote: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
- Posts: 5538
- Joined: 06 Aug 2011, 15:16
Post
by Zini » 21 Feb 2014, 13:04
Edit: Wrote nonsense.