In Progress Bug fixes

tauKhan

Smash Lord
Joined
Feb 9, 2014
Messages
1,347
#1
Thread purpose: Archive for game mechanic glitch fix (and related) codes.

Code:
$Freeze glitch fix (v1.02) [tauKhan]
041239A8 60000000
Code:
$Invisible ceiling glitch fix (v1.02) [tauKhan]
0406BB14 D01D0004
I'll be adding more codes down the line.
 
Joined
Nov 9, 2014
Messages
665
#3
Code:
$Fix Samus Extender Crash [UnclePunch]
*Disables extender grab box from appearing on problematic frames
042b9d28 48000078
https://gfycat.com/BlondIlliterateBedbug

Activating the extender grab box on frame 39 of dash grab and frame 74 of standing grab cause the grab box to not be terminated. This results in a 10 frame window and 1 frame window (respectively) where the grapple object is despawned, but the grab box is still active. If a player gets grabbed by Samus during these frames, a nullified pointer to the grapple object is referenced and the game crashes. This code prevents the extender from being activated on these problematic frames.
 

tauKhan

Smash Lord
Joined
Feb 9, 2014
Messages
1,347
#4
Code:
$Update TopN Location In ECB Calculation [tauKhan]
C204250C 00000009
7C7F1B78 7C9E2378
807F0000 80830028
8063002C 800300B0
90040038 800300B4
9004003C 800300B8
90040040 7C832378
3D808037 618C32E8
7D8903A6 4E800421
7FE3FB78 00000000
In some cases, for example when a character gets caught in a grab, Melee warps characters position and performs environment collision tests without updating TopN position ("model's location"). That means the ECB is calculated as if the model was in a different place than it really was, which means it won't really line with the animation and can allow weird looking "stage clips".

GALE01-2385.png


The code fixes the issue by manually updating TopN location right before ECB corner calculation
GALE01-2386.png
 
Joined
Nov 9, 2014
Messages
665
#8
Code:
$Break the Targets Intangibility Glitch Fix [UnclePunch]
*Fixes glitch that causes player to not receive intangibility after quitting Adventure Mode while the stage was transformed
C21B65AC 00000005
9003000C 3C608046
6063B488 388001C0
3D808000 618CC160
7D8903A6 4E800421
60000000 00000000
Explanation:
Code:
In the "EnterState_Damage" function, everytime a player takes knockback:

-checks "is1PMode" bool in match struct (prevents this from happening in VS mode)
    -checks isStageTransformed bool in AdventureStage struct (this isnt initialized in any mode other than Adventure Mode, Event Mode, and All Star Mode, so it uses the previous value in BtT)
        -checks if the damaged player is the only player created
            -gives player intangibility for the entire duration of knockback+tumble+downbound+downpassive
            -queues up 90 frames of intangibility that start when entering tech/techroll/getup/getuproll/getupattack
 
Last edited:

tauKhan

Smash Lord
Joined
Feb 9, 2014
Messages
1,347
#9
Code:
$Box Glitch Fix [tauKhan]
0404C98C 41800090
C204C988 00000004
98030034 C00285C4
FC030040 C00285F0
40800008 D0430008
60000000 00000000

Box glitch is an interesting collision detection glitch where a character becomes trapped "between" a floor, and a ceiling that is below that floor, unable to move vertically from the floor. The glitch occurs once a character comes into contact with such a floor and a ceiling simultaneously. Once the simultaneous contacts have been made, the ECB top corner of the character gets pushed below the ceiling while the character is placed above the floor.

To understand why that happens, one needs to look at a concept I've dubbed "ECB Squeezing":

GALE01-3253.png


When a character is in a tight gap between a ceiling and a floor, such that contact is made with both, the game needs to make a choice on how to act. The collisions have opposing effects: the floor collision would push the character through the ceiling, while the ceiling collision would push the character through the floor. The solution Melee chooses in the instance is to place the character where the floor collision would leave it. By itself that would cause the ECB to clip through the ceiling. That is unwanted as it would allow the character to jump through the ceiling, for instance. So in addition, the game squeezes the ECB to fit into the gap, by lowering the ECB top corner to below the ceiling. (as visible in the picture)

The ECB squeezing always happens once a simultaneous floor and ceiling contacts occur. Thus the ECB top is lowered under the contacted ceiling even when that ceiling is below the contacted floor. ECB top being placed below a ceiling under a floor creates a state that fuels itself: The ECB tries to regain it's normal shape with ECB top attempting to return to it's normal elevation. That of course causes a ceiling contact, as the ECB top was just below a ceiling previously. The ceiling contact negates any possible upward movement, and also causes a downward displacement. Naturally that downward displacement leads to a floor contact, as the character (and it's ECB bottom) was just above floor previously. The floor contact negates any downward movement. And, both floor and ceiling contacts were made simultaneously, and thus the ECB top squeezes to below the ceiling once again, completing a loop.

The code fixes the glitch by adding a special case to the ECB squeezing function (The function is located at 0x8004C91C in NTSC 1.02): ECB corner changes are skipped if and only if the contacted ceiling was below the floor. Then, a simultaneous contact with a floor and a ceiling below that floor simply lead to the character being moved onto the floor.


The omission of that special case in Melee is understandable, as the requirements of contacting both a ceiling and a floor at the same time would appear to be contradictory. Contacting a floor requires a line from previous ECB bottom to current ECB bottom to go through a floor. Hitting a ceiling in turn requires ECB top to cross the ceiling in same manner from below. ECB top is (without squeezing) always above ECB bottom, so it seems impossible to have the lower ECB bottom move down through higher boundary, while the higher ECB top moves through the lower boundary.

The secret to initiating the box glitch lies in a third simultaneous contact: if a character moves from above a floor, then collides with a wall that's facing a ceiling below the floor, then the char can hit both the ceiling and the floor at once.

gotstuck1.png


The main collision logic function looks for wall contacts first. Then as it detects a contact on a wall, it'll determine a new target destination for the character, where the characters ECB would no longer clip through its surroundings. This is where a ceiling contact is noticed, and the target destination is set low enough that the ECB top would fit exactly under the ceiling.

All of that is done before floor contact is checked. Since the previous ECB bottom was above the floor, and the current one is below, a floor contact is still made.
gotstuck2.png


gotstuck3.png


Since both floor and ceiling contacts were made, the game proceeds as if the character is between a ceiling and a floor. The character is placed above the floor, and the ECB top is lowered below the ceiling, initiating the box glitch.

It is also possible to trigger box glitch from the opposite direction, by moving up through a ceiling to on top of a floor above that ceiling, and hitting a wall that's connected to the floor. That version works pretty much exactly same as moving down below a ceiling: the wall contact makes the game detect a floor below the character, in that case. Ceiling collision detection also happens after the wall collision, thus that works the same way.
 
Last edited:

Punkline

Dr. Frankenstack
Premium
Joined
May 15, 2015
Messages
406
#10
T tauKhan Thanks for going into detail to illustrate the cause; I’ve never studied the ECB detection mechanics very closely, but I've been curious about this ever since I first heard about the bug. What an interesting freak case of conflicting corrections. Great work sniffing out the conditional details!
 

BXBX

Smash Cadet
Joined
Nov 25, 2018
Messages
44
#11
This is great work. I don't understand why these fixes have not become standard yet. Have you considered fixing port priority related things for more consistency? Like having identical start times for every port at the beginning of the match (and fixing which ports can drop through platforms), making grabs on the same frame clank or something. And I think it also affects ledge grabbing at identical frames (maybe make both players miss the ledge) and have consistent throw frame data.
 
Top Bottom