Infernal King spawning multiple copies when using multiple

It actuaally can be, depending on the order things happen.

If IK1 dies, trait hits in, IK2 is spawned AND simultaneously checked for same event, thus snowballing over in an IK3.

If it is so, it could possible spawn 4 IK from a single one’s death.

Simillar mechanic to thief’s rising shadows after all, it kills one enemy, does the trait/talent check, snowballs to a 2nd enemy, etc, and ends up in killing whole team.

Ah I did forget that trait. I feel like this is the neighborhood of uncertainty where I believe it’s a bug that was left alone “because players like it” and now there’s a little shrapnel.

“Did a troop die” is a turn-based flag on either team IIRC, and more specifically it is, “In which slots did troops die?”. I imagine traits are checked when a new troop is summoned, and since an Infernal King has died in the same slot this turn, that trait can trigger twice. Interesting.

1 Like

I really don’t think it is as simple as “newly spawned Infernal King also gets to roll 25% odds to spawn another one”. I have played more than a few pet rescues against IK where it was the last remaining troop. If it could spawn more than one copy on death, I have to think I would have seen it happen by now.

Edit: is it a coincidence that both videos above show the IK double-spawning as part of a skull cascade following a player-initiated action? And that both skull hits were OHKOs?

3 Likes

Keep in mind some things my explanation implies, that the resurrect is a 25% chance, and that lately we have a lot of reasons to distrust the GoW’s RNG.

For my explanation to work, the IK that is summoned must be in the slot that the summoned IK will appear in. If, say, the IK you kill is in slot 3 and other slots are empty, I suspect the new IK will not trigger because it asks, “Did an Infernal King die in this specific slot on this specific turn?” You also have to win a 25% proc trigger, and to get more you have to win an even-less-probable multiple 25% proc trigger. (Bear in mind there are suspicious GoW RNG loves 0 and either 2 or 3 with a higher probability than it loves 1.)

That said I am open to the notion that this is more complex than my theory and perhaps it’s related to skull mechanics as you’ve pointed out! And I guess I’m cluttering up the thread oops.

I was dreading testing to see if I could recreate it without skulls since it took hours last time.

Got that first try :laughing:

So not skull related. No other summons. Bottom troop was a firebomb I ate to make room so no extra infernal king deaths.

A few possibilities busted there. Still dont know what causes it.

1 Like

Seems Slypendale’s theory is the most probable then.

You devoured IK in slot 3, that spawned a new IK in the SAME slot, slot 3.
As it was the same slot that the original IK died in, the trait check went over to the spawned IK as well, so IK1 (devoured) checked trait and spawned a IK2, that checked trait and spawned a IK3 as well.

Each video so far is similar in that purpose, the new IK is summoned in the same slot as the dead one (first slot in first 2 videos, 3rd slot in last one).
I suspect the multiple spawns will never happen if an last man standing IK is killed in last slot, as the new IK will spawn in slot 1 then.

Maybe people could test fighting vs 2 random troops + 2 IK, using spell based single target instakill teams (Bonnie Rose/Bronzelock pistol is the easiest I can come on, followed by Irongut), to try to kill first enemy and then the last IK, while leaving the middle troops untouched and excluding skull cascades. That would guarantee that a replacement IK will spawn in slot 1.

I know for a fact that a such situation never ever happed to me in pet rescues, where IK is always the last troop.

1 Like

Tested. Recreated the bug a few times but they were all spawned from a slot where another IK had previously died. Cant call it confirmed as the problem but it is looking more likely. I will run some more today to keep testing but I would say that this is the most likely candidate.

Edit - Recreated it a few more, always from a slot where another IK had died. Giving up testing.

You could probably reproduce the bug with Ubastet as well, since it kills two troops at once.

This is a lot of discussion for what clearly is a bug.
Infernal Kings Trait only applies to it’s self. No other Infernal Kings on the team.
Anyone who believes I’m wrong can start a different thread to debate it.
Shit like this needs to be fixed ASAP before it ruins a lot of people’s days during Guild Wars.
That being said, stop spamming this thread with your wrongness and leave the information to be as concise as possible for the devs to see and fix.
Those who feel you are trying to help the problem, are most likely doing the opposite. I tried saying that the nice way, it was ignored, so here’s the other way.

1 Like

AWR I appreciate you put a @Kafka mask on and quoted her but you’re not really Kafka. I appreciate your armchair modding but it would’ve been easier to do this if you wanted to get the thread back on topic:

Platform, device version and operating system:
Probably everything, but Switch might be behind and not have some part of this recipe.

Screenshot or image:
(See the above thread, there are several videos.)

What you were expecting to happen, and what actually happened:

If Infernal King dies, I expect it to resurrect itself with 25% probability.

However, if an Infernal King dies in, say, slot 1, it is capable of resurrecting itself twice. I suspect it is because the summoned troop checks its traits when it appears, notices “an Infernal King has died in this slot on this turn”, then incorrectly triggers as if it has died.

How often does this happen? When did it begin happening?

It happens about 6.25% of the time you create a scenario where:

  • Infernal King A is in the slot where a Summon would choose to put a troop if it were empty.
  • Infernal King A is killed.
  • Infernal King’s trait procs and summons Infernal King B.
  • Infernal King B’s trait procs.

Two of those steps rely on the RNG to kick in, so it can take many trials to create a success, this could be obscuring more ingredients for the recipe.

I don’t have enough information to determine if this has been a longstanding issue, the scenario has low probability and the most reliable IK fights in Explore don’t always end up in this state. Heightened player interest in Explore could’ve made it more likely someone discovers this, or some modification to the “which troops died in which slots this turn” data structures might have introduced it. git blame thatfile.cs.

Steps to make it happen again
I accidentally all that in the last section.

Happened to me on stream during my Guild Wars fight:

NSFW Language Warning (Start at 18 minutes, 23 seconds if the timestamp doesn’t work)

2 Likes

I’ve reported this to the team.

Please be civil.

1 Like

A perfect example of why somebody checking out if there are any bug reports every couple of weeks or so is a suboptimal approach.

:sweat_smile::man_facepalming::vulcan_salute:

Writing a bug report ticket for every bug report means that bugs go longer than 2 weeks without a response. At least here we can avoid a bulk of multiple reports and try to keep all the information in one place AND when something isn’t a bug try to inform everyone on the thread title to prevent further reports about non-bugs.

I know it’s not great, but I’m doing what I can here.

I encountered this 3 times today, twice in pet battles and once in guild wars. One infernal king respawned into two kings. Great to see in guild wars :stuck_out_tongue_winking_eye:

Happened to me in pet rescue twice.
Killed infernal king and instead of none I had suddenly two :face_with_raised_eyebrow: