Go?

Involved development of the OpenMW construction set.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1140
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Github profile: https://github.com/lgromanowski
Contact:

Go?

Post by lgromanowski » 15 Aug 2011, 10:41

Zini wrote: Since the launcher is complete (for now), shall we get started with the editor?

@pvdk: Feeling up to giving it a try?

I think these tasks should be handled first (in this order):

* http://bugs.openmw.org/issues/137
* http://bugs.openmw.org/issues/142
* http://bugs.openmw.org/issues/141

The first two are GUI-less and probably the harder parts to get right.

Edit: Actually, the second one is half GUI and half backend. I guess we still need to discuss some aspects of the GUI half.
pvdk wrote: I would love to start on the Editor, however, I'm not a real programmer. I suck at math and I don't know C++ too well. The backend will be a problem for me as I imagine it will use all kinds of C++ trickery I just don't know about.

I happen to have 8 free days starting from thursday, but I won't have access to a compiler then. I could do some reading on the stuff I should know for the backend, if you provide me with a list of things/paradigms/etc. I should know about.

I will also continue working out my GUI ideas.
Zini wrote: I have added two more tasks (see 0.12.0 thread), that should serve as a preparation for Load and Save. If we can find people to handle them, the backend part of this task should be just a question of iterating over all records and calling save (the load part can be taken with little modifications from components/esm_store/store). And the rest should be pure GUI.

Based on your posting, the task Data Storage on the other hand sounds like it will turn into a problem. It is fundamental to the editor and we can't afford to divert any manpower from OpenMW for it. This is tricky business and I am not sure myself yet how to handle it.

Maybe it would be best, if you work around the backend for now, and do purely GUI tasks. But you won't get very far with it.
I could do some reading on the stuff I should know for the backend, if you provide me with a list of things/paradigms/etc. I should know about.
Can't help you with that, sorry. I haven't given much thought to how to implement the record storage. I suspect it will rely heavily on template usage, but that is just an educated guess.
pvdk wrote: There's quite a lot of GUI related stuff I could start with. For instance, the tabbed interface we discussed and making windows detachable, figuring out how to have one or more main windows separate from the core application, etc.

For the data storage we could subclass QAbstractItemModel, but I wonder: each record its own model? Or a big model with all the records in it?
Zini wrote:
For instance, the tabbed interface we discussed
Did we ended up with a tabbed interface? I honestly don't remember, what the outcome was.
making windows detachable, figuring out how to have one or more main windows separate from the core application, etc.
I think you did already some experimenting with this? Some prototyping? So the actual task would be to write these functions in a way that they can be used when the backend is ready without the need for another rewrite.
For the data storage we could subclass QAbstractItemModel, but I wonder: each record its own model? Or a big model with all the records in it?
One model for each record type sounds reasonable. But from what I see QAbstractItemModel assumes a table like data structure. Therefore it can't be used for all record types.

We also need to consider those record types, that can be referenced (in MW-terminology). We decided that these should share a single view. Is that even possible with separate models? If not, we need to build another abstraction layer around these records.
Zini wrote: Right. We agreed on a tabbed interface. Just found the thread.

Thinking about it a bit more, merging all the referencable record types into one model seems reasonable. We need to provide a proper abstraction anyway.

I guess we should start with categorizing record types:

* TES3

special case (there can only be one)

* GMST, GLOB, CLAS, FACT, RACE, SOUN, SCPT, REGN, BSGN, SPEL, ENCH

A model each, accessible via a string handle (note that all records with string handles share a single namespace)

* SKIL, MGEF

A model each, accessible via an integer handle.

* STAT, DOOR, MISC, WEAP, CONT, CREA, LIGH, NPC_, ARMO, CLOT, REPA, ACTI, APPA, LOCK, PROB, INGR, BOOK, ALCH, LEVI, LEVC,

A single model for all of them, accessible via a string handle

* CELL

Special case. Maybe we need to split them up into interior and exterior.

* DIAL, INFO

DIAL accessible via string handle (topic), but several sub-categories. Also
contains INFO records as sub-records (even though this is not represented in the structure of the ESM/P files).


I am unsure about these: LTEX, BODY, LAND, PGRD, SNDG
best regards,
Lukasz

Locked

Who is online

Users browsing this forum: No registered users and 1 guest