Quality of life: Spellcasting

[NQNStudios]

This makes changes to the spellcasting UI.

• M or P to recast will no longer default to Light or Minor Bless/Minor Heal. You need to cast something before recast becomes available. This fixes load party, press P: "Priest spell Light not implemented for town mode." #535 and I think it's disorienting when I've just started the game and M casts Light in a town that's fully lit, so the change is generally good I'd say.
• I implemented a recasting hint in the text bar, which was one of the things I mentioned in my quality-of-life checklist Quality of life wishlist NQNStudios/cboe#16. It should move status icons to the left when necessary, to fall between the left text and right text. I think with very long spell names, this could overlap with the text, which would be bad. But I don't know what statuses go in the text bar so I haven't tested/handled that case yet.

• Sometimes when my eyes glaze over, I think I'm casting the spell on the wrong side of the LED. I thought there was a bug when I cast Long Light instead of Dumbfound (even though I know the distance between the two is pretty large -- I wasn't paying much attention). I thought it would be nice to highlight the name of the selected spell. Light green seemed to make more sense than red for that, because the LED turns green. Then I made the caster/target selection texts also use light green instead of red, to match. Uncastable spells are grey.

Honestly still haven't decided if I like how it looks, so feedback is welcome.

[NQNStudios]

• It should move status icons to the left when necessary, to fall between the left text and right text. I think with very long spell names, this could overlap with the text, which would be bad. But I don't know what statuses go in the text bar so I haven't tested/handled that case yet.

The thing to do about this would probably be to calculate how much space is taken up by the name, APs, and active status icons, then squish the spell hint horizontally as needed.

[CelticMinstrel]

Hmm… my first reaction to the spell hint was "that sounds bad, there just isn't enough space", and I still mostly feel that way (what about characters that can cast both mage and priest spells)? However, if it's only shown as part of the combat AP indicator, then I think I can live with it. In that case we can drop the status icons altogether – the only statuses shown there are whole-party statuses (fly, detect life, firewalk, stealth), most of which have no relevance in combat. (I think only firewalk could have combat relevance?)

So, to be clear: in combat we can show this indicator, and outside of combat we can show the status icons, but not both at the same time. Does that work? I'm not sure if it undermines the intent of your hint.

Oh, and about the redesign of the spellcasting dialogue: I like it.

While you're at it, maybe you can fix the alignment of the headers? Like, aligning "HP" with the column of HP, "SP" with the column of SP, etc.

[NQNStudios]

Here's a redesign of the spell window that aligns the numbers, buttons, statuses etc. and colorizes HP/SP numbers

[NQNStudios]

So, to be clear: in combat we can show this indicator, and outside of combat we can show the status icons, but not both at the same time. Does that work? I'm not sure if it undermines the intent of your hint.

I think this is just fine.

(what about characters that can cast both mage and priest spells)?

I've just made it so attempting to recast the opposite spell type of the hint, toggles the hint to the other spell type, so you get to see it before repeating the input to do the recast.

I made this part of the spellcasting action that we already record and replay, so it should work in replays.

[CelticMinstrel]

Regarding the colours, I think my logic behind choosing those colours was that they are the basic HTML colour set… or perhaps it was that it's the basic Win32 console colour set, or the union of the two. So I think I'd prefer to keep all the colours that were defined before, though moving them to a colour map definitely makes the code cleaner.

One other note on the colours – for two-word colours, could we replace the underscores with hyphens? So for example color="title-blue" instead of color="title_blue".

Also, I think you missed updating the schema for the colours change? Unless I missed it.

---

I notice you added a documentation comment in the cpp (asPeaceful). Wouldn't that make more sense in the header?

[NQNStudios]

Regarding the colours, I think my logic behind choosing those colours was that they are the basic HTML colour set… or perhaps it was that it's the basic Win32 console colour set, or the union of the two. So I think I'd prefer to keep all the colours that were defined before, though moving them to a colour map definitely makes the code cleaner.

For the ones that exist as Colours constants can I use those values instead of the ones that were defined before? It'd be really weird/inconvenient if the xml couldn't make controls match colors with the programmatic values

[NQNStudios]

Also, I think you missed updating the schema for the colours change? Unless I missed it.

color/colour actually doesn't have its acceptable values specified in the schema.

[NQNStudios]

I notice you added a documentation comment in the cpp (asPeaceful). Wouldn't that make more sense in the header?

I think it would actually make the most sense right next to the declarations of all the spells. I added that note in because I thought all the instances of when(WHEN_COMBAT).asPeaceful() were bugs and they're not.

So I put it there.

[CelticMinstrel]

For the ones that exist as Colours constants can I use those values instead of the ones that were defined before? It'd be really weird/inconvenient if the xml couldn't make controls match colors with the programmatic values

How different were they? If they're reasonably similar colours then the version in Colours should be fine.

color/colour actually doesn't have its acceptable values specified in the schema.

Hmm, maybe that should be added, but if it's already not there then it won't block this PR.

Also, you misspelled "silver".

[NQNStudios]

How different were they? If they're reasonably similar colours then the version in Colours should be fine.

They're pretty similar, and also nothing was referencing the variants that would have come from the old parseColor() so there's no functional change.

Also, you misspelled "silver".

That I did. Funny that it wasn't fuchsia that tripped me up!

[CelticMinstrel]

Okay, I did a comparison of the colours. The ones that are different are:

• red and blue use 0xdd instead of 0xff
• yellow adds 0x31 blue to mellow it out a bit
• navy is even darker - 0x39 instead of 0x80
• teal is a significantly different colour

The differences mostly aren't noticeable unless you look closely (except for teal). I did wonder if perhaps some of the "extra" colours that use 0xff should instead either use 0xdd or fill the gap with 0x31, so I tried this out:

• lime with 0xdd is noticeably darker but still quite bright
• aqua as 00dddd is noticeably darker but still quite bright
• aqua as 00ffdd is about the same as 00ffff while 00ddff is about the same as 00dddd
• fuchsia as dd00dd is noticeably darker but still quite bright
• fuchsia as ff00dd is about the same as ff00ff while dd00ff is about the same as dd00dd
• aqua as 31dddd doesn't look noticeably different to me
• fuchsia as dd31dd doesn't look noticeably different to me.

I think they're probably fine as they are, but if you think any of them are overly bright then you could try reducing them as above.

[NQNStudios]

I don’t think I’ll noodle with the values any more.

…

On Wed, Jan 22, 2025 at 6:37 PM Celtic Minstrel ***@***.***> wrote: Okay, I did a comparison of the colours. The ones that are different are: - red and blue use 0xdd instead of 0xff - yellow adds 0x31 blue to mellow it out a bit - navy is even darker - 0x39 instead of 0x80 - teal is a significantly different colour The differences mostly aren't noticeable unless you look closely (except for teal). I did wonder if perhaps some of the "extra" colours that use 0xff should instead either use 0xdd or fill the gap with 0x31, so I tried this out: - lime with 0xdd is noticeably darker but still quite bright - aqua as 00dddd is noticeably darker but still quite bright - aqua as 00ffdd is about the same as 00ffff while 00ddff is about the same as 00dddd - fuchsia as dd00dd is noticeably darker but still quite bright - fuchsia as ff00dd is about the same as ff00ff while dd00ff is about the same as dd00dd - aqua as 31dddd doesn't look noticeably different to me - fuchsia as dd31dd doesn't look noticeably different to me. I think they're probably fine as they are, but if you think any of them are overly bright then you could try reducing them as above. — Reply to this email directly, view it on GitHub <#536 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATXBKJI7Q5OKRT44X7AVL32MA2U5AVCNFSM6AAAAABVOCSVGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGU4DONRYHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>