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?
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?
Comment