Various 2.5 Beta Bugfixes | Patreon Weekly #275

Hey Patrons, in this weekly I’m going to go over some of the more interesting bugfixes that I’ve made during the v2.5 beta!

Also as a quick note, v2.5.0-RC-1 is going to be releasing soon, but unfortunately won’t be available on Google Play right away. BETA-5 has been help up in review for almost 4 days now, and there’s nothing I can really do about it but wait =S. This may impact v2.5.0’s full release on Google Play as well.

Bug Squashing

The beta for v2.5.0 is getting close to ending, and I hope to release early this week. One thing that’s always interesting to me when I run betas is the number of reports for bugs I get that end up having nothing to do with any new content. This does make sense of course, people are looking for bugs and the ones they find won’t necessarily be new, but sometimes it feels like betas are better for finding old bugs than new ones. v2.5.0 has been especially heavy in this regard, as the new catalog has entouraged a lot of players to use items or mechanics they otherwise wouldn’t. There’ve been a few dozen bugfixes made since the beta started, but for this weekly I thought I’d go over a few of the most interesting ones:

• Firstly a very simple bug: sometimes the new cursed wand lightning effect was managing to apply itself twice, including one report where a player managed to be killed by it twice and get two rankings entries! The way this effect works is that it applies itself to every character in a 3x3 AOE centered on the hero and then again on the target cell. If those two areas overlapped though, there was no logic to prevent the effect from applying to the same character twice. The fix is simply to build a list of affect characters (checking for duplicates) and then apply to everything on the list.

• Second, I got a report from a player that noticed an elastic spear was triggering ‘on ability kill’ effects (like lethal haste) from its spike ability even without killing an enemy. This was due to a previous fix, where sometimes the elastic enchant and spike knockback would mess with each other. As part of that fix I made a malformed ‘if statement’ that essentially read: “If the enemy is alive and hasn’t already been moved, perform spike knockback logic, otherwise perform on-kill logic.” The problem here of course is that this meant the on-kill logic would trigger if the enemy was just knocked back. The fix was to simply amend the ‘otherwise’ part of the statement to become an ‘otherwise if’, which checks if the enemy isn’t alive specifically.

• Third, an existing bug relating to sleeping enemy AI. A player noticed that if the hero was very stealthy (e.g. a Rogue with silent steps) then allies would also never wake enemies, unless the hero left the sleeping enemy’s FOV, then allies could wake them. This was to do with enemy targeting logic, which prefers to stick to the same target unless they are unreachable, out of view, or a closer potential target attacks them. This was applying while sleeping too, resulting in sleeping characters often only ever checking sleeping logic against the hero. I made two changes for this, firstly I amended sleeping logic to check all nearby potential enemies and use the closest, least stealthy one for sleeping logic. Then, as a compensation buff, I’ve let the shadow clone ally inherit the Rogue’s silent steps talent and I’ve tweaked flying characters (e.g. the ghost) to not wake enemies from a distance.

• And lastly, a real mind-bender: The hero would occasionally refuse to step on triggered traps for seemingly no reason. I actually discovered the fix for this one thanks to a video from someone who recently joined the Patreon. In the video the player moves into the door of a trap room by tapping just into the fog of war, throws an item to disarm a trap (to add it to the catalog), drinks a levitation potion, and then is unable to move onto the triggered trap to pick the item back up. I’ll be seriously impressed if anyone can think of why this might happen before reading the explanation. The cause for this one is actually related to some old logic I wrote to prevent heroes from walking onto visible traps just at the corner of the fog of war (where you could easily mistap on them). The variable for “Don’t let the hero step onto a trap” is set to yes/no whenever a movement action occurs, based on if the hero is going into the edge of the fog or not, but tapping onto an item to go and pick it up technically isn’t a movement action. So because of this, the variable previously set to ‘yes’ when tapping just beyond the door to enter the room, is not set to ‘no’, and the character refuses to move onto the disarmed trap to pick up the item! The fix for this is surprisingly simple, just reposition the variable assigning logic so that it happens before any hero action, not just movement.