Multiple pvals

[Magnate]

Then omit the pvals altogether, or use 2 lines. The 3 choices { full, omit, two lines } should be a display option.

Ironically I was writing a post about options as you posted this. But of the three I would go with omit altogether. IMO both the other two are hugely problematic, and the pvals are very neatly displayed in the character detail subwindow anyway.

[PowerDiver]

The big space-taker for equipment is the equipment type. You could replace "Studded Leather Armor" with "Armor" and save 16 characters right off the bat. Or just remove it entirely, since it has to be armor given that it's in the torso slot.

Wouldn't want to do it for non-handhelds since space isn't at a premium there, of course.

Continuing on this, I'd would rather see
a cloak Int+2 Wis+3 Stl+4 Spd+1
rather than
an elven cloak of the magi

IMO the former is more useful. Anyone who can memorize what <+2, +3, +4, +1> is supposed to mean will recognize the cloak as being the hypothetically wis-improved "of the magi" given the first desc.

If you want to save every character, then
a cloak I+2 W+3 Q+4 E+1
is just as short as full names without pvals, but then you need 1 letter abbreviations for all of the flags with pvals.

[Magnate]

Continuing on this, I'd would rather see
a cloak Int+2 Wis+3 Stl+4 Spd+1
rather than
an elven cloak of the magi

IMO the former is more useful.

Yeah but we still want a modicum of flavour, and item names are one source of it, IMO. I don't see the need to include pvals in item names when you have a nice little table showing them all in a subwindow (or overlay, pop-up etc.).

[Nick]

There is a hackish version of short descriptions in current FA, which I want to do properly at some point.

[PowerDiver]

Yeah but we still want a modicum of flavour, and item names are one source of it, IMO. I don't see the need to include pvals in item names when you have a nice little table showing them all in a subwindow (or overlay, pop-up etc.).

The values in the one-line desc really are useful when you are looking at the contents of your home, deciding what to swap in and swap out. Also, everything about pvals on egos applies equally to pvals on artifacts. I end up inscribing what pval is what on randarts. It's also useful to get the info from the object list ']'. Heck, I want it whenever I bring up my inventory. A small inven window can be treated differently.

Is there some reason this should not be ruled by display options? Let the player choose what he doesn't want listed if space is limited.

People like me, who set up a very wide screen, should be able to get both name and pval descs in the one-line desc.

[Magnate]

The values in the one-line desc really are useful when you are looking at the contents of your home, deciding what to swap in and swap out. Also, everything about pvals on egos applies equally to pvals on artifacts. I end up inscribing what pval is what on randarts. It's also useful to get the info from the object list ']'. Heck, I want it whenever I bring up my inventory. A small inven window can be treated differently.

Is there some reason this should not be ruled by display options? Let the player choose what he doesn't want listed if space is limited.

People like me, who set up a very wide screen, should be able to get both name and pval descs in the one-line desc.

Hmmm. Maybe the issue here is intelligent truncation, rather than display options. I don't have an opinion on the display stuff, except that as a general rule we want fewer options rather than more.

I also think that there is mileage in investigating a new subwindow display that shows the flags of inven and home, in the same way that the character detail screen does for equipment. I know that some variants already do this in dumps, but I'm not aware of any that have a ready-made display set up. I guess it would just be a third tier of the 'C' screen.

[fizzix]

FWIW I agree with Eddie that it's better to have the stat boost info rather than the item type. However, it's very hard for me to approach this from a novice player point of view. I'm also really bad at understanding UI stuff in the code...

If you're trying to make a game that can work on both handhelds and 23" double monitors, it's really hard not to have settable display options. If there was one place where options were desirable it's here. I understand the need to limit "option-creep" but these types of things are important.

[d_m]

It might even be worth having a game command that swaps display back and forth between "flavor" mode and "stats" mode. I think I usually like seeing the flavorful stuff, but I can totally imagine wanting the stats display when I am choosing between 2-3 different body armors, for instance.

But yes, I agree that having one or more options around the "small screen" concept is probably a good idea.

[Magnate]

It might even be worth having a game command that swaps display back and forth between "flavor" mode and "stats" mode. I think I usually like seeing the flavorful stuff, but I can totally imagine wanting the stats display when I am choosing between 2-3 different body armors, for instance.

But yes, I agree that having one or more options around the "small screen" concept is probably a good idea.

Well, I am really not the person who should lead any decision-making around any UI stuff, so I'm happy to defer to the rest of you on it. I'll just think a little more about whether there are good non-UI reasons for keeping flags associated with specific pvals, or allowing them to sum across multiple pvals. Instinctively I want the former, but I need to test this instinct.

[PowerDiver]

I also think that there is mileage in investigating a new subwindow display that shows the flags of inven and home, in the same way that the character detail screen does for equipment. I know that some variants already do this in dumps, but I'm not aware of any that have a ready-made display set up. I guess it would just be a third tier of the 'C' screen.

Sure, that's all good, but nothing in an extra window helps you pick which item to inspect from a long list of items.

[Derakon]

If I could scan through a window and see at a glance all the items that provided some combination of resistances, that'd be helpful for picking out equipment. Sounds like a good idea to me!

[PowerDiver]

If I could scan through a window and see at a glance all the items that provided some combination of resistances, that'd be helpful for picking out equipment. Sounds like a good idea to me!

That's on my todo list, except it wouldn't be a separate window. It would be a fairly large table I imagine would only fit in the main screen. Is there any reason for it to be in a window?

[PowerDiver]

I'll just think a little more about whether there are good non-UI reasons for keeping flags associated with specific pvals, or allowing them to sum across multiple pvals. Instinctively I want the former, but I need to test this instinct.

You are wearing too many hats. The implementation details of a data structure should not concern you, except I guess that you have signed yourself up to do them too.

There ought to be a file pvals.c, containing [at least] 3 functions. You need to be able to set the pval of a flag, add to a pval of a flag, and inquire the pval of a flag. The first two need to return whether the change was possible. However that is done, be it addition or triple indirection or something truly strange, is irrelevant. The code outside pvals.c should never look directly at the data structures.

The implementation details should be considered to be sequestered, and likely to change without notice. You shouldn't be worrying about whether additive is good or bad when you are thinking about UI issues. Implement multiple pvals however you like in the access routines, but you should write the rest of your code so that it still works if someone radically alters the details of how pvals are stored.

[Putting on data structures hat:] One point in favor of the additive implementation is that you want a rational interpretation of any setting of the data structure. It is possible to set a flag as corresponding to more than one pval given the current fields in the object type. What's the most natural interpretation of what that should mean? You could go through hoops trying to make sure it never happens, but that sort of code is rarely robust. It's far better to accommodate all bit settings when possible.