Width (SCTRL)

[JustNoPoint]

Temporarily changes the size of the player's width bar for 1 tick. Useful for controlling the "pushing" behavior when the player makes contact with another or with the sides of the screen.

Required parameters:
none

Optional parameters:
edge = edgewidth_front, edgewidth_back (int, int)
Sets the player's edge width in front and behind. Edge width determines how close the player can get to the edge of the screen. These parameters default to 0,0 if omitted.

player = playwidth_front, playwidth_back (int, int)
Sets the player width in front and behind. Player width determines how close the player can get to other players. These parameters default to 0,0 if omitted.

Alternate syntax:
value = width_front, width_back (int, int)
This is a shorthand syntax for setting both edge width and player width simultaneously. This may only be used if the edge and player parameters are not specified.

Notes:
When collision box display is enabled, the edge width bar is displayed in orange, and the player width bar is displayed in yellow. Where they overlap, the overlapping region is displayed in bright yellow.

Width is ADDITIVE. This example would move the player's player bar back to start at the 0 position, but remain the same size.
Example:

Code Select Expand

[State 0, Width]
type = Width
triggerall = life <= 500
trigger1 = 1
player = -const(size.air.front),const(size.air.front)
Read this post below for a better explanation 

[Odb718]

One thing that really isnt pointed out here is the relationship between the blue box and the width bar. It is a problem/concept new people dont tend to figure out.
NOTE: THESE HIT BOXES WERE MADE FOR THIS EXAMPLE. DO NOT USE SIMILAR CLSN BOXES.

I've tried to show a couple things in this pic. The first thing you'll notice is some Ryus are bright blue, and the others arent. CTRL+C changes that.
But the sets of Ryus have "normal" width(s) and clsn boxes. You can see the line under his feet. The first set they arent touching at all, and the second set you can see the blue clsn boxes are overlapped and the width lines arent.

When the blue boxes touch AND the width lines touch, Mugen says the characters cant go further.
But here's the tricky part. See the two Ryus that have the edited widths? The first Ryu's Ground.Back is juuuust slightly outside of his clsn box. The rightmost Ryu's width is offset and is outside of his clsn boxes too. They'll both cause problems.
Width lines can overlap. Mugen allows this to happen. But the moment the clsn boxes of P1 & P2 touch, Mugen SNAPS the two players so that the width bars arent overlapping. It POPS! the character back. Most of the time you'll notice this happen when either player is walking forward and bumps into the enemy. They'll keep popping back a bit and walking forward and popping back.

One pixel more and the two Ryus jump to the second set's position because P1's in the corner.
When the width bar is inside the clsn box, Mugen is actively looking to set the 2 players apart. So when the width bars finally do make contact Mugen stops it smoothly. There's no pop. 

[JustNoPoint]

The above CLSN are also "incorrect". To see a discussion on that and why go to this thread.

[Fausto Mugen]

In which cases would it be useful to use this SCTRL?

[JustNoPoint]

The most common is with certain attacks that make the char step forward visually but not actually step forward. They return to their axis they started in. With attacks like these you can easily step outside your width bar. So at close range the attack passes through P2, misses, then steps back in front of P2. With width it could push P2 as needed.

Or some chars hunch over and look wider. Sometimes they have attack where they stand straight and get slimmer. You would walk and push them without touching them.

[altoiddealer]

I haven't tested it, but I believe the width controller also adjusts the size.ground.front and size.ground.back values returned by the Const trigger (?)  At least it would make sense.  In which case, an accurate width would be useful for other characters relying on the values from that trigger.

[Odb718]

Having not worked with width in a while I was rereading this thread because I was getting things wrong.

The Width sctrl is additive. It EDITS the Size air.front and air.back

Adding this code to state 0

Code Select Expand

[State 0, Width]
type = Width
triggerall = life >= 751
trigger1 = 1
player = 15,15

[State 0, Width]
type = Width
triggerall = life <= 750
trigger1 = 1
player = -5,-5
produces these 2 Widths. The third width is the unedited width. The code will not include the normal width.



My Ryu's Size settings are
ground.back = 15     
ground.front = 15   
Using the stack of feet on the right you can see when he's at full health the top and middle bar are not the same width (pun intended)
You can also tell the bottom bar when he's under 750 health is 2/3 the normal bar, not 1/3. If both values went -5 from 0, the total size of the bar would be 10. But you can tell it's 20, instead of the normal 30.

The feet stack are all centered on the word Ryu under his feet. That's the best I could do to center them evenly.