Page 1 of 1

Looking for a place to start

Posted: 13 Aug 2011, 17:56
by lgromanowski
Star-Demon wrote: I'm looking at files here and there, and making notes on what I think might be missing and wondering what needs to be done. Unfortunately I'm still kinda studying everything...but I did notice a few things and have some questions:

For example:

Each weapon has a lot of its own properties. Ignores weapon resistance, is a silver weapon ,and so on, Immediately, I would imagine these things would be defined in either weapon file, but they don't have any of these instance variables - only methods for it interacting with the world.

Is it like this for other mwclass objects? Where are these variables? Is this an opportunity for me? Go through the mwclass objects and make them have the properties each one of them would have?
Zini wrote:
Each weapon has a lot of its own properties. Ignores weapon resistance, is a silver weapon ,and so on, Immediately, I would imagine these things would be defined in either weapon file
Nope. These are defined in loadench.hpp, which in turn references to loadmgef.hpp.
Is it like this for other mwclass objects? Where are these variables? Is this an opportunity for me? Go through the mwclass objects and make them have the properties each one of them would have?
Nope. MWWorld::Class and derived classes are state-less.


If you want a suggestion, most beneficial for the project would be work on the GUI. This requires reading up on MyGUI and the stuff in apps/openmw/mwgui/ and extern/mygui_3.0.1/openmw_resources/.
We definitely need the dialogue window and the character creation windows.
Star-Demon wrote: Huh. How about that? it's all over there in components/esm
So where does that come from? A weapon object's properties are set up and defined over in esm, and then at some point the application either assigns those values or reads them....huh...

Wait, weapon is defined as a type in esm/components, and in our application a weapon is a MWWorld that has some getters, that requires a pointer toward some place in memory....so at what point does this piece of data in an esm becomes the thing in the world you can pick up and swing and use? How does the application access the esm's data and gets it into the game without reading all the data?

Its missing ignores resistance flag...the enums are...well, I suppose I don't use them enough to know why it's done like that other than saving numbers. I'm a noob.

Yeah, I was thinking about playing with the gui, too. I'll have to get on looking at all that, thanks.
Zini wrote: An esm file consists of a list of records of various types (weapon, armor, cell, sound, ...). Most of them have a unique name (a few types are identified by an index value).
When an esm is loaded all records are stored in an ESMStore object (components/esm_store/store.hpp).
Among these types is the type CELL. Each cell consists of a few parameters and a list of references. A reference consists of the name of a record and some more data. These are the "objects" you have in the game world.
Now when a cell is loaded, each reference is rendered to an Ogre scene.

The purpose of the whole MWWorld::Class business is to impose polymorphic behaviour onto the ESM records, which are implemented as a collection of unrelated dumb structs. This is basically a hack that compensates a design-flaw in the very early stage of OpenMW.
Star-Demon wrote: Is every window or message in the game going to be defined in mw_layouts, or is that for the purpose of just the player's gui? or for gui elements that require input handling all the time?

As long as I knew what went into each, I could do:
Message (covered by script already DId i see a message in a screenshot at one point?)
All of CharGen's window and choices

I could even finish the book and journal one, but I'm going to have to bone up on my XML, since it's been a few years since I touched it. I never got to use it for gui work, but yay! we use xml!
Zini wrote:
Is every window or message in the game going to be defined in mw_layouts, or is that for the purpose of just the player's gui? or for gui elements that require input handling all the time?
I think it would make sense to split up the window collection into several files. It might even make sense to split up mw_layouts.hpp into files for individual windows; maybe even splitted into hpp/cpp.
Message (covered by script already DId i see a message in a screenshot at one point?)
MessageBox texts are printed to std::cout currently. IMHO the message box GUI implementation is not so urgent. We can get by with the current method for a while. But I have no objections if you want to do it. IIRC the message box variant with buttons is not implemented yet on the script side, but it wouldn't take me long to fix it up.
Star-Demon wrote: Okay - thanks for the ESM bit - a part of why I ask so many questions is to understand it (this is the first real project I've done, I'm already learning way more than school likes to teach me at my level) and another part is that I can convert these explanations to the guide. It's all part of my eeeeevil plan.


okay, so, I guess I should just make a file for each class?
That I can can do. We can always merge them later. :)
I'll start broadly and work down to specifics.
Zini wrote: Okay. We are probably going to start merging in your work after the next release. You can start pushing it to your fork on github whenever you feel ready to share.
Star-Demon wrote:
Zini wrote:Okay. We are probably going to start merging in your work after the next release. You can start pushing it to your fork on github whenever you feel ready to share.
hehe - I have to make sure how to create a window, button, etc, place the button where I want, and so on. If I want to make XML for everything or just want to code it as is and then add in the xml and read that later.

I gues a good question to ask is if the smaller elements that make up the hud, like this one:

class StatsWindow : public OEngine::GUI::Layout

Every gui window is one of those? or should I find a reference and get reading?
Zini wrote: From what I see every Window is implemented as a class derived from OEngine::GUI::Layout. And the non-Window part of the HUD is another such class. Nico can probably answer these questions better. I am not very familiar with the Open Engine stuff and the MyGUI integration.
Star-Demon wrote:
Zini wrote:From what I see every Window is implemented as a class derived from OEngine::GUI::Layout. And the non-Window part of the HUD is another such class. Nico can probably answer these questions better. I am not very familiar with the Open Engine stuff and the MyGUI integration.
No problem. Here's an example I'm working on just to start myself out,m I'll check it with you guys, and if it looks like it works I'll start on the others.

Without knowing much about it:

Code: Select all

#ifndef CHARGENMETHODCHOOSE_H_
#define CHARGENMETHODCHOOSE_H_

//"There are a few ways we can do this and the choice is yours." 

namespace MWGui {
class CharGenMethodChoose : public OEngine::GUI::Layout {
public:
   CharGenMethodChoose() : Layout("openmw_hud_layout.xml") {

      //I like 1280x1024, but this does need to be relative to screen res
      setCoord(640,512, width, height); //oops...what's the second pair? 
      //Make buttons
                    //Button1

   }
   }
   virtual ~CharGenMethodChoose();
};
#endif /* CHARGENMETHODCHOOSE_H_ */
Zini wrote: setCoord: xpos, ypos, width, height
Star-Demon wrote:
Zini wrote:setCoord: xpos, ypos, width, height
Well, I get that, but it's width and height that I'm confused about. a position on a 2d plane is only two coordinates, in C# and XNA it's a Vector2, in SDL they...hmmm...yeah, that looks more like a SDL rect.

You know what? maybe I should eat something! haha!
Zini wrote: Read the code? in mw_layouts there are several examples and you can see the result when you run OpenMW (press I to open the GUI). From that you should be able to determine how the function works.
Zini wrote: I added the missing implementation for the message box buttons (just in case you want to give the message box implementation a shot at some point).

You might want to add my fork as a remote:
git remote add zini [url=git://github.com/zinnschlag/openmw.git]git://github.com/zinnschlag/openmw.git[/url]
The changes are in the script branch. If you want to merge them into your own code base, use the following lines:
git fetch zini
git merge zini/script
Star-Demon wrote: Cool, thanks - I never tried to see if right clicking the functions or hovering would reveal everything about the function in VS, since there's no project, and I was under an assumption that everything inside the HUD constructor was only for the menu after right clicking, which stops the game (but not game time, if you notice...or was that another game?) and reveals it - all of this making it a special case. If it all works the same, then that makes this a lot easier.

I should install OpenMW windows, as well. Maybe later.

So, I can't really step in and out of everything because there's no actual project, and Eclipse, which I would prefer at this point, doesn't have very good tools for C++ on the order of VS's...it doesn't understand C++ very well.

Sometime I've just been using notepad.

Should I just create a VS2010 project to make this easier? What harm or good would it do to include that? Since projects use paths well enough, I would imagine that once a project is set up it can be used by anyone as long as the files are the same, as long as the files are in the same place, right?

Can you see how I've thrown myself into the deep end on this? hahaha! I'll swim, dammit!
Zini wrote: Huh? I have absolutely no idea, what you are talking about. If you went through the cmake steps correctly you should have a project for whatever IDE you specified.
Star-Demon wrote:
Zini wrote:Huh? I have absolutely no idea, what you are talking about. If you went through the cmake steps correctly you should have a project for whatever IDE you specified.
Making with Cmake is a work in progress - ummm - see the SSh public key thread.

EDIT: Scratch that, I'll make a new thread since I made some progress.