Inventory GUI

Everything about development and the OpenMW source code.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1143
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Github profile: https://github.com/lgromanowski
Contact:

Inventory GUI

Post by lgromanowski » 15 Aug 2011, 10:02

akebono wrote: I've started some drag-n-drop and placement of icons, but stuck with item's pointer to retrieve anything about like type, icon (sorry, me very poor at c++ and english). And i've a warning in gcc about horizontal scroll bar eventScrollChangePosition while prototyping like (MyGUI::WidgetPtr, size_t), or bunch of errors if (MyGUI::HScrollPtr, size_t)
Zini wrote: I pushed a new branch (inventory) to github. Please use it as a basis for your work.

You will find a new function (getInventoryIcon), that will allow you to get an item's icon via a MWWorld::Ptr. I suggest you store these pointers in your layout data structure.
Greendogo wrote: Zini: What's the story on the inventory tabs? Will my idea for custom inventory tabs in a post-1.0.0 release be doable?
Zini wrote: Technically, I don't see a problem. From a design perspective, I don't know. I haven't followed the discussion about inventory improvements too closely, but I got the feeling that its too focussed on the original design.
What I would like to do post 1.0 is to take a step back and build a new inventory GUI from scratch. The outcome may not even look remotely like what we have now. If any of the currently proposed ideas will make sense, would obviously depend on with what we end with. I can't say yet, how well your ideas would fit into it.
jhooks1 wrote: Just did a checkout of the inventory branch. Akebono, how do you want to split this up?

EDIT: I think the first thing we should do is make a basic screen that pops up when the "i" key is pressed. The window should contain a few basic icons and should be resizable.
Zini wrote: There was a partial implementation of the inventory window. I don't know how complete and how buggy it was, but the code should be still there (commented out). Maybe you should take a look at it first.
akebono wrote: yes, i take the commented implementation from layouts.cpp and done some stuff in separate file. almost done picking and placing widgets. still most of the time fighting with ++'s (and git).
akebono wrote: at last i somehow push it somewhere in akebono/openmw on github. those test workaround cause i still cant figure out how to use getInventoryIcon, and have no thoughts how (and where, actiontake in world i think?) to place those additem
Zini wrote: I see your branch. Don't have the time to review it right now, but I noticed a few things:

- You are using your master branch for the feature. But you should make a separate feature branch, as you would know from the wiki, if the wiki were not down right now. *sigh* I guess we can leave it in master for now, but for future tasks, please make a feature branch.

- You are using the preprocessor for constants (ICON_SIZE). Don't! That is a C-ism. In C++ you should avoid to use the preprocessor, except for includes, include-guards, conditional compiling and a few special situations.

Regarding your questions:
i still cant figure out how to use getInventoryIcon
MWWorld::Class::get (ptr).getInventoryIcon (ptr)
and have no thoughts how (and where, actiontake in world i think?) to place those additem
The inventory GUI is responsible for reading out the content of the container and keeping track of changes. You can get the container of an object via the class interface (getContainerStore).

That brings us to an interesting question though. Can the container GUI keep track of changes to the container? Sounds a bit inefficient. I guess we could add two more functions to the window manager, that get called when a script is changing the content of a container (only scripts can affect a container's content while a GUI is up); one for adding and one for removing.

Edit: I probably should also mention how to get a ptr to the player reference. The MWWorld class has a getPlayer function, which returns a Player instance, which in turn has a getPlayer function, which returns the ptr (yes, I know that the function names are slightly suboptimal in some places).
Star-Demon wrote: So - just to make sure I'm following right - we've generalized this where we can get the inventory of a container, NPC, or the pc in one function?
Zini wrote:
in one function?
I guess you mean one class instead of one function.

No, that does not sound right. I see the current implementation more as a draft. Once we got it working to some degree, a container GUI class needs to be factored out, that will serve as a base for both the inventory GUI and other container's GUI.
Star-Demon wrote:
Zini wrote:
in one function?
I guess you mean one class instead of one function.

No, that does not sound right. I see the current implementation more as a draft. Once we got it working to some degree, a container GUI class needs to be factored out, that will serve as a base for both the inventory GUI and other container's GUI.
Well, I implied the class it's a member of - I didn't know we would be factoring out a new class later and thought that was going to be our means of doing these sorts of things. :|
akebono wrote: still have troubles with ContainerStore, things store there in some LiveCellRef stuff or something with similar name. Jhooks i'll fight bloody ages with this kind of stuffs, if you have an idea how do it i'll keep doing the gui stuff (like piling up similar items, popup on them, tooltip etc) and you if wish do the hardcoding interfacing with that ContainerStore?
Zini wrote: This is hardly black art. Just look it up in the API documentation: http://zinnschlag.github.com/openmw/index.html
Zini wrote: But actually, if you got the the LiveCellRef, you are already done. The Ptr class has a constructor, that takes a pointer to a LiveCellRef (and a pointer to CellStore, but you can set that one to 0, because an object in a container isn't directly part of any cell).
Zini wrote: Finally managed to examine your code a bit closer.

I think you need to do some clean up first:

At least comment out everything related to equipping items. This feature is not implemented and when it gets implemented I will probably be incompatible with what is currently in the inventory GUI class.

We also need to get the data structures sorted out. I see

Code: Select all

std::vector<MWWorld::Ptr> mItems;
std::multimap<MyGUI::WidgetPtr, MWWorld::Ptr> mWItems;
I don't think we need them both. Also a multimap doesn't make sense here. A regular map should do the job just fine.

The container code needs to handle the following cases:
1. Container GUI is opened/category is changed
2. An item is added or removed via script
3. An item is added or removed via a inventory user-interaction.

I suggest we start with 1.
Opening the GUI and changing category is almost the same (the later has also to clean up first). You can simply go through the appropriate ContainerStore members, iterate over them to generate Ptr instances and fill your mWItems accordingly. btw. what does the W in mWItems mean?
akebono wrote: some dirty push. about multimap i thought about similar items that should be stacked and so would be pointed with the same widget, maybe im wrong. and yes std::vector<MWWorld::Ptr> mItems; is redundant, W in mWItems was for Widget. still having bloody fight with constucting MWWorld::Ptr from ESMS::LiveCellRef<T, MWWorld::RefData>.
Zini wrote: Huh?

You have a ref object r.

Then you construct the Ptr as this:

MWWorld::Ptr ptr (&r, 0);

Doesn't get any more simple.
Zini wrote: Regarding item stacking: Not fully implemented yet. Assume that items can stack for now, but when you add items to a container (as a result of a drag & drop operation) ignore stacking and simply append it as a new item. We first need to work out an algorithm to determine what can stack and what not (which is not trivial). But that is a separate issue and can be addressed another time.
You can get the number of stacked items via RefData::getCount().
Zini wrote: Seen your most recent commit.

- Don't hand around the ContainerStore per value (that makes a copy each time). Use a reference.

- Don't create Ptr objects via new.

- Switch mWItems back to Ptr and make it a map instead of a multimap.
Zini wrote: @akebono: If you are still interested in working on this task, you should register on our issue tracker so I can assign it to you.
akebono wrote: icon with name returned by ...->base->icon (iconstring.tga for short) seems like inexist at least in mine Data Files' files, but there is icon with name icons/iconstring.dds. And of course million of tough for me things made as workarounds in recent.
Zini wrote:
icon with name returned by ...->base->icon (iconstring.tga for short) seems like inexist at least in mine Data Files' files, but there is icon with name icons/iconstring.dds
I guess that makes sense. When all icons are in the icons directory, it would be wasteful to specify the icon-part for each ID.
And of course million of tough for me things made as workarounds in recent.
Sorry, can't parse this sentence.
best regards,
Lukasz

Locked

Who is online

Users browsing this forum: No registered users and 2 guests