openmw.org

The latest build (I have 29a33364cc + minor local changes to compile) seems to work fine with ffmpeg-20140221-git-8c55ff3-win64-shared which is the latest as of today for windows env. The older ones (for me at least, on x64) crashes at the intro video more often than not. I've been using the version...

Just a question - latest commits are requiring some manual tweaks due to qt4 preceding many of the includes. Would it be ok if we drop them? e.g. diff --git a/apps/opencs/view/filter/editwidget.hpp b/apps/opencs/view/filter/editwidget.hpp index 555b6d3..e7e34b8 100644 --- a/apps/opencs/view/filter/e...

Here is the diff against 29 branch: apps/openmw/engine.cpp | 5 ++++- apps/openmw/mwstate/statemanagerimp.cpp | 2 +- components/esm/esmwriter.cpp | 2 +- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/apps/openmw/engine.cpp b/apps/openmw/engine.cpp index e80bd95..0975778 100644 --- a/ap...

I'll summarise the changes I made against 0.29 branch. Screenshot seems to work for me?




Or did you mean in-game one?

So here is a crazy thing. I go through the chargen process right up to the final door. I then hit F2 and set chargenstate to -1. Save. Go outside the door and save again. The save from inside is ok but the save from outside is not. (still none of them will load properly) I'll try the binary mode now...

gus wrote:did you try binary mode? Because it does work on my computer.

sorry, please remind me how to try binary mode

I backed out gus's suggsted change on page 9 of this thread and that particular issue doesn't happen any more. I've discovered that the savefile generated inside the prison ship (debug or release version with int changed to uint32_t) does not have "0D0A" for the size of "PLCE". H...

Release version has the same issue. But I noticed that a savefile that had only a few entries in it (because I aborted it during debugging) does not have the issue. I'm wondering now whether the file get over-written with junk later. I'll step through the save part once more. EDIT: debug save result...

Found something: In esmwriter.hpp: struct RecordData { std::string name; std::streampos position; size_t size; }; And then in esmwriter.cpp, ESMWriter::endRecord: 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...

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.