Hmm, if an inscription was just "!L" then s[0] == "!", s[1] == "L", s[2] == 0, and then s[3] is out of bounds, no? Where else in the code makes this assumption?

(I hate C)

Yeah, uppercase sounds good, too.

In that case " && '0'<=s[2] " fails so further && conditions are not evaluated, which is how out of bounds accesses are prevented ;) (I also don't like lots of things about C but it still beats assembly code :D )

----
About @<cmd><letter> I just realized my plan would essentially make the inscriptions array a keymap (input letter-or-digit -> equipment slot), since we'd first assign working normal letters to the array (after inscriptions are processed) to guarantee nobody claims that letter. So we could rename this array keymap if we go that route.

About the UI, we have several possibilities:
1. Don't use uppercase letters inscribed by the user. This guarantees 26 free slots for pathological cases.
2. Let the user use uppercase inscriptions and
.2a. just do nothing if the user has somehow messed with all letters (an item is unreachable)
.2b. provide a few non-letter keys for those cases.
It's just that I don't see in what practical situation there'd be a 2a pathological case. "Assign the first free uppercase letter" should always work (going for an uppercase letter first to emphasize in the menu that a lowercase inventory slot was temporarily reassigned), unless the user inscribed all uppercase letters somewhere on purpose right?

EDIT in fact @Ee might be safer than @EE in case I'd release the shift key between the Es and end up eating something at slot e. It could be lowercase inscriptions are safer. Or I'd engrave both @EE and @Ee.

It seems to me that this entire thread has been sidelined into what should be in the "Development" portion for talk about coding specifics rather than the "Vanilla" portion, but maybe that's just me.

You got some positive feedback from the initial change to Satisfy Hunger specifically because it meant that players would no longer have to hoard Purging/Salt Water for the final fights to avoid getting healing-gorged. Reverting that part of the change is therefore likely to provoke complaints.

What if it set your percentage to MIN(90, current+50)? Or current+25 or whatever you think a reasonable number is.

You are very likely correct :)

Here are my reasons for going ahead with this anyway:

1. The hunger meter means the player has a chance to plan their food intake before the final fights, which seems reasonable and the sort of integration of the hunger mechanic that I am aiming for
2. Slowing through fullness sets in gradually - one healing potion will slow the player by a maximum of 1 - so it is a situation the player can respond to dynamically
3. Only two classes of nine get Satisfy Hunger as a spell, so others choosing to rely on "hunger reduction" would need to devote a slot to it in any case
4. I plan to introduce some more variety of food, so the player can have more control over their hunger level

While I'm aware that there are some people who wish hunger would just go away as a mechanic, I'm in general not in favor of extreme optimisation of aspects of the game to facilitate the equivalent of speedrunning; I think that's the player's job, not the maintainer's. There was a choice between actually removing hunger or making it more integrated within the game, and overall we came down on the side of integration. So I don't want to then do things that run counter to that, in the same way as I'm not going to introduce thisas a town layout :)

You forgot the little courtyard for the townspeople and Farmer Maggot to spawn in, which is of course separated from the rest of the town by a pile of rubble. :)

But anyway, fair enough. I'm not personally trying to persuade you to go one way or another, just making sure you're making as informed of decisions as possible. Which you are, as best I can tell.

HPs would probably also be a problem. I think level limits make more sense if you add something like giants & give them insane hps/level. Quickband gives high elves the "Doom of Mandos" from clvl 27 which does bad stuff (not sure what, never played the high elf) but you could adapt Sil's danger mechanic where monsters are spawning at a higher depth or do something different.

I'm pretty sure I've seen ladder wins with character levels lower than 40. At level 40 with max CON you get 40*12.5=500 HP from CON, which means you need 2.5 HP per level from your hit dice to be out of instadeath range from Morgoth. The worst hit die in the game is a halfling mage with a d7, which has an average roll of 4. I'm not saying it'd be a fun fight, but it should be doable.

But sure, there's plenty of other neat ways to penalize powerful races in the lategame. You could give one race a time limit of 1 million game turns (~= 100k normal-speed turns, plenty to win with), for example. There might also be some way to tweak the experience-received-per-enemy formula such that as a particular race dives deeper they have to get more and more of their experience from "novel" kills (where the monster type hasn't been killed before).

As in PowerWyrm's epic win of the Hobbit comp with The One Ring, Sting, and a Mithril ChainMail to start, with the win condition being the lowest experience. ;) However, I think ladder wins are less comparable across versions, especially as the newest rendition of the end-game is appreciably more difficult to win - in a good way.