Fire interactions with weird dice

[jl8e]

Or: Things That Happen When Julian Wakes Up Early And Can't Get Back To Sleep

This is a for-the-future issue, but the existence of Dr. Lucky means we're going to have to address it at some point, or make hard rules that prevent the two from ever meeting. (And that's difficult, because there are skills that copy dice, swap dice between players, etc, etc.)

So, there are non-integral dice.

If you start thinking about the way they interact with Fire, you immediately get into questions like "how do you turn a fire die down half a side?" (Well, I did, anyway), and the only way out looks like just banning the weird interactions.

There's a better way to look at it, that makes everything work (except the code; that may have problems):

Fire dice don't care about values; they care about sides. (We may need to update the rules text to make this clear.)

That 19.5-sided die has 20 sides, it's just that one has a silly number on it and is half the size of the rest. If you turn it down once, it goes to the next lower side, 19. If you turn the 19 up, it goes to the next higher side. Either of these is one side as far as a Fire die cares.

This also answers the question of how non-linear dice should behave -- turn a wildcard showing joker down, and it shows an ace.

(And, if there were any question about it, how dice with a different minimum, like Fudge dice, would behave)

Implementation-wise, this is going to require changes to the fire code, but conceptually it's easy enough -- dice need a method to tell them to turn up or down N steps. The skill attack revisions needed to replace hit tables are going to require reworking the Fire code anyway.

(There is a related question for Wildcard dice: what to do if you want to turn it to a new side, and there are no cards left in the deck for that side, so everything has to be prepared for the possibility that the "adjust yourself" method could fail.)

[jl8e]

(There is a related question for Wildcard dice: what to do if you want to turn it to a new side, and there are no cards left in the deck for that side, so everything has to be prepared for the possibility that the "adjust yourself" method could fail.)

This problem is going to be hairy AF, unless we just allow WC dice to flip to cards not in the deck; I'm not at all sure it's reasonable to test for it in the attack verification because of the situation where there's only one card of a rank remaining, and you have to adjust two WC dice to the same value to make the attack work. (Exceedingly rare, requires Fire Wildcard dice, but it could happen.)

Just to elaborate on the scenario: This is, AFAIK, the only scenario where whether or not a die can do a thing depends on whether another die has already done the thing. To actually test for it properly at the stage where we're just figuring out whether an attack can happen requires the attack-testing code being able to save and restore the WC deck state so it can experimentally commit one die before checking that the other can still do the thing, and it Just Isn't Worth It. Better to have an emergency green suit (Hippogriffs -- there's a reason for that, but it's from a deeply obscure joke) available for the case where a WC thought it could be turned down or up, and it turned out to be wrong.

[TheOrgg]

Fire would be so much less messy if it just contributed value to an attack, period, without manipulating other dice values, and unbounded by the other dice's maximum printed value.

Since the community is the arbiter of the rules now, in effect, could we all talk about modifying Fire to adjust how the rule is overall? I've talked to the creator of the skill, and he wasn't that pleased with how the skill turned out in the end.

Since the original skill has so many issues, why not rebuild it mechanically from scratch, simplifying (and improving) it?

[jl8e]

Eh, the turning-down part would presumably still remain, and that's where many of the potential problems happen.

Functionally on-site, it mostly does just contribute to an attack, because manipulating specific dice is too big a nuisance for little effect.

[TheOrgg]

True, but the negative fire value element would be removed as Fire would only add to attacks, and the skill would be more powerful (but not significantly so due to the lack of Power Attacks). This'd also solve the Wildcard adjustment problem, too, as the Wildcard die itself wouldn't be adjusted, just the Fire die.

A Wildcard Fire, though, is an eventual fix that's currently going to simply treat the wildcard as a d20 for the purpose of Fire, Focus, and Shadow.

It would bring the skill into line with the site, which also seems to be a good thing to me. The site's implementation is what started giving me this idea in the first place.

As for the 19.5, Fudge, and other Nonlinear dice would function, I think you're right. The only time the 'what happens' question comes in then is what happens if we have a Fire Doubling Cube showing 64 contributing 23 to a Skill Attack? Does it turn down to the 32, or does the value change to 41-- a side that does not exist on the die? Similar to Fire contributing to a skill attack on a 19.5 die, though I think the intent there was partly to keep it safe from skill attacks.

For the 19.5 die, I'd be fine saying it couldn't be skill attacked. It's also likely to be the only fractional die, so I'd treat it almost as a skill itself. Really, that question is better asked when BSS is looking into implementing Dr. Lucky.

[jl8e]

As for the 19.5, Fudge, and other Nonlinear dice would function, I think you're right. The only time the 'what happens' question comes in then is what happens if we have a Fire Doubling Cube showing 64 contributing 23 to a Skill Attack? Does it turn down to the 32, or does the value change to 41-- a side that does not exist on the die? Similar to Fire contributing to a skill attack on a 19.5 die, though I think the intent there was partly to keep it safe from skill attacks.

The point of my post is that we've got a bad model of Fire, because all the currently extant dice have a 1:1 correspondence between sides and value.

If you turn down a doubling cube showing 64, you don't get to add 32, nor can you choose any value between 1 and 32. You get one side (up to five total if you turn it down all the way). That one side can turn a normal die up from 3 to 4, or Dr. Lucky from 19 to 19.5, or a Wildcard from Ace to Joker, or a doubling cube from 8 to 16. Each of those is one side, and when you think about it like that, most of the weirdness goes away.

[blackshadowshade]

I've chosen to deal with the Wildcard Fire problem by only allowing Wildcard to flip to a number in the deck (with reshuffle as required). I think that's reasonable.

[jl8e]

But does turning down a wc joker give you one side or six (seven?).

[blackshadowshade]

It gives you seven sides! (turn down to King)

[blackshadowshade]

The interesting thing that I'm dealing with at the moment is if you use a fire die to turn up a Wildcard Ace during a Power attack, you can currently (with the fixes) fire it up any value between 0 and 6.

I'm not sure whether we should be restricting this to firing up by either 0 or 6, but not any value in between.

[jl8e]

The interesting thing that I'm dealing with at the moment is if you use a fire die to turn up a Wildcard Ace during a Power attack, you can currently (with the fixes) fire it up any value between 0 and 6.

I'm not sure whether we should be restricting this to firing up by either 0 or 6, but not any value in between.

By the mechanics of fire dice, it should be strictly six.

However, that requires special-casing.

As described above, I think this is incorrect behavior, and we're gonna have to fix it eventually to make Dr. Lucky work, if nothing else.

However, as the "right" behavior requires non-trivial rewrites to the code, I'm inclined to say "this is good enough for now, document it and move on"

[PoshFrosh]

EDIT: i misunderstood how Fire works and there is no bug here. see this coglubi1 comment in this issue.

I think I encounted a Fire turndown bug, but I'm not sure. Also I'm not sure if it has to do with any of the skills on participating dice. I figured I'd post it here:

On the staging site in [game=444] I'm trying to skill attack and turn down the fire die to finish the attack. Here is what works and what doesn't:

1. bdIkw(1):1 and bgMt(1,1):2 attempt to skill attack Gq(8):7 results in "Attacking die values do not sum up to target die value." FAIL
2. bdIkw(1):1 and bDtp(5):1 attempt to skill attack Gq(8):7 results in "Attacking die values do not sum up to target die value." FAIL
3. bgMt(1,1):2 attempts to skill attack Gq(8):7 results in "Attacking die values do not sum up to target die value." FAIL
4. bDtp(5):1 attempts to skill attack Gq(8):7 results in "Attacking die values do not sum up to target die value." FAIL
5. bDtp(5):1 and bgMt(1,1):2 attempt to skill attack Gq(8):7 results in "PoshFrosh chose to perform a Skill attack using [bgMt(1,1):2,bDtp(5):1] against [Gq(8):7]; PoshFrosh must turn down fire dice to complete this attack." SUCCESS
6. bDtp(5):1 and bdIkw(1):1 and bgMt(1,1):2 attempt to skill attack Gq(8):7 results in "PoshFrosh chose to perform a Skill attack using [bdIkw(1):1,bgMt(1,1):2,bDtp(5):1] against [Gq(8):7]; PoshFrosh must turn down fire dice to complete this attack." SUCCESS

Four failures and two successes. However, I would expect the same result from all of those attempts (i.e. successes). And I wrong? Or is this bug?

EDIT: i misunderstood how Fire works and there is no bug here. see this coglubi1 comment in this issue.

[cgolubi1]

@PoshFrosh it'd be a good idea to screencap your game prior to the attack and post the screencap, so we can see the situation even if it has changed.

In particular, afaict the text you posted doesn't say what the available Fire dice are, and obviously that has a big impact on what fire-assisted attacks will be allowed.

[cgolubi1]

Update: looks like the fire die is bFpqw(9):9, so that should provide up to 8 points of potential fire support.

Looking at your list in more detail, this looks expected because of "Dice can never be increased or decreased outside their normal range" (from the Fire skill description). The way Fire works is that the points which are taken away from the bFpqw(9) die are (implicitly) added to one of the dice directly involved in the attack, so there needs to be room for those points on one or more of the dice directly involved in the attack.

In your case 1, for example, bdIkw(1):1 has 1 side and is already showing 1, and bgMt(1,1):2 has 2 sides and is already showing 2 --- neither of those dice has any room for any additional points to be assigned, so they can't be fire-assisted.

By contrast, bDtp(5):1 has 5 sides and is showing 1, so it can take up to 4 points of fire assistance. That's not enough for it to capture a die showing 7 on its own, but once it's joined by 2 or more sides from the other dice (as in your cases 5 and 6), it can get up to 7 with fire assistance.

So i think that explains what you saw, and there's no bug. LMK if i missed anything!

[PoshFrosh]

omg, i completely misunderstood how Fire works! Thanks, for the thorough explanation and sorry for taking your time!

[cgolubi1]

No apology needed; fire is confusing, and it's great that one more person now knows how it works! Thanks for writing up what you saw.

[PoshFrosh]

@cgolubi1 found a related but smaller (UI not functional) issue in the same game: i didn't screen capture it (oops), but i just saw the message that i could turn down my Fire do to "between 3 and 4" however, it would only accept "4". This is confusing for two reasons:

1. There is no integer between 3 and 4
2. There was only one option, so offering 3 is wrong

staging game 444 PoshFrosh chose to perform a Skill attack using [bdIkw(1):1,bgMt(1,1):2,bDtp(5):1,bdHv(0):0] against [Gq(8):7]; PoshFrosh must turn down fire dice to complete this attack PoshFrosh turned down fire dice: bFpqw(9) from 9 to 4; Defender Gq(8) recipe changed to Gqv(8), was captured; Defender q(8):3 was added; Attacker bdIkw(1) does not reroll; Attacker bgMt(1,1) rerolled 2 => 2; Attacker bDtp(5) rerolled 1 => 3; AttackerbdHv(0) changed size from 0 to 1 sides, recipe changed from `bdHv(0) to bdHv(1), rerolled 0 => 1

I would suggest that in this case the message should read that I must turn down my Fire die to 4 (or else cancel)

[TheOrgg]

Re-reading this thread... What happens if you turn down a F(C) to a number that four other Wildcard Dice have showing, thus there not being that integer in the deck at all to flip to?

[PoshFrosh]

Re-reading this thread... What happens if you turn down a F(C) to a number that four other Wildcard Dice have showing, thus there not being that integer in the deck at all to flip to?

I don't know the specific answer to this, but when skyhawkb and I tested in staging with multiple M(C) in one recipe, we discovered the deck has more than 2 jokers. My guess is that the card turn down works "good enough" but shows weird behavior in these edge cases. I haven't tested it, but I imagine that you could have 4 or 5 jokers showing... this would be easy to test with recipe 5x M(C)... so I imagine if that's the case, fire turn downs could also result in other instances of 5 of a kind showing. I just noticed I never opened an issue about this... I think it's only mentioned in the forum post linked above.

[scipiohaereticus]

@cgolubi1 found a related but smaller (UI not functional) issue in the same game: i didn't screen capture it (oops), but i just saw the message that i could turn down my Fire do to "between 3 and 4" however, it would only accept "4". This is confusing for two reasons:

1. There is no integer between 3 and 4

2. There was only one option, so offering 3 is wrong

staging game 444 PoshFrosh chose to perform a Skill attack using [bdIkw(1):1,bgMt(1,1):2,bDtp(5):1,bdHv(0):0] against [Gq(8):7]; PoshFrosh must turn down fire dice to complete this attack PoshFrosh turned down fire dice: bFpqw(9) from 9 to 4; Defender Gq(8) recipe changed to Gqv(8), was captured; Defender q(8):3 was added; Attacker bdIkw(1) does not reroll; Attacker bgMt(1,1) rerolled 2 => 2; Attacker bDtp(5) rerolled 1 => 3; AttackerbdHv(0) changed size from 0 to 1 sides, recipe changed from `bdHv(0) to bdHv(1), rerolled 0 => 1

I would suggest that in this case the message should read that I must turn down my Fire die to 4 (or else cancel)

I think the issue here is that you're misinterpreting the message. You're not turning it down to 3 or 4 but by 3 or 4. What surpises me more is that you turned it down to 4, so actually you turned it down by 5! This is actually a bug. Is it a known one? I've recreated the issue in Game 457 and I got the same result: I was prompted to turn down by 3 or 4, I turned it down by 5 and it worked.

[cgolubi1]

I'm not sure offhand what the authoritative issue for this is --- maybe #1803, but i'm not sure.

The root cause of all of these is that the UI does its own (low-quality) calculation of how much fire turndown is needed, because the API doesn't tell it. That's the problem to fix --- the API should report this and the UI should just display what it's told --- and with that fix, all the various specific inconsistencies should go away (to be replaced with a new set of inconsistencies if the UI isn't good at interpreting the API data, of course).

[blackshadowshade]

I'm pretty sure that when turning down a Fire Wildcard die showing a Joker, that it only has valid values showing in the dropdown to be selected. Test it, but I'm almost certain that I specifically dealt with that edge case.

[PoshFrosh]

After some testing on staging (games 463 and 464), it appears to me that turning down a Fire die does not count as that die "participate[ing] in / ever [being] part of / [being] used in any" attack. The behavior is so consistent that I figure it must be intentional, but figured I would ask. Is this behavior intentional?

Skills that do not "trigger" when turning down the fire die (which seems to contradict the rule sentence stated in parentheses): •FJ Jolt is NOT activavted during Fire turndown ("If a Jolt Die participates in an attack, then the player will take another turn and the Jolt die loses the Jolt skill.") •FG G is NOT lost when turning down using Fire ("If a Rage Die participates in an Attack, it loses its Rage ability...") •Fm m does NOT trigger on Fire turn down ("When a Morphing Die is used in any attack against a single target die, it changes size...") •Fv v does NOT affect the value of dice captured with Fire assisted attacks ("If a Value Die is ever part of an attack, all dice that are captured become Value Dice...") •Fn n does NOT affect the value of dice captured with Fire assisted attacks ("When a Null Die participates in any attack...")

1. If this is not intended bahavior, can someone let me know (to inform my button designing decisions).
2. If this is intended behavior, I suggest we change the skills text to reflect this behavior, either: a. an interaction text for each of these cases or more elegantly b. a note on the Fire skill that says "turning down a Fire die to assist a skill attack does not count as "participating in" an attack for the purpose of other skill descriptions.

[PoshFrosh]

Is this a fire / warrior interaction bug?

Game 503 on staging:

g(10):2 and `k(1) skill attack (10):8 hoping to add 5 from Fire die F(9,9):6 but staging site will not allow

2 + 1 + 5 = 8 and the 5 can be added to the g(10):2 without going over 10, so it should work, right?

I'm assuming this is related to "the UI does its own (low-quality) calculation of how much fire turndown is needed, because the API doesn't tell it" from this post above. I'm guessing that the warrior die isn't being considered in the math.

[cgolubi1]

I don't have time to take a look and come up with a different theory, but, no, that's not going to be a UI issue. How can you tell? A couple ways (if you're curious):

• The bug we've been describing about the calculation is literally just for the numbers the UI displays in the fire turndown display, i.e. the display you get to when once the fire-assisted attack has been provisionally allowed. You're not getting that far.
• In general, the UI doesn't get involved in whether attacks are likely to be valid. It just passes what you asked to do to the backend via an API called submitTurn, and reports what the backend tells it about how that went. Attack logic is really hard, so if the UI did have pre-attack opinions (beyond really really simple things like "unless you're passing, you should have more than zero attacking and defending dice), it would break things all the time, especially since we don't have automated large-scale random-action-based testing of the UI the way we do of the backend.
• This isn't at all universally true, but most red messages are constructed by the backend and the UI just displays them, so it's a reasonable first guess that a given message you see is probably from the backend.
• If you want to know for sure, search the code (under src/, not test/, since the latter is just the tests and thus more ambiguous). If the message text is defined under src/ in a file ending in .php, it's from the backend. If it's defined in a file ending in .js, it's from the UI. In this case: https://github.com/buttonmen-dev/buttonmen/blob/054a722c1dc57c1abad3d673ba97351c2c1f9710/src/engine/BMAttackSkill.php#L309

[cgolubi1]

All of that said: yes, that attack looks valid to me too. So it does seem like a bug.

[PoshFrosh]

Thanks for the detailed explanation. That all makes sense. Ok, so it's a new and different bug. I tried to create a simpler case in another game, but I couldn't because it worked as expected. So there's something special about the bug in game 503 I mention above. Not sure what it is. Unfortunately, I didn't leave the game in that state.

[cgolubi1]

Oh, wait, i wasn't paying enough attention. That's not a bug. You need 5 sides of fire support, but twin dice can't show 1 (because each die rolls individually and has its own minimum of 1). So your F(9,9):6 can only be turned down to 2, so it can only contribute 4. Sorry, i should have caught that.

[TheOrgg]

Posh and I were just talking on the main site about how bad twin Stinger dice felt.

Feel bad about them yet, Posh?

[PoshFrosh]

It must be dozens of times I've made this mistake in the past few weeks. I always think of the benefits of twin and forget this drawback. Yes TheOrgg Twin Fire and Twin stinger feel bad to me. But devious once commented that dg(2,2) is "cleverly awkward".

[PoshFrosh]

Ok, I found another fun one. For some reason I tried to capture a (1) using a (1) and a k(1) and it thinks I can complete the attack by "adding" -1 from Fire Game 705 on staging. i haven't yet proceeded beyond this screen

NEVERMIND! I guess I'm still learning Fire dice. as chaos pointed out, this is valid: "the other fire die (noBFb(11)) fires %mgF(11) up to 2, and konstant is treated as negative in this attack such that 2 - 1 = 1. there's no reason that can't happen afaik."

[blackshadowshade]

Yeah, that's issue #2726 rearing its head again.

[PoshFrosh]

Ok, new Fire issue today. Wrong value showing after Fire turndown on a Twin Die.

If I turn down a FM() I expect the Fire turndown value to show, not the maximum value. I confirmed this with a simple example: "PoshFrosh chose to perform a Power attack using [g(4):1] against [(4):2]; PoshFrosh must turn down fire dice to complete this attack" (I also checked this using a skill attack and it functioned identically). "PoshFrosh turned down fire dice: FM(11) from 11 to 10; Defender (4) was captured; Attacker g(4) rerolled 1 => 3" And the FM(11) shows "10" Everything checks out.

But while testing my Fanatic I encountered this oddity: "PoshFrosh chose to perform a Skill attack using [Fmg(11):8,Fmg(11):7] against [(20):20]; PoshFrosh must turn down fire dice to complete this attack" "PoshFrosh turned down fire dice: FMInbJ(11,11) from 22 to 17..." But the die still shows "22" in the graphic, not "17" 😕 EDIT: I did further testing to determine which additional skill is causing the bug and finally discovered that: this bug is caused by the presence of the twin skill, see comment below (https://github.com/buttonmen-dev/buttonmen/issues/2744#issuecomment-2368806377)

[PoshFrosh]

I figured out the above. It's the twin die causing it! Log: "PoshFrosh chose to perform a Skill attack using [g(4):4,g(4):2,g(4):2] against [(10):9]; PoshFrosh must turn down fire dice to complete this attack" Log: "PoshFrosh turned down fire dice: FM(11,11) from 22 to 21; Defender (10) was captured; Attacker g(4) rerolled 4 => 4; Attacker g(4) rerolled 2 => 1; Attacker g(4) rerolled 2 => 2" But the final twin die value is incorrect, still showing 22.

In short, it appears to be a twin+maximum+Fire bug FM(11) turndowns work properly, but FM(11,11) turndowns incorrectly retain the maximum value

So I'm thinking we need a responder test for:

FM(10,10) performs fire turndown

to see why the twin die is precenting the Maximum Fire die from showing the proper final value