Thanks for your feedback, I have fixed it according to your suggestion.

In the Nightly build these will show up as faded red.

[State 220, StateTypeSet: Idle]
type = StateTypeSet
trigger1 = AnimElemTime(4) >= 0
moveType = I

<===== 09/13/2024 =====>
   * Various small code changes/fixes/refactoring;
   * Slightly adjusted the vertical air velocity of Rapid Charge's target as it was whiffing some characters I tested;
   * Updated Tia's AI to use more the mechanic of Just Defended;
   * Counter and Super/DreamCancel texts, and MAX Mode Bars position values adjusted to Sh1nRa358's positioning method (https://mugenguild.com/forum/msg.2560827).

<===== 09/13/2024 =====>
   * Various small code changes/fixes/refactoring;
   * Edited going-down Nerichagi to be a overhead;
   * Updated Yungmie's AI to combo with her Light Normals a little better when she's close to her opponent;
   * Updated Yungmie's AI to use more the mechanic of Just Defended;
   * Counter and Super/DreamCancel texts, and MAX Mode Bars position values adjusted to Sh1nRa358's positioning method (https://mugenguild.com/forum/msg.2560827).

ceil((-ScreenPos Y)+(((GameHeight*0.4125)))))

Ceil(GameHeight*(99/240.0) - ScreenPos Y)

You can use it anywhere that you use pos x, pos y, offset x, offset y. When calling helpers, postype doesnt matter because you're going to have this in the helper to move it to your desired position. for explods, you're gonna use space = screen since that is the new standard.

It worked a little differently and kinda seemed like it was shifting a little during stagezoom (minus the .0 and the abs part) compared to using the multipy/decimal numbers. But the multiplication seemed to lock it in place just right. So does adding that .0 fix that shifting?

The thing about adding the direct 320.0 is that you will remove part of the self adapting part. What if a character was innately coded in another localcoord and it not be 320.0 or what if we figure out the self adapting velsets and we can freely change the localcoords to a higher rez at will? Then we wouldnt be able to because we have 320.0 listed. I tried to make it so you wouldnt have anymore numbers to inject making the process longer.

Edit: This seems to suffice without having to use calculator:

Code:

Ceil(GameWidth * Abs(20/GameWidth  - (TeamSide = 2)) - ScreenPos X)

Shweet!

What would your shortened solution for Y be so you wouldnt have to use calculator on Y?

ceil((-ScreenPos Y)+(((GameHeight*0.4125)))))

And for your x solution, what if you wanted to elevate a particular teamside to a diff level aka, make your presentation shake on gethit for example, and not have both sides do it at the same time if one didnt get hit (since teamsides arent separated by the ifelse anymore and assuming one is doing common1 coding for every roster member)?

Ceil(GameWidth * Abs(20/GameWidth  - (TeamSide = 2)) - ScreenPos X + (Root, GetHitVar(HitShakeTime) > 0)*(1-(GameTime%2)*2))

IfElse((teamside = 1), ceil((-ScreenPos X)+((GameWidth * 0.0625))), ceil((-ScreenPos X)+((GameWidth)-(GameWidth * 0.0625)))) 

Ceil(GameWidth * Abs(20/320.0 - (TeamSide = 2)) - ScreenPos X)