Doppelganger + Radioactive logging bug

[irilyth]

When a Doppelganger die captures a Radioactive die with a Power Attack, the log says e.g.

irilyth performed Power attack using [tD(4):4] against [%Ho(1,6):3]; Defender %Ho(1,6) was captured; Attacker tD(4) showing 4 changed to Ho(1,6), which then split into: Ho(1,3) which grew into Ho(2,4) showing 5, and Ho(0,3) which grew into Ho(1,4) showing 2

The "changed to Ho(1,6)" part seems like it should say "changed to %Ho(1,6)", because the die hasn't split yet.

[PoshFrosh]

Observed behavior: "PoshFrosh performed Power attack using [%bDtp(10):1] against [(V=6):1]; Defender (V=6) was captured; Attacker %bDtp(10) showing 1 changed to bDtp(10), which then split into: (V=6) showing 2, and bDtp(5) showing 1" in short: the %D spilt into two dice, one which is like a normal decay product, and another which copies the target exactly

Expected behavior (see skill text below): for the %bDtp(10) to first decay into bDtp(5) and bDtp(5), then for both of those dice to be replaced with (6) and (6)

Skill text: "Interaction with Doppelganger: Dice with both Radioactive and Doppelganger first decay, then each of the "decay products" are replaced by exact copies of the die they captured"

Even if I'm slightly misinterpreting the skill text, the observed behavior seems wildly inconsistent with it. It looks to me like I end up with one decay product, and one copy. So it appears that either this is a bug or the skill text needs to be changed. (although I hope it is the former).

I'm planning to use the %D combo in my fanatic, which is how I uncovered this behavior while testing recipes.

[game=444] on staging

Here is a second example in the same game: PoshFrosh performed Power attack using [%bBDMv(22):22] against [(30):10]; Defender (30) recipe changed to v(30), was captured; Attacker %bBDMv(22) showing 22 changed to bBDMv(22), which then split into: (30) showing 13, and bBDMv(11) showing 11

Note: this case is different from the example irilyth posted in this issue because in my example % and D are on the same die, while in his example % is in the target die.

[blackshadowshade]

If you could generate a minimal example for this (i.e., with a minimally complicated recipe), that would be lovely.

[PoshFrosh]

Gladly! Here ya go:

Staging Game 460

Result of a %D attacking an unskilled die: PoshFrosh performed Power attack using [%D(20):7] against [(X=19):7]; Defender (X=19) was captured; Attacker %D(20) showing 7 changed to D(20), which then split into: (X=19) showing 1, and D(10) showing 8

Observed behavior: split into (19) and D(10)

Expected behavior (by my interpretation of the skill text): split into (19) and (19)

[blackshadowshade]

Many thanks! That's easy enough for us to build into our test suite.

@cgolubi1, when you have the opportunity, if you could build a responder test for this, that will let me fix this bug once and for all.

[blackshadowshade]

Just an addendum: I think we've probably got two test cases here, one is irilyth's, the other is PoshFrosh's.

[PoshFrosh]

PLEASE IGNORE. THIS POST IS INACCURATE

I got a new bahavior. This time the %D die didn't split at all when using C in game 495 on staging:

PoshFrosh performed Power attack using [%D(C):8C] against [(20):4]; Defender (20) was captured; Attacker %D(C) changed size from Wildcard to 20 sides, recipe changed from %D(C) to (20), rerolled 8C => 15.

Observed behavior: Became a single (20) die

Expected behavior (by my interpretation of the skill text): split into two (20) dice

This is different from the behavior I posted above where it splits into two different dice intstead of two identical dice. (And let's not forget irilyth's third issue at the very top).

In this instance, it appears the D triggers, but the % does not. And it appears that the Wildcard may be causing it. So this is some new information for use in troubleshooting this bug.

@blackshadowshade perhaps it makes sense to also create responder test for %D(C) power attacks (20) what do you think?

PLEASE IGNORE. THIS POST IS INACCURATE

[blackshadowshade]

Sure, when we have a bug, the standard way of fixing it is to lock in the desired behaviour with a responder test.

[PoshFrosh]

I got a new bahavior. This time the %D die didn't split at all when using C in game 495 on staging:

PoshFrosh performed Power attack using [%D(C):8C] against [(20):4]; Defender (20) was captured; Attacker %D(C) changed size from Wildcard to 20 sides, recipe changed from %D(C) to (20), rerolled 8C => 15.

Observed behavior: Became a single (20) die

Expected behavior (by my interpretation of the skill text): split into two (20) dice

This last line is incorrect. And it makes my entire post above incorrect.

Let's follow the skill text step by step: "Interaction with Radioactive: Dice with both Radioactive and Doppelganger first decay, then each of the 'decay products' are replaced by exact copies of the die they captured"

Step 1: "first decay" should not happen So, a %D(C) cannot decay because wildcards do not shrink, grow, or split.

Step 2: "decay products are replaced..." In this case, the split never happened, so the decay products would just be the original die. This original die is replaced with a (20).

So, I think the result is actually correct and does not need to be fixed. @blackshadowshade and anyone else: tl;dr ignore my wildcard example. only my original example using regular dice in this post is unexpected behavior.

[cgolubi1]

Okay, so to sum up, the only currently-active issue here is the original logging bug (because the behavior PoshFrosh saw was actually an expected outcome of having a wildcard die - good catch there!)

[PoshFrosh]

Okay, so to sum up, the only currently-active issue here is the original logging bug (because the behavior PoshFrosh saw was actually an expected outcome of having a wildcard die - good catch there!)

@cgolubi1 Nope, there is still a second issue. This post: https://github.com/buttonmen-dev/buttonmen/issues/2240#issuecomment-2218050778 is still relevant and needs a responder test, thanks.