Jump to content


Photo

Inventory Grid


  • Please log in to reply
83 replies to this topic

#51 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 04 February 2016 - 04:43 PM

Very cool,and am I understanding correctly that you have fixed the objectives scrolling issue?

Yep, that minibug got fixed in the same commit.

#52 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 04 February 2016 - 05:23 PM

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, 04 February 2016 - 07:03 PM.

  • Anderson, SteveL and Spooks like this

#53 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 36631 posts

Posted 04 February 2016 - 08:05 PM

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?



#54 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 04 February 2016 - 08:17 PM



 

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


  • Anderson likes this

#55 Taquito

Taquito

    Member

  • Member
  • PipPip
  • 257 posts

Posted 05 February 2016 - 01:50 PM

Thank you for this Durandall.



#56 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 07 February 2016 - 08:54 PM

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?


  • AluminumHaste, Anderson, Deadlove and 1 other like this

#57 Outlooker

Outlooker

    Member

  • Member
  • PipPip
  • 155 posts

Posted 07 February 2016 - 09:21 PM

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

#58 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 07 February 2016 - 09:39 PM

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.



#59 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 36631 posts

Posted 07 February 2016 - 11:40 PM

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.



#60 demagogue

demagogue

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 5254 posts

Posted 08 February 2016 - 01:41 AM

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. 


Posted Image

#61 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 08 February 2016 - 03:01 AM

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 :)
  • AluminumHaste and VanishedOne like this

#62 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5948 posts

Posted 08 February 2016 - 08:08 AM

That looks great.


I always assumed I'd taste like boot leather.

 

#63 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 09 February 2016 - 05:30 PM

I've applied my changes against r6575, but am unable to test them without the matching data files.



#64 Outlooker

Outlooker

    Member

  • Member
  • PipPip
  • 155 posts

Posted 11 February 2016 - 12:57 PM

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

#65 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 11 February 2016 - 06:13 PM

I've added variables to support excluding and ordering categories.



#66 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 11 February 2016 - 07:27 PM

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.


  • Springheel likes this

#67 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 11 February 2016 - 07:32 PM

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.



#68 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 11 February 2016 - 07:40 PM

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?



#69 VanishedOne

VanishedOne

    Advanced Member

  • Member
  • PipPipPip
  • 819 posts

Posted 11 February 2016 - 08:27 PM

Making people relearn (or restore) their bindings might well cause annoyance.


Some things I'm repeatedly thinking about...

- louder scream when you're dying


#70 demagogue

demagogue

    Mod hero

  • Active Developer
  • PipPipPipPipPip
  • 5254 posts

Posted 11 February 2016 - 09:17 PM

My vote is binding 'i' for this is the obvious choice and worth overtaking its old purpose. 


  • Goldwell likes this
Posted Image

#71 Durandall

Durandall

    Member

  • Member
  • PipPip
  • 74 posts

Posted 11 February 2016 - 11:09 PM

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

No new features, although the speed gains can support 25/36 entry grids.

Untested as I don't have the 2.04 data files, but worked when backported to 2.03.

TDM204_r6575_refinements.7z



#72 AluminumHaste

AluminumHaste

    Darkmod Contributor

  • Development Role
  • PipPipPipPipPip
  • 5948 posts

Posted 12 February 2016 - 07:03 AM

I vote to keep it unbound. Anyone who reads release notes, or watches the YouTube videos I usually put out, or reads the forums, will know about this.
That way you don't step on anyone's toes.

I always assumed I'd taste like boot leather.

 

#73 Deadlove

Deadlove

    Advanced Member

  • Member
  • PipPipPip
  • 978 posts

Posted 12 February 2016 - 07:32 AM

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


Plastik Musik - Andrew Nathan Kite, Owner

plastikmusik33@gmail.com

http://www.facebook.com/plastikmusik /

http://www.youtube.com/plastikmusik

http://www.plastikmusik.bandcamp.com

 

 


#74 SteveL

SteveL

    Hero Coder

  • Active Developer
  • PipPipPipPip
  • 3669 posts

Posted 12 February 2016 - 09:48 AM

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.

#75 Goldwell

Goldwell

    Team Member

  • Active Developer
  • PipPipPipPip
  • 2209 posts

Posted 12 February 2016 - 12:05 PM

 
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?


The Accountant Series
Part 1: Thieves and Heirs | Part 2: New In town


Lord Edgar Series
Lord Edgar's Bathhouse
 
Stand Alone Missions
Spring Cleaning





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users