The ESM struct situation

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

The ESM struct situation

Post by lgromanowski »

Zini wrote: I am sufficiently pissed with the world model situation, that I have finally decided to do something about it. The problem with the dumb struct approach is, that ID-type specific code is spread all over the place and uniform handling of references requires very ugly workarounds.

Respecting Nico's decision to keep the world model structs non-specific (e.g. allow re-using them in an editor) I am creating a parallel class hierarchy on top of it (in apps/openmw/mwworld).
The classes will be stateless, which means that you will always have to provide a MWWorld::Ptr argument for every function call.
This change will reduce coupling between apps/openmw and the world model greatly (and probably between different apps/openmw sub-systems too). It will also provide us with the required abstraction to isolate possible future CellRef optimisations in only a few classes.

Since I suspect this will be a lengthy line of development, I moved it to a separate branch (poly). Nico, please don't pull the poly branch. I will integrate it into master once it is ready.
Zini wrote: Ape's work on activation got me by surprise. We need my work from the poly branch to finish it up. Therefore I have merged the poly branch into master and deleted poly. At this point it doesn't make sense anymore to have a separate branch.
nicolay wrote: I apologize for the terrible layout of the esm/load* files, I've grown to dislike it over time myself really. It was one of the first things I made for OpenMW, written way before there ever was any engine to speak of (before rendering and even NIF reading), and was just as much a tool for decoding the file format itself as for storing game data. The current C++ version is more or less a direct port of that old D code.

I don't personally put a very high priority on rewriting/replacing it, but if you see the need and have a good idea for how to do it, then that would of course be very welcome! I would only ask that it's done in a parallel branch or as a separate component/app or in some other way so that it doesn't break things before it's done.
Zini wrote: Changing the esm implementation would mean rewriting a large part of OpenMW from scratch. Not planning to do that, especially after I spend so much time with writing code to contain the problem. With MWWorld::Ptr, MWWorld::Class and a few other helpers the esm situation is reduced to being only slightly annoying.
nicolay wrote: Well, ok, that's good I guess :)
Locked