Nice find. I also remember superskuj in the Water temple dungeon. The first block puzzle. He pushed the block and while it was moving picked up the upper jar (this is solvable with HM by simply placing a jar some more units aways from movable blocks). The block turned into the infinite-liftable jar, similar to here. Yes only those speedrunners are able to find hidden imperfections like that.

It's up to the supervisor if this will be addressed in the planned update.

the sign issue is a simple hm block that you cannot go into the wall and pick it from the right. Guess SePH can fix this in 30 seconds - thanks for reporting

As for the bosses... you are the only one of 30 beta testers who reported this problem, so for now I assume this to be "bad luck", a random glitch, where we have problems to fix (a bug needs to be 100% reproducable in order to fix, and as long we do not know the trigger, there's no chance...). If you know about something special you did during that fight that led to the bug, we can fix, otherwise not, I am afraid

I see, it's the underverse where both bosses appear together. Thought it was the dungeons and you had the problem separately with each boss on it's own. Well, an asm solution is difficult. Maybe Seph simply want to renounce on one boss... or leave it as it is. It appears difficult to run into this bug by defeating both bosses at exact the same time. Bad luck for you

LoL, what combinations are random players capable of finding: using Nimbus while during a boss fight and while lightning is on screen. I guess not even 20 beta testers could do something like that. And it should not delete the save in any case.

I actually said it once before: the best beta tester is the crowd, ie after you release the game, you wait for the thousand players to try to make all non-planed scenarios and then come up with the update.

This is great. Game Makr said it once that ASM is "just" some addings on the cake, while he meant the cake being the romhack. But now we can see without an ASM person a hackmaker could easily be in the dark, specially in situations such as this; since I believe you debugged hundreds of such problems.

I am playing on snes9x v1.54.1, that supports MSU-1.No idea if this is emulation error.

-Vaati: I had to use cheats for this one. After i kill a few of the swarms, they do the attack they usually do. spinning fast around it, but then they dissapeared. Vaati flew up, and then soon after, the remaining swarm re-appeared, and teleported onto me, right where Vaati is supposed to land, killing me. I was revived, Vaati was going fast, and its swarm was following it. I hit Vaati, Vaati jumped, swarm stayed in place, And then they teleported onto me again because of Vaati wanting to land on me. I got killed eventuaally again because of this. i refused this, and started to use rewinds.

-Eye boss: If i kill its little friends, and there is less than 4 remaining before the Eye starts chasing me, it will never start chasing me. Instead, it stops attacking for a while, then resumes with the lightning attacks.

If needed, i can make a video about these, but ill need to restart the game, since this happened a while ago, and i 100%'d it.

I don't think these are buggs, but the "spiced up" version of bosses, which use custom coding, thus some of the bosses might look bugged or seem to behave strangely, when in fact this is how there were programed. I believe the Helmasaur/Bowser went off screen eventually when on spiced up/hard mode if someone didn't know how to defeat him.

During the first boss fight in the "Bat Cave" I defeated half of the giant worm thing. The body was destroyed but the worm's head was still alive and moving and the door wouldn't open. The "killing blow" with this boss was a spin strike with the blue lightsabre. Included is a screenshot and the save file

Attachments

conker000.png You don't have permission to download attachments.(3 Kb) Downloaded 7 times

conker.zip You don't have permission to download attachments.(1 Kb) Downloaded 2 times

For some reasons in the bug triggered branch, $0F11 doesn't reach #$00, so the branch doesn't lead to $9D/DC16 (boss head explodes).The reason it won't branch there is that $0D81 is set to #$00 where $0b37 (another timer) is involved as far as I can say. I point Euclid here, as I wouldn't have an elegant solution. I could only try to hardcode it in dependence of boss health, room and so on... which might be cpu-time intense and bug affective...

Here's a geiger savestate which might help (I also included 2 trace logs (bugged and not bugged)- In the bug version $9D/EDCD A9 00 LDA #$00 $9D/EDCF 99 80 0D STA $0D80,y[$9D:0D81] is called too early, before $0F11 reaches #$00 ):

Armos knights share the same ram address area for a different reason - another reason why you shouldn't put two bosses in the same room, it's going to take some hardcore AI debugging to fix this.

Without going into extreme low level detail or the actual fix to fix it, what's happening at the moment is something else in the room (i.e. Armos Knight check sprite) is tripping the timer interrupting the head dying animation - thus the head don't die and continue to shuffle around. If you feel like seeing what's causing it, check for writes into that 0F11 address where it's not part of the worm dying animation countdown.

Not exactly a game-breaker, as the player should have tardis key to reset the room.