Quality of life: Spellcasting #536

2025-01-18T23:47:25Z

NQNStudios commented

2025-01-18 23:47:25 +00:00

(Migrated from github.com)

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 #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 https://github.com/NQNStudios/cboe/issues/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.

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 #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 https://github.com/NQNStudios/cboe/issues/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. <img width="452" alt="Screenshot 2025-01-18 at 5 39 31 PM" src="https://github.com/user-attachments/assets/17bdc363-d67a-4924-a14d-197430693d30" /> * 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. <img width="915" alt="Screenshot 2025-01-18 at 5 39 15 PM" src="https://github.com/user-attachments/assets/9e52ecc2-c82a-4a8b-9a75-c2433591f85e" /> Honestly still haven't decided if I like how it looks, so feedback is welcome.

NQNStudios commented

2025-01-20 02:20:57 +00:00

(Migrated from github.com)

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.

> * 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 commented

2025-01-20 14:24:02 +00:00

(Migrated from github.com)

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.

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 commented

2025-01-20 19:23:50 +00:00

(Migrated from github.com)

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

Here's a redesign of the spell window that aligns the numbers, buttons, statuses etc. and colorizes HP/SP numbers <img width="920" alt="Screenshot 2025-01-20 at 1 22 45 PM" src="https://github.com/user-attachments/assets/a4be7866-8560-4fd8-a51b-3599b2150eeb" />

NQNStudios commented

2025-01-20 20:45:45 +00:00

(Migrated from github.com)

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.

> 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 commented

2025-01-22 00:50:07 +00:00

(Migrated from github.com)

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?

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 commented

2025-01-22 01:11:23 +00:00

(Migrated from github.com)

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

> 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 commented

2025-01-22 01:31:29 +00:00

(Migrated from github.com)

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.

> 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 commented

2025-01-22 01:38:58 +00:00

(Migrated from github.com)

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.

> 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 commented

2025-01-22 14:17:58 +00:00

(Migrated from github.com)

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".

> 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 commented

2025-01-22 17:01:01 +00:00

(Migrated from github.com)

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!

> 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 commented

2025-01-23 00:37:11 +00:00

(Migrated from github.com)

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.

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 commented

2025-01-23 02:00:18 +00:00

(Migrated from github.com)

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
https://github.com/calref/cboe/pull/536#issuecomment-2608587689, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AATXBKJI7Q5OKRT44X7AVL32MA2U5AVCNFSM6AAAAABVOCSVGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGU4DONRYHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

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 > <https://github.com/calref/cboe/pull/536#issuecomment-2608587689>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AATXBKJI7Q5OKRT44X7AVL32MA2U5AVCNFSM6AAAAABVOCSVGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBYGU4DONRYHE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: openboe/oboe#536