RicePigeon

3-month usage stats are out

 

 

 

The following Pokemon are now BANNED from UnderUbers:

• Blaziken-Mega
• Darkrai
• Ditto
• Mewtwo-Mega-X

 

The following Pokemon are now UNBANNED from UnderUbers:

• Pheromosa
• Tapu Lele

The following items are now BANNED from UnderUbers:

• Blazikenite
• Mewtwonite X

 

The following items are now UNBANNED from UnderUbers:

• None

Reisen & Alice updated

 

	6y: Can now be airblocked. Undersense Break: Fixed incorrect juggle flags.
	Volatile Doll: Damage decreased (90->85), splash damage now properly applies proration. Thousand Spear Dolls: Damage increased (25xN->26xN), proration decreased (97%xN->95.5%xN). "Shanghai Doll": Damage increased (15xN->16xN), proration decreased (98%xN->97%xN).

Chen updated

 

Forward dash velocity increased. 6y: Startup decreased by 2f. Blockstun increased by 3f, is now +2 on block. 3z: Fixed unintended knockdown behavior. Throw: Now applies 90% proration in addition to standard throw proration. Rumbling Jikokuten: Fixed chip damage being static for all versions, added projectile limiter.

Reimu updated

 

j5x: Hitbox on first 3 active frames slightly extended downward, startup decreased by 1f. j5z: Startup increased by 1f Throw: Now applies 90% proration in addition to throw proration, damage decreased (100->90). Ascension Kick: Vertical hitbox size on 1st active frame increased, horizontal hit velocity decreased. Ascension Kick: Startup invulnerability on all versions increased (12/6/6/14->18/12/6/24). Hakurei Amulet [Ground]: X version recovery increased by 2f, Y version recovery increased by 1f. "Omnidirectional Demon Binding Circle": Damage decreased (36x10->35x10), proration decreased (92.5%xN->92%xN).

Mokou updated

 

Self-Harming Fire Talons: Corrected bug with chip damage. Resurrection: Fixed inconsistency with juggle flag. Mt. Fuji Eruption: Fixed juggle flag. Blazing Bamboo Tube: Fixed juggle flag. Graphic updated.

Flandre Scarlet updated

 

3y: Is no longer air blockable. Now counts as a grounded melee attack. 3y: Blockstun increased by 2f. Starbow Break [X ver]: Startup after hitting wall decreased by 2f, now projectile invulnerable while on wall. Starbow Break [X ver]: Horizontal velocity increased. Starbow Break [X ver]: Recoil velocity & recovery decreased, now -7/-8 on block. "Laevatein": Now only hits once, damage values increased to compensate. Velocity increased. "Weapon of Mass Destruction": Explosion hitbox size drastically increased.

Utsuho and Marisa were updated during MFFA's downtime.

 

	Slight adjustments to dashing behaviors. Corrections to guarding behavior regarding crossups. Adjustments to invincibility on Guard Cancel. Adjustments to reset behaviors. Rocket Dive: Fixed incorrect visual effects when fully charged. "Yatagarasu Dive": Dive portion damage increased (80xN->82xN).
	6z: Is now air blockable. Witching Blaster: No longer whiffs against certain opponents in the corner. Witching Blaster [Air ver]: Recoil velocity slightly increased. "Sungrazer": Adjustments to startup invulnerability, can no longer be knocked out of attack on successful hit.

Byakuren updated

 

Adjusted dash cancel timings. Corrected guarding behavior in regards to crossups. Adjustments to reset behavior. Adjustments to invulnerability on Guard Cancel. j2y: No longer autocorrects.

Ichirin updated

 

Adjustments to dash behavior. Corrected guarding behavior in regards to crossups. Corrected invuln timing on Guard Cancel. Adjustments to reset behavior. Knockdowns will no longer cause Unzan to deactivate. 5y (Unzan): Hitstun & Blockstun decreased by 2f. 5y (Unzan): Active frames decreased by 2f, startup increased by 2f. Hurtboxes adjusted. 6z (Unzan): Corrected faulty juggle flag. 2y (Unzan): Recovery increased by 4f. Hanging Cloud's Iron Hammer: Hitbox size drastically reduced, recovery time increased by 3f. North Mountain Wind of Mercy: Damage decreased (100/120/140->90/110/130).

You do realize the character was an April Fool's joke, yes?

 

An april fools character from over four years ago, I might add...

Damage Proration System

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

Proration, also known as Damage Dampening, is a system implemented in many fighting games that prevent combos from becoming too overpowered by decreasing the amount of damage dealt by each successive hit in a combo. The exact method of how proration is achieved differs by game; most Capcom games such as the Street Fighter and Marvel vs Capcom games use a linear proration system based on the number of hits in a combo, while most games by Arc System Works tend to use a scalar method where each hit of an attack applies its own scaling value. This tutorial will deal with the latter method, which gives you greater control over how damage is scaled.

 

First, you'll need two floating point variables for this to work; we'll be using fvar(10) and fvar(11). We'll be dealing with fvar(11) as our final dampener later on, but for now, start with the following in your -2 state:

[State -2, Reset var when the opponent recovers]
type = Varset
trigger1 = numenemy
trigger1 = (enemynear,movetype!=H)
trigger2 = !numenemy
fvar(10) = 1.0

[State -2, Final Dampen]
type = null
trigger1 = (fvar(11) := ifelse(0.1>fvar(10),0.1,fvar(10)) || 1
ignorehitpause = 1

[State -2, Dampener itself]
type = Attackmulset
trigger1 = 1
value = fvar(11)
ignorehitpause = 1

The first state controller will initialize our character's proration to 100% damage (the default), as well as reset our proration value whenever the opponent is not being comboed. The second state controller is optional, but is handy to have if you want there to be a minimum proration value, as many games that use this system tend to have one. In our above example, our minimum proration is set to 0.1 or 10%, so our damage scaling will never go below 10% of an attack's base damage. You can also further modify fvar(11) for any other system mechanics you might need, including counterhit bonuses or other scaling such as the damage penalty incurred with systems such as Custom Combo. The final controller here will apply fvar(11) as our final proration value and scale our Attack stat accordingly. Note that this will only apply to damage dealt by the player and not any helper projectiles spawned by the player; in order to apply our damage proration to those, you'll need to apply the proration value directly to the attack's damage value in the hitdef:

 

damage = ceil(220.0*root,fvar(11)),44

Here, we see a helper projectile with a base damage of 220 having the root's (aka the player's) proration value applied. The ceil function is needed to ensure that the damage never falls below 1 and always returns an integer value. Note that chip damage (block damage) is never scaled.

 

Now that we have a proration system in place, all that's left is to actually apply the proration values. Go through each of your character's attacks and add a varset under their hitdef with the amount of proration you want to apply on hit:

 

[State 200, Damage Dampen]
type = varset
trigger1 = movehit
fvar(10) = fvar(10)*0.92
ignorehitpause = 1
persistent = 0

Above, we see a controller for attack that deals 92% proration on hit. As mentioned at the beginning, this will multiply the proration value by whatever proration is set by the attack, which is then applied to the damage of the next attack in the combo. If you're doing this in a helper projectile, you'll want to substitute this for an equivalent parentvarset controller:

Quote

 

[State 200, Damage Dampen]

type = parentvarset

trigger1 = movehit

fvar(10) = (root,fvar(10))*0.92

ignorehitpause = 1

persistent = 0

 

 

If an attack deals multiple hits, you'll need to apply a proration controller for each individual hit in a similar fashion; this can be accomplished through the use of the animelemno() and animelemtime() triggers, or whatever system you are using to keep track of multiple hits.

Homing/Tracking/Aimed Projectiles

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

Another relatively simple concept; you have a projectile spawned at a stationary location and want it to either aim in the opponent's direction or to home in on the opponent. For this you'll need a few variables to spare and simply place the following at the beginning of the projectile's state:

 

[State 24010, Conditional Varset]
type = null
triggerall = time = 0 ;<-- See notes below
trigger1 = numenemy
trigger1 = (fvar(0):= (enemynear(0),pos x - pos x) * facing) || 1
trigger1 = (fvar(1):= enemynear(0),pos y - pos y + enemynear(0),const(size.mid.pos.y)) || 1
trigger1 = (fvar(2):=((fvar(0)**2.0)+(fvar(1)**2.0))**0.5) || 1
trigger2 = !numenemy
trigger2 = (fvar(0):= 320.0 * facing) || 1
trigger2 = (fvar(1):= 0.0) || 1
trigger2 = (fvar(2):=((fvar(0)**2.0)+(fvar(1)**2.0))**0.5) || 1

What this does is uses simple trigonometry to calculate the vectors between the opponent and the projectile. The second set of triggers (trigger 2) is necessary in the event that an opponent doesn't exist so that the code doesn't bug out, and will simply cause the projectile to fire in a straight line if there is no opponent. You might be wondering about that triggerall line at the top. Depending on what this value is will determine on whether or not the projectile is aimed or homing; an aimed projectile will simply track the opponent's position at the time of creation and fire at that direction, while a homing projectile will continuously chase the opponent for as long as the projectile exists. The above code is for an aimed projectile, but to change this to a homing projectile, simply replace "triggerall = time = 0" with "triggerall = 1".

 

But we're not done yet. We still need to apply these vectors to the projectile's velocity. Assuming that the projectile's base velocity is 10:

 

[State 24010, Velset]
type = velset
trigger1 = 1
x = 10.0*fvar(0)/fvar(2)
y = 10.0*fvar(1)/fvar(2)
ignorehitpause = 1

What we're doing here is normalizing our vectors and applying them to our projectile's base velocity. This is what will cause the aimed/homing behavior of the projectile.

 

If for some reason you also need your projectile to rotate in the direction it's traveling, make sure to add the following under your velset controller:

[State 2010, AS]
type = varset
trigger1 = vel x != 0
fvar(3) = atan(vel y/vel x)*(-180.0/pi)+((vel x<0)*180)

[State 2010, AS]
type = varset
trigger1 = vel x = 0
fvar(3) = ifelse(vel y<0,90,-90)

[State 2010, AS]
type = angledraw
trigger1 = 1
value = fvar(3)
ignorehitpause = 1

Just make sure that your projectile's graphic is facing horizontally or you'll need to make adjustments to the above code. This also checks if the projectile is traveling straight up or down; since the tangent of 90 degree angles are undefined, we need that second state controller there as a failsafe or else the code will bug out and you won't get a proper rotation.

1 hour ago, PlasmoidThunder said:

For there to be any kind of validity to this thread, you'd need to supply far more than just the names of characters you want made.

 

Pretty much this, its one thing to say what character you want, but without a solid game plan in mind as to how the character should play, there isn't much that can be done.

So its been almost 6 months since the last post here and there's a been a number of changes to the gameplay system, especially now that we have an actual playable demo of the system in the form of IZ Yukari, which was released last month. I suggest taking a look there for the most up to date changes to the system compared to what's listed here.

 

I kinda of want to steer the direction of this toward the next three characters planned for this system: Marisa, Sakuya, and Reimu. While these three won't receive that many drastic changes as Yukari did (it was mostly a last-minute decision due to her being included in 15.5, which was released in December), I do feel that I should go over some of the changes they'll be receiving, as well as any ideas anyone else has in mind.

Improved Guarding States for Crossup Detection

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

In most fighting games, you need to hold the joystick in the direction away from the opponent in order to guard, which is straightforward when the opponent is directly in front of you. But when the opponent is behind you, such as during an attack that crossed up the opponent, holding back should not allow you to guard an opponent's attack, only when holding forward. By default, Mugen's default guarding states cannot take into account these cross-up attacks. The following modifications to Mugen's guard states will replicate this proper behavior.

 

First, go through States 120, 130, 131, and 132 and search for the following block of code:

 

[State 132, Stop Guarding]
type = ChangeState
trigger1 = command!="holdback"
trigger2 = !inguarddist
value = 140

Replace this with the following:

[State 132, Stop Guarding]
type = ChangeState
trigger1 = cond(p2dist x<0,(command!="holdfwd"),(command!="holdback"))
trigger2 = !inguarddist
value = 140

What this does is tells the engine to stop guarding if we are holding back and player 2 is behind us.

 

In a similar fashion, check states 132 and 155 for the following:

[State 132, 6]
type = ChangeState
trigger1 = sysvar(0)
trigger1 = command="holdback"
trigger1 = inguarddist
value = 130

Replace with this block of code:

[State 132, 6]
type = ChangeState
trigger1 = sysvar(0)
trigger1 = cond(p2dist x<0,(command="holdfwd"),(command="holdback"))
trigger1 = inguarddist
value = 130

This will do the opposite: Tell the engine to start guarding if we are holding back ONLY when the opponent is in front of us, and when holding forward ONLY when the opponent is behind us.

Hitdef Animtype Quirk

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

This is more of a bug in Mugen/IKEMEN's parser. Basically, Mugen's parser only checks the first letter of the Animtype parameter (L for Light, M for Medium, H for Heavy, B for Back, U for Up, and D for Diagup), while ignoring the rest of the parameter's value. This means that Animtype = Hard and Animtype = Heavy are functionally equivalent. This also means that some silly parameter values that normally shouldn't be accepted by the engine are valid values:

 

Animtype = Hamburger

resolves to Animtype = H (Heavy)
 

Animtype = Methamphetamine

resolves to Animtime = M (Medium)

 

Animtype = Boobies

resolves to Animtype = B (Back)

 

Basically, as long as the parameter's argument begins with an L, M, H, B, U, or D, the engine will accept it as a valid parameter.

Multiple Attack Variants Using a Single State

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

This one is fairly simple, and makes use the assignment operator. Instead of defining Light, Medium, and Heavy variants of a special move in separate states, have the changestate in -1 as follows:

 

[State -1, Shoryuken]

type = ChangeState
value = 1100
triggerall = ctrl
trigger1 = command="DP_X"
trigger1 = (var(10) := 1)||1
trigger2 = command="DP_Y"
trigger2 = (var(10) := 2)||1
trigger3 = command="DP_Z"
trigger3 = (var(10) := 3)||1

 

As we can see here, each command will still bring us to our main Shoryuken state, but will keep track of which version we are using. If you have multiple different animations or anything else that varies depending on the version of the move used, you can simply refer to the variable as follows:

 

[Statedef 1100]
type = S
movetype = A
physics = S
ctrl = 0
poweradd = 20
anim = 1100+1*(var(10)=2)+2*(var(10)>=3)
sprpriority = 1
facep2 = 1

[State 1100, Hitdef]
type = HitDef
trigger1 = movecontact = 0 && movereversed = 0
trigger1 = animelemtime(1)>=0
attr = S, SA
damage = 60+10*(var(10)=2)+20*(var(10)=3),11+2*(var(10)=2)+4*(var(10)=3)

As we can see here, animations 1100, 1101, and 1102 each correspond to the Light, Medium, and Heavy versions of our DP command, and the damage values can be modified with this as well.

Please don't post or redirect to any links containing warez/other illegal or pirated software. The links in your video contained downloads of .gba files, which, despite being ROM hacks, are still pirated copies of the official Pokemon games.

 

Links to IPS patches, on the other hand, are fine, since they only contain the necessary changes, and not the ROM itself.

More Efficient Random Number Spreads

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

Many times I've seen authors use modulo division to generate a spread of random numbers for whatever purpose (be it for AI triggers, random animations, or whatever). For those who don't know what I'm talking about, I'm referring to pieces of code like this:

 

Quote

trigger1 = random%2 = 0

 

To understand why the above code is inefficient, we have to take a deeper look into the results its producing.

For those who don't already know, in MUGEN, random generates a random integer from 0 to 999 (effectively producing 1 of 1000 different values each time random is called), each with an equal probability of being returned by random. With the % operator, such as in expression X%Y, we are dividing value X by value Y and returning only the remainder as a result. 17%10, for example, would return 7 as its value (17/10 = 1 R7). If we were to apply modulo division to random, for instance, we would be generating a random value from 0 to 999 and then dividing this number by an arbitrary value and returning its remainder as a result. By applying modulo division to random, we expect to see results that have an equal probability of being generated, as follows:

 

Random%10 generates:

Quote

0 (10% probability)
1 (10% probability)
2 (10% probability)
3 (10% probability)
4 (10% probability)
5 (10% probability)
6 (10% probability)
7 (10% probability)
8 (10% probability)
9 (10% probability)

 

As we can see above, we have a nice even spread of the 10 possible values that random%10 can generate. While this works great for numbers that are factors of 1000 (such as 2, 4, 5, 10, 20, 50, 100, etc), more arbitrary values won't be as neat and organized.

 

As an arbitrary example, instead of 10 values, we try for 666 (which should return an even spread of numbers ranging from 0 to 665). The results are listed below:

Random%666 generates:

 

The problem should be immediately clear: the values ranging from 0-333 each have a 0.20% probability, while values ranging from 334-665 each have a 0.10% probability. If this were an even spread, we should expect any value from 0-332 to be generated only 50% of the time, but instead we see that numbers in this range are generated 66.6% of the time! If we were relying on a number being generated from this range, random%666 would be returning these values TWICE as often as the rest of the spread.

 

The solution? Rather than using modulo division, we use the following:

Quote

floor(X*random/1000.0)

What this does is multiply arbitrary value X by random, then divide by 1000, then floor the result to produce an integer value. This results in a spread ranging from 0-X, but in a much more even fashion. Say we revise our above code to the following:

 

floor(666*random/1000.0) generates:
 

 

While this isnt foolproof, as we still have values that are twice as likely to be returned than the other values, you'll notice that the spread is much more even. Values ranging from 0-332 now have a 50% chance of being generated, as we would expect them to be, as opposed to the 66.6% probability we were generating before.

Asymmetrical Palette Display using ReMapPal (aka The Gill Effect)

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

 

You've probably heard of the term "Gill Effect" or something similar before if you've ever played any of the Street Fighter III games; a character with an asymmetrical color scheme on their body. In Mugen, attempting to replicate this would require a duplicate of every sprite with the reversed palette, but even then custom states cause a problem. With the ReMapPal controller introduced in Mugen 1.0, this can now be done easily with a simple controller:

 

 

The idea is simple; using the new SFFv2 format, instead of duplicating each sprite, duplicate each palette and then remap the palettes with the new controller depending on the direction the character is facing. However, keep in mind that executing a ReMapPal controller conflicts with an earlier state controller; PalFx.

To get an idea of what I'm talking about, here we have the same attack which puts p2 into a custom state that applies a PalFX controller to simulate being frozen. One default Kung Fu Man, while the other is a character that continuously applies a ReMapPal controller in her -2 state in order to simulate the Gill effect;

 

 

Purely discovered by accident, I was easily able to find a workaround to this by, rather than continuously applying ReMapPal, instead only apply the controller when it needs to be. This can be done with a variable to act as a flag and compare it to the current direction the character is facing. If they do not match, only then should ReMapPal be applied, with the flag set to that facing value to avoid the controller being executed again until needed. This isn't a perfect workaround, however, as custom states that both apply a PalFX controller and repeatedly changing the opponent's facing direction may still cause the PalFX to end prematurely.

 

In the end, to address the issue outlined above, your code should look something like this:

 

Quote

 

[State -2, GILL SYNDROME]

type = RemapPal

trigger1 = facing = 1

trigger1 = var(26)!=1

source = 1,1

dest = 1+0*(var(26):=1),palno

 

[State -2, GILL SYNDROME]

type = RemapPal

trigger1 = facing != 1

trigger1 = var(26)!=2

source = 1,1

dest = 2+0*(var(26):=2),palno

 

 

The way it works is simple: You'll need a variable to keep track of which direction your character is facing: 1 for facing right, 2 for facing left. Additionally, you'll need to have two palette groups for each direction as well. The above code will check which direction you're currently facing and if you were previously facing the opposite direction; if you were, change the palette to the opposite palette group, otherwise don't change anything. This will also simultaneously set the value of the palette group to use.

Hitdefs with Multiple Attributes

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

 

Ever wondered if you could assign multiple properties to a hitdef, but didn't want multiple hitdefs conflicting with each other each tick? Thanks to a discovery by a friend of mine, you might not need to:

Quote

DoomBowser: ...
DoomBowser: Why the hell is it possibly to assign multiple attributions to a hitdef?
DoomBowser: Elecbyte wtf
Midori: WAIT WHAT
Jenngra505: Does this mean we can make Command Normals by having it be both a Normal and a Special?
DoomBowser: No
DoomBowser: It means it's both a Normal and a Special
DoomBowser: At the same time
DoomBowser: I need to look further into this
DoomBowser: Set a character's LP to be both NA and NP
DoomBowser: The attack still interacts with counters that only counter melee attacks, but also interacts with things like Yukari's gap, which only absorbs projectiles
DoomBowser: So it's both a melee attack and a projectile at the same time
DoomBowser: But why is this possible, and for what reason?
Midori: so you can type A,SA,SP?
DoomBowser: Yes, and it would probably be both
Midori: oh damn
Midori: Question
Midori: what happens if you put a hitdef that's NA,NT and there was a NotHitBy by NT
DoomBowser: I need to double check that one
DoomBowser: The opponent gets hit
Midori: !!!!
Jenngra505: Can you have an attack that's standing, crouching and aerial all at once?
DoomBowser: By the looks of it, yes
DoomBowser: SCA,NA,NP,NT,SA,SP,ST,HA,HP,HT is completely valid for a hitdef's attr parameter
DoomBowser: What's odd is that this is an extension of what I found with that crappy Futo the other day where there's AA, AP and AT functions
DoomBowser: S,AA = Standing Normal/Special/Hyper Attack
DoomBowser: Then I just happen do find the multi-function parameter in Aperson's Robotnik
DoomBowser: Robotnik's Pissed off slap worked both against Youmu's melee counter and Yukari's gap, because the hitdef attribution is S, SA,AP
RicePigeon: can we get a gif of him using it on the gap just for lulz?
DoomBowser: Sure
DoomBowser:

DoomBowser: It's a bit of a cheaply made gif, but you get the point
RicePigeon: oh man thats fresh
RicePigeon: lol
RicePigeon: and its not even Yukari's fault this time :p
RicePigeon: assuming Doom hasnt done it already, Im gonna go post that finding about the hitdef's attr parameter on guild
RicePigeon: out of curiousity if you have an attack classed as S,SA,SP and the opponent has two different hitoverrides active, one for melee and the other for projectiles, which one takes precedence?
DoomBowser: I haven't checked that one
DoomBowser: Is there a character I can test this on? I'm not sure if I have a character like that on me
RicePigeon: none that I know of, but I can probably whip up something real quick for testing purposes
DoomBowser: Alrighty then
RicePigeon: Okay so just tested it
RicePigeon: it seems like the hitoverride with the lower slot number takes precedence
RicePigeon: tested it first with the melee override in slot 0 and projectile in slot 1, the melee override took effect
RicePigeon: reversed the slots and the projectile override occurred
RicePigeon: Imagine what kind of broken shit you can do with this discovery

 

The tested code in question:

 

[Statedef -2]
[State 0, HitOverride]
type = HitOverride
trigger1 = 1
attr = SCA,AA
slot = 1;0
stateno = 1200 ;Melee counter state
time = 1
forceair = 0
ignorehitpause = 1
[State 0, HitOverride]
type = HitOverride
trigger1 = 1
attr = SCA,AP
slot = 0;1
stateno = 1300 ;Projectile counter state
time = 1
forceair = 0
ignorehitpause = 1

 

Other stuff to make note of due to this bug:

 

• If an attack is attributed as multiple levels and KOs the opponent, MUGEN will flag the victory condition in the order of Special, Hyper, and Normal (ie: S,NA,SA,HA will be attributed as a Special).
• Similarly, MUGEN will prioritize the Throw win flag if the attack is attributed as a combination of Throw and either Attack or Projectile.

 

Both of these conditions will ignore the ordering of multiple hitoverrides.

 

Some practical uses of this bug include the ability to code melee attacks that can destroy helper-based projectiles without needing to code in an additional Helper to handle projectile collisions:

 

Workaround for Missing "ParentExist" Trigger

Compatibility:

WinMUGEN	Mugen 1.0	Mugen 1.1b	IKEMEN

 

 

Have you ever had a situation where you needed to create a complex projectile or effect that utilized a single helper creating multiple helpers that were bound to it, only to encounter a glitch where, in the event that the parent helper was destroyed, the child helpers would just sorta stay on screen and Mugen's debug is spitting out complaints that all your child helper's bindtoparent controllers have no parent to bind to. You rush to alter your child helper's Destroyself controller, only to realize that there is no "ParentExist" trigger you can use to force them to destroy themselves. Sounds like all hope is lost right? Fortunately there is a clever workaround using trigger redirection.

 

For each parent helper, you'll need to reserve one variable for a unique ID, while each child helper will require two variables; one to keep track of the parent's unique ID, and one to keep track of the parent helper's playerID, which is created by the engine each time a helper is created and are periodically recycled as helpers are destroyed and new helpers created to take their place.

 

In the first state of parent helper, at the following line of code to the beginning of its state:

[State 20000, Parent ID]
type = varset
trigger1 = time = 0
var(0) = random*1000+random

This will generate a unique, 8-digit ID when the parent helper is created. You only have to set this once each time the helper is created, even if the helper goes through multiple states. Note that there is a very small chance (approx 0.0001%) that the same ID will be created twice, but the chance is so miniscule that this will rarely, if ever, happen. That's all for the parent helper.

 

The child helper is where things start to get a bit complicated, so I'll go through each part here. In the first state the child helper is created in, add the following to the beginning of the state:

[State 20010, Parent Destruct Safeguard]
type = varset
trigger1 = time = 0
var(1) = parent,id ;Set to parent's PlayerID

[State 20010, Parent Destruct Safeguard]
type = varset
trigger1 = time = 0
trigger1 = playeridexist(var(1))
var(0) = playerid(var(1)),var(0)

 

What you are basically doing is copying the values of both the parent helper's playerID (which is set by the engine) and the 8-digit ID that you generated earlier, into the child helper. The reason for copying both of these values into the child helper is to check for two possible scenarios:

 

• Scenario 1: Parent no longer exists, Helper with Parent's Player ID doesn't exist
• Scenario 2: Helper with Parent's Player ID exists, but unique ID don't match

 

Scenario 1 is pretty straightforward; if a helper with the parent helper's PlayerID doesn't exist, then that means that the parent helper doesn't exist and you can safely destroy the child helper.

 

Scenario 2 is a bit more complicated to understand, and requires a bit of understanding of how the MUGEN engine assigns PlayerIDs. As stated before, PlayerIDs are recycled by the engine each time a helper is destroyed; MUGEN will typically use the first available free PlayerID in these cases. In other words, you may run into situations where a helper with the parent's PlayerID exists, but the helper with that ID was actually created after the actual parent helper destroyed itself! It is for this reason that we needed that unique 8-digit ID number, as PlayerID alone is not enough to check if the parent helper no longer exists.

 

To satisfy both of these scenarios when checking to see if a child helper's parent exists, your triggers should typically look something like this:

 

trigger1 = !playeridexist(var(1))
trigger2 = playeridexist(var(1))
trigger2 = playerid(var(1)),var(0) != var(0)

 

Trigger1 will satisfy the first scenario; because there is no helper that exists with the parent helper's PlayerID, we can safely say that the parent was destroyed.
Both Trigger2s satisfy the second scenario; a helper exists with the same PlayerID as our child helper's parent, but their unique 8-digit ID number does not match what we initially recorded, indicating that the original parent helper was destroyed.

 

If you want to prevent any unusual debug errors, you should also add the following triggers to all State Controllers utilizing a parent that isn't the root (ie ParentVarSet, BindToParent, etc.):

 

triggerall = playeridexist(var(1))
triggerall = playerid(var(1)),var(0) = var(0)

 

These triggers will check for the same consistency as the ones we defined above. If everything checks out, then the state controllers will execute without any problems. Otherwise, the controllers will not execute and prevent unnecessary debug flood.

This will mostly be a repository for anything that I've come across during my experience with the engine.

On 4/15/2018 at 6:57 AM, PlasmoidThunder said:

From the board description:

Quote

DO NOT REQUEST CHARACTERS TO BE MADE

 

 

Koishi updated

 

Adjustments to dash behaviors. Fix to guard behaviors regarding crossups. Adjustments to invincibility on Guard Cancel. Adjustments to reset behaviors. 6z: Damage decreased (80->70), Power gains decreased (120/60->90/45). 4z: Damage decreased (90->80), Power gains decreased (120/60->90/45). j5x: Damage decreased (50->40). j5y: Damage decreased (65->55). j6z: Damage decreased (90->80), Power gains decreased (120/60->90/45). j2z: Damage decreased (90->80), Power gains decreased (120/60->90/45). Catch & Rose: Damage decreased (111->101), Y & Z versions now properly deal chip damage. "Superego": Startup decreased by 8f, corrected persistent sound effect when Koishi is interrupted.