By default, LF2 uses 500hp & 500mp as the maximum. You spawn in frame219(crouch2) with 200mp unless you're playing stage mode where you start with 500mp.

HP actually has two types: Red HP & Dark HP.
Red HP is your actual HP. Dark HP is the maximum amount you can regenerate(i.e. heal without milk).

Any damage a character takes will hurt his Red HP by 100%, while Dark HP is reduced by only 33% rounded down.
If the character is thrown by cpoint, both Red & Dark HP will be reduced by 100%.
If an attack is blocked, a character only takes 10% damage rounded down, this also applies to Dark HP(3.3%).
Armor also blocks the same amount as defend, but appears to be calculated by a different formula.

HP regenerates 1hp every 12tu.
Healing spells recover 8hp every 8tu over 100tu; the 1st 8hp is applied within 4tu.
John's heals (state 1700 or itr kind 8) do not stack with each other, stopping prematurely if Red HP = Dark HP.
State 1700 only begins healing after leaving the frame, though the HP bar will start blinking when 1700 starts.
Jan's heal(ball hit_Fa4) applies a "regeneration" status effect that lasts the full 100tu, and stacks with state1700 or itr kind 8.

When proceeding to next stage, you will auto-heal up to your current Dark HP +X, where X is the amount based on difficulty.
E: 200, N: 150, D: 100, C: 50.
You do not recover any Dark HP in Championship mode.

MP regenerates Xmp every 3tu, maximum of 5mp/3tu.
The value of X is determined by the following formula, rounded down(decimals not counted):
Standard: (500-health)*0.01 + 1 ; start with 1mp/3tu, +1 every 100hp lost exclusive. 1-99, 100-199, 200-299, 300-399, 400-500
Firzen & Julian: (500-health/2)*0.01 + 1 ; start with 3.5mp/3tu(but in practice 3mp/3tu). At 200-399hp = 4mp/3tu. At 1-199hp = 5mp/3tu.

It should be noted that clones(Julian.52/Rudolf.5 opointing themselves) will not regenerate more than 150mp, but they can reach 500mp if they drink milk/beer or when proceeding to next stage.

Milk restores 160 Red HP + 80 Dark HP + 500mp at a rate of 4rHP/2.5tu + 2dHP/2.5tu + 5mp/2.5tu, can be drank for 100tu (stop drinking almost immediately after the 7th glug).
Beer restores 750mp at a rate of 6mp/tu and can be drank for 125tu (8 full glugs, almost 9th).

33.3% is a magic number; bpoint appears only when hp hp<167.
Firen & Freeze fusing into Firzen requires hp<=176 each. This property is tied to state: 2 and id 7 & 8.
Louis' transform to EX requires hp<=177. This property appears to be tied to id 6 and its frame 300.
Safe to say, if you're bleeding, you can definitely fuse/transform, but its still possible even if you're slightly above the bleeding threshold.

All objects by default have 500hp when spawned (with exceptions such as id 5 & 52 Rudolf/Julian opointing themselves, creating clones with 10hp).

The MP tag (mp: xxyyy) where xx is HP*10 (yyy is MP cost) can be used to heal or drain Red HP. If mp: xxyyy is on the 1st frame and the number is negative, the player can regain HP & MP. While the -mp tag does work in 2nd frame onwards for MP, it has no effect on HP.

Using hit_a on type 3 objects will cause their Red HP to drain. Yes, this HP can actually be healed, its just that when an object is not a type 0 character, it does not benefit from HP regeneration. You cannot use -ve hit_a to regain HP.

Milk & Beer(id122 & 123) actually have 100 & 125hp respectively which is drained at a rate of 1hp per 1tu when being drunk. This is not the same as weapon_hp.

"weapon_hp:" can never be healed, even with negative damage.

Hitlag is the shake that happens one object interacts with another, and it works by freezing the character in his current frame.
Attacker/Victim/Defending hitlag is 3/3/5 respectively.

Attacker/Victim hitlag accelerates momentum (especially upwards), while defend hitlag appears to decelerate any momentum - these lead to bugs such as Davis' super high uppercut if he performs it from the last hit of DvA or armored characters losing all their momentum when jumping. This is why you'd notice that LF2 never has any -ve dvy movement in the same frame as an itr - check out Jack, Julian, Davis & Woody!

Hitlag also freezes fall recovery, so if you are creating a shrafe attack (fall 1), make sure you avoid using a vrest smaller than 4, else it'd be as good as using fall 20 (see 5. Fall & Injury).

If you decide to modify the hitlag values(making sure attacker/victim have the same amount), most combos should continue to work as before, but you will need to double-check your vrest for shrafe attacks and any combo that uses projectiles such as Firen's D>AAA will likely be broken.

Note that when I generally disregard the attacker/victim hitlag time when I state any time in tu since they cancel each other out in practical terms.

Raw details
A character accumulates from an itr bdefend & fall points, which are used to help determine which frame he goes to when hit. These points are lost at a rate of by 1 per tu.

Defend & State 7
Characters are hardcoded to use frame 110 for defend, which allows turning, and goes to frame 111 when taking a hit(which also loops into itself if it also takes a hit). Otherwise, defend is the same as using state 7 on its own.

1. If total bdefend <=30, the attack will be blocked successfully.
   
2. If total bdefend >30, the character is forced into broken_defend(frame 112).
   
3. This broken_defend check does not apply if the character is in mid-air(effectively giving you a super block), or if self-catch state 7 is used.
   
4. If an itr has bdefend >60, defend is ignored (see: Deep's >>A 1st hit bdef65 & bdefend 100).
   
5. bdefend 100 is a specially coded number; it instantly destroys weapons & completely ignores any form of defense including armor.
   
6. You generally cannot block an attack that is "behind" you - determined by whether the attack is facing the same direction as you or opposite from you.
   

The last point has some interesting bugs & exceptions:

1. If the itr's dvx is negative, you can block the attack even with your back facing to it. -dvx normally pulls rather than pushes, though this is the reverse if effect 22/23 is used. This is why Firen's groundfire & explosion can be blocked even though you're facing the wrong way!
   
2. When a non-type 2 heavy object gets deflected, it actually doesn't change directions automatically. Projectiles usually get around this either by forcing it to a negative next: (such as John & Dennis' homing balls), or by opointing a new copy of itself in the opposite direction(which is what most balls do, which is also why they always tend to move downwards on z-axis since opointing always spawns 1px lower than the spawner's z-axis). This is precisely why type4/6 weapons such as Baseball & Milk/Beer are apparently unblockable when deflected; they simply change their velocity(which causes them to go into throwing frames if they reach a certain velocity threshold), not their facing. The game therefore thinks the deflected baseball is hitting the player from behind. Thus, counter-intuitively, in order to block a deflected weapon that you threw, you should actually block with your back.
   
3. There are also a few IDs that are hardcoded to always be blockable regardless of facing: 124(boomerang), 220(jan_chase), firzen_chasef/i(221, 222). The boomerang specifically has this property(regardless if swung or thrown) because the hit_Fa: 3 homing tag it uses doesn't actually let it change facing direction when thrown. For all 4 IDs, I suspect its also because the creators consider it too difficult to correctly determine which direction to face when blocking projectiles coming from directly above you.
   

If you use state 7 on a ball, it will act quite similarly to an aerial defense:
* If it hits or gets hit in the front, it will persist on like a state 15.
* It will appear to grind against an itr that doesn't destroy it with hitsparks silently.
* It will only be destroyed or rebounded if it is hit in the back or by an attack exceeding bdef60.
* It does not appear to use broken_defend frame 112.

Armor
id52(Julian), 37(Knight) & 6(Louis) all possess armor, which actually works a bit differently from defend & has a lot of hidden secrets.

Armor also uses bdefend points. However, while defend can always block a high bdefend attack albeit sent into broken_defend, armor can block as long as the character's CURRENT bdefend before the itr doesn't exceed the armor threshold, otherwise it simply doesn't work. That means for example, Louis can take a bdefend60 >>JA hit even though his armor threshold is only 1 point, but his armor will not be able to protect another hit for 59tu, which is the time it takes for his bdefend points to drop to 0.

Armor is able to tank normally unblockable attacks with bdefend >60, and if the armored character is defending he will go into broken_defend. This however, does not apply to bdefend 100 which simply ignores all defense.
Armor is also hardcoded to not be able to block id208 & 214 (john_biscuit D^A & henry_arrow2 D>J). So if you combine those two ids with bdefend >60, you can create an anti-defense attack that does not instantly destroy weapons as well.
Armor does not work if the character is in states 8(broken_defend), 11(injured), 12(falling), 13(frozen), 14(lying), 16(DOP) or 18(burning).
Armor continues to work but does not regenerate if the character is caught, which is important if using self-catch with an armored character.

There is a bug where if an armored character is defending(frame 110) but is hit from behind, the character still goes into hit_defend(frame 111). Similarly, if he is broken_defended from behind, he will appear to break defense in the wrong direction.

For specific characters' armor:
* Julian(52) & Knight(37) have 15 bdef threshold. Louis(6)' is only 1 bdef threshold.
* Louis(6) & Knight(37) armor is metallic & cannot protect against any itr with fire/ice(this includes effect 23).
* Louis(6) armor only works in frames 0-19, or when using state 4(jump), 5(dash) or 7(defend).
So if you want to make Julian/Knight have no armor at specific frames, try using state 8 or 11.
If you want Louis to have armor but not defend at certain non-air frames, try using state 4.
State 5 should only be used if you don't intend for Louis to move on x-axis but able to change facing direction.

There are 4 injury frames, and 6 categories of fall values:
fall <0 (negative) = no injury frames
fall 0 is the same as fall 20.
fall 1-20 = injury1(frame 220) OR injury2(frame 222/224 if you get hit in mid-air).
fall 21-40, front = injury2(frame 222). You fall instead if you get hit in mid-air.
fall 21-40, back = injury3(frame 224). You fall instead if you get hit in mid-air.
fall 41-60 = injury4(DOP frame 226). You fall instead if you get hit in mid-air. Itrs with this range of fall can hit falling characters and have stronger pushing power.
Anything more than 60 will just send you into falling immediately, can hit falling characters and have stronger pushing power.
Apparently, fall 80 is a magic number - it can cause balls to have the same power as a state 3005 ball, and seems to be related to the "multishot bounce" glitch..
* When you get sent into injury, your bdefend value is automatically set to 45.

Sounds simple right? Not quite. When you reach each fall threshold, your fall value is actually automatically set to the maximum for that threshold.

For example, let's assume Davis is using DvA(shrafe) against an enemy with 0 fall points. When the first punch connects, its fall is 1, which sends the enemy to injury1.
Because the enemy is in injury1, his fall is set to 20. The time between the 1st & 2nd punch is just long enough to account for hitlag & for the enemy's fall points to drop below 20.
Now the 2nd punch connects, and let's say the enemy's fall point is now 18. 18+1 is 19, so the enemy gets sent into injury1 again and fall is then set to 20.
This also applies if the enemy's fall point starts at say 30, then it'd be the same as above except the threshold is now 40 and he goes into either injury2 or 3 depending on his facing direction.

This also explains why fall25 & fall40, used for 2-hit DOP and baseball bat normal swing, behave so differently despite sharing the same injury frame. The first hit you land is virtually identical, its the 2nd hit that determines how far up the injury hierarchy to go. In this case, the 2nd fall25 hit(with roughly 5-7tu time discounting hitlag between hits) only raises the fall from 40(dropped to about 30-35) to about 60 for DOP, but the 2nd fall40 hit sends the fall value to 70-80. If you paused long enough between 2 bat hits, you can actually send the enemy into DOP instead of falling.

The reason why DOP infinites exist is because(not accounting for hitlag) DOP lasts for 28tu - enough time to lose just enough fall points to be hit into DOP again by fall 1-25 attacks. Said moves also often bypass the itr kind 6 super punch system either by the character's regular punching range or by simply not being a regular punch(and thus not accidentally trigger super punch).

The "pushing power" described in fall >40 is absolutely vital for fire attacks, lest the enemy becomes "fire-frozen" in the air. It is also used to make sure heavy weapons can be deflected (else the heavy weapon retains its momentum, though it'd still changes ownership regardless and become harmless to you) and more likely for frozen enemies to break upon landing on the ground.

In LF2, you can press commands like D^A/DJA etc by hitting all keys at once to trigger them at the current frame instantly, or you can buffer commands by pressing the inputs one by one consecutively. Most of the things listed here are a result of the buffer's quirks.

If you use DxA (where x is any direction), and then press J, you will perform DxA and then DxJ in succession.

In LF2, the inputs >,^,v take priority in descending order. Assuming you have valid inputs:
If you hit D>, and then D^A(or D^J/DvA/DvJ) simultaneously, you still use D>A(or D>J).
If you hit D^, you can only override Dv inputs; if you used D^ D>A it'd use D>A correctly.
Dv cannot override anything.
[according to LASER: DJA, D ↓ J, D ↑ J, D ← J, D → J, D ↓ A, D ↑ A, D ← A, D → A is the order of priority from lowest to highest.]

BluePhoenix debugged the walking frames and found that the way running is detected:
* when you hit left or right, the is_walking is set to -10(for left) & 10(for right)
* this number is reduced by 1 towards 0 every 1tu.
* this counter does NOT decrease when catching an opponent.
* this counter is reset when you do certain actions like jump, dash or defend.
As an example, when you're using Davis:
* > DvA(all buttons at once) >(just as the move ends) JA
* AAA >(grab) Ax4-5 DvA(all buttons at once) >(just as the move ends) A
* AAA >(grab) Ax4 >A >(just as the throw ends) A
Zort also wrote a detailed thread on this, detailing throw >>JA, though unfortunately the images are lost.

LF2 only detects one input at a time per game frame. That means if you played in really low FPS like if you used FPS changer or playing a laggy game online, you probably only want to slowly buffer D^A in advance, or press all the keys of D^A the instant you want it. Assuming you can't press all 3 keys, you can press D, and then the remaining 2 inputs together.

If you press a basic input like A within 5tu of the end of a move, you will automatically use A when you return to a neutral state. This is most clearly seen when playing in lag. [unverified]

As a tip for rolling in general: if you want to roll and then punch in the opposite direction, instead of pressing D < A, you should press DD < A. The 2nd D cancels the command buffer. This is especially useful if you're using Henry or Rudolf.

Type 5 objects are rarely used, but they have some useful interesting properties:

1. Has almost all behaviors of a Type 0 char. This includes camera movement.
   
2. Has no ground detection; will fall through ground. The only ways to circumvent this without dvy: 550 are to use state 400 or 401, or start as a type 0 on the ground that transforms into a type 5.
   
3. Can walk out of the map, and be deleted when that happens(the instant you reach 0px, unlike balls which have 300px of leniency).
   
4. Does not automatically change frames when falling; stuck at frame 180 or 186.
   
5. HP & MP does NOT regenerate!
   
6. Cannot use "Come/Stay/Move" commands.
   
7. When hit in the front in State 7, body appears to be hit continuously but without taking any damage.
   
8. When injured, does not have any injury sound.
   
9. Cannot be burned/frozen; will act as if normal itr kind 0.
   
10. Cannot be affected by itr kind 0 effect 20, itr kinds 8,9,10,11,15,16(heal,shield,sonata,whirlwind) (14 collision is okay).
    

This could use more testing. rewlf2 has made a thread regarding how he used this for his character Furzee.

arest(attacker rest) - you hit one person, and then you can't hit again for a while.
vrest(victim rest) - you can hit multiple people, but you can't hit the same person for a while.
Sounds simple? Its actually a bit more complicated than that.

First off, ever notice that in Deep or Rudolf's >>A, the first hit is arest and then vrest, so that it always hits twice?
This proves that arest & vrest are separate tags when hitting the same person. arest only cares if the attacker has hit someone before, vrest only cares if the victim has been hit by an attacker's vrest itr.

Secondly, the order of an itr in the data is important. The itr on top(the 1st one) has priority over the ones below - this is applicable to vrest. However, arest seems to work in a strange way. The game appears to somewhat randomly pick an arest itr to use, followed by picking a vrest below it but not any of the vrests above it. Unfortunately this "randomness" appears to work very inconsistently and seems to bug out when hitting multiple chars, its as though the arest is unstable.

Multiple arest (proc lowest to highest - values obtained from a test I did):
1 - A = 100%
2 - AB - 50% / 50%
3 - ABC - 28% / 26.5% / 45.5%
4 - ABCD - 11% / 10.5% / 28.5% / 50%
5 - ABCDE - 9% / 6.5% / 9.5% / 23% / 52%

There are various applications for this:
1) @Nyamaiku discovered that if you put 2 arest itrs, you can make an attack that has a 50-50 chance of hitting with either itr.
2) @YinYin discovered that if you could make a sweet spot for a critical hit, as he did with his Clide character.
3) Using arest + vrest in that order, you can make an attack that has a double-hit. This can be extremely useful for making an attack that pierces armor(bdef16+whatever) for instance, but do be warned that it can lead to bugs with fall values, just like the multishot falling injury bug(try fall100 arest + fall60 vrest).

This is an area that could use more testing, but I think the results are relatively consistent.

I recently discovered that Vrest is stored as a 16-bit signed integer. Some numbers:
0 = arest.
1-127 = this is the maximum range of vrest numbers.
128-255 = this is negative vrest, which hits as fast as possible, faster than even vrest 1.
256 = this is the actual vrest 0(no default number assigned). Behaves the same as negative.
257-383 = same as 1-127.
So that means Freeze's whirlwind vrest200 is actually vrest-56, and Firen's vrest300 is actually vrest44.

Arest numbers I've discovered so far:
0-4 = takes 7tu beteween hits (similar to vrest 7)
5 = takes 8tu beteween hits (similar to vrest 8)
6 = takes 9tu between hits (similar to vrest 9)
7 = takes 10tu between hits (similar to vrest 10)
8 = takes 11tu between hits (similar to vrest 11)
9 = takes 12tu between hits (similar to vrest 12)
10 = takes 13tu between hits (similar to vrest 13)
So on and so forth. So basically, arest has a minimum value of 4, and then it adds +3 to whatever your arest number is.

When an attack is defended, the vrest/arest are capped within a certain range no matter what arest/vrest value you have\
Vrest defend hardcaps are 4 to 12.
Arest defend hardcaps are 7 to 15; the +3 is not a coincidence.
So even if you have vrest 1 or 127, you always won't hit a defending person again until 4tu or 12tu later respectively.

Walking & running speed are activated when state 1 or 2 are used, and the player will autoloop into the default frames 5-8 and 9-11.
If carrying a heavy weapon, then it will loop into 12-15 and 16-18 respectively.

When walking diagonally, your x-speed is reduced by a factor of 5/7.
When running diagonally, your x-speed is reduced by a factor of 5/6.
z-speed is unaffected.
The x-speed factor is the same as regular walking/running respectively when carrying a heavy weapon.

If you set dv to a certain set of numbers >500, you will be able to set the object's velocity to a fixed number.

If your dvx is 501, you will ALWAYS move -49 (left)
If your dvx is 550, you just don't move at all (not the same as dvx 0 which is simply neutral i.e no acceleration).
If your dvx is 599, you will ALWAYS move +49 (right).

For Y and Z-axis, negative is UP, positive is DOWN (opposite of what you'd expect from math).
dvy 501-549 for 49-1 pixels up (fly).
dvy 551-599 for 1-49 pixels down (fall).

dvz 501-549 for 49-1 pixels up (background).
dvz 551-599 for 1-49 pixels down (foreground).

You can actually exceed 49px for down/right if you want(eg dvx 700 for 150px right), but I'm simply listing the range where all directions will be equal.

Bonus:
* dvX normally always deccelerates over time until it reaches the current frame's dvx value, which will be the minimum x-velocity.
* dvY normally works by acceleration. Using the dvy >500 property, you can instead set it to an exact number you want.
* dvZ normally doesn't force you to move in a certain direction, instead you have to hold ^/v.
* For type 3 objects, the hit_j tag serves an identical purpose to dvz>500, except the number is smaller by 500.
* When in mid-air, even if you set dvZ back to 0, you will continue moving in the last direction you were heading.
* dvZ overrides the default z-movement used for state 19 & 301 (which is the running z-speed).

The way LF2 determines whether an object is drawn in front of another object on the same z-axis depends on the object id(not the same as data.txt id) - that is the newer an object is, the more priority it has to be drawn in front over an older object.

When you opoint an object, you actually create the new object 1px below yourself on the z-axis. This effect is most visible when you take into account balls being reflected: try rebounding an energy ball between 2 John energy shields and you'd find that the ball(which is actually a new ball being spawned on each rebound) will move downwards over time.

When you carry an object with wpoint, the default "cover: " is 0. What this actually means is that the weapon is deliberately made 1px below the weapon-carrier's z-axis(i.e in front of him). Conversely, when cover: 1, the weapon is positioned -1px of the weapon-carrier's z-axis (i.e behind him). The exact z-position of the weapon is always rounded to the nearest integer.

When you grab a character with cpoint, not stating the "cover: " will actually cause the grab victim to stay on his current z-axis, which is why sometimes if you grab from the edge of your grab's zwidth, the grab victim sometimes appears to be at the top or at the bottom of your character. cpoint does make use of the cover tag to align the position as needed, as described accurately on mainsite with thanks to YinYin.

Mainsite hit_Fa page - a bit dated
Running some tests with 3 players(1 enemy, 2 allies) in HKC, I conclude that a homing ball will always chase the same target until it is no longer in hit_Fa homing state.

By default, all chasing balls will pick the nearest enemy at the point when it starts becoming homing as their target. If it loses its homing property via removal of hit_Fa (not by hit_a timer) and regains it again, it can pick a new target.

However, I would like to point out a few special cases where the chase ball does not pick the nearest target:
* Firzen's overwhelming disaster created by hit_Fa 9 & 11 will always split themselves evenly among enemies.
* hit_Fa 5 & 6 used by Jan will spawn 1 ball per ally/enemy respectively, and each will only go after that 1 unique target.
* Each bat spawned by hit_Fa 8 will target a random enemy.
* Skulls spawned by hit_Fa 13 will target a random enemy.
I am not aware if the random targeting has a maximum range, but if it does, I've no idea what the maximum distance would be.

It should be noted that john_biscuit (id 214) will automatically have its hp set to 0 and go into hit_d frames (which will never be homing again unless you modify it to continue using chase frames) when it hits.

Generally mainsite is good enough.
State 5
State 5 is used for dashing (>>J) in LF2. On its own, state 5 simply grants you the ability to change direction without any limitations - but there's a catch.

state 5 specifically detects for X-velocity. When x-velocity is detected, this state 5 frame will be converted into a dash frame - either dashback if moving backwards or dash forward if moving forward, and the hardcoded dash A input will be activated. It doesn't matter if you're in mid-air or moving on the z-axis, only x-movement matters.

One possible application is to make Woody's D^/vJ able to change direction mid-teleport, with the help of dvx550 to stop all x-movement to prevent the hardcoded moves from taking effect before applying state 5.

State 14
State 14 is used in LF2 to detect if a character is dead and makes the AI back away from you.
When the character is dead, no matter the original wait, the frame will repeat itself with wait 0 (1tu - unlike what mainsite says), and thus opoints will trigger every 1tu.

Blinking(i.e. cannot be hit) will be triggered when the following happens:
1. Character is not a player in stage mode (beware if you use Move After Death in stage mode!).
2. The state 14 frame has wait >0 and uses next into another frame (even if its another state 14 frame).
3. Exiting the state 14 frame using an input that leads to a frame with wait 0 and a next other than 0.

In the latter 2 cases, the blinking will last for 15tu (wait 14).

State 18/19 with itr kind 0 Effect 2
This particular combination of state and itr will make the type 0 character's itr NOT reflect projectiles, but rather send them into "frame 20 hit (balls)". This is used in Firen's D>J burnrun.

It should also be noted that state 18 is immune to state19 + effect 2 together.

State 19 & 301 z-movement
State 301 is identical to state 3, but it has a fixed dvz speed... which is entirely dependent on the running z-speed stated in "running_speedz".

This means you can actually have a decimal dvz speed! Unfortunately this property is very limited, since setting a dvz value on a frame with state 301 will just cause it to overwrite the default speed rather than add to it. Similarly, putting dvz in running frames will overwrite the running z-speed.

This also applies to state 19.

wpoint is a really useful tag for you to make any object carry another object without using cpoint, and then subsequently throw/drop the weapon for a variety of uses such as broken_weapon or replicating something similar to Julian's Soul Bomb exploding. It does come with a few special properties however:
1) Any itr by the "weapon" will automatically be able to rebound projectiles even if the "weapon" is actually a type 3 that should send projectiles into "hitting" frame. If said "weapon" uses state 3005/3006 or itr kind 9, it can even rebound state 3005/3006 attacks.
2) "Weapon" itrs as well as ik9 somehow cannot damage light weapons that are lying on the floor.
3) "Weapon" itrs will not hit grabbed teammates.

On another note, you can use itr kind 5 with weapon_strength_list on any object that you want to be held with wpoint(not just weapons). Do note that if you do this, you'll override all the itrs to have the same property based on weapon_strength_list, so this method is not recommended if you plan to do something like an explosion without using effect 22/23.

Source(Chinese): http://ztage.com/forum/viewtopic.php?f=10&t=14875&p=161776#p161776
When an wpoint uses attacking to activate itr kind 5, and the attacking uses a weapon_strength that has effect 4 and specific -fall values, this attack forces chars into a specific injury frame regardless of his fall points.

With effect 4, the fall system would basically have inverted numbers:
Fall: -80 ~ -100 = no injury
Fall: -79 ~ -60 = injury1 (frame 220), ALWAYS knocks down even in midair unlike regular.
Fall: -59 ~ -40 = injury2 back (frame 224)
Fall: -39 ~ -20 = DOP stun (frame 226)
Fall: -19 ~ 60 = causes falling, but without upward velocity (as if you used a fall40 bat to hit someone in midair).
Fall: 61 ~ 100 = regular falling.
It should be noted that no hit sounds will play and this always ignores defense like a bdefend 100 attack.

If you use effect20 or 21, it'd cancel out their special properties, treating it as a normal effect 2. Ditto for effect 30 being like effect 3.
Haven't tested on effect 22 or 23 though.

The mainsite article on cpoint's "decrease" tag appears to be complete nonsense.

When a grabber is holding someone, the grabber starts with a cpoint timer of "300".
The "decrease" value works similarly to hit_a in a ball; it will tick down non-stop every 1tu except during the 1st tu of EACH new frame.
Hitlag will cause the timer to tick down for longer than expected, generally for an extra 2tu from a grab punch (injury: 15 instead of injury: -15, since negative injury in cpoint removes hitlag).
Regardless positive or negative, the cpoint timer will still tick down. The only difference is that you will automatically drop your victim if the decrease is a negative number.

I can't test out the exact numbers, but it seems the grab attack usually only hits a maximum of 5 times for most characters, likely because aaction works slower than hit_a. If you use hit_a instead of aaction, you can grab punch BEFORE the decrease in the catching frame takes effect and thus can keep grab punching your victim infinitely.

Article on mainsite isn't too helpful if you want practical use for Stage dialogues etc.

The best, most practical way to make use of State 9997 is:
1) Positive centerx (graphic moves to the back, or left if you're facing right)
2) Object to be on the left side (if it were on the right, it would only show ~80px of the object at most)
---
3a) Object to also be facing(1) the LEFT side. (if you want the thing to appear on the rightmost possible position)
3b) Object to also be facing(10) the RIGHT side. (this makes sure the object is on the leftmost possible position)

When an itr of id 8(Freeze), 209(iceball) or 213(icesword) interacts with an energy ball(state3000?) of ids:
200(John), 203(Deep), 205(Dennis), 206(Woody), 207(Davis), 215(Dennis chase), 216(Jack)
The energy ball is directly changed into id209 in frame 40 - which will eventually go to frame 31 (same as iceball's rebound) to opoint a new ice ball in the opposite direction.
Incidentally, energy balls cannot hit iceballs and if iceballs' itrs were removed, both balls will just pass by each other. Presumably this is to prevent issues with the energy ball destroying the iceball before conversion etc.

Firen & Freeze (id6 & 7) need to touch each other during running(state 2) to fuse. Direction does not matter; it only influences who controls Firzen.
Fusion can only be done when both parties have 176hp or less, so safe to say when you see blood(or slightly above the bleeding threshold) you can both fuse. lf2.net removes this limit.
Fusion lasts for a maximum of about 2min30s or 4500tu. The player who was on the right is the one controlling the Firzen.
You will forcibly defuse when the timer runs out, even if you're in mid-air or doing some special move.
Upon defusing, both appear in broken_defend frame 112 & burning_smoke is created. The left player is spawned slightly to the left but not properly planted on the ground, so he quickly goes into crouch2 and recovers slightly faster.
A defusion cooldown of about 30s or 900tu is applied only on the player who controls Firzen, preventing him from fusing again.
The player who didn't get a chance to use Firzen however can continue to fuse with other partners until he himself has taken control of Firzen.

If one of the partners is an AI, direction is ignored and the player will take control regardless.
Firen & Freeze AI will NEVER run near each other, thus they will never fuse. It is not known what will happen if you try to force them to fuse by modding.

Due to a bug in the current version 2.0a, the stats of the player NOT controlling Firzen would be wiped out, so his stats would have to be recorded from scratch. However, the game will not record his kills or attack, so he would always have 0 kills and 0 attack. It is not known if its possible to unbug the kills & attack stats.

(credits to dixon for gif, bug #50.)
Alternate Video link(from 6:05 to 6:34)
It is possible for Rudolf to transform into Firen/Freeze and subsequently fuse with a partner to become Firzen.
Assuming Rudolf is in control, pressing DJA will cause "Firzen" to transform back into Rudolf. Transforming again will cause Rudolf to become Firen/Freeze rather than Firzen.
Rudolf's partner would apparently be gone forever. It is not known which partners can be saved if you ate multiple partners.
However, at least if you ate only 1 partner, he can be saved as long as you can find a Firzen to transform into as Rudolf.
This will cause Rudolf to instantly defuse back into Firen & Freeze, with Rudolf taking the form he originally was during fusion.
Rudolf can then revert back to Rudolf, and then transform again into Firzen properly.

If state8xxx is applied during fusion, the player who controls Firzen will use the _b sprite. It doesn't matter if the person controlling Firzen starts with a _b sprite, Firzen always starts off using his regular sprite until the frame with state 8xxx takes effect. Upon defusing, whoever was in control of Firzen would continue using _b sprites. However, the other player would always use normal sprites, even if he started off with _b sprites.

Directly opointing a type 0 character has several properties:
* Starting MP is 0.
* Maximum MP is locked at 150. Drinking beer/milk or proceeding to next stage temporarily exceeds the limit.
* If you transform or turn invisible, the clones will transform/turn invisible as well.
* You can only bring 2 clones with you to the next substage. It is not known how the game determines which clone makes it.
Only id5 & 52 (Rudolf & Julian) can opoint themselves with 10hp, otherwise if they opoint someone else or any other id opoints anything, HP is always 500.

If you want to break the link, you should instead opoint a type 3 that either opoints another type 0 or itself transforms into the desired type 0.

When is less than or equals to mp150:
* Firzen, Bat & Jan never use any of their special moves.
* LouisEX's AI doesn't use D>A.
* Jack's AI doesn't use D^A.
* John doesn't use D^A or Heal due to mp cost.
* Henry doesn't use D>J or D^J due to mp cost, and AI doesn't seem to use DJA.
* Rudolf doesn't use D^J/DvJ due to mp cost.
* Firen doesn't use D^J due to hp & mp cost.
* Freeze doesn't use D^J due to mp cost, and AI doesn't use D>J.
* Woody doesn't use D>J due to mp cost.
* Davis doesn't use D^A due to mp cost, and AI doesn't use DvA.

* It appears that only id200(John_ball) with itr kind 9 can make the AI act stupid around a John shield.
* It appears that only id211(firen_flame) with state 18 can make the AI act stupid around an inferno or explosion. Groundfire doesn't use state 18 and so it doesn't affect AI and they stupidly walk into them.

Quote:<Ramond_> i think you misunderstand, I'm aware the "current" frame will be interrupted and not wait out its "wait" value. but, let's say for the sake of argument we have frames A, B and C, all with wait 1.
normal frame sequence, A->B, but on hit_a in A, go to C. Doing the move normally will be A in frames 1,2 and B in frames 3,4 , then standing in 5
now, let us assume during frame 2, we hit a, will C cover frames 2,3 or 3,4? while I tend to the latter, the former would make more sense in the opointing problem
oh and perhaps also only cover frame 3 (if the first frame of the C move happens in frame 2, but it is not updated yet)
<Stm93> i mean, if we look at Davis' >>A... you actually end up skipping the itr that's supposed to be in the frame where you can press hit_a itself
<Ramond_> imo that could explain why opoints on frame 1 isn't triggered, because the first frame of that frame is actually skipped, kind of
<Stm93> and then there's times when it seems like i can hear the sound from a frame i skipped
<Ramond_> yeah this could actually deserve some thorough test
<Stm93> incidentally when i was testing Steiner, who is using a ball that is holding a weapon to be dropped, i made frame 0 have wait 0.
It created a huge bug where everything i spawned using that ball will always end up exploding because the weapon immediately goes to the explode frame for some reason. Same thing for the state18 flames appearing out of nowhere and the sounds playing among other things. i guess its kind of like what BP said about the drinking thing some time ago... apparently there's a half frame that isn't being shown in the game?
<Ramond_> in my mind, it's like (taking the example above) if press hit_a in frame 2 (during A), C will still occur in frame 2, but the change happens within the frame, so opoint doesn't trigger, and pic doesn't update and neither do the other tags
so internally it is in the C move but everything outside points to the A move, and in frame 3, the second frame of the C move applies
<Stm93> if that's the case, then what should happen is that if C is only 1 frame long and there's a frame D after that, it'd look like you skipped from A to D, while internally you went from A(frame1-2)-C(frame2)-D(frame3)?
<Ramond_> yeah i imagine it that way. so C never actually happens, but that should be tested, just a very rough hypothesis

Something I'll probably come back to look at:
* frames A,B,C,D. all have wait 1 except C wait 0.
* A frame 1-2. hit A during frame 2.
* frame 2 appears to be A but is internally C.
* frame 3 becomes D.
That'd be the result based on the hypothesis, will need to test.

by me.
Itr kind 11 is used to lift enemies who have already been lifted by ik10.

Without this ik11 buffer I notice that the flute tends to constantly only slightly lift up someone at the edge of the flute's AOE and then drop.