Option to reverse the naming order of containers and their contents


#1

This is a very specific option I would really appreciate seeing in the game: The ability to reverse the order of the container and its contents when displaying item names. For example, instead of seeing a “plastic bottle of clean water” you would see “clean water in plastic bottle”.

My main reason for this is that it make it much easier to identify things at a glance, especially when I’m looking at a long list of items like in advanced inventory management or listing visible items with V. When I’m reading down a list looking for specific things it’s much easier if I can identify each item within the first one or two words. This is the case for most items in the game, but containers of liquid and food are a very common case where this is never true.

Reversing the name order also helps any time items are listed in alphabetical order. If I’m scanning a list to see how much “clean water” I have, I’ll need to check the whole list because it could be stored in any number of container types.

This might also help localization (though I’m really not sure on this) because it seems likely that different languages use different grammar such that one order or the other sounds much more natural to a native speaker.

I do recognize that many lists of items have various [F]ind/[F]ilter options that can mitigate this problem, but it seems like overkill. If I use advanced inventory management to look at my display rack of food and drink it would be nice if I can see them sorted by the part I intend to eat; it doesn’t really matter to me whether it’s in a glass jar, a plastic bottle, or a paper wrapper.

I’m imagining that this would be implemented as a game option under the “Interface” section. I toyed around with the code and it seems like you can just change a few lines in item::tname() to get this result. I managed to compile the game with the name order manually reversed in item.cpp and it seemed to work fine. I don’t know nearly enough about the code base just yet to make it a menu item and I have no idea if there might be any consequences for putting an option check at this point in the code.

So I’m posting here to see if people with more knowledge think that this is possible and/or practical without tons of coding and/or causing problems. If the code involved is as simple as it seems and it’s something that could be included in the game I’d be happy to do the coding and create the PR for it.

So what do people think about this?


Do containers themselves ever have charges?
#2

I would like to see this as an option.


#3

Don’t know much about the code side, but it seems perfectly reasonable. I’ve idly thought about that in the past actually. It doesn’t change anything that would alter anything drastic aside from ‘of’/ ‘in’ in the filters but I don’t think anyone searches for things that way… althoguh that seems like a good way to search for all your containers with things in them now that I think about it. Would like to see it.


#4

Not a fan of making it an option, as that’s one more thing to break, but I don’t have an objection to just swapping it unconditionally.


#5

I would also have no complaints with just changing the order without adding any kind of option to the game. I want containers to be named by contents first all the time; I was just suggesting it as an option because I assumed there might be some disagreement as to which order is better.


#6

Are there any reasons for the current order? Typically the contents are more important then the container type.


#7

None that I can think of really. I imagine it was made the way it is because “bottle of water” sounds more natural than “water in bottle” to most English speakers. It probably didn’t make much difference back when the decision was made, but playing now it seems pretty clear that container name after the contents makes more sense from a usability standpoint.

If we decide to just permanently switch the order that’s going to involve changing a whopping three lines of code unless item names are ever generated outside of item::tname(). All three are close together starting at line 2268 of item.cpp. In my testing I just swapped the latter two arguments of the string_format function and edited format string.

Oh wait, just had another thought now that I’m looking at the actual code. The first two are for liquid and food respectively which are exactly what we’ve talked about in this thread so far. The third is for things like holsters and quivers which I’m less sure on. Because these types of containers are often equipment or similar it’s less certain that the content is more relevant than the container. I’m tempted to leave it alone for those cases, but I think changing it has benefits as well. Anybody have thoughts on this? Is “Glock 19 in Holster” better than “Holster with Glock 19”? I don’t feel strongly one way or the other for these items.


#8

The origin of this phrasing is the original game developer whales. It predates my involvement in the project and hasn’t been seriously examined ever.

I think placing the contents first is just as valid for holsters and such as it is for food and liquid containers.


#9

So is this something where I should create an issue on github at this point? I’m not familiar with the process for this sort of thing.


#10

The process is minimal, create an issue about it laying out your argument, or if you can do the code change yourself just make a pull request.
If you open an issue instead of a pull request, be aware that it can sit for quite a while until it catches someone’s eye.


#11

I should be able to do the code myself. I’ll put together the pull request as soon as I have a chance.


#12

So guns with magazines are a fairly complicated example of containers. This raises a few questions.

  1. Do we want to name items like guns with the name of their contained magazine and/or ammo?
  2. Should magazine names include their contents (if any) like other containers do?
  3. Are there currently other recursive container situations I should be aware of, or any planned in the future?
  4. Should this discussion be on the forum, the issue tracker, or both?

#13

There’s also one bit in the naming code that’s confusing me a little. This line in item.cpp, copied below:

} else if( contents.size() == 1 ) {
    [...]
} else if( !contents.empty() ) {
    maintext = string_format( pgettext( "item name", "%s, full" ), label( quantity ).c_str() );
} else {

So when the size of the contents list is not exactly equal to one and it is also not empty (aka when its size is greater than one) we add ", full" to the end of the item’s name.

I can’t think of a single time I’ve seen this during game play; it also doesn’t seem to make much sense. Can anybody point me at which type of item or container uses this naming scheme?


#14

That certainly looks like a step back when it comes to readability. I think it would be better if you special case guns and keep them with the current naming scheme.

I think it should simply read:

M1911 (7) in holster.

I dont think its important to know the magazine name or the ammo. Whats important is if the gun is loaded and the remaining ammo, and the current naming scheme lets you know both this things at a glance


#15

Yeah I wasn’t suggesting we leave it that way. I just found that the simplest version of the code caused this sort of recursion and thought I’d ask others where we should draw the line. This is what I’ve managed so far:

That’s what it looks like in my current test save. Let me know what you think of these and please suggest any combination of items, containers, charges, etc you don’t see here.


#16

HMuch better!

I think magazines could read better if they were listed like this:

4 Glock Magazines (15) (.9mm FMJ)

As I believe that conveys the same info


10 clean water (2) in plastic bottles

May also be slightly confusing, maybe introduce a multiplication symbol like so:

10x clean water (2) in plastic bottles


Btw thanks for doing this.


#17

Yeah the magazines didn’t seem perfect to me. I’ll look at putting the count and type at the end like that. The tricky part is that guns/magazines/bandoliers are already adding several special cases to the code and I’m trying to keep that at a minimum.

I totally agree, but that’s not actually part of the item naming code. The quantity number is added later by some part of the code that lists items and/or displays inventory. I’ve decided to leave that as a separate issue and limit my changes to item.h + item.cpp right now.


#18

Amazing. Thank you for existing you guys. I Never realized how much better that could be, and now I feel like this should have been thought of sooner.


#19

So here’s the current state of things. I think I’ve fully finished the original goal, but there are a couple things that still need addressing:

  1. My code probably doesn’t correctly handle translation/localization so I’ll need to learn more about how localization works and get it fixed up for that.

  2. This change breaks alphabetical sorting because items are sorted by their base names and not their display names (so “water in plastic bottle” still sorts as “plastic bottle”). I could possibly fix this within item.cpp by hacking something together but I’d rather track it down to its source and fix it properly which will probably take significant time and effort.

  3. I need to do some reformatting on my code so it matches the style of the code base. I have certain coding habits that are apparently not very common. It’s all just style type stuff so no big deal.

So that’s my progress. Let me know if you have any other feedback or anything.


#20

Looks great.

Strong improvement overall.