SUBLIME TO GOD
A tutorial mini-site by Choon_2i
Based roughly on "Simply FPU" by Raymond Filiatreault

Chap. 3
The 7 Defensive Commandments
CONTENTS
A Primer
Com. 1 You Will Only Generate Player Helpers.
Com. 2 You Will Liberally Use IgnoreHitPause.
Com. 3 You Will Indiscriminately Manage Your Life.
Com. 4 You Will Control the Flow of the Game.
Com. 5 You Will Be Immune to Stopping Time.
Com. 6 You Will Never Be Thrown.
Com. 7 You Will Judiciously Manage Your State.

A Primer

Why is this before Instant Death? Because not losing is arguably just as important as defeating an opponent[citation needed]. In addition, knowing about these methods in advance will allow you to both account for them in your own design and implement them early enough to not have to stress about it later.
Most commandments have their exceptions, which will be listed.

You Will Only Generate Player Helpers.

Without helpertype=player, helpers are effectively left helpless to any sort of throw that they may happen to be in, which happens more often than you’d think. The important part is them accessing Def -2, which is always active if it is specified and will allow them to escape throws.
Failing to do this and properly defend with liberal SelfState usage can and will result in various bugs or, of course, dying at random. There are only a few things※Namely the fact that player helpers have are ScreenBound by default and can die, outside of obviously reading Defs -3 and -2. that need to be accounted for when generating a player helper by comparison.

While, if you know that you will only ever be put on the P1 side※In other words, you’ll crash if you don’t., using normal helpers is acceptable for the sake of reducing lag, you do so at your own risk, as certain Null-tier opponents can throw helpers.

You Will Liberally Use IgnoreHitPause.

This is especially true with throw escapes, and should be fairly self-explanatory. If it’s something important, you should be able to use it at all times.
Without ignorehitpause, any ReversalDef suddenly becomes a threat, which can lead to your character’s untimely demise. While it may seem tempting to simply forgo HitDefs entirely, this is actually a detriment versus certain opponents※In fact, having your character be reversed in order to deal damage is common enough to be referred to as 雷神耐性 (Raijin Resistance), named after edits such as R-Masamune and R-Akatsuki..

In certain cases, you can get away with excluding ignorehitpause, namely if you want something to only occur when you don’t have hitpausetime (like executing something that acquires it, or something that explicitly asks for not having it), but these applications are few. If you know for sure that you won’t have hitpausetime※Like removing hitpausetime before branching to a state, you can also exclude it.

You Will Indiscriminately Manage Your Life.

Whether some random YouTuber decides to hit the F1 key on your character, you’re fighting a low Null-tier character※Remember, Donald Period is one of these. %n F1 is a very common “gotcha” in older edits., or you need to defend against Marking to some extent, if you don’t have life management, there is a very high possibility for countless unintended effects, like dying[citation needed].
Therefore, it’s important to have at least one LifeSet in -2. The exact value is up to you, whether it’s something related to gametime or random※Be mindful that the % operator can return 0., simply setting it to lifemax, or changing it depending on the situation.

Unlike most other commandments here, there is no exception to this. You should always manage your life as long as the F1 key is present on a user’s keyboard.

You Will Control the Flow of the Game.

When you’re trying to defeat an opponent, constant NoKO usage will be the bane of your existence. Constantly using it yourself will have the same effect. This is where the word “tactically” comes into play; you obviously don’t want to die by accident to Null-tier opponents, but you also want to make sure that your opponent can still die.

Typically, NoKO is used by a helper in one of the final slots or a helper that spawns from another helper for this purpose. The most common use case is something like the below:

[State ########]
type = AssertSpecial
triggerall = isHelper(########)
triggerall = enemy,alive        ;We can accept a DKO if we need to.
trigger1 = !root,alive          ;If we just died, don't go to RS=3.
trigger2 = loseKO               ;Even if we've revived, we still need to use NoKO.
flag = NoKO
ignorehitpause = 1

This isn’t to say that the body shouldn’t use NoKO at all. In fact, there are some cases where it’s beneficial to do so. Namely to prevent the body from accidentally dying, like the below:

[State -2]
type = AssertSpecial
triggerall = !isHelper
triggerall = alive && hitpausetime < 1 ;We won't die to this if HPT>0.
trigger1 = life < 1                    ;Put this after life management (RS=3/Max Tampering).
trigger2 = movetype = H
trigger2 = life-gethitvar(damage) < 1  ;Don't die to damage calcs!
flag = NoKO
ignorehitpause = 1※Since you found this, as a bonus challenge, can you determine if ignorehitpause=1 is actually necessary?

It’s important to have this present after life management to prevent it from activating when it doesn’t need to. It may also be wise to add something similar to the helper NoKO listed above, but with a !numhelper condition attached for the body.

TimerFreeze is another important tool to ensure a match doesn’t end early. When used by a helper alongside NoKO, it serves as a way to ensure that time can’t run out when you’re dead and still result in a loseKO end screen. Otherwise, it’s a way to ensure that you can use every bit of interference you can regardless of the user’s configuration.
Older nukes typically bind this to a gametime-dependent expression to “lengthen” the timer, newer ones simply exert it at all times until they reach some “endpoint.” TimerFreeze has far more flexibility than NoKO in terms of implementation.

Both using and not using NoKO/TimerFreeze have their own benefits and drawbacks※For example, what if you removed hitpausetime after the body NoKO didn’t proc? What if the opponent uses constant helper NoKO themselves, but you managed to kill them?. It’s up to you, the creator, to decide which is more important to you.

You Will Be Immune to Stopping Time.

On one hand, if a character is paused, it cannot die. On the other hand, a character that is paused can’t defend itself. Guard states fail to do anything, unreversible HitDefs that become reversible will stay that way, and players that need to execute NoKO no longer can.
For helpers, having this immunity is incredibly easy, as you can manually specify incredibly large pausemovetime and supermovetime values upon creation. As long as said helper doesn’t linger in movetype=H, it will be completely resistant. For the root it’s more complicated, requiring you to execute Pause and SuperPause with those values for both the time and movetime fields※Or just use VarExp to set them manually.. And sure, it’s not hard to execute

[State -2]
type = Pause
trigger1 = !isHelper
time = 2147483520         ;For some reason, 1.X needs this, not 2147483647.
movetime = 2147483520
ignorehitpause = 1
[State -2]
type = SuperPause
trigger1 = !isHelper
time = 2147483520
movetime = 2147483520
anim = -1                 ;Let's not constantly display this.
darken = 0
unhittable = 0            ;We may want to get hit.
p2defmul = 1              ;Environment-specific problem avoidance
ignorehitpause = 1

every frame, but won’t this simply cause a deadlock..?

To remove (Super)Pause (herein referred to collectively as “TimeStop”), you can generate a helper dedicated to removing it. In other words, if a helper executes both state controllers with time fields of 0 then destroys itself, it will cancel out the previous one without anyone even noticing that the TimeStop was there to begin with! This method, referred to as 時止め解除 (TimeStop Deletion) in Japanese communities, comes in 3 flavors:

The latter is the most common and stable method, albeit the more complex. It also leaves the helper around for a frame before destroying it to prevent occupancy from impacting the method to a significant extent.

I will be referring to エメル's template for the sake of explanation, as it solely contains various different methods of TimeStop deletion and very little else. In particular, I will be referring to the version found in the 消去型 (Deletion/Resummon) folder. I will add Def numbers to the [State ] fields and trim out some unnecessary information for readability, but those are the only changes I will make.
The principle of this is utilizing reiteration to generate a new helper that will almost surely go last to avoid the downside of having a movetime of 0. This requires the empty slot our helper is going to be placed in be before the helper generating this. In the template's Def -2, 

[State -2];領域確保用ヘルパー
type=Helper
trigger1=!ishelper
trigger1=roundstate<4&&alive
trigger1=!numhelper(好きな番号2)
trigger1=!numhelper(好きな番号1)
ID=好きな番号1
name="ryoiki"
stateno=好きな番号1
helpertype=player
supermovetime=2147483647
pausemovetime=2147483647
ignorehitpause=1
[State -2];時止め解除召喚ヘルパー
type=Helper
trigger1=!ishelper
trigger1=roundstate<4&&alive
trigger1=!numhelper(好きな番号2)
ID=好きな番号2
name="kaijo"
stateno=好きな番号2
helpertype=player
supermovetime=2147483647
pausemovetime=2147483647
ignorehitpause=1
the "ryoiki" helper serves to occupy the space temporarily such that the "kaijo" helper can be placed after it. Once the latter is summoned (which should be immediately), the former will destroy itself within its own state, which frees up the space. 
[State 好きな番号1]   ;時止め解除用のヘルパーが出たので、確保用ヘルパーは消す
type=DestroySelf
trigger1=ishelper
trigger1=numhelper(好きな番号2)
ignorehitpause=1
Within the state for the kaijo helper itself, outside of some supplemental things, the only action that is performed is the summoning of the helper responsible for actually performing the TimeStop deletion now that the state is empty. 
[State 好きな番号2];時止め解除ヘルパー
type=Helper
trigger1=ishelper
trigger1=!numhelper(好きな番号3)
name="kaijo2"
id=好きな番号3
stateno=好きな番号3
Helpertype=player
pausemovetime=2147483647
supermovetime=2147483647
ignorehitpause=1


This is where it gets more complex. For this method, we need a way to check if a single frame has elapsed since it spawns. While there are plenty of alternate ways to do so※For example, you could put gametime in a const like size.height or you could use the helper's animation/animelemtime to check (common method), in this case, エメル uses a time variable, which is defined and modified at the start of the state. 

[state 好きな番号3];消去時間計測
type=varadd
trigger1=ishelper
trigger1=roundstate<3
sysvar(1)=1
ignorehitpause=1
Afterwards, エメル uses a Pause and SuperPause to cancel both types of TimeStop. 
[state 好きな番号3];時止め解除　必須
type=pause
trigger1=ishelper
time=0
movetime=0
ignorehitpause=1
[state 好きな番号3];時止め解除　必須
type=superpause
trigger1=ishelper
anim=-1
time=0
movetime=0
darken=0
p2defmul=1
ignorehitpause=1
There is also another application right below it, which is taking advantage of this helper (hopefully) acting last to force TimeStop to happen, which allows this single helper to serve as a toggle switch on demand.
Lastly, a self-destruction condition is defined such that a new "kaijo2" helper can replace it, closing the loop. 
[State 好きな番号3]         ;召喚した直後に消すと正常な時止め解除が発生しない為、
type=DestroySelf ;1F置いて消す必要がある
trigger1=ishelper
trigger1=sysvar(1)>1
ignorehitpause=1
In this case, because sysvar(1) will be 1 on the first frame of execution due to where the VarAdd was placed, sysvar(1)>1 is checked.

The only exception to “you must be immune” is in cases like the above, where you technically need to no longer be immune to remove TimeStop entirely. There is absolutely no benefit to being able to be paused.
In the case of actually using Pause/SuperPause with the body to grant movetime, you don’t have to execute it every frame, though. Simply once at the start of the match, then whenever the body somehow has MT=H, is mostly sufficient※Of course, this doesn’t cover Null-tier opponents..

You Will Never Be Thrown.

A character being thrown has a very high possibility of instantly killing them by a variety of methods[citation needed]. Even just a single helper being thrown has a very high possibility of inducing undesired effects. Because of this, you want to avoid being thrown at all costs.
The only way to do this is to utilize Def -3. Because code contained within here is only run if the user isn’t thrown, by checking to see if it ran somehow, you can conclude whether you’ve been thrown or not.

The most common way to do this is by performing a GameTime-specific check, which is where the common name of “GameTime Defense” came from. For example, by using a VarSet like this in your Def -3,

[State -3]
type = VarSet
trigger1 = !isHelper
sysfvar(4) = gametime*pi/4 - 69.69
ignorehitpause = 1

your character can escape from every throw in the game simply by adding this to its Def -2.

[State -2]
type = SelfState
triggerall = !isHelper
trigger1 = sysfvar(4) != gametime*pi/4-69.69
trigger2 = !sysfvar(4) ;QNaN Detection
value = (SOMEWHERE)
ignorehitpause = 1

Common options besides sysvars/sysfvars are hitfall (use HitFallSet), differences between edgedist and bodydist (use Width), and Explods (with a gametime-dependent ID). While, certainly, you can use a normal var/fvar for this, it is not recommended, especially for helpers※A common tech that high-level nukes have is Parent Change, which allows you to tamper normal helper variables or if you’re creating a nuke in 1.X.※The cond bug allows you to remotely use variable assignment on opponents..

The cases where your character has to be thrown to win are incredibly niche, usually requiring Dedicated Measures in some form. Oftentimes, it is the only way to win in those cases. However, allowing your helpers to be thrown※As long as they have helpertype=player to make sure they can escape in dangerous situations, and aren’t generated directly by the character, but another helper, is something that top-level nukes do to gather information that can only be obtainable that way.

You Will Judiciously Manage Your State.

Managing your stateno is key to make sure that escaping from a throw puts you right back to where you want to be. Even state changes without a throw, like those induced by an attack with p2getp1state=0, are covered by this principle.
This is typically performed through “Absolute SelfState,” which is essentially executing a SelfState on every frame within Def -2 based on some arbitrarily selected choice. This additionally gives natural throw immunity without needing a GameTime-based expression, because you are technically always escaping a throw. Some examples are as follows:

Because you’re executing a SelfState on every frame, crouching, walking, jumping, and other actions that change your state and are “automatically handled by the engine” will no longer happen. This can be fixed by manually specifying such cases in Def -1, or wherever your command processing happens to be.
You can additionally opt to add a ChangeState at the end of your state’s code to “fix” your stateno to a functionally useful value. Especially in older nukes, one of the more common ones is sending to a guard state, like the below:

[State ########, Pseudo-Fix] ;Put this at the end of your state.
type = ChangeState
trigger1 = !isHelper
value = 120                  ;Other valid options are 130~132, 140, and 150~155.
ignorehitpause = 1
persistent = 256

Assuming the character acts before any potential users, these states grant immunity to Target-related state controllers※Contrary to popular belief, they do not grant immunity to ReversalDef.. Other choices include 5150 for being invisible to MUGEN’s internal AI and any p2 redirects (a common one for helpers) and an opponent’s Throw State to potentially trick them into giving the nuke an advantage※For example, some OTHK templates generate normal helpers upon seeing that the opponent is in their special OTHK throwing state..

Most high-level nukes don’t constantly SelfState in any situation, so Absolute SelfState is used sparingly in the modern era. They usually only do so when being thrown or sent to a state that is different from the one they want to be in. Having a more natural-looking statetime can help versus opponents that demand you to maintain the appearance of a “normal character” lest their anti-cheap kicks in.
Similarly, the top-level nukes don’t even use Guard States that often and trust their own strong defense. The only exception is when roundstate>2, because protection from any target-related interference becomes incredibly important. Overuse of guard states may also trigger opposing anti-cheaps in some fashion due to their association with this defense method.

RETURN TO
SUBLIME TO GOD
CONTENTS