openmw.org

1. Rename components/esm/load*.[hpp|cpp] into components/esm/classname.[hpp|cpp] (it's not mentioned in coding policies, but when I add store() method then file name become misleading)
2. Rename esm_reader* to esmreader* (according to Naming conventions)
3. Write esmwriter class (based on esm_reader)
4. For each load*.[hpp|cpp] write a store() method
5. Prepare a tests (maybe we could use CppUnit or Google C++ testing framework?)

Zini wrote:Okay on #1, #2 and #4.

#3 looks like overkill, since we don't write esms from the data structures we have in components. We need to write in two cases:

1. Save game (dynamically generated records only): This will probably use a new file format; maybe similar to esm/p. But we haven't designed it yet and we won't write the data from the default record store anyway.

2. Save esm/p from the editor: The editor will use a different kind of data storage (components/esm yes, components/esm_store no).

We may need something like an esmwriter for the testing part, but I suspect that we can get away with writing out each record immediately after we have read it in.

Zini wrote: About #5: I am considering revamping the esm tool: Clean up the command line interface and add commands similar in style to git. The current function could be handled by a "dump" command. And the testing by a "test" command, which would read in an esm, write it to a separate location (on disc or in memeory), read it in again and compare this with what was read originally.
This approach might be more useful in the long run. But if you are more comfortable with using a testing framework, that would be okay too.

Zini wrote: P.S.: I think Corristo has some code for handling some terrain-related record types that are not available in master yet. Maybe you should pull them in (cherry pick?) .

Zini wrote:
P.P.S.: Also, I think jhooks has a fix for one animation related record in his branch. Cherry pick too?

esmtool: /home/marc/OpenMW/openmw/components/to_utf8/to_utf8.cpp:152: std::string ToUTF8::getUtf8(ToUTF8::FromType): Assertion `0' failed.

Zini wrote:@lgro: Since you were planning to revamp the esmtool anyway, could you have a look at this bug I found:

esmtool: /home/marc/OpenMW/openmw/components/to_utf8/to_utf8.cpp:152: std::string ToUTF8::getUtf8(ToUTF8::FromType): Assertion `0' failed.

Happens when running the esmtool with a non-English Morrowind.esm. I assume the encoding fixes in OpenMW broke something in the tool (probably just requires an option to specify encoding or something like that).

Zini wrote:@lgro: Since you were planning to revamp the esmtool anyway, could you have a look at this bug I found:

esmtool: /home/marc/OpenMW/openmw/components/to_utf8/to_utf8.cpp:152: std::string ToUTF8::getUtf8(ToUTF8::FromType): Assertion `0' failed.

Happens when running the esmtool with a non-English Morrowind.esm. I assume the encoding fixes in OpenMW broke something in the tool (probably just requires an option to specify encoding or something like that).

components/esm/esm_reader.hpp: In member function ‘float ESM::ESMReader::getFVer()’:
components/esm/esm_reader.hpp:156:58: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

float getFVer() { return *((float*)&mCtx.header.version); }

enum Version
  {
    VER_12 = 0x3f99999a,
    VER_13 = 0x3fa66666
  };

float getFVer() {  if(mCtx.header.version == VER_12) return 1.2; else return 1.3;  }