openmw.org

Original Thread

I am actually not sure where exactly we are standing right now. Last time the discussion kinda fizzled out. But since the launcher is out of the way, we definitely should get started.

What I remember:
-UI a mess (Agree)
-Data loading
-Needs Workflow design (Agree++)

Other than that - the thing is really up to whoever wants to make a QT application - agree on a framework - agree on what it should have going forward. We add those things to the QT app. Just fill it all in. That's pretty much the plan with me. I'm going to try to reproduce my Editor in Qt - it might sa well serve as guidance for the OpenMW one.

Basic menus and forms - then provide access to them. Code functions for helping and loading certain kinds of content. However you want to organize it. Just find all the tasks - organize them by Tier or dependency, and we'll pick em ass we do em.

I don't think I'll be able to take a very active role at this point seeing as I've just started Uni. I might be able to do some smaller work at the moment, I'll see about doing more once I've gotten myself an apartment.

Just a little clarification. The editor effort is mostly meant for people who are not comfortable with working on something as complex as OpenMW but have enough GUI skills to work on the editor. Our main focus is still on OpenMW (the big 1.0.0) and we should avoid diverting manpower to the editor that would be otherwise available for OpenMW.

I just started with school again so I will have less spare time to spend on OpenMW. I will however continue desigining the editor. I have some plans already, just need to write them down. I think we need a proper design proposal before we start coding, as the editor is a bit more complex than the launcher.

Also, in terms of GUI I won't have any problems. But my C++ skills are lacking in other fields so help is appreciated. For instance, I currently have no idea how the resource loading works in OpenMW. It would be great if someone could tell me how these things work.

We have a pretty good documentation about the data structures on the wiki: http://openmw.org/wiki/index.php?title= ... orld_Model. I suggest you read these pages carefully, especially those about the Terminology, the Record Store and the Cells. The linked API documentation is also important (look for a function called load).

You can reuse the components/esm part. What you can not reuse are components/esm_store and additional structures defined in apps/openmw. These are/will be optimised for playing the game, not for editing the world.

Here is a list of differences you should pay attention to:

* OpenMW stores the mutable cell data (the reference lists) separate from the cell record. This is most likely not a useful approach for the editor.

* Each reference is represented by an ESMS::CellRefList<X, D> instance (http://zinnschlag.github.com/openmw/str ... fList.html). These consist of three parts: base, ref, mData. Base is a pointer to the record defining the references ID. You need this one too in the editor. ref are additional reference data. These you need definitely. mData are runtime-data. These you don't need. Maybe you need other additional data for the editor. These could go there instead.

* OpenMW usess the CellStore class (http://zinnschlag.github.com/openmw/cla ... Store.html) to store the references for one cell. This class is not suitable for the editor. As discussed above you probably want to store the reference list in the same place as the cell record. But class has still some interesting code for loading the reference lists. Even if you can't use it directly, you could have a look at it to see what needs to be done.

* You will need additional data per record, that represent the ESM/ESP structure. The best solution probably would be composition (make a new class/struct or even better a template) that contains the record struct as a member)

* Remember you need two record stores. One for the ESM/ESPs that are not edited (the base) and one for the ESP that is edited.

What do you think we should do for storing a list of change for both undo/redo and for saving to esp?

What do you think we should do for storing a list of change for both undo/redo

Depends. Apparently Qt has some support for undo/redo. I don't know what exactly is offered, so I can't give much advice here. When writing editor type applications with Gtkmm or another toolkit I usually apply the command pattern for undo/redo and as an abstraction layer between frontend and backend.

for saving to esp?

I am not entirely sure if I understand what you mean here. But if I read you correctly, the answer is using two record storages. There is a whole thread about it in the old forum/archive. Basically you merge all the base ESMs and ESPs into one record storage, while the ESP you are working on is written into a second storage.


Found the thread: http://openmw.org/forum/viewtopic.php?f=14&t=139

So - just to clear this up for me, are we making a Qt Application for this? If so - I could spend time just making the forms, menus, and prototype/helpers while we continue to iron out details.

I have a giant isocohedron with duals to make, though. I need to buy a ream of paper...

Yeah it's going to be a Qt application, but there's no need to make GUI stuff just yet. We need to decide on what the application is going to look like and how it's going to behave. Mockups would be a good idea.