Configuring property display in character screen

[backwardsEric]

I'm looking at trying to implement a "resistance grid for home" in Vanilla, a knowledge menu item that would show a summary of items that can be worn from your current equipment, pack, and home. Since there's overlap between that and the information shown in the second page of the character screen, I looked at how that was generated. Except for the characters and colors used to display the item type, the display details for that appear to be hardwired and can't be set from gamedata/player_property.txt or gamedata/object_property.txt. There's also no option for the player to customize something like the colors used for penalties and bonuses.

Given the size constraints, limiting what's configured at runtime keeps the display code manageable. This post is asking for feedback at adding fields to the files in gamedata so some customization, like adding or removing a property or setting the character/color for a class of entries, is usually possible without having to change ui-player.c or ui-knowledge.c.

What seems to be necessary is to link a property to a "display mode" that would control how it's displayed in a certain context. The two screens for the character sheet display would be examples of two different contexts in Vanilla. I'd imagine the "resistance grid for home" command would use the same display mode as the second character sheet (to avoid having to configure much the same information twice) but would lay out and filter things differently. It would also be necessary to specify some parameters along with the link to the "display mode" to tune how the property is presented.

To link "cold immunity" so it can be displayed on the second character sheet, I'd propose adding these fields to its entry in object_property.txt:

gridview: name_of_renderer
gridviewentry: name_of_entry
gridviewval: value_passed_to_renderer

The name_of_renderer would be the name of a renderer configured in a new file in gamedata, gridview.txt . I'm imagining four broad classes of renderers. One would display boolean values. Another one would display things with a small number of different "qualities" (in Vanilla, examples of that would be brands (none, weak, strong), slays (none, "slay", or "*slay*"), or resistance (vulnerable, none, resist (permanent), resist (temporary), resist(permanent and temporary), or immune)). Another would display values shown as numbers (with either options or separate renderers to configure the number of digits, display of a +/- sign, display of a % or other unit indicator). Another is for the specialized case of displaying the modifier to a core stat, like strength, with an indicator for whether or not it was sustained.

The name_of_entry would also link to something defined in gridview.txt. For "cold immunity", the same entry would be used as for "cold vulnerability" and "cold resistance" so they are shown in the same bit of screen real estate. The entry would configure the label (probably several different lengths so the command in ui-knowledge.c or ui-player.c could choose the length appropriate for its layout) and a broad category or categories for the entry (that's so something like the second character screen can filter out certain attributes that it does not display while the "resistance grid for home" might shown them, at least in certain modes). The entry would also configure a priority (should that be one value or one for each category?) to instruct the display command how to order properties and, when there's not enough space, to choose which ones won't be displayed.

For "cold immunity", value_passed_to_renderer could be a literal integer value like "4" (permanent "cold resistance" could be "1" and "cold vulnerability" could be "-1"). For other cases, it would have to be some string which would be interpreted as "look up the value in the object" or another which would be "lookup the value in the object and apply conversion x".

That's likely more than enough rambling. What do you think about the idea?

[Nick]

I think it's a fantastic idea, but then I live for this stuff. Having just spent some hours tweaking this for FA, I fully appreciate the value.

I think home item property info is something a lot of people would like, and I think there's also a decent proportion of players who would appreciate the configurability.

[Diego Gonzalez]

I know my question isnt exactly related to the subject of this topic, but... It's possible to break the barrier of the minimum 80x24 display?

I've tried to do something like that for Android briefly, but many screens in Vanilla have hardcoded positions and dimensions (menus, knowledge screens, birth, character sheet). Another example, the right sidebar uses a lot of space in portrait mode.

I could use a separate dungeon term to draw the dungeon and switch to term 0 when drawing the knowledge screens and birth, but it sounds a bit hackish to me.

I think that the last Sangband used separate "displays" to draw things on the main window.

Perhaps the size of term 0 is not the problem. What I would to achieve is a more independent dungeon view, separated from command input, menus and info screens. Maybe is all there, but I dont know the code so well.

[Nick]

I know my question isnt exactly related to the subject of this topic, but... It's possible to break the barrier of the minimum 80x24 display?

That's a really good point, I'll have a look into whether that assumption is still around and where. I guess the opening screens, at least.

[Diego Gonzalez]

And things like the knowledge screens. Perhaps the dungeon view not so much. I saw that the LOS length is in gamedata.

I dont want to change the core game so much, so I just asked just by curiosity. Its a lot of work.

[backwardsEric]

An attempt to do what was rambled about in the original post, to drive more of the layout for parts of the character screen from the configuration files, is now in this GitHub branch, https://github.com/backwardsEric/ang...r-sheet-config. Any comments are welcome. For a player it doesn't add anything except the option to change some symbols/colors for display. For a maintainer, it's not clear if it makes things better.

I know my question isnt exactly related to the subject of this topic, but... It's possible to break the barrier of the minimum 80x24 display?

What minimum size for displaying the character screen would you want on Android?

There's an open issue, issue 2177, that requests lowering the minimum number of rows to 16. It lists the unresolved parts as handling selections from the inventory and the character screen layout. From what I saw making the above changes is that the character screen seems feasible to do at 16 rows by splitting into more pages. Handling fewer columns would require adapting the layout of the top part of the character screen; the resistance panel would be easier to adapt to a change in width by using two rather four columns. For more flexibility with the size of the character screen, it also seems like it would also be necessary to decouple the generation of the contents of the character dump from the character screen display or keep the coupling but handle it by an offscreen render to the 80x24 size.

[Diego Gonzalez]

I have less time these days to work on the port, but I could try these couple of things:

1. Configure the panel size dynamically, from the ui. It could be smaller than the main screen.

2. The core should notify the ui when a dialog is displayed (menus, recalls, etc). Basically coordinates and dimensions of that region.

That way, I can display different regions of the screen with variable font sizes. Or change their positions.

Some commands, like L, M, and l, could briefly use a bigger panel size and a smaller font.

I already have a notification system for random things. Basically I have to implement point 1.

This approach benefits landscape mode without changing the layout. Portrait mode would need a different layout for the big dialogs, but I think the focus should be in landscape mode first.