Good point. I will say that I lost about 6 observations because of my phone not correctly saving the screenshot, but all 6 showed the first (or only) troop frozen.
A few more for good measure. Because of the team I’m using, I frequently have Greed fully charged, so I can cast his spell and keep the turn. I’m doing this as much as possible to try to get the trait to trigger on a different troop, but it never does.
Likely stupid thought: is a new random number drawn between when the trait procs and when the target is selected? If the trait procs, you know the random number drawn was less than 0.25. If I were assigning equally-weighted probabilities to each troop slot, I would give slot 1 numbers between 0 and 0.25. Thus guaranteeing that any random number triggering the trait would fall in the first troop’s range.
#1. As suggested prior by others. Please turn “snap freeze” off on the talent tree.
#2. Please provide a video of it “working as intended”.
Seems only fair after the 100 times a video is requested to prove a bug exists… That in this case. Prove that it’s not bugged.
Since none of us players seem to be able to to reproduce the one single occurrence your tester managed to freeze a different troop, even after several thousand combined attempts, wouldn’t it make sense to approach this the other way around? Could you please ask your tester to reproduce this once more, posting a screenshot of the frozen state as well as team and class talents used? Maybe we can point out which part of the test might have caused a false positive.
@Kafka FYI. If it helps with repro testing, my frostmage class is currently at champion level 45 with the following talents selected:
All the battles above were played in casual or ranked PvP. I haven’t systematically tested other modes, but I’d be happy to if it would help.
Excuse the poor quality of the videos and no sound (I’ve never recorded anything before, so just used some random free software)
Here are three consecutively recoreded videos where I play as a Frostmage with Freeze Snap turned off:
You’ll notice that only ever the troop in first slot gets frozen. I can make a million more of these, but I hope this will be enough for now…
This was already brought up back when Frostmage was just released in October and, judging from what I read here, the situation now is exactly the same as when I test-played then (on painful 1x speed in order not to let things slip past) - Frostbite targets first filled slot.
Indeed. Either @Kafka’s testing team confused this bug to be about the talent Freeze Snap (which is working as intended), while it is about the trait Frostbite (which is definitely not doing what the trait description implies), or the tests have been done with some kind of debug version of the game where the bug has not sneaked in.
This bug occurs 100% of the time on the Steam/PC version.
Yes, this trait (Frostbite) looks to be incorrect in the game files. Will follow up with the devs on this privately.
Whatever hocus-pocus you used to figure this out, thank you Lyya
Could you also ping them about this bug?
The community did an amazing amount of research in that thread, documenting beyond the slightest doubt that the numbers are incorrect. Unfortunately, it got moved to Game Feedback to rot because it contained numbers, a dev with a basic grasp on statistics should easily be able to confirm the issue with the data provided.
To be honest, that’s very disturbing for me. As a software developer myself, I cannot imagine a situation when developers cannot look into their own source code while people outside can do that…
I suspect that it probably lead to nothing but… @Sirrian if you ever would read it - please look into your work processes. Something is definitely not right.
To be fair, a “dev” isn’t a “dev” isn’t a “dev”. It’s more like:
- Community manager does not have casual access to the game code.
- Community manager takes an external bug report, and passes it to an internal tester.
- Internal tester almost certainly does not have casual access to the game code.
- Internal tester cannot reproduce the bug, so informs community manager that it’s working correctly.
- Community manager reports to the community that the issue is working correctly.
At no step in that process did anyone “look into their source code” because the issue never made it into the hands of an engineer. If the internal tester had verified a bug, they would’ve passed it to an engineer who would’ve investigated within the code base…but in the given chain of events, that never happens.
As I said I made a video
1.17 gigs of a video
had to convert it and lower the resolution just so I can actually upload it today with my awful upload speed.
You owe me an hour of my life hahaha
video coming soon (youtube says)
Hey folks, got an update for you:
When this was originally reported in October we tested the game version at the time and weren’t able to reproduce the issue. Different Troops could be targeted randomly on this version - as intended. We requested more information from you so we could try to reproduce the scenario again to help pinpoint the exact problem. At this time the random targeting was set correctly.
Due to this more recent bug report being raised alongside other reports we’ve been trying to collect more information to retest again. Overnight, Lyya’s information was noticed by the coders and allowed them to quickly determine the exact issue and fix it.
We investigated with design and code and found that in between our tests in October and the report this week that the way the targeting works had become broken.
This issue should be fixed within a few days.
I apologise for not catching the issue when I first responded to this thread, it’s unusual for something that was originally working as intended to break between versions and not be reproducable on multiple game versions.