Jump to content
The Dark Mod Forums

Inventory Grid


Durandall

Recommended Posts

Initial tests on smaller items (64x64) in a 6x6 grid (total 36) have unfortunate results.

The gui file almost doubles in size (not really a surprise) and the engine noticeably pauses on GUI updates.

I think we may be at our limits on the total number of grid items.

 

At this point I'm content to call the current system done.

If anyone has any graphical components (backgrounds or corner flourishes) they want worked in, we can look at it and vote.

If anyone has a gui they made themselves, we can look at it and vote.

If I see enough votes for centering the current grid components, I'll do it.

 

Thanks everyone for all the support.

I was very happy to see all the positivity.

I'm glad this system made it in for everyone to enjoy. :)

Edited by Durandall
  • Like 3
Link to comment
Share on other sites

The gui file almost doubles in size (not really a surprise) and the engine noticeably pauses on GUI updates.

 

 

I don't understand how that would make such a difference. Most .gui files are less than 50kb, and even the extra images would only boost things by a couple mb at most. How could that cause noticeable pauses?

Link to comment
Share on other sites

 

I don't understand how that would make such a difference. Most .gui files are less than 50kb, and even the extra images would only boost things by a couple mb at most. How could that cause noticeable pauses?

 

Honestly, I wouldn't know. Any explanation I could give would only be a guess.

Parsing the gui file itself? The sheer number of elements to process?

I'm not sure the dark mod has a gui file with so much in it.

I'm also unaware of any built-in means of avoiding code duplication in a gui.

 

You can try out a test version here to see for yourself.

invgrid_36_test.7z

  • Like 1
Link to comment
Share on other sites

I've done some poor man's profiling using some STL chrono time points and have found the bottleneck is the number of elements.

The communication layer between GUI and SDK is slow. Not really surprising, it's all strings and conversions.

I've offloaded the grid clear functionality onto the GUI itself. I was originally going to try this, but I wasn't sure how at the time.

I've also trimmed some vars, as every call to set or get a variable from the GUI is slow and everything trimmed gives a speedup.

These changes really speed things up. A 6x6 grid now runs at acceptable speed. (Atleast on my machine)

 

What's the level of interest in a larger grid?

dSkkkZg.png

Are these entries to small? What about a 5x5 with 25 elements?

  • Like 4
Link to comment
Share on other sites

It seems in any bigger than small missions the number of inventory items becomes overwhelming in a grid that shows everything at once.

How about grouping items in categories?

For example, the first thing when your inventory is activated is a list or button (or also a grid) of the category:

Keys/potions/weapons(mines)/books/scrolls/tools or something like that.

In bigger missions with lots of readables even those could get a subgroup (diaries, recipes, ...); maybe even keys (if in a specific mission are really many of them),

for example (keys:/cathedral/city watch/manor 1/manor 2).

In the end, I think a design goal should be to provide the quickest and most direct/easy way to select things from the inventory grid - if there is no grouping,

finding a specific item in larger inventories would often take an unnecessary long time.

"Good people do not need laws to tell them to act responsibly while bad people will find a way around the laws." - Plato

"When outmatched... cheat."— Batman

Link to comment
Share on other sites

It seems in any bigger than small missions the number of inventory items becomes overwhelming in a grid that shows everything at once.

How about grouping items in categories?

For example, the first thing when your inventory is activated is a list or button (or also a grid) of the category:

Keys/potions/weapons(mines)/books/scrolls/tools or something like that.

In bigger missions with lots of readables even those could get a subgroup (diaries, recipes, ...); maybe even keys (if in a specific mission are really many of them),

for example (keys:/cathedral/city watch/manor 1/manor 2).

In the end, I think a design goal should be to provide the quickest and most direct/easy way to select things from the inventory grid - if there is no grouping,

finding a specific item in larger inventories would often take an unnecessary long time.

 

It's an interesting idea that has brought up before in this thread.

Spooks posted a mock-up of what you are suggesting.

 

For me, the items I want to find are plainly visible on the current grid.

If you need a key, you need only a glance to find them. The same is true of readables.

A health potion or holy water is easily spotted.

The above image is filled with 36 items. I would think most missions do not exceed this.

I'm worried that introducing clickable categories will only slow the process down.

It would just take longer to get to an item that would normally take a single click.

 

If we get enough votes for it, I have no problem whipping up new code and a new gui for it.

I just want to make sure that it's what most people want and the dev team agrees with it.

 

I'm also afraid it would delay the release of 2.04.

We may want to sit on the current system for the time and gather votes.

Link to comment
Share on other sites

I like the idea of a 6x6, but would be happy with a 5x5 if people with smaller screens found the latter too small.

 

What's the average number of items per mission? Another possible issue is that the 6x6 grid could more often than not be half empty.

Link to comment
Share on other sites

Would it be worth having the grid scale up in number as the inventory items increase? I recall a script function that gets number of inventory items. So when you have a few items (0-16) it starts with 4x4, when you get the 17th item it scales up to 5x5, then when you get the 26th item it scales up to 6x6 at the maximum. (Theoretically you could count potential inventory items and scale it at game-start, but it may not be accurate, so I think scaling dynamically by actual inventory count would be the way to do it.)

 

One the one hand, it keeps things as big as they can be, and skirts around the issue Spring just mentioned (for FMs with a small number of items, the grid stays large sized. It only gets smaller sized for the FMs that need it.) On the other hand, people may remember where things are, and then they get moved and that's a second of annoyance maybe, but it's not the worst because they can find the new places quickly enough. It may be more of an aesthetic issue (a major gui system changing so much over the course of a game) than a practical one.

 

I'm just mentioning it for discussion's sake. It makes sense, but don't have a strong opinion for or against it.

 

Edit: My laptop has a 12" screen, which is pretty small, and the 6x6 is good enough to be functional without frustration.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

I like the "current" system and don't think a bigger grid is needed. It feels perfectly natural to use the mousewheel in the test map, and it won't often be needed in real maps. I'll help deploy any changes though if you guys decide in favour of tweaking it.

 

I'm looking forward to being able to cope with lots of readables :) I usually end up leaving a pile of them somewhere inappropriate in whatever mansion I'm robbing, which offends my sense of ghosting. Although they'll usually confuse the people who're investigating my crime :)

  • Like 2
Link to comment
Share on other sites

I thought about the categories idea - in TDM, there are actually not that many categories possible.

You have tools (lockpicks, compass, spying glass, lamp), weapons (IIRC only mines), potions, keys and readables as

inventory items.

Only keys and readables can become numerous enough to cause confusion in the inventory grid.

Therefore, I suggest something like this:

Tools and weapons, if present, are sorted so that they are always and reliably in the beginning (1st line or so) of the inventory grid - in

the same ordered position, so that they are consistently and quickly accessible: When you got them in the inventory, these items

are always there in the same spot and accessible at the first glance, then potions, then keys are sorted in, and after keys all readables.

With a system like that, all more "tactically" necessary items are always in the same position and can be accessed very quick, while readables

are always at the end, forming a "tail" that causes no real hindrance if it takes a bit longer to search through, because reading them takes a lot

of time anyway.

"Good people do not need laws to tell them to act responsibly while bad people will find a way around the laws." - Plato

"When outmatched... cheat."— Batman

Link to comment
Share on other sites

Should we be adding options? IMO the simple version that we already implemented is the right solution. It just works, perfectly, without the player having to do any research. Touching the scrollwheel is not a inconvenience.

 

I'm just slapping some code together.

We don't have to use it. No big deal.

Link to comment
Share on other sites

Your original version seems finished to me, but it's just my opinion, I'll defer to any consensus. We should discuss how to deploy it in 2.04 though. What do people think of rebinding the default action of the 'i' key from cycling through readables to showing the inventory grid?

Link to comment
Share on other sites

Here's a small diff and new gui that contain the refinements for speed.

Cool, thanks. I'll merge it when I get back to the UK on Sunday.

 

Can this just be added to the keyboard control settings menu so any user can bind it to whatever key they desire?

I expect so. I favoured 'i' because that's what every other game does, but if people will have rebound it then we should probably leave it alone.

Link to comment
Share on other sites

 

Cool, thanks. I'll merge it when I get back to the UK on Sunday.

 

 

I expect so. I favoured 'i' because that's what every other game does, but if people will have rebound it then we should probably leave it alone.

 

I think mapping it to "i" by default makes sense as well, will this also have an option in the binding menu?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...