Will that include the MKT variant for his MK2 self?

Didn't Juano16 and Mike Obrecht already have animation numbers for these? I shared a download file for Juano16's fatality compatibility numbers and Mike Obrecht's MK characters have a readme with the animation numbers for his MK fatalities.

About these, with the bisection fatality animations one can use the same standards as Darkstalkers/Clayfighter with Bishamon by B-Kun for more compatibility with other characters and to keep the animation list short. The decapitation standards are pretty valid though, as is the torso held as trophy standard. I’ve also started to wonder if SamSho standards exist for the fatalities from those games?

Also you can use MKT sprites for 7696 (shocked), as well as Survival Arts having sprites for 88500 (Burning) for digitized characters like Cage there.

About the normal/special reactions, those are pretty valid, but MK also has a sweep/trip standard also used in SF2. The fatalities a bit less so,  one can use 7780 (the Sangue=Passare standard) for Kitana and Shang’s fatalities.

So you are moving the stage elements around via ModifyBGCtrl?

I did that for all my old MK interactive stages and the MKvsSF stage. It was a hassle because you have to fake the deltas instead of using actual camerawork.

You have a Discord contact?

Really nice! You doing this via AttachedChars?

Welcome to our exclusive club!

I've been working a true stage transition system, not just via ModifyBGCtrl, but the camera still misbehaves after the transitions.

Or maybe you offset the entire second stage by the camera position in the first stage.

I figured out the problem, it's a rounding error that happens on characters with big enough horizontal localcoord on MUGEN. It seems characters with horizontal localcoord of at least 720 from my experiments experience this issue when returning values from fall.envshake.ampl.

It's probably that Mugen does the localcoord conversion then rounds the result down because the amplitude must be an integer. So 56 becomes 55. Maybe you can use a var that's a float? Like frequency?

Edit: On second thought that will probably have the same issues since you still need to round the result yourself.

Tried Mugen 1.0, 1.1 and Ikemen GO and they all seemed to work correctly.

Example:

fall.envshake.ampl = ID

[State set speed]
type = velset
triggerall = PlayerID(GetHitVar(fall.envshake.ampl)), var(50) = 0
trigger1 = time = 0
x = (2 + ((random/999.0) * 1.0))*PlayerID(GetHitVar(fall.envshake.ampl)), fvar(10) ;2 plus a number between 0 and 1 added at random
y = -7*PlayerID(GetHitVar(fall.envshake.ampl)), fvar(11)

It looks like the chars are too close to the bottom of the screen, even when compared to MKII. Especially in 4:3 where you have more room to play with.

EDIT: The parallax slides a bit and the shadows can be projected on the sky if chars jump high enough, but I didn't check MK2 to see what it does.
I'm personally not a fan of making the playable area (screenleft and screenright) smaller than Mugen standards, but I can see why you'd do it and it's easy enough to change.

Wait, it should? Other MK characters for normal MUGEN like those of Pneophen (including Juano16's MK2 Ninjas) and OMEGAPSYCHO don't add "D" (downed, i.e. when the opponent is in LieDown states) to their sweep attack's hitflag. Are you playing with Mike Obrecht's characters whose sweep attack can hit lying down opponents?

In Ultimate Mortal Kombat Trilogy romhack, MK2 Jade is still hit by Stryker's gun despite she is being immune to projectiles. If the player IS the projectile itself, this would cause some problems [...]

For uppercut's hitboxes, I will fix that one, even though it is not supposed to hit crouching opponents in original UMK3. For high punch/jab and high kick hurtboxes, I'll probably fix that one in some kind by decreasing their size (if that doesn't work, probably remove the hurtboxes).

2D Mortal Kombat games used blood instead of hitsparks, so only shortening the hitpauses will work.

I found another issue, the opponent's fatality compatibility sprites are the wrong size if the opponent's xscale and yscale values are anything below or above 1.