Jump to content

need some brainstorming: managing spells cast per day with opcode 214


Recommended Posts

Alright, I'm frustrated and going to try to crowdsource this a bit. I want to figure out a way to manage number of casts per day of an ability that uses opcode 214 (think NRD).

 

The problem: When you click the spellcasting icon, it brings up a list of memorized spells. You can choose one to cast, or you can just look at what's available and then change your mind, using melee attacks instead (or whatever). You don't lose any spell slots when you change your mind in this way. On the other hand, when you cast a spell like NRD, it brings up a list of spells to choose from... and if at this point you change your mind or click on another character, the list disappears and you lose that spell slot. Because the slot has been expended in simply generating that list.

 

I'd like to find a way to circumvent that. Like, have it detect whether you do or don't actually cast a spell, and restore the spent slot if you don't.

 

Rough ideas so far:

 

1) Track spell slots via stats, and have spells you cast reduce the proper stat, and have some kind of checks to constantly reset your "spells slots" to match the value of the stat. (Could be done with 172/171 for innate abilities... but then you have the issue of innate abilities jumping all around the innates bar, which is horrible.)

 

2) Track "slots" via stats, and actually cast from an item. The item abilities would be infinite-use, but would not work if the relevant stat = 0. Renew the stats every morning.

 

3) Could get crazy... add back the slot via a subspell, cast every round when you trigger the initial NRD ability. But that ability would also apply a subspell coded as a bard song, which gives 206 protection against the slot renewal. Choosing an actual spell from the list would 321 cancel the repeated subspell, so it never renews. (You cast a spell, so you have spent that slot.) Also apply a 363 'cancel bard song on movement' effect so that if you click away from the list and do something else, it cancels the 206 protection and the slot renewal will take place (you didn't cast an actual spell, so you don't lose a slot).

 

Any other crazy ideas? Or, any thoughts about how to make one of these ideas actually work?

Edited by subtledoctor
Link to comment

On the other hand, when you cast a spell like NRD, it brings up a list of spells to choose from... and if at this point you change your mind or click on another character, the list disappears and you lose that spell slot. Because the slot has been expended in simply generating that list.

This does sound like a bug and should be reported on Redmine......

 

EDIT: OK, nevermind, it's already been reported here and here......

Edited by Luke
Link to comment

Yeah, it's still finicky. The goal is to replicate the reliability of spellcasting with the 'cast spell' button, for a class without that button. Rather than have a "cancel" spell, I'd like it to assume it was canceled, unless and until a subspell is cast.

If 172 could decrement instances of an ability, rather than just erasing it, this would be super simple... :(

Edited by subtledoctor
Link to comment

This might be the answer:

 

- Keep track of the proper number of "spell slots" you should have with an unused proficiency.

 

- When you cast an actual spell from the 214 choices, decrement that proficiency by 1 (or, maybe, by 1 bit). (Because, I just found out that this is possible.)

 

- Every round, have a background spell 172 your NRD ability and then give back via 171 a number of slots equal to the proficiency. So even if you keep burning the ability to look at your 214 list and then fail to cast anything, a few seconds later you'll have the right number of "slots" for that ability.

 

- After every rest, reset the proficiency.

 

Use 9 proficiencies (or, maybe, the upper 3 bytes of 3 proficiencies) and you can do this simultaneously for every... well, I'll get to that later.

Link to comment

Wait, this is actually more complicated than I thought. Might need someone like @Camdawg or @kjeron to confirm my suspicions (and yes, I know those @'s don't tag anyone, I'm just following form from the other website)

 

So, let's say I want to simulate "number of 1st-level spell slots" with a stat. I might try to use byte 2 of stat 113 (Single-Weapon Style). I want something to fire every morning that restores the stat to a set number - say, 2. I might use opcode 233 to set the proficiency to (2 << 8). Casting a spell would reduce the stat by (1 << 8), leaving the value at (1 << 8). Casting another spell would drop it to (0 << 8) and at that point you will not be able to cast 1st-level spells. Rest, and the morning effect will once again set the stat to (2 << 8), giving you back your "spell slots." This is, in a nutshell, what I am trying to achieve. (For all 9 spell levels.)

 

But how does this interact with the lower byte of the stat? If the morning effect sets the stat to (2 << 8), is it effectively setting it to... 512? (Right?) Would it zero out the values in the lower byte of the stat? So if you are proficient in Single-Weapon Style, would this eliminate your proficiency?

 

If so, does that mean this must be done by incrementing the stat each morning, rather than setting it? And if the answer to that is yes, does that mean detection of the value in the upper byte will have to be done by bit-equality, rather than simple equality?

 

If so, that will complicate the decrementing effect of casting spells, right? Spells won't "know" the bit value of the upper byte, so they won't know whether to decrement by 256, or 512, or 1024, etc.

 

Maybe bit equality isn't necessary. Maybe those spells can decrement by 1 (or (1 << 8)... not sure which would be necessary), and the once-every-morning spell can simply detect your value in the lower byte before deciding how to set the stat. SWS, SnS, and 2HW only go to 2 points, so the lower byte will always be bit-equal to either 0, 1, or 2, and that can be detected independent of the upper bytes' value. So to give you 2 "spell slots" in the morning it could check your style proficiency first, and then set the stat to 512, 513, or 514, as appropriate. Is that right?

 

So as an exercise, let's say you are supposed to have 3 1st-level slots, 2, 2nd-level slots, and 1 3rd-level slot, like a 5th-level mage. We'll keep track of those slots in the 2nd, 3rd, and 4th bytes of stat 113, respectively. ((3 << 8), (2 << 16), and (1 << 24).) Can we set up three variant opcode 233 effects that would give you the right number of such "spell slots" (i.e. set the stat to those values in the upper bytes) while retaining your SWS proficiency? I think it would be the numerical sum of those upper-byte values, and then that same number +1 and +2...?

 

I don't even know if I'm expressing this correctly, I feel slightly crazy for trying to do this. But if I can make it work, it will be super-nutso-awesome. :jump:

Edited by subtledoctor
Link to comment

But how does this interact with the lower byte of the stat? If the morning effect sets the stat to (2 << 8), is it effectively setting it to... 512? (Right?) Would it zero out the values in the lower byte of the stat? So if you are proficient in Single-Weapon Style, would this eliminate your proficiency?

 

If so, does that mean this must be done by incrementing the stat each morning, rather than setting it? And if the answer to that is yes, does that mean detection of the value in the upper byte will have to be done by bit-equality, rather than simple equality? :jump:

More or less yes.

Another way around this would be to run all such increments through the same "parent" resource, and just have the "morning reset" remove all effects of that resource, while retaining the base increment for total slots.

 

CLAB applies Increment (1 << 8) or appropriate bit for each level, for each new spell "slot".

Each spell does casting-effect bitwise check (any one of):

  • "row stat 0xfffff1ff 10" = Can still cast after this spell (contains bit not in value)
  • "row stat 0xfffff1ff 6" = Cannot cast more after this spell, remove selection ability (doesn't contain bit not in value)

Casting spell applies (resource) to decrement (1 << 8), or appropriate bit for it's level.

Morning Reset removes effects by (resource), restores all selection abilities.

 

One thing about the "Set"/"Increment":

Some opcodes (such as modify proficiency) do not apply their "Increment" mode effects until all other effects in the stack have processed their checks, which is why the above bitwise check if the value is greater than "1", not "0" - decrementing the proficiency before the check would not make any difference.

(This behavior is dependent on the opcode used, but I believe it is exclusive to "Increment" modes, and that any "Set" modes are always instant).

Edited by kjeron
Link to comment

Huh. Using 321 to cancel the stat reductions makes a lot of sense. I don't remember why I was steering clear of that.

CLAB applies Increment (1 << 8) or appropriate bit for each level, for each new spell "slot".
Each spell does casting-effect bitwise check (any one of):

  • "row stat 0xfffff1ff 10" = Can still cast after this spell (contains bit not in value)
  • "row stat 0xfffff1ff 6" = Cannot cast more after this spell, remove selection ability (doesn't contain bit not in value)
Casting spell applies (resource) to decrement (1 << 8), or appropriate bit for it's level.
Morning Reset removes effects by (resource), restores all selection abilities.

 


But I'm not quite getting that bitwise check. Not least because, I don't know what "0xfffff1ff" is. I think it equates to... 4,294,963,711? Which is a full 4-byte dword minus 3585? I know I'm dense about this stuff, but the significance of that is going right over my head.

 

In any event I don't think that part is necessary. I don't need to remove casting ability by a stat check; all casting will be run through innate abilities, and the number of innate abilities representing each spell level should give you a visual indicator of how many "slots" you have at that level. So every 6 seconds an effect will 172 remove the innate, and then apply 171 adding the innate a number of times equal to (x << 8), where x is the current value of the stat in the relevant byte. As you cast spells, they will decrement the stat, and every six seconds the repeating effect will make sure the visual indicator will match the stat value. When you cast too many spells, there will be no 171 effect, and the innate ability will simply be gone.

 

Then the next morning the stat will be restored to its proper value, and within 6 seconds, you will gain a number of innate abilities matching that value. So, the effect that operates every 6 seconds will look like this:

Repeated spell:
172 - remove innate ability Z
326 - if stat bit-equal (1 << 8) then cast subspell A
326 - if stat bit-equal (2 << 8) then cast subspell A
326 - if stat bit-equal (3 << 8) then cast subspell A
326 - if stat bit-equal (4 << 8) then cast subspell A
326 - if stat bit-equal (5 << 8) then cast subspell A
326 - if stat bit-equal (6 << 8) then cast subspell A
326 - if stat bit-equal (7 << 8) then cast subspell A
326 - if stat bit-equal (8 << 8) then cast subspell A
 
Subspell A:
171 - give innate ability Z

I guess a lingering question in my mind is, if I'm using bit equality, shouldn't that be:

326 - if stat bit-equal (1 << 8) then cast subspell A
326 - if stat bit-equal (2 << 8) then cast subspell A
326 - if stat bit-equal (4 << 8) then cast subspell A
326 - if stat bit-equal (8 << 8) then cast subspell A
326 - if stat bit-equal (16 << 8) then cast subspell A
326 - if stat bit-equal (32 << 8) then cast subspell A
326 - if stat bit-equal (64 << 8) then cast subspell A
326 - if stat bit-equal (128 << 8) then cast subspell A

?

 

Or is it that, I can use the former, but it must use relation 10 (contains bit not in value) rather than relation 8 (binary match)?

Edited by subtledoctor
Link to comment

In that case: You can get more slots per stat if you store the slots as an integer rather than actual bits, using 4 bits you can get 15 spell slots (should be enough per level I think), so your first one would be best, using relation #7 (binary more or equal - contains all bits of value)

Repeated spell: (level 1)

  • 172 - remove innate ability Z
  • 326 - if stat bit more or equal (1 << 8) then cast subspell A
  • 326 - if stat bit more or equal (2 << 8) then cast subspell A
  • 326 - if stat bit more or equal (3 << 8) then cast subspell A
  • 326 - if stat bit more or equal (4 << 8) then cast subspell A
  • 326 - if stat bit more or equal (5 << 8) then cast subspell A
  • 326 - if stat bit more or equal (6 << 8) then cast subspell A
  • 326 - if stat bit more or equal (7 << 8) then cast subspell A
  • 326 - if stat bit more or equal (8 << 8) then cast subspell A
  • 326 - if stat bit more or equal (9 << 8) then cast subspell A
  • 326 - if stat bit more or equal (10 << 8) then cast subspell A
  • 326 - if stat bit more or equal (11 << 8) then cast subspell A
  • 326 - if stat bit more or equal (12 << 8) then cast subspell A
  • 326 - if stat bit more or equal (13 << 8) then cast subspell A
  • 326 - if stat bit more or equal (14 << 8) then cast subspell A
  • 326 - if stat bit more or equal (15 << 8) then cast subspell A

Subspell A:

  • 171 - give innate ability Z

Repeated spell: (level 2)

  • 172 - remove innate ability Z2
  • 326 - if stat bit more or equal (1 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (2 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (3 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (4 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (5 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (6 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (7 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (8 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (9 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (10 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (11 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (12 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (13 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (14 << 12) then cast subspell A2
  • 326 - if stat bit more or equal (15 << 12) then cast subspell A2

Subspell A2:

  • 171 - give innate ability Z2
Link to comment

Hmm, maybe someone can spot a problem here. I start out with a character with 3 effects increasing the prof by 65536; i.e. his proficiency is incremented by (3 << 16):

post-6306-0-87988300-1536775112_thumb.png

 

When I cast a 1st-level spells, it casts a subspell:

post-6306-0-45095200-1536775148_thumb.png

 

The subspell reduces the proficiency by (1 << 16):

post-6306-0-71773200-1536775182_thumb.png

 

Now, I have a spell running once per round which removes an innate ability, and then casts a subspell one or more times, depending on whether that proficiency is (1 << 16), (2 << 16), etc.:

post-6306-0-34148400-1536775306_thumb.png

post-6306-0-11738500-1536775318_thumb.png

 

That subspell adds the innate ability. So what should happen is, when I have (3 << 16) in the proficiency, and I cast a spell, it drops me to (2 << 16), and the next time the running spell takes effect, it will remove all instances of the innate ability and add two instances of it.

 

But what happens is, when I have 3 instances of the innate ability, after I cast a spell, it drops to only 1 instance, and stays there.

 

EDIT - and it really stays there - I can keep casting spells indefinitely, because the running effect keeps adding one instance of the innate ability each round. :(

 

EDIT 2 - could it have to do with the timing mode? Is this one of those things like opcode 0, where timing mode 1 is wonky? Should I switch everything to timing mode 9?

Edited by subtledoctor
Link to comment

Looks like the subspell adding the innates is removing them before adding the new one, resulting in there always being just "one".

That's intended - 171 can add a number of instances of an ability. Apply 171 referencing SPCL521 three times, and you'll be able to use Defensive Spin 3x per day. (Right?). Whereas, 172 can only remove the ability entirely.

 

So the running effect starts with 172, removing the ability altogether. Then it has ten 326 effects, checking for stat values from 1 to 10 witj RELATION 7. Each of those, if it returns true, casts a spell that applies 171 once. If my stat value is 2, it should remove the innate ability, then cast the 171 spell 2 times.

 

(Because, just so I'm clear: if (stat bit_g_e 2) returns true, then (stat bit_g_e 1) will also return true... right?)

Edited by subtledoctor
Link to comment

(Because, just so I'm clear: if (stat bit_g_e 2) returns true, then (stat bit_g_e 1) will also return true... right?)

No, I screwed that part up, but it can be fixed.

 

Make 4 subspells with Opcode 171:

one with 1x Opcode 171, one with 2x Opcode 171, one with 4x Opcode 171, one with 8x Opcode 171

 

Running spell applies:

Opcode 326: stat (1 << X) 8 subspell1

Opcode 326: stat (2 << X) 8 subspell2

Opcode 326: stat (4 << X) 8 subspell3

Opcode 326: stat (8 << X) 8 subspell4

Edited by kjeron
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...