Little Fighter Empire - Forums - Tutorials

Comprehensive Guide of ItrKind:1 & ItrKind:3..? Secret Tech of Catchment.

Fri, 11 Feb 2022 09:25:14 +0100

(Bad english ;')(Would be happy if u would repost this post with better phrase/the better way of explaining.)

End up Position of ItrKind:1 And ItrKind:3 Control (Click to View)

Timed Heavy System

Fri, 17 Dec 2021 10:25:48 +0100

Idk if this trick/tech/.. whatever already invented somewhere but since i don't see a thread that talk about this, then lemme make it :'3

Explanation

By using the bug when an object that being held does OpointKind:2 which causing the character got stuck in his Heavy System, to then spawn an object on the stucked object that being held to destroy it whenever u wanted.

In short, this trick are just spawning an object when the char pick a heavy object to enter his heavy mode, but making the picked heavy object to stuck by using Ok2.
Nice, double useless explanation.

Abit lazy to explain in detailed about the way to make it, so just take a look to the Study Example if you're interested.

Study Example

Study Example - Timed Heavy System.rar (Size: 151.18 KB / Downloads: 186)

This template also including some cool skills anyway..
• AJ/DJ : Full Break Punch
• D > A : Breaking Pulse (100 MP)
• D > J : Magical Pulse (150 MP)
• D J A : Open Mode (500 MP)

By using Open Mode, template will increase his atk spd and enchant his Full Break Punch to enter his Overwhelming Mode that allowing him to spam Breaking Pulse within 7 seconds.

This template are just a result from complications of abilities in LF2ET.

Arest & Vrest - a comprehensive guide

Mon, 13 Dec 2021 20:14:11 +0100

This thread is about the Arest/Vrest system in LF2, as used in "itr:" tags and "Weapon_strength_list".
I am compiling what is known previously, and something that was shared in Discord, plus some of my personal input.

I will detail what arest & vrest are individually, as well as what happens when you mix these two tags (in multiple separate itrs, in a single itr, and in wpoint).

Arest: Attacker Rest
You can only hit x1 person. The default value appears to be 4.
However, arest has several complicated properties that are not commonly known.
* Arest does NOT count down during attacker's hitlag(3).
* Type 3 (balls) technically have 0 attacker hitlag, and so can immediately hit again upon next tu with arest: 1.
* Type 0 (chars) have a minimum capped arest of 4, even if you type arest: -1.
* Arest instantly resets to 0 when attacker goes to a new frame that has no itrs of any kind at all.
* Arest will pick a target at random.
* For some reason, arest has a maximum x-axis range of 1000 in each direction (so from -1000 to 1000, total 2000px).

To summarize the randomization if you put 2~5 arest itrs in the same frame:
* 2 arests: 50% / 50%
* 3 arests: 25% / 25% / 50%
* 4 arests: 12.5% / 12.5% / 25% / 50%
* 5 arests: 8.33% / 8.33% / 8.33% / 25% / 50%

Vrest: Victim Rest
You can hit **up to 20** objects, but not the same person again until after x time has passed.
It continues to countdown during hitlag;
Hence, vrest7 can be said to be equivalent to arest4 (unless you're using type 3, then v7=a7).

Default: 0 (vrest is not enabled)
BlockCap: 10 (if attack is blocked, the vrest inflicted is capped at 10)
Maximum: 127
Fastest: -1 (you get the same effect with numbers 128 to 256; vrest300 is technically vrest44)

Unlike arest, it is *not* random.
LF2 will always choose the 1st vrest itr from the top, and then go down the list.
If a vrest hits successfully, no further vrests below it will be calculated.

[v+a] Vrest(itr1) + Arest(itr2): Arest takes priority
This tech uses 2 itrs at the same time.
The order is important; the vrest being written above arest.

DC-Code:

itr: kind: 0  x: 22  y: 5  w: 58  h: 64  dvx: 12  dvy: 12  fall: 70  vrest: 12  bdefend: 60  injury: 70  effect: 1  itr_end: 
itr: kind: 0  x: 22  y: 5  w: 58  h: 64  dvx: 12  dvy: 12  fall: 70  arest: 9  bdefend: 60  injury: 70  effect: 4  itr_end:

In this example, Deep's >>JA will hit multiple enemies at the same time as usual.
However, if a ball/weapon gets thrown into Deep's sword, he will only hit the ball/weapon and not any characters his sword is attempting to cut.

If you have v1+a2+v3+a4, in that order,
You will randomly prioritize either a2+v3(50%), or a4(50%) only.

[a+v] Arest(itr1) + Vrest(itr2): Both hit, but with bugs
This tech also uses 2 itrs at the same time, again the order is important.

DC-Code:

itr: kind: 0  x: 22  y: 5  w: 58  h: 64  dvx: 6  dvy: -4  fall: 70  arest: 1  bdefend: 16  injury: 20  effect: 2  itr_end: 
itr: kind: 0  x: 22  y: 5  w: 58  h: 64  dvx: 12  dvy: -7  fall: 70  vrest: 12  bdefend: 20  injury: 50  effect: 1  itr_end:

In this example, the attack will hit twice at the same time; you will see 2 hitsparks.
* Normally, it does 70 damage. The enemy goes into falling(not burning). You will hear burning & cutting sounds.
* If you use cheat engine, you'll notice that the values I used for dvx/dvy will make the enemy fly at xspeed=12 exactly, and yspeed=-7.33333.
* You can bypass Louis/Knight's armor, because of the 1st arest itr inflicts effect 2.
* The attack can be blocked, but will send the blocker into broken_defend since 16+20=36 which greater than 30.
* You can bypass Julian's armor because the 1st arest itr inflicts bdefend 16, just enough to bypass armorclass 15. However, you will notice that Julian doesn't fly as far/high as normally, because his velocity is reduced due to the action of blocking the 1st itr, and he only takes (20/10)+50=52 damage.

However, if you use this attack on multiple enemies at once, its arest behaves inconsistently.
I find that it will always function properly against x1-2 enemies, but there is a chance the arest will fail to hit a 3rd enemy, and pretty much always fail to hit a 4th enemy.
Hence in practice, you'd find that only 2-3 enemies take full damage, while the other enemies only take the vrest damage.

This arest+vrest tech can be used to induce the injurybounce mechanic, which happens when a character reaches fall80 and then takes another hit, confusing the game and sending the character into injury frames while receiving falling velocity.

This tech can also be used to consistently inflict fall80 on type 3 attacks.
This is done by using itr 1[arest effect 4 fall: -70](set fall to exactly 10) and itr2[vrest fall: 70](add fall 70), therefore always triggering fall80.
Fall80 can destroy state3005/3006, and if frame 180/186 is defined in the type 3, it will be sent to those frames(based on direction hit) instead of frame20/30.

[a%v-1] Arest + Vrest: Within the same itr
Credits go to for sharing this tech on Discord and giving its name.
So it turns out that you can actually put both arest and vrest tags in the same itr.
Normally, this is pretty pointless since the vrest would sort of override the arest.
The trick is to use vrest: -1.

DC-Code:

itr: kind: 0  x: 22  y: 5  w: 58  h: 64  dvx: 12  dvy: 0  fall: 70  arest: 1  vrest: -1  bdefend: 30  injury: 100  effect: 1  itr_end:

The order is not important in this case, what matters is that you have both tags written in same itr.

In summary, it gives you an arest with vrest properties, by shorting out the rest values.
* You can hit multiple enemies at once, like vrest.
* However, you cannot hit any further enemies/objects during hitlag, just like arest.
* You can define the rest period via the "arest" tag, its minimum value is 1 instead of 4!
* It is not random.

This tech is useful if you want to say, buff John's super_punch to hit multiple enemies at once, but not cause him to hit the weapon that the enemies might be holding.
This can also be used to replace the normal arest for the a+v tech mentioned above, which largely solves the lack of consistency problem when hitting more than 2 enemies.

However, this tech has a few important caveats:
(1) If the enemy has more than 1 bdy, and the itr overlaps both of those bdys, it will hit that same enemy multiple times.
(2) This attack can only hit up to 20 times (same as vrest).
(3) The itr will prioritize enemies lower on the object memory list.

#1 is a very big problem if you intend to use this tech in original LF2, because it will appear to cause random x2~3 damage/fall etc when hitting enemies in certain frames. Therefore, this trick is only recommended for full mods that intend to standardize everyone to have only x1 bdy.

#2 and #3 are more relevant if you intend to use multiple a%v-1 itrs or enjoy large Battles.
Suppose you use x3 of such itrs, and you(Player 1) are attacking Players 2,3,4, who have x5 bdy each.
* You will ALWAYS hit Player 2 a total of 3x5=15 times.
* You will ALWAYS hit Player 3 a total of 5 times.
* You will NEVER hit Player 4.

Itr Kind 5 + Wpoint: Attacking(Weapon_Strength_List)
Incidentally, ik5+wpoint also have some arest/vrest related magic.
(1) weaponStrength[vrest], ik5[arest]; original lf2 weapons.
(2) weaponStrength[vrest], ik5[vrest]; basically normal vrest.
(3) weaponStrength[arest], ik5[arest]; basically normal arest.
(4) weaponStrength[arest], ik5[vrest]; actually the same as a%v-1 tech.

#1 is what you see in original LF2 weapons.
Notice that if you swing a weapon at multiple enemies, they will fall over one by one instead of altogether at once like in a normal vrest(#2).
Therefore, v%a-1 *technically* exists in LF2, but as far as I know, it is only available through weapons, and appears to be a pretty impractical tech when proper vrest and a%v-1 tech exists.

#4 while you cannot directly put a%v-1 tech into weaponStrength, you can get the exact same results by putting vrest ik5 in the weapon's on_hand frames, and then using an attack value from the weapon_strength_list that uses arest.

Can I mix a%v-1 with arest/vrest?
a%v-1 + arest (both orders) behaves pretty randomly, I do not recommend it.
That being said, in my tests, arest + a%v-1 in that order seemed to have better success in hitting multiple enemies(around 2-3) to get hit than a%v-1 + arest in that order. I would advise messing around to get better sample data for your needs.

a%v-1 + vrest (in that order) as advised is a good alternative for arest+vrest, but beware the more than 1 bdy problem.

vrest + a%v-1 (in that order) will always prioritize vrest first. However, I also do not recommend this; on testing with vrest(itr effect 4)+a%v-1(normal), I find that if you hit a weapon/ball, it will actually short the vrest, causing you to be able to double-hit enemies.

Overall, it seems the most suitable applications for a%v-1 are:
a) Making an attack hit up to x20 enemies in an instant, but not during hitlag.
b) Making an attack that needs to perform up to x20 simultaneous hit on the exact same target.

[v-1v%] Vrest(-1)(itr1) + Vrest(itr2):
After everything above, it turns out Arest+Vrest and [a%v-1]+Vrest is a bit obsolete for the purposes of simultaneous hits.
Just use vrest: -1 and vrest: %.

Other Notes:
This tech is not exclusive to kind 0; it can be used for other kinds itr kind 3(catch)/8(healball).
I have managed to use x4 itr kind 4 + x1 itr kind 1 and 4 bdys to make it such that ik1 always grabs the person with the lowest object number instead of attempting to catch everyone.
Feel free to experiment and find more possible practical uses.

A Certain Position Image

Mon, 01 Nov 2021 08:59:09 +0100

....

Kinda dunno why i'm doing this... (bad english warning '-'). (Might just wanna increase my green star .__.)

Explanation

A certain position image is a DC trick that manipulating/controling an Object's PIC/Appareance to be disappear or appear based on Camera's position. This trick are using a bug where when an Object/ID load an image that has smaller size than the Object/ID needed/wanted/trying to load in the , which will make the Object/ID's appreance become invisibile at certain position.

The trick itself doesn't giving any effect to the gameplay except the appreance of an object, but this trick might made your char become cooler.

Example

As you can see, the black background will only visible at certain position.

Well, i don't... i mean, i can't giving the study example about this trick, but here's the example of the object that will be the background, this is should be enough info if you a DCer. Just Opoint the Frame 300 of this object with FACING: 10 and give it the black_layer.bmp with 795 x 510 Px size.

readme.txt (Size: 659 bytes / Downloads: 122)

Well, just wait for 2022, about the example of the trick usage if there's no one will use this trick.
(hopefully, this won't just become a word. ;'))

Furthermore

Anyway, this trick kinda need some calculation to be made perfectly, so be prepared to be confused if you wanna use this trick furthermore, well here's another info about this trick.

Basic Mechanism (Click to View)

Additonal (Click to View)

Significant Frame Numbers

Sun, 29 Nov 2020 05:31:03 +0100

This is a reference page for ALL hardcoded frame numbers, regardless of data type.
Catching/Picked_Caught/Throw_Lying_Man is actually not hardcoded.

Let me know if I missed out anything that is frame specific.

ID Specific - excluding broken_weapon fragments.
id6, fr300 onwards = LouisEX transform's HP Lock. Yes, it is tied to a frame, not to the actual DJA input.
id51, fr290 = Fusion.
id200, fr50-59 = Healball lures <50% darkHP teammates. fr60-69 = JohnShield's effect on enemy AI(repel & prevent weapon pickup).
id209, fr40 = energyBalls converted into iceballs will go to this frame.
id211, type3_hitFa13 always spawns fr50(grdfire) and fr109(exp).
id212, fr150-159 = Whirlwind's effect on AI. type3_hitFa13 always spawns fr100(icicles).
id212, all frame numbers ending in 0(eg: 0,10,20,...380,390) will be able to hit allied icicles despite being type3.
id221, fr81 = spawned from type3_hit_Fa13.
id998, fr0,2,4,6 = come/stay/move/join respectively.
id999, fr101 = lands on this frame.

frame
0 = THE default frame; extremely important. st8xxx, cpoint injury -1, finish drinking, invisible, catch interrupt, weaponDropFromSky etc... all will return here.
5-8 = Walking Loop.
9-11 = Running Loop. Type0 spawned in Stage without indicating act: will default to 9.
12-15 = Walking(heavy) Loop. 12 is the heavy default.

10 = state3000 upon hitting something.
0-5 = wpoint kind3 will drop its weapon in one of these 6 frames at random. Also heavy_weapon sky frames.
0-15 = weapons that get hit, or dropped by state10/12, or state1002 hitting something(gains dvx-2,dvy-2) will go to one of these 16 frames at random. Linked to 40-55 for throwables/drinks. heavy_weapon dropped by flute/shield also goes to these set of frames(resulting in occasional bugs).

1-2 & 3-4 = used by type3_hitFa2 dennis chase.
0-9 & 50-59 = used by type3_hitFa14 skull chase.

16-18 = Running(heavy) Loop.
19 = heavy_stoprun.
20 = normal_weapon_attack, Type3 upon taking a hit. Landing frame for Type2.
25 = normal_weapon_attack2.
30 = jump_weapon_attack, Type3 upon getting rebounded.
35 = run_weapon_attack.

40 = dash_weapon_attack.
wpoint dvx/dvy weaponthrow always sends weapon to this frame.
type3 hit_Fa7 spawns this frame as a tail.
state 3005 getting hit by itr kind 9 will go to this frame as well.

45 = light_weapon_throw
50 = heavy_weapon_throw
52 = sky_weapon_throw
55 = drinking

40-55 = Linked to 0-15 for throwables/drinks.

60 = punch. landing frame for light weapons & type3(hitFa7).
65 = punch2.
70 = superpunch. also landing frame for light weapons.
80 = jump_attack
85 = run_attack
90 = dash_attack
94 = landing frame for state100 on Type0 only.
100 = rowing.
102 = Rolling.
108 = rowing_back.
110 = Defend. Can change direction.
111 = getting hit while in 110.
112 = broken_defend. Firen & Freeze will actually enter these frames upon de-fusing, but one of them will be in midair for some reason.
115 = picking light weapon via ik2.
116 = picking heavy weapon via ik2.

180/186 = fall(61-80) && yspeed -10 or lower. Always goes here if hit by physical attacks while in state13. Please note that type3 can enter these frames if they get sent to fall80 EXACTLY.
181/187 = yspeed >-10. Cpoint released by "decrease" goes t0 181 with dvx2/dvy-2.
182/188 = yspeed >0 (can flip)
183/189 = yspeed >6
184/190 = unused, but has trajectory detection.
185/191 = bounce(dvx2,dvy-2) upon landing if xspeed >10 or yspeed >1.

200-201 = Frozen. Also generates ice particles. Immune to itr effect 30 (yes, its tied to frames, not state 13).
202 = Grants 20tu of blinking timer! (compared to 15tu for state14 blinking)
203-204 = Burning while dvy <0. Hardcoded trajectory detection & landing frame on state18.
205-206 = Burning while dvy >0. Hardcoded trajectory detection & landing frame on state18.
210 = Default Jump input.
212 = state0/next999 goes here if in midair. Using next212 will automatically trigger jump. Lands in frame215 instead of 219. If victim in cpoint kind 2 stops being grabbed, he is released into this frame with dvy-2.
213 = dash(forward). state5 automatically goes here if you have any form of dvx.
214 = dash(backward). state5 automatically goes here if you have any form of -dvx.
215 = type0 will land here if they are in frame212 or have state6. Has dvz determined by dash_distancez. Can press D=roll, J=dash.
218 = stop_run.
219 = default landing frame for type0. This is also used when "I join you" happens, with a longer wait duration.
220 = injury(fall1-20)
222 = injury(fall21-40) or midair fall1-20, front.
224 = injury(fall21-40) or midair fall1-20, back.
226 = stun(fall41-60)
230 = lying(front)
231 = lying(back)
245 = transformBack frame if you untransform from Rudolf's DJA(cpoint injury -1).
399 = no special property, but this is the highest frame number possible per data file.

Remove flipping from falling frames(and unused frame 184/190)

Wed, 24 Oct 2018 02:42:44 +0200

In LF2, being able to flip from frame 182 and frame 188 is a hardcoded default input, even if you changed the state from 12 to something else.
Furthermore, if you tried to use a custom frame with state 12, you'd find that the falling animation would no longer be trajectory-sensitive.

Well, I've found a way to remove flipping from an LF2 character for good, and also allow you to make a custom flip with hit_j that actually costs MP to use.

The trick is to set frame 182/188's wait from 3 to 0, and then change their next from 0 to 184/190 respectively.
Now, it'd look consistent in regular play, but you'd find that if you did F2 pausing, you'd see the character appear to glitch graphically, as seen here:

The reason why I used frame 184/190 is because they happen to be unused falling frames, yet they are trajectory-sensitive. So even if you next into 184/190, the game will frantically try to bring you back to frame 182/188, only to immediately next back into 184/190.(in the gif, I used frame 183/189 instead)

To fix that, we'll make frame 184/190 identical to 182/188.

You will also need to fix the freezing frame 202 to use next: 181(or 184 if you prefer) instead of next: 182, otherwise you'd still be able to instantly flip as soon as you thaw from being frozen for too long without getting hit.

The data would look like this:

DC-Code:

 182 falling
   pic: 32  state: 12  wait: 0  next: 184  dvx: 0  dvy: 0  dvz: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0
   wpoint:
      kind: 1  x: 38  y: 43  weaponact: 21  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 
   wpoint_end:
   itr:
      kind: 4  x: 13  y: 18  w: 46  h: 26  dvx: 2  fall: 70  vrest: 20  bdefend: 10  injury: 30  
   itr_end:
   bdy:
      kind: 0  x: 27  y: 22  w: 20  h: 18
   bdy_end:

...
 184 falling
   pic: 32  state: 12  wait: 3  next: 0  dvx: 0  dvy: 0  dvz: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 203
   wpoint:
      kind: 1  x: 38  y: 43  weaponact: 21  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 
   wpoint_end:
   itr:
      kind: 4  x: 13  y: 18  w: 46  h: 26  dvx: 2  fall: 70  vrest: 20  bdefend: 10  injury: 30  
   itr_end:
   bdy:
      kind: 0  x: 27  y: 22  w: 20  h: 18
   bdy_end:

 
...
 
 188 falling
   pic: 42  state: 12  wait: 0  next: 190  dvx: 0  dvy: 0  dvz: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0
   wpoint:
      kind: 1  x: 29  y: 35  weaponact: 22  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 
   wpoint_end:
   itr:
      kind: 4  x: 14  y: 29  w: 58  h: 23  dvx: 2  fall: 70  vrest: 20  bdefend: 10  injury: 30  
   itr_end:
   bdy:
      kind: 0  x: 30  y: 31  w: 24  h: 21
   bdy_end:

...
 190 falling
   pic: 42  state: 12  wait: 3  next: 0  dvx: 0  dvy: 0  dvz: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 203
   wpoint:
      kind: 1  x: 29  y: 35  weaponact: 22  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 
   wpoint_end:
   itr:
      kind: 4  x: 14  y: 29  w: 58  h: 23  dvx: 2  fall: 70  vrest: 20  bdefend: 10  injury: 30  
   itr_end:
   bdy:
      kind: 0  x: 30  y: 31  w: 24  h: 21
   bdy_end:

 
...
 
 202 ice
   pic: 105  state: 15  wait: 1  next: 184  dvx: -4  dvy: -3  dvz: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0
   wpoint:
      kind: 1  x: 18  y: 44  weaponact: 20  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 
   wpoint_end:
   bdy:
      kind: 0  x: 8  y: 6  w: 67  h: 73
   bdy_end:

In this example, I've added hit_j: 203 to frames 184/190, meaning instead of flipping you can set yourself on fire. You can add an mp cost if you so desired.

If you try to use hit_j into frame 100/108, you'll notice that you would lose the default trajectory of the flip that you can set in the stats at the top of each character's data, but that's a minor problem since the goal in the first place is to change the flip.

Finally, you can use frame 184/190 for burning frames to add a potential 3rd/4th frame for burning as well! Feel free to experiment with this.

That'd be all, enjoy this new tech!

EDIT:
There is just one tiny little problem with using the hit_j custom flip.
You can now flip out of Henry's D^J flute! XD

State machines and itr (Interaction) Studies in LF2

Sat, 26 Aug 2017 07:10:39 +0200

This essay is aimed to provide a detailed explanation regarding how state and itr parameters take effect inside LF2.

This will expand without prior notice.

Before you read on
This essay is a collection of studies which has much deeper knowledge compared to what is hosted on LF-empire site DC tutorial.
This includes research results of Managing playable type: 3, 5 characters, which is highly abstract.
The essay will frequently use terms regarding state machines, and will have a sick amount of pragmatic (and possibly incomprehensible) code and psuedocode.

I would use code similar to this:

Code:
frame XXX

if (some condition)

  do something

  do something

else

  do something else

frame XXX_end

Although a player character and non-player character are designed to be type: 0, there will be a lot of facts which are tested by using non-type: 0 characters.
Because of that there are a lot of possibly unwanted information but I will try to show the final results clearly.

Human States

State: 0

The standing state.

If a character's hit_a parameter is 0, it will run the following check.
If hit_a isn't 0, the parameter will override the whole check. (I assume later examples will also override unless specified)

If the controlling player (including computer, I assume laters samples include computers unless specified) presses A, the system will check if the character is holding a weapon.

If he is holding a weapon, he has 50% chance to go to frame 20 and 50% chance to go to frame 25.
If he holds no weapon, he has 50% chance to go to frame 60 and 50% chance to go to frame 65.

I will explain weapon usage and super punch in details later.

If a character's hit_j parameter is 0, he will go to frame 210 when J is pressed. Otherwise the parameter overrides.

If a character's hit_d parameter is 0, he will go to frame 110 when D is pressed. Otherwise the parameter overrides.

If direction key is pressed, character will go to one of frames 5-8, but the initial frame it goes to is neither random nor fixed.

However, if both of these happen (Left and right are both or neither pressed) (up and down are both or neither pressed), the direction keys are cancelled.
This can be represented by logic condition (up XNOR dn) & (lt XNOR rt)

A character (pragmatically, any object including weapon and projectile) has a hidden "walking counter" that counts from 0 to 5 whenever a tick has begun when the character is in state: 1.
The counter starts at 0 when the character is spawned.
The specific frame when a character goes to when he moves from state: 0 is:

C=0 -> Frame 5
C=1 -> Frame 6
C=2 -> Frame 7
C=3 -> Frame 8
C=4 -> Frame 7
C=5 -> Frame 6

The period of a tick is equal to (walking_frame_rate+1) tu, but exe will crash if walking_frame_rate is set to 0.

There is bad code hidden in lf2 that causes a simultaneous key input of JA and DA to go to frame 210 or 110 respectively, listed by Yinyin here.

If no button is pressed, a hidden standing counter will be incremented. Whenever this character leaves a frame with state: 0, this counter is reset to 0. The counter similar to walking counter except its highest possible number is equal to total tu of walking frames.
For example, if a character has standing frames with wait 3,4,5,9, the counter can go to maximum of (3+4+5+9-4) = 17tu.
Which standing frame the character goes to is determined by the counter.

State: 0 machine (Click to View)

Picking up a weapon is NOT related to state: 0.

State: 1
The walking state, it acts very similar to state: 0 (there are some misconception regarding this state though)

It acts identically as state: 0 regarding A, J and D buttons,

If direction key is held, it will determine if walking should be continued.
If direction key is released, although the character will go to standing, there is a hidden running initiation counter that records the last left/right key pressed and its initial press time.
If the same direction key is pressed quickly after the last key press, it will trigger running.

Also notice a hit_x tag leading to running frame grants the character automatic running.

State: 1 machine (Click to View)

Grabbing a stunned person is NOT related to state: 1.
Picking up a weapon is NOT related to state: 1.

State: 2
The running state, this also has a hidden running timer which maximum number equals to 3. It is very similar to walking counter except with 4 transitions:

C=0 -> Frame 9
C=1 -> Frame 10
C=2 -> Frame 11
C=3 -> Frame 10

If hit_d parameter is 0, character will go to frame 102 (rolling) when D is pressed.

If hit_j parameter is 0, character will go to frame 213 (forward dash) when J is pressed.

If hit_a parameter is 0, character will check if he holds a weapon when A is pressed.
If he holds weapon he goes to frame 35 (run_weapon_attack)
If he doesn't hold, he goes to frame 85 (run_attack)

If an opposite direction key against his running direction is pressed, he will go to frame 218 (stop_running)

hit_XX are disabled if a character is holding a heavy weapon via itr kind 2, state: 2 itself doesn't disable hit_XX. For details go the section for itr kind 2.

State: 2 machine (Click to View)

State: 3

State 3 is the "Attack" state, which has NO state machine inserted into it.
It is very similar to State 15 except State 15 does not provoke defense on computer characters.

State: 4

The "Jump state" is an aerial state that takes some well-known and some hidden properties.

If hit_a parameter is 0, character will check if he holds a weapon when A is pressed.
If he holds weapon he goes to frame 30 (jump_weapon_attack)
If he doesn't hold, he goes to frame 80 (jump_attack)
It does not work when character is on ground.

If an opposite direction key to what he's facing is pressed, he changes direction.
It does not work when character is on ground.

There's no J and D state machines here, but a hidden issue that if a character with state: 4 gains velocity in either direction, he will change into falling frame.
This can be presented by the dazed Louis bug, where Louis tried to jump but his armor taking a hit will render him fall to ground instead.

Landing in a frame with state: 4 does not mean character will go to frame 215. Frame 212 is actual cause, that regardless of its state will result in going to 215.

State: 4 machine (Click to View)

State: 5

The dashing state uses y-axis-velocity, direction control and initial direction to interchange between 4 frames, namely 213, 214, 216 and 217.
The 4 frames represent the following:
213: Forward dash 1
214: Forward dash 2
216: Back-facing dash 1
217: Back-facing dash 2

If a character is in frame 213, pressing opposite direction will go to 216, vice versa.
If he is in frame 214, pressing opposite direction will go to 217, vice versa.
If he changes into frame 213 or 216, there's no hidden cooldown and frame countdown is refreshed.

If hit_a parameter is 0 and character is in frame 213 or 216, character will check if he holds a weapon when A is pressed.
If he holds weapon he goes to frame 40 (dash_weapon_attack)
If he doesn't hold, he goes to frame 90 (dash_attack)

Henry and Hunter can use dash backward shoot because there is hit_a: 81 written on frame 214 and 217.

State: 5 machine (Click to View)

State: 6

Rolling/Flipping State: 6 is identical to state: 15, has no effect on computer behavior and has NO state machines in it.

When a player is rolling he can press A to pick a weapon, however it is NOT caused by state: 6, but itr kind: 7.

If a character in state: 6 lands from air, he goes to frame 215. Character in frame 212 landing will also go to frame 215.

State: 7

State 7, the defending state is a well-known state for developing special characters.
Apart from its defense system which is well covered by others, there are something regarding hit_x keys about state: 7.

If a character is in state 7 and frame 110, and takes a blow that doesn't break his defense, he will go to frame 111.

Taking a blow that doesn't break defense outside frame 100 won't change frame.

Breaking defense makes character go to 112, but if character is in air or grabbed into state: 7 frame, his state: 7 frame cannot be broken.

Nonetheless an attack with bdefend >60 can negate state: 7.

If a character in frame 110 (but not necessary in state: 7), he can change his direction if he presses opposite direction key as his current facing.
This only affects frame 110.

frame 110 machine (Click to View)

State: 8

Broken defend State: 8 is identical to state: 15, has no effect on computer behavior and has NO state machines in it.

When a player is in broken_defend frames, hostile character pressing A will go to frame 70 (super_punch), but it is not caused by state: 8 but itr kind: 6 emitted by the frames.

State: 9

Catching, State 9 has no innate state machine.

The catching properties is done by cpoint parameters.

In an experiment, putting state: 0 on frame 121 overrides all cpoint properties, so there's little need for a separate state machine on state 9.

State: 10

Caught, State 10 has no innate state machine.

Object from any team can interact with an object in state: 10.

State: 11

Injured, State 11 has no innate state machine.

Knight and Julian lose innate armor in state 8, 10, 11, 16,
Louis's armor is only effective in frame 0-19 or state: 4, 5 frames.

State: 12

Falling, State 12 has a state machine when the object is also a type: 0.
Any non-character with state: 12 frames are not affected.

The state machine is similar to dash system, using y-axis velocity and facing direction to display falling animation.

Any characters being sent to falling frame will either start in 180 or 186.
He will immediately go to frame the machine indicated after 1tu.
The frame which the character will go to is as follows:

Frame 180/186 = velocity_y-8 or lower
Frame 181/187 = velocity_y>-8
Frame 182/188 = velocity_y>0 (can flip)
Frame 183/189 = velocity_y>8
Frame 184/190 = (apparently unused according to rewlf2)
Frame 185/191 = (bounce)
Bounce happens when xspeed is >10 or yspeed >1. The bounce itself has a cap on its speed.

If someone has a large negative yspeed, he will stay in frame 180 for some time before velocity_y exceeds -8.

Putting a dvx tag in falling will not change facing direction of character, but dvy tag will change its frame because y-axis velocity is changed.

Character hitting ground will be set to a fixed x and y-axis velocity which again is affected by gravity, and goes to frame 185 or 191 (forward or backward)

An object with state: 12 is immune to any attack that has less than 41 fall, and will automatically drop weapon, like the effect of wpoint kind 3.

State: 12 machine (Click to View)

Flipping function in frame 183 and 188 are independent of state and type. I once stumbled with a glitch that allowed a type: 3 character to go to frame 108 when she's in frame 188. It appears 183 and 188 are separately hardcoded to allow flipping.

Flipping machine (Click to View)

State: 13

Ice, State: 13 has no innate state machine, although it alters the reaction frame when attacked by an itr.

A detailed explanation of state: 13 is here.

There also seems to be a threshold for ice characters to not break if he lands on ground with too small x-axis and y-axis velocity.

State: 14

Lying, State: 14 has a condition-based state machine which either grants the character blinking status after he leaves the frame, gives a retreating warning to computer characters, or loops the frame every tu if the character has no current health.

The computer-warning part is not explained here but the state machine is as follows:

State: 14 machine (Click to View)

Note that if a character has 0 health is revived by F7, the lying frame countdown will start at when F7 is pressed.

State: 15

Normal action, State 15 has no innate state machine.

State: 16

Stunned, State 16 has no innate state machine.

Only a character with state: 16 can interact with a hostile's itr kind: 1. The hostile will perform a grab if hostile is pressing a direction key and itr collides with state: 16 character's bdy.

A stunned character can trigger a super_punch for the hostile, but it is caused by itr kind: 6.

State: 17

Drinking, State 17 has no innate state machine.

Frame 55-58 responsible for drinking action has NO state machine, if a character presses D in these frames, they stop drinking because there are hit_d: 999 in these frames.

State: 18

The fire state uses y-axis-velocity but has no direction control.
There are 4 frames representing the following:
203: Upward fire 1
204: Upward fire 2
205: Downward fire 1
206: Downward fire 2

Changing frame 203-206 to use state: 15 disables the state machine.

When a type: 0 character is in state: 18 and in frame 203-206, the next frame is determined by current y-axis speed.

If character is going up, next frame will be 203/204, otherwise will be 205/206
The exact frames are not confirmed and it is unknown if non-type: 0 share this property.

A state: 18 character landing will always be directed to frame 185 (forward bouncing)

state: 18 characters are immune to itr held by state: 18, 19 objects and itr with effect 20.

state: 18 characters can hit projectiles (example: soul bomb's explosion and firen's inferno), itr effect: 20 doesn't hit projectiles though.

State: 18 machine (Click to View)

Note that state machine doesn't change frames if characters is rising in frame 203/204 or falling in frame 205/206

State: 19

Firerun, State 19 is a state that allows a z-axis movement based on running_speedz, generates fire smoke and be immune to certain fire attacks. There is no state machine on this though.

state: 19 characters are immune to itr held by state: 18 objects and itr with effect 20.

State: 19 characters attacking state: 3000 projectiles will change their frame to 20 (hit) not 30 (rebounding)

State: 100

Special landing, State 100 changes the mechanism on landing frames, character must be directed to frame 94 if he is landing.

There is no state machine added, just altered.

State: 100 machine (Click to View)

State: 301, 400, 401, 1700

State 301 is a state that allows a z-axis movement,
400 causes character to teleport to ~120 pixels in front of nearest enemy,
401 causes character to teleport to ~60 pixels in front of furthest ally,

the first frame of state: 1700 adds 100 "flashing heal" points that is the effect of itr kind: 8, which causes the character to heal up to 100 HP or the difference between red and brown HP, whichever the lower.

Multiple state: 1700 frames do not stack flashing HP, but will set flashing HP to 100. In effect of state: 1700 frame the bar flashes but flashing HP does not start restoring. Only regular restoration occurs.

Flashing HP shares display with healing from Jan's Angel but have independent counter. When both of them are in effect the HP bar will restore HPs with both the rate, but will a distinct interval difference between the two restoration methods.

There is no state machine on these though.

State: 500, 501

Rudolf's Transform should be better explained here:
Rudolf's transform attack

State: 8XXX

Hostage transform, State: 8XXX (8000-8999) will cause character to change into the id: XXX.
This transformation will cause the character to go to frame 0 when id is changed.
The character will try to use frame number with +140 offset.

Transforming into Knight will try to use +140 offset sprites which normally will glitch display.

State: 9995

LouisEX transform, State: 9995 will cause character to change into the id: 50.
This transformation will cause the character to go to frame 0 when id is changed.
This will not give an offset on frame number

State: 9996+

9996 generates a set of LouisEX's armor
9997 causes the object to take a message property.
9998 deletes object
9999 functions exactly like 15

None of these probably ever needs state machine.

Weapon states

State: 1000

Light weapon fly freely in sky in this state.
Whether it will damage others is dependent on if this frame has an itr.

Light weapons in original LF2 have no itr in any state: 1000 frames.

Baseball, milk and beer will not go to frame 0-15 (which have state: 1000) even if they are hit by itr with less than 60 fall.

Others light weapons will go to frame 0-15, which frame it goes to is random.

State: 1001

Held state.
The weapon frame number and action is controlled by the object having wpoint interaction over it.

State: 1002

Weapon thrown in this state.
This is typically directed by a wpoint throw,
but milk, beer and baseball will go to thrown frames even when hit by low fall frames.

State: 1003

Weapon just on ground.
Studies on non-type: 0 characters revealed if a character with weapon type drops to ground, he will go to frame 20, 21 (heavy object) or 70, 60 (light objects).

Therefore state: 1003 does not have state engine, the ground collision is determined by type of object.

State: 1004

Weapon on ground.
Object in this state can have a bdy that interacts with itr kind: 2 of the character, the character links the object via wpoint.

1004 will cause picking character to go to picking_light frame.

State: 2000

Heavy weapon fly freely in sky in this state.
Whether it will damage others is dependent on if this frame has an itr.

Heavy weapons in original LF2 have itr in state: 2000 frames, thus the random stones hitting unlucky characters.

If a heavy weapon is hit by itr with fall: 70+, it will change its frame to 0-5 in random.

State: 2001

Held state.
The weapon frame number and action is controlled by the object having wpoint interaction over it.

State: 2004

Weapon on ground.
Object in this state can have a bdy that interacts with itr kind: 2 of the character, the character links the object via wpoint.

2004 will cause picking character to go to picking_heavy frame.

A study revealed hit_d, hit_j and hit_a of which picking_heavy will lead to will be inherited exactly for the picking_heavy frame.

If picking_heavy has next: 999 and frame 0 has hit_d: 99, when picking a heavy weapon and immediately pressing D, character will go to frame 99 but is incapable to use and commands inscribed in frame 99 (and following frames). Afterwards character goes back to heavy_walking.

To fix it, set frame 117 to have next: 12 (heavy_walking)

Projectile states

States - State 300X - Ball States

itr (interaction)

Kind: 0
The most common interaction, this will cause the following effects:

If the itr is held by type: 0 (Character), 2 (Heavy weapon), 5 (Etc),
Attacker will suffer from hitlag but will not change frame.

If the itr is held by id: 201/202 (Henry's arrow or Rudolf's dart) and it hits a type: 5 object, it will not change frame. (As per saving hostage with arrows and darts)

If the itr is held by type: 1(light weapon), 4(baseball), 6(drink),
Attacker will go to frame 0-15 in random

If the itr is held by type: 3(projectile), it checks for defender's state.
You can see States - State 300X - Ball States for details.

If a defender is type: 3 but is of state 0-15, it is found if defender is hit it will go to frame 20 or 30, depending on type of attacker. If attacker is type: 3 but is of state: 0-15, attacker will suffer from hitshake but will not change frame and will not suffer from hitlag.

State machine before Projectile part (Click to View)

Understanding catching and weapon itrs

Interactions regarding weapons and catching are different in how they are activated.
Allow me to introduce a term: Key-augmented input.

A lot of itr use Key-augmented input,

for instance, you might think itr kind: 2 on punch frames are used to pick up weapons.
The truth is even if a frame has itr kind: 2, if the character does not press A in the frame, he will never pick up a weapon. It can be easily shown if you try to add itr kind: 2 into jump frames. By quickly pressing J+A you can cancel your jump and pick a weapon.

To give an input to a non-type 0 character is tricky for human and extremely difficult for computer, the latter caused of AI glitching whenever a character transforms from type: 0 to another type.

Kind: 1

itr kind: 1 can only be activated if character presses direction key, his itr is overlapping with bdy of a hostile character with state: 16, and pressed direction key matches the x-axis displacement direction between attacker and victim:
Ppressing right when victim is at right side of character will grab him, moving away from enemy or up or down will not cause itr kind: 1 to trigger. Moving Up/Down AND towards enemy triggers itr kind: 1.

It then acts identical to what itr kind: 3 does.

Therefore, putting an enemy into DOP will not immediately cause your character to grab him, you can move out, press A to trigger super_punch or move towards him to grab.

It is proven no matter the type of character of attacker and victim, attacker can still catch victim. There's a rigid restriction on bdy of victim would be prone to any incoming attacks though.

Kind: 2

itr kind: 2 is an augmented weapon-picking interaction. Character must be pressing A key and the itr overlapping with bdy of an object with state 1004 or 2004 to pick a weapon. Character will go to frame 115 if picking state 1004 or frame 116 for state 2004.

Normal punches have itr kind: 2 incorporated in their initial frames, automatically triggering the picking actions.

hit_XX are disabled if a character is holding a heavy weapon via itr kind 2, state: 2 itself doesn't disable hit_XX.

The full list of hit_XX commands:
hit_Fa: -- D>A
hit_Fj: -- D>J
hit_Da: -- DvA
hit_Dj: -- DvJ
hit_Ua: -- D^A
hit_Uj: -- D^J
hit_ja: -- DJA

Kind: 3

itr kind: 3 is an aggressive grab that activates whenever itr collides with bdy of type: 0 character.

It's a stable alternative of itr kind: 1, even usable by uncontrolled objects including projectiles and any weapon, but cannot target anything outside type: 0.

Kind: 4

itr kind: 4 acts as itr kind: 0 only if character is "thrown" into falling frames. Otherwise it will not be counted. Escaping from falling frames resets the flag that enables itr kind: 4.

Escaping include being hit by fire or ice attack, flipping, or unusual means including being caught by an itr kind: 3 with fall: 70. Anything leads character out of falling frames before dropping to ground will do. Being floated by flute (itr kind: 10) will deactivate itr kind: 4.

When active, itr kind: 4 will hit objects in all teams.

Kind: 5

weapon attacks, implemented by itr kind: 5 is an overloaded itr that activates only if there is a character having a wpoint link with the weapon (simply speaking holding it) and character has attacking parameter equal to 1-4.

The overload progress is as followed:
All itr kind: 5 in a frame is loaded.
attacking parameter determines which set of strength_list should be loaded.
dvx, dvy, fall, vrest, arest, bdefend, injury and effect are read from weapon_strength_list in weapon .dat file

the fall value of active frame of weapon is recorded in another place
itr kind: 5 is treated as itr kind: 0 and takes effect

Apart from some wierd effects by putting weapon with effect: 4 and negative fall,
itr kind: 5 has an unique effect on how it hits an enemy.

I mentioned the fall in active frame is recorded, this value will determine if weapon can hit characters with state: 12 (which is immune to attacks under 41 fall)

The fall in weapon_strength_list is the actual fall value given to victim.

For instance, Sickle has fall: 70 in weapon_strength_list, but fall: 20 in on_hand frame. It will never hit anyone in state: 12, unless fall in itr kind: 5 frames are changed to 70.

Kind: 6

Any character that emits itr kind: 6 does not directly affect other characters, but if other character has an bdy that collides an itr kind: 6 box and is in state 0 or 1, doesn't hold weapon and has next: 0, pressing A will trigger frame 70 (super_punch) instead of 60 or 65.

Kind: 7

Itr kind: 7 is similar to itr kind: 2 except character does not go to picking_light frame, and only light weapons (state 1004) can be picked.

Kind: 8

Itr kind: 8 only triggers when itr box collides with a bdy of type: 0.
It will set "flashing HP" of the victim character by amount of injury (victim heal for that amount over time)
The attacker will teleport to the same x and z-axis position of victim and go to frame indicated by dvx value of itr.

Itr kind: 8 will attack (heal) character of any team.

Flashing HP of itr kind: 8 and state: 1700 won't stack with each other.

An itr kind: 8 with injury NOT 100 HP, regardless of if the amount is less then current flashing HP amount, will set flashing HP value to new amount. If you are trying to use itr kind: 8 with injury: 0 tag to make some triggered moves, this will kill off flashing HP of detected character!

Kind: 9

Itr kind: 9 will cause all type: 3 objects to join attacker's side and make them go frame 30.
This itr when hitting a bdy of type: 0, will deplete all its health (red HP reduced to zero).
STM had test showing that health of object is actually "set" to zero, therefore if an character has negative health hits someone with itr kind: 9, his health is increased although unseen.

Kind: 10

Itr kind: 10 is Flute (Sonata of Death) which puts type: 0characters into a floating state that looks like falling frames but has a consistent damage and dropping ground damage. The exact falling frame is dependent on y-axis velocity of victim.

Weapons also are pushed upwards but do not suffer damage as type: 0 do.

Type: 3 and 5 are immune to this.

In floating state, victim is always facing the front side until victim is no longer pushed by itr kind: 10/11 and is hit from the back.

Kind: 11

Itr kind: 11 is an assisting flute that only takes effect if victim is already in float state.

Kind: 14

Itr kind: 14 is a blocking itr that disallows any object with bdy to move towards the itr area.

Kind: 15

Itr kind: 15 is a wind itr that sucks objects except type: 3 and 5. Character will continue his actions until return to standby state, and system will treat character as in-air and direct him to frame 212.

Weapons will go to on_sky (possibly throwing) frames, but will not further reset frames until it has been hit or drops ground.

If a baseball or drink is already in effect of state: 15, and its itr took effect earlier, its itr will not occur again (precisely the object stays in in_sky frames) until a different itr affects it.

Kind: 16

Itr kind: 16 is a wind itr that sucks weapons and causes a freezing effect to type: 0 without determining bdefend values. There is also no hitlag regarding itr kind: 16.

Knight - using 3 spritesheets!

Wed, 09 Aug 2017 11:36:04 +0200

Knight has always been a troublesome character DC-wise. He is hardcoded to use +114 to pic for his _b sprite, but using state 8037 just results in the Knight appearing messed up because it still uses +140 to pic. Either you make him look good in Battle, or able to work with state 8xxx.

NO LONGER SHALL THIS TROUBLE YOU! Introducing the data & sprite edit template for the Knight that allows you to have the best of both worlds!

Just to give an idea of how its done:

DC-Code:

file(0-25):    sprite\knight\knight_0.bmp     w: 79  h: 99  row: 13  col: 4   #1  unused 26-51
file(52-77):   sprite\knight\knight_1.bmp     w: 79  h: 99  row: 13  col: 4   #2  unused 78-103
file(104-108): sprite\knight\knight_2.bmp     w: 79  h: 99  row: 5   col: 2   #3  unused 109-113
   file(114-139):   sprite\knight\knight_0b.bmp   w: 79  h: 99  row: 13  col: 4    #4 0c = (140-165)
   file(166-191):   sprite\knight\knight_1b.bmp   w: 79  h: 99  row: 13  col: 4    #5 1c = (192-217)
   file(218-222):   sprite\knight\knight_2b.bmp   w: 79  h: 99  row: 13   col: 3    #6 2c = (244-247) unused 248-256
file(257-269): sprite\knight\knight_3.bmp     w: 109 h: 99  row: 13  col: 2   #7
   file(270-341):   sprite\knight\nth.bmp           w: 1   h: 1   row: 88  col: 1  #8
   file(371-396):   sprite\knight\knight_3b.bmp     w: 109 h: 99  row: 13  col: 3  #9 3c = (397-408)

Knight_0b - containing the Battle b sprite, and the _c sprite used for state 8xxx (courtesy of Hari)

As you can see, I was able to fit almost all the sprites into 9 out of 10 bitmap slots, into sections of 26 at most. I only needed to use 1 filler slot, though that filler can potentially be converted for in a new spritesheet. I said "almost all sprites" because I removed 2 specific injury sprites that are identical to his grab attack sprites.

Feel free to use this "template" for your LF2 modding projects!

Download:

Knight 3 Pic.zip (Size: 1.62 MB / Downloads: 413)

As a bonus, here's an old pack which contains b_sprites for ALL characters:
https://www.lf-empire.de/forum/showthrea...#pid204649

Enjoy!
Credits to Hari for the new knight sprite.

edit: I decided to update this after taking some notes from YinYin's goldknight, see the original post in the spoiler below.

Original Post (Click to View)

Managing playable type: 3, 5 characters

Tue, 18 Jul 2017 08:36:19 +0200

This thread talks about some crazy (proved) ideas about creating a playable character that runs on type: 3 or 5.
A number of other things will also be discussed.

For a live example, please visit Furrzee, a character that transforms into type 3 or 5.

Why to create a character that runs on type: 3 or 5

type: 3 is the common "projectile" data type. Apart from its chasing, z-axis managing, health and side changing properties,
It closely resembles a gravity-free object.

A large amount of functions can be done in type: 3 if you manage to get through the huge pain managing it.

type: 5 is similar to type: 0, the notable difference are its immunity against many itr effects and a similar injury model to type: 0.

How to setup data file first

To properly create a "playable" type: 3, 5 character, you must firstly understand there must still be a type: 0 placeholder character as same team as the t3/5,
otherwise the system will treat your side as no more characters and end the game.

So you should generate a type: 0 placeholder if your type: 0 character transforms into t3/5, and kills the placeholder when it transforms back,
unless you are using it inside some special system that has another t0 placeholder.

The placeholder is expected to be invulnerable all the time, so put state: 14 on it.

Then, add every tag in a type: 0 to the type: 3 or 5 you wish to control:

Spoiler (Click to View)

The bold lines in spoiler are originally in type: 3, you can remove this altogether to eliminate sound. (Thanks to STM)

Make sure your sprites are aligned in 140 blocks per section, and use pic: 0-139, 280-419 to properly access the sprite resources.
"Per section" means you can allocate any number of bmp files to occupy at most 140 pictures in area 0-139, 280-419 respectively.
If your sprite layout doesn't meet 140 slots, you can use some empty slots to fill up the space

In the example below, empty_slot.bmp fills up missing 10 spaces for pic: 130-139 (270-279 for _b sprite) so pictures starting from 280 will be shown properly.

Spoiler (Click to View)

Next, you must determine how invulnerable your character is. Be warned because you are controlling a non-type: 0 character,
nobody will recognize you as an attack-able target unless you summon a type: 0 that follows you around.

If you are happy about being untargetable, you might put an opoint that summons state: 14 object to scare computers away.

Type: 3 and 5 injured system

type: 3:
You may check here first for a beginner's guide.

Below I will outline some very important information regarding type: 3 playable characters:
A type: 3 with state 3, 7, 15 that has an itr that hits anything will not change its frame.
However, even in state 3, 7, 15, if type: 3 gets hit it will be treated as state: 3000

The frames which a type: 3 will jump into when attacked: 10, 20, 30 are all already allocated for type: 0 weapon actions.
It means if you wish to use type: 3 injured frames, you will be required to drop both light and heavy weapon system (or do a very significant change on these)
Not to forget the character will change side if being hit by a itr from type: 0 or itr kind: 9.

You are best be preventing the character from being hit at all costs if you don't want to mess with either weapon system or changing sides.

type: 5:
System is largely outlined by STM here (section 7)

Something to add:
itr kind: 3 (forced grab by Louis's D^J) doesn't work but itr kind: 1 (grabbing DOP character by moving towards him) works.
However you can change all state: 16 to something else to completely remove possibility of being grabbed.

P.S. a type: 3 (I guess every object) at a frame with bdy and state: 16 can also be grabbed by a controlled character not necessary a type: 0, although usually it cannot be seen because state: 16 is generally used in DOP frames, and grabbing non-type: 0 objects are uncommon.

There is no landing collision in type: 5,
however a notably safe method is to lead all falling, jumping and dashing (latter two are used to counter fall:100+60 bashing problem) frames to transform to type: 0 to prevent locked in unending gravity fall. (provided you don't have a move that buries a character under the ground)

Any type: 3 object hitting a state: 7 type: 5 will not peel the latter's HP, does not hitlag, the type: 3 will not trigger a hitting animation.
If an energy disk hits a defending type: 5, it will damage the character from behind.
However a type: 0 does not follow this standard, Dennis's shrafe used against a defending type: 5 will cause first 3 hits to miss but the last one dealing normal damage (unless type: 5 blocks in time)

type: 5 will take damage from itr kind: 0 effect: 4, because all ik0 are treated as effect: -1.

Type: 3 and 5 and AI

There is NO AI inscribed for any type: 3 or 5 or anything other than type: 0.
However if a type: 0 character is transformed into a non-type: 0 character, that character is locked at the last input point.
For example, if you put state: 8xxx on one of Freeze's D>A frame, Freeze will become a non-type: 0 character that repeatedly presses A or J or direction forever
(or until there is a forced transformation back to type: 0)

It means the new character will punch forever, jump (not forever because it will drop indefinitely) or run. But definitely not using any move or do any intelligent thing. This glitched character however will do anything that is related to spamming a single button, like performing super_punch or picking up weapons.

Type: 3 and 5 and Playable characters
Firstly, by controlling a non-type: 0 character, it will inherit most of non-aerial properties (except injury system) that are written in data files.
This include the new character can drink, use and throw weapons, use basic attacks, super punches, grab enemies, and inherit all the tags that are written in tags.
The type: 3/5 character can have different running speeds from the type: 0 you transformed from.
Friction naturally occurs just like type: 0 characters on ground.

Aerial states are f***** up. Although you can jump, you will suffer from these:
type: 3: There is no gravity
type: 5: There is gravity but you will fall below ground forever.
Both jumping states will render you unable to use jump attack/ dash attack until you put a hit_a tag there.

Do notice if you are t3/5 playable character, the camera still follows you even when the t0 placeholder and computer are left behind.

If you wish to create a t5 that can be damaged, it is best to put all falling frames to transform back to t0.

hit_a, j, d, XX tags and mp tags will all work.
For t5, it is easy to implement any move with these tags, but for t3 it will by much much more complex.

Using hit_x tags in type: 3 playable characters

The big problem on using tags on type: 3 PC is: hit_x tags will both act as key input and type: 3 properties at the same time.
For instance, if type: 3 has a frame that has hit_a: 1, it will deplete its HP by 1 per frame.
however since type: 3 is used as a playable character, hit_a also acts as "if you press A in this frame, the character will go to frame 1".

This property renders putting hit_a and hit_j commands much harder than expected when making type: 3 character.

P.S. However there is a stable way to bypass hit_a,j effects by using negative tags and then a frame with wait: 0 and negative next.

The hit_a or j tag will not take effect during the frame, you just need to reverse the direction again to cancel out the consequence. The character will also turn around if F6 is pressed, due to negative direction in hit_a,j no longer working.

The frames will look like this:

Spoiler (Click to View)

Do notice there is NO AI whenever a character is transformed to type: 3, so we can just leave behind some assumptions and use some gimmicks to bypass it.

The hit_a tag as mentioned, will drain HP from character whenever the frame is present. We can however limit the amount of health drained by avoiding any move that has a "+A" input and possibly make use of normal punch properties:

A normal punch is triggered by pressing A, but the "A" input can last to next frame.

it means something like this will cancel out health drain unless F6 is pressed or computer is using the character (the latter is impossible)

Spoiler (Click to View)

In the example, when normal punch goes to frame 60, it will drain 61 HP per frame
(frame 60 only lasts 1 frame before it goes to frame 61)
And because player "is pressing A" to go to frame 60, the "A" key input lasts to frame 60 and it redirects to frame 61, which then drains 9 HP but the mp tag restores 70 HP, which cancel out each other.

frame 61 literally lasts 0 frame because it is triggered by a hit_a tag in frame 60, but the hit_a in frame 61 can act for 1 frame only for the HP drain, and does not trigger a "press Attack" effect. The character will never go to frame 9, only going to either 62 or 218.

If the character has less than 61 HP, he will become 0 HP instead and go to frame 281.

The trick is the frame number where your character goes to is equal to the amount of health for detection. So you might need some lower frame numbers to create some specific death effects.

Because type: 3 does not go to frame 180/186 whenever its HP reaches zero, but instead remains controllable by player, it is then possible to return to standing frames after going to frame 281.

Do notice if a type: 3 character is killed by using hit_a tags, he will never be able to fulfill hit_a requirements tags again unless some attacks that have negative damage is dealt upon him, but it will cause the character to go frame 20... Or, a mp tag that revives the character.

I must also note that using any attack onto bdy of a type: 3 does NOT deal any damage to the latter. The latter instead goes to certain frame and possibly change side.

Be warned F6 will disable any mp tag and prevents the hit_a tags to be cancelled out with mp tag, causing rapid HP drain whenever this kind of move is used.

For hit_d tag, it is quite simple to implement. hit_d both acts as the frame whenever type: 3's HP runs out, it will go to,
and the frame the character will go to if you controll him and presses D. It works in type: 3 and 5.

For hit_j tag, type: 3 will have an addition of z-axis movement indicated by hit_j, but it also acts as the frame the character goes to if you presses J.
You might need to move around weapon frames elsewhere to properly use hit_j to perform moves that shift character in z-axis.
Alternatively, if you wish the particular move to be unable to control the z-axis movement, a dvz: 5XX tag can be used to cancel out the movement.

For hit_Fa tag, bear in mind the only hit_Fa: 1-14 tags have special effect. Above 14 you can use any number without side effects.

Using type: 3 as a part of character

If you wish to only use type: 3/5 as only a part of your character, like becoming a whirlwind which drains your health until you press D to cancel, this section is for you.

By sacrificing the standing frames (and weapon holding frames), you can put hit_a, j, Fa tags to small numbers,
like in the above example, your character transforms into a type: 3, because transformation will lead to frame 0,
your frame 0 nexts to whirlwind frames that have hit_a: 1, hit_d: XXX.

When you press A in whirlwind form, character goes to frame 1 and you can use frame 1 to do something else,
like performing a slash and then returning to human, or you can press D to return to human form directly.

P.S. weapon types are unsuitable for making a character

If you try to create a controllable character in a weapon type, they suffer from these:

1. When they land on floor, they go to frame 21 first (just_on_ground) and then frame 20 (on_ground)
While they are have a good gravity model and have stable landing animation, frame 20 is used by heavy object management.

2. If you transform into a weapon object by state: 8xxx, there is a [s]random[s] chance of character disappearing if someone attacks the character.
Update: This is caused by depleting the "Weapon hp" of the object, which is set to 500 by default. The number is not shown in gui of the game but manages the destruction of a weapon. Typically if a weapon is damaged, the weapon hp goes down, but in this case your character transforms into weapon, and takes "weapon damage" which is independent of "character hp". So there is little way to deal with it other than setting the weapon hp of your character to extremely high.... but it still breaks when character hits something with bdefend: 100 (soul bombs)
This is a critical problem making the character highly unstable.
The chance is observed to be independent of frame layout of the character.

3. The damage animation goes into frame 0-15 (light) or 0-5 (heavy). This means to properly create such weapon-based character, frames regarding weapon management (10, 15) must be freed out except for heavy ones.

P.S. Choosing between type: 3 hit_j and dvz: 5xx for movement in z-axis

Thanks for STM for reminding me about using dvz for z-axis movement.

hit_j specifies a movement speed that is added towards the current z-axis speed of a type: 3 object.
For example, by holding Down key, Davis's energy blast can be directed slightly downward but the propagation pattern still follows its normal or upward pattern.

You must also be wary that a positive hit_j also acts as a goto tag if you are using a type: 3 character.

dvz: 5xx (or more precisely, dvz: 501+) in the other hand, can be used in any object.
Dvz: 501+ is a dvz tag with a number no less than 501, dvz: 501, dvz: 550, dvz: 9999 all will contribute to z-axis movement.

Dvz: 501+ will cause the object to force its z-axis speed to (number-50) while the frame is active.
Even if you are controlling a character and tries to walk down, a dvz: 549 tag will drag you upwards (for 1px per tu).

However it's perfectly okay if you are planning on a move that doesn't allow z-axis custom movement in occasion. And it's a very convenient choice compared to making a type: 3 character just for z-axis movement. Don't forget dvz tag does not interfere with hit_a,j,d tags and you can cancel a z-axis moving move as you wish.

Pushing

Sun, 10 May 2015 16:23:35 +0200

Here is how I plan to do the cold touch for Ryce.
When you catch and instantly throw another character you can skip some of the cpoint related repositioning and gain a lot of cool features:

force the opponent into a frame of your choice
go into a hit frame with hit sounds and effects of your choice
gain z control over your opponent
no y-axis trouble or characters getting stuck in jump frame (so it works on any character size)

Here are some template frames that change a templates walking grab into a push:

DC-Code:

 4 standing
   pic: 0 state: 9 wait: 1 next: 999 centerx: 39 centery: 79
   sound: data\013.wav
   cpoint:
      kind: 1 x: 60 y: 79 vaction: 112 cover: 21 throwvx: 9 throwvz: 9
   cpoint_end:
   wpoint:
      kind: 1 x: 33 y: 45 weaponact: 21
   wpoint_end:
   bdy:
      kind: 0 x: 21 y: 18 w: 43 h: 62
   bdy_end:

 
 5 walking
   pic: 4 state: 1 wait: 3 next: 999 centerx: 39 centery: 79
   wpoint:
      kind: 1 x: 45 y: 53 weaponact: 21
   wpoint_end:
   itr:
      kind: 1 x: 40 y: 16 w: 25 h: 65 catchingact: 4 caughtact: 112
   itr_end:
   bdy:
      kind: 0 x: 28 y: 15 w: 27 h: 65
   bdy_end:

 
 6 walking
   pic: 5 state: 1 wait: 3 next: 999 centerx: 39 centery: 79
   wpoint:
      kind: 1 x: 40 y: 55 weaponact: 21
   wpoint_end:
   itr:
      kind: 1 x: 40 y: 16 w: 25 h: 65 catchingact: 4 caughtact: 112
   itr_end:
   bdy:
      kind: 0 x: 28 y: 15 w: 27 h: 65
   bdy_end:

 
 7 walking
   pic: 6 state: 1 wait: 3 next: 999 centerx: 39 centery: 79
   wpoint:
      kind: 1 x: 33 y: 57 weaponact: 22
   wpoint_end:
   itr:
      kind: 1 x: 40 y: 16 w: 25 h: 65 catchingact: 4 caughtact: 112
   itr_end:
   bdy:
      kind: 0 x: 28 y: 15 w: 27 h: 65
   bdy_end:

 
 8 walking
   pic: 7 state: 1 wait: 3 next: 999 centerx: 39 centery: 79
   wpoint:
      kind: 1 x: 24 y: 56 weaponact: 23
   wpoint_end:
   itr:
      kind: 1 x: 40 y: 16 w: 25 h: 65 catchingact: 4 caughtact: 112
   itr_end:
   bdy:
      kind: 0 x: 28 y: 15 w: 27 h: 65
   bdy_end:

You can do pretty crazy things with this (outside of walking with kind 3 as well).

Weakness for fire/ice

Mon, 01 Dec 2014 22:38:35 +0100

Weakness for FIRE/ICE
-----------------------------------------------------------------------------

Hi everyone, long time ago, when i was creating character called Rimfrost I wanted to make a weakness for fire with this champ using injury etc. But it was impossible, and today i created good idea about that weakness.

Using correct bdy position and invisible ball (with state 18) we can make this easy!

So let's create that invisible ball:

====================================
STEP 1 - effect that causes injury
====================================

Code:

file(0-11): sprite\sys\firzen_chasei.bmp  w: 81  h: 82  row: 4  col: 2

weapon_hit_sound: data\002.wav

weapon_drop_sound: data\002.wav

weapon_broken_sound: data\002.wav

 0 invisiblecolFIRE

   pic: 11  state: 18  wait: 1  next: 1000  dvx: 0  dvy: 0  dvz: 0  centerx: 41  centery: 43  hit_a: 0  hit_d: 0  hit_j: 0 hit_Fa: 0

   itr:

      kind: 0  x: 0  y: 0  w: 81  h: 82  dvx: -8 dvy: -8  fall: 70  vrest: 15  bdefend: 20  injury: 80  

      effect: 0 

   itr_end:

 2 invisiblecolICE

   pic: 11  state: 18  wait: 1  next: 1000  dvx: 0  dvy: 0  dvz: 0  centerx: 41  centery: 43  hit_a: 0  hit_d: 0  hit_j: 0 hit_Fa: 0

   itr:

      kind: 0  x: 0  y: 0  w: 81  h: 82  dvx: -1  fall: 70  vrest: 15  bdefend: 20  injury: 80  

      effect: 0

   itr_end:

Pic 11 from firzen_chasei is blank, so i used this number in both frames.
Anyway, the most important thing is STATE 18, because this causes that ball to hurt anyone (even character which releases opoint).
Remember that with injury you can change the additional damage.
And why 2 cols? Because guy on fire is dynamic, and it looks stupid when he inhibit after hit, but guy on ice is static, so he'll fall limply.

You can ask: Why effect 0? It causes to release the effect of fire or ice!
I'll explain of course, namely there's a big problem. I tried to combine that (especially ice with kind: 16) and it causes loop, and character with weakness was still knocked by that effect until he died, so there's a huge defect with my weakness patent.

====================================
STEP 2 - setting the body
====================================

Even if that effect got vrest, if you'll attack that sensitive character staying next to him you'll get hit also, so we must set infeasible body out of map.

Code:
 200 ice

   pic: 8  state: 15  wait: 2  next: 201  dvx: 0  dvy: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0

   wpoint:

      kind: 1  x: 18  y: 45  weaponact: 20  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 

   wpoint_end:

   bdy:

      kind: 0  x: 10  y: 9  w: 55  h: 68

   bdy_end:

We know that we can't put OPOINT here, because this is first frame of ice, so possibly we can shorten WAIT or something, i'll leave that option.

Code:
 201 ice

   pic: 9  state: 13  wait: 90  next: 202  dvx: 0  dvy: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0

   opoint:

      kind: 1  x: 21  y: -220  action: 2  dvx: 0  dvy: 0  oid: 666  facing: 0

   opoint_end:

   wpoint:

      kind: 1  x: 20  y: 55  weaponact: 35  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 

   wpoint_end:

   bdy:

      kind: 0  x: 8  y: 6  w: 67  h: 73

   bdy_end:

   bdy:

      kind: 0  x: 8  y: -200  w: 67  h: 73

   bdy_end:

   itr:

      kind: 14  x: 8  y: 6  w: 67  h: 73 vrest: 1

   itr_end:

Here we have second frame of ice, so we must add second BODY high above clouds, for example [y: -200] as in code.
Now is needed OPOINT striking this second BODY, no one can reach him, so it will works only for character with weakness.
[opoint: kind: 1 x: 21 y: -220 action: 2 dvx: 0 dvy: 0 oid: 666 facing: 0]
That Y helps us cover with BODY.
[OID: 666] is that script which is showed in step first.
[action: 2] because its concerns ICE weakness.

With fire we do the same, but with [action: 0]

Code:
 203 fire

   pic: 18 state: 18  wait: 1  next: 204  dvx: 0  dvy: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0

   wpoint:

      kind: 1  x: 42  y: 46  weaponact: 21  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 

   wpoint_end:

   bdy:

      kind: 0  x: 22  y: 35  w: 26  h: 19

   bdy_end:

   itr:

      kind: 0  x: 22  y: 35  w: 26  h: 19  dvx: -6  dvy: -6  fall: 70  vrest: 10  bdefend: 16  injury: 30 

      effect: 20

   itr_end:

 204 fire

   pic: 18 state: 18  wait: 1  next: 203  dvx: 0  dvy: 0  centerx: 39  centery: 79  hit_a: 0  hit_d: 0  hit_j: 0

   opoint:

      kind: 1  x: 21  y: -220  action: 0  dvx: 0  dvy: 0  oid: 666  facing: 0

   opoint_end:

   wpoint:

      kind: 1  x: 42  y: 46  weaponact: 21  attacking: 0  cover: 0  dvx: 0  dvy: 0  dvz: 0 

   wpoint_end:

   bdy:

      kind: 0  x: 22  y: 35  w: 26  h: 19

   bdy_end:

   bdy:

      kind: 0  x: 22  y: -200  w: 26  h: 19

   bdy_end:

   itr:

      kind: 0  x: 22  y: 35  w: 26  h: 19  dvx: -6  dvy: -6  fall: 70  vrest: 10  bdefend: 16  injury: 30  

      effect: 20

   itr_end:

And finally...

====================================
STEP 3 - HAVE FUN!
====================================

Here's my DAT files for you to study

char with weakness: http://speedy.sh/Fk3t2/weakguy.dat
weakness effect: http://speedy.sh/ptDPe/weakguy-col.dat

Just put that into LF2/Data
and remember to add this into DATA.TXT

Code:
id:  60  type: 0  file: data\weakguy.dat

id: 666  type: 3  file: data\weakguy_col.dat

If you noticed any bug or english mistake just write in thread or PM me.

TUTORIAL BY -=ONYX=-

DC course

Thu, 27 Mar 2014 16:42:49 +0100

can anybody help us (Newcomers and bad DCer) to Dc better and give us a course please.

HELP!!!!

Can anyone also give us a Course for DCing[/color]

Mechanism: RECT

Tue, 31 Dec 2013 15:00:05 +0100

The tag "rect" is very useful in background files, because using them does not require a graphic file, thus saving space, and we often need areas with a single color. In the original LF2, stage (1-5) backgrounds and HK Coliseum have used RECT. However, it is a little bit more advanced to understand what every RECT codes the color they represent. For those who tried to perform experiments on it, it may be found that the actual color "jumps here and there" in the RGB cube as RECT value changes, leaving no interrelationship seems to be found.

This "tutorial" explains the mechanism behind RECT codes in background files, as well as providing two-way formulas exchanging RECT codes and permitted RGB codes.

For quick reference, you may want to read the Summary. You can easily see this is one of the longest article in this forum, but if you have some spare time, it is recommended to start from Part 1 or 2 at least, which describe the mechanics more detailed so you will have a concept of how the formulas work.

From here on, italics will be representing my hypothesis and some points I am not completely sure, but generally I think they do make sense, or else I won't even keep them here. Just to notify.

~~~ Table of Contents ~~~

Part 0 - Preface

Part 1 - RGB

Part 2 - The 1-Dimensional Notation

Part 3 - Linear Color Codes

Part 4 - Examining RECT Basics

Part 5 - Secrets Disclosed in Binary RECT

Part 6 - The Jackpot and R'G'B' to RGB
- 6.1 - 777 Jackpot
- 6.2 - B' and B Exchange
- 6.3 - R' and R Exchange
- 6.4 - G' and G Exchange
- 6.5 - R'G'B' to RGB

Part 7 - RECT to RGB and its Inverse
- 7.1 - RECT to RGB
- 7.2 - RGB to RECT
- 7.3 - R, G, B to RECT
- 7.4 - RECT to R, G, B
- 7.5 - Handling Negative RECT

Part 8 - Exceptional Cases

Part 9 - Mechanical Summary and Applications
- 9.1 - Overview of Formulas
- 9.2 - The Exchange Cycle
- 9.3 - Formulas for Secondary Base Colors

Summary

Part 0 - Preface

Spending a short while saying why I write this: I was too searching what a certain RECT represents a RGB, or more ideally the interchange formulas so that I can type in the color I want. I have found YinYin had wrote something about it, I guess a long while ago. The link to his "extremely professional explanation", provided by Marshall, is dead, so I was not certain what its content is. The passage by YinYin can be found now so far is this (click). Maybe this is actually that explanation, but I just can't make sure. Anyway for this explanation, compared to the theory now I have made up below, contains some errors. I know he had wrote a program for us to get RECT codes by selecting a color, but I could not install it, so I was looking for a manual translation. I could not completely understand RECT just after reading his explanation, until I had done further experiments. However, it surely clarify the biggest concept of the RECT mechanism (see Part 2), so I could test samples on the correct way very soon. Now this tutorial will fix the remaining minor errors in YinYin's explanation, and show you the system as detail as I can.

Part 1 - RGB

For some catch-up I explain also the RGB codes. If you think it is fine you may skip this.

"RGB" stands for simply Red-Green-Blue, a code system representing digital color by notating the three basic optical colors red, green and blue, which could mix together to other colors. RGB codes are usually represented by a set of three decimal (base-10) numbers or a single number made up by three groups of hexadecimal (base-16) numbers. Today's computer systems and applications generally support a word size of 32 bits; when applied to RGB codes, these 32 bits will be divided into 4 parts: 3 parts of 8 bits each for the 3 colors, and the remaining part is for alpha (transparency; just put this aside since LF2 and *.bmp files do not support alpha scales). One bit means a binary (base-2) digit which stores either 0 or 1 only, i.e. 2 possible values, then 8 bits combined will be 2^8 = 256 combinations. Three colors of 256 combinations each will be 2^24 = 256^3 = 16,777,216 distinct colors.

Here comes to the end of this part. There will be some further RGB-related contents later.

Part 2 - The 1-Dimensional Notation

This is all about combining arrays with multiple dimensions into linear arrays, or more than one variable into one. RECT works in this way too; but before mentioning RECT, I first provide you several examples of what this term is about, so after this step-by-step bridging, you will understand RECT exactly when we approach there. I assume you have some basic Data Changing knowledge when reading this, so you should have no problem understanding the terms in the following examples.

Let's repeat. This is a technique when we need to combine arrays more than one dimension, into one. A simple example would be stage/id:. Excluding the latest Survival Stage, we know that id: 0 is Stage 1-1, up to id: 9 is Stage 1-10, then id: 10 is Stage 2-1 ... , all until id: 49 which is Stage 5-10. Now pay attention. (1) Stage X-Y contains two variables which store integers, where 1 <= X <= 5 and 1 <= Y <= 10; but (2) id: only recognize one integer variable ranged 0 to 49 inclusive, instead of something like catchingact: which recognize two variables. For normal players (1) makes sense to them, and imagine LF2 reads your stage selection input after confirming fighters the first time into variable X, then Y starts from 1 at any conditions, later Y is assigned to be (Y + 1) if an act is completed, and so on. However, we data changers know that stage.dat actually only list the stage acts with one id:, which is case (2). The stage selection in the game interface actually reads and translate the id: into 0, 10, 20, 30, 40 for Stages 1 to 5 or 50 for Survival. Translation between the 2-D imaginary system and the 1-D actual system would be like

Code:
Two-Dimensional Array [1..5, 1..10]

[1, 1]  [1, 2]  [1, 3]  [1, 4]  [1, 5]  [1, 6]  [1, 7]  [1, 8]  [1, 9]  [1, 10]

[2, 1]  [2, 2]  [2, 3]  [2, 4]  [2, 5]  [2, 6]  [2, 7]  [2, 8]  [2, 9]  [2, 10]

[3, 1]  [3, 2]  [3, 3]  [3, 4]  [3, 5]  [3, 6]  [3, 7]  [3, 8]  [3, 9]  [3, 10]

[4, 1]  [4, 2]  [4, 3]  [4, 4]  [4, 5]  [4, 6]  [4, 7]  [4, 8]  [4, 9]  [4, 10]

[5, 1]  [5, 2]  [5, 3]  [5, 4]  [5, 5]  [5, 6]  [5, 7]  [5, 8]  [5, 9]  [5, 10]

Code:
One-Dimensional Array [0..49]

[0]   [1]   [2]   [3]   [4]   [5]   [6]   [7]   [8]   [9]

[10]  [11]  [12]  [13]  [14]  [15]  [16]  [17]  [18]  [19]

[20]  [21]  [22]  [23]  [24]  [25]  [26]  [27]  [28]  [29]

[30]  [31]  [32]  [33]  [34]  [35]  [36]  [37]  [38]  [39]

[40]  [41]  [42]  [43]  [44]  [45]  [46]  [47]  [48]  [49]   ...

For 2-D [X, Y] and 1-D [Z], translation: Z = 10 (X - 1) + Y - 1

Their difference is that, cells of the 2-D system are linked like a net -- five horizontal linking lines and ten vertical, but the 1-D system is actually a single line like [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] ... [48] [49]. It seems that from [0] to [10] is only one vertical block apart, but actually there is no vertical leap in a 1-D horizontal line; the leap is actually 10 horizontal blocks. Ideally, [anything, 1] is where you may start a stage, but actually it is [anything divisible by 10]. The locations allowed to start Stage Mode are marked { }, and the whole line would looks like

{0} [1] [2] [3] [4] [5] [6] [7] [8] [9] {10} [11] [12] [13] [14] [15] [16] [17] [18] [19] {20} [21] ... [29] {30} ... {40} [41] ... [48] [49]

You see the locations are greatly apart but with constant interval, because one interval means one cycle of completion of the smaller digit. Here it is the imaginary Y variable. In translation, Z changes as Y changes, but Z moves a whole interval (10, which contains all possible values of Y) as X changes only by 1. This is just like the minute hand and second hand of (some types of) clocks. When the second hand completes a cycle, 60 units, the minute hand will move one unit.

Concerning time, we can talk about TU in DC too. Randomly say, if I want a wait: value of 3:31:16 (3 minutes, 31 seconds and 16 frames in 30 fps), I need to combine all 3 numbers into TU. Examine the cycles first: 30 frames (TU) = 1 s, 60 s = 1 min; 31 s = 930 TU, 3 min = 180 s = 5,400 TU. Sum together, it is 6,346 TU. This seems a bit off-topic, but I want to say, a change of unit can make multiple variables into a single possible. For time values the exchange of units is obvious, 1 hour = 60 min = 3,600 s = 108,000 TU, but for some systems -- more on-topic -- colors, it is not. How can I say 256 units of blue = 1 unit of green? This is ridiculous.

Really? No, in fact human can define many things. The original LF2 has 5 acts for each stage only. It is perfectly possible for Wong to define id: 0 to 4 for Stage 1, up to id: 20 to 24 for Stage 5. In this case every 5 id: units exchange to 1 stage, and the act number repeats the cycle and returns to the start again. When it moves to color, it is just the same -- when one cycle completes, another moves 1. Let's see RGB first.

Part 3 - Linear Color Codes

As mentioned in Part 1, RGB may be one hexadecimal number. For example, the largest, static blue area on the top of the LF2 screen listing HP MP bars, that blue is coded #324D9A. In the three-variable decimal notation it is (50, 77, 154), which is the decimal numbers of 32h, 4Dh and 9Ah. But what if we directly exchange 324D9Ah into decimal? It will be 3,296,666, which seems to be meaningless, but it will not if we do some calculations. Why we can directly breakdown 324D9Ah into 32h, 4Dh and 9Ah, is because each color's available depths is 256, from the 8 bits per color system (see Part 1), and 256 is delicately 100h. So now

Code:
-    32     h

-   * 10000 h

-      4D   h

-     * 100 h

-   +)   9A h

-   -------

-    324D9A h

324D9Ah = 32h * 10000h + 4Dh * 100h + 9Ah

           50 * 65536  +  77 * 256  + 154 = 3296666

After breaking down the number, it looks just the same no matter we change all of its elements into decimal or not.

Let's try notating a number in RGB and 1-D decimal simultaneously. Say, we start from color #000000, and represent it by 0. If we treat the code as one number and add it by 1, it will be 1 or #000001, which is R0 G0 B1. Continuing the process, until 255 or #0000FF, separately it is R0 G0 B255. Next it is the critical point, where degree 255 of blue color "transform" into 1 green point; it is 256 or #000100, R0 G1 B0. The previously said weird color transform occurs. It is indeed weird if you move one unit by one unit on this line ranged from 0 to 16,777,215 which intend to represent a 3-dimensional array. If you move 3-D-ly, that is, cycle by cycle, it should be just fine. Let's go back to the #000100 code. Normally you adjust the base color directly, like adding degree 100 of green. Now one cycle of blue is 256 units, so every 256 (16^2) units in whole means degree one of green. Degree 100 would be 100 * 16^2. Add it to the #000100 or 256, will become #006500 or 25,856. Similarly, if I want another degree 16 of red, it is 16 * 16^4 = 1,048,576; add to the code it will be #106500 or 1,074,432.

"Degree 256 of blue means degree 1 of green" still looks not very natural; we should rather say: degrees of red, green and blue moves in steps of 65,536, 256 and 1 unit respectively on the 1-D RGB color representation. To "decrypt" an 1-D color code, conversely we see how many steps of a certain base color it has taken. Take the previous #324D9A, in hexadecimal it is simple since red and green are moving in steps of 10000h and 100h units respectively. In decimal, it is still not that complicated, just require some division.

3296666 / 65536 = 50 ... 19866

So it has taken 50 steps of red, which is 65536 units each, and something is left. Process that number,

19866 / 256 = 77 ... 154

Thus 77 steps of green, 256 units each, is taken. The remainder represents blue degree since it is 1 unit each.

You may wonder why I tell so much on RGB instead of our subject RECT, and even use such an unpopular decimal method to notate RGB codes. Well, the RECT mechanism is quite similar to this. We are approaching, but there are still some points to be clarified.

Part 4 - Examining RECT Basics

From YinYin's explanation, we (or I) learn that RECT codes are lying on an 1-D line representing sets of 3-variable color codes; from it and also Part 3, we learn that if we put 3 color degrees into 1-D, 2 of the colors need to be represented by leaping certain intervals. Therefore, before experimenting we expect only one base color will change if we change the RECT value by certain amounts which are or are multiples of its intervals. The following are the actual samples I have taken using LF2.exe, LF2 Data Changer and Paint.

Code:
rect   R   G   B

------ --- --- ---

Code:
0      7   7   7

32     7   11  7

2015   7   255 255

2016   8   3   7

2048   15  7   7

4032   15  255 7

4063   15  255 255

4064   16  3   7

4095   16  3   255

4096   23  7   7

5984   23  243 7

6000   23  243 135

6016   23  247 7

6048   23  251 7

6079   23  251 255

6080   23  255 7

6090   23  255 87

6100   23  255 167

6110   23  255 247

6111   23  255 255

6112   24  3   7

6143   24  3   255

6144   31  7   7

6368   31  35  7

6751   31  79  255

6752   31  83  7

65503  255 255 255

65504  0   3   7

65535  0   3   255

65536  7   7   7

71646  23  255 247

262144 7   7   7

You may find many equal values within one base color, and one seems to be out-of-pattern phoneme in red code (often jumps in 7 but very occasionally in 1) which will be explained in lower parts. Now let's follow my interpretation of the data collected.

First, we can see the smallest changing in RECT represent the blue code, i.e. when RECT changes by one, it is likely only blue depth changes. Then, we see RECT is similar to RGB in fact -- red using largest intervals and green using moderate intervals, lastly for blue -- refer to RECT values 6079 to 6112, we see green value changes as blue completes a cycle; finally red is the largest, by comparing RECT: 0 and 2048, only red changes while green and blue are kept at 7. So, now we discover that in RECT, the base colors red, green and blue moves in steps of 2,048, 32 and 1 unit respectively.

Green in steps of 32... this actually means there are 32 degrees of blue depth levels available in total. 32 is 32 divided by 1; similarly for green cycles, there are... 2,048 / 32 = 64 depth levels. This looks inconsistent but true, because green depths jumps in 4 in RGB, 256 divided by 4 that is 64; and for blue it jumps in 8, so only 32 depth levels are available. For red, first we must find out how much is one cycle of it. If you have noticed RECT: 0 and 65536 has all the same RGB representation, you know the answer. Everything in RECT repeats in cycles of 65,536 units. Lastly, 65,536 / 2,048 = 32 depth levels for red. (There are only 32 designed depths for red, not 64 as it seems. The reason of the phoneme will be discussed in Part 6.) This should clarify the error in YinYin's explanation, "goes from 7 to 255 in steps of 4, thus leaving you 32 colors." (In fact if a sequence goes from 7 to 255 in steps of 4, it has 63 members.) Only red and blue "go from 7 to 255" and "leave you 32 colors," and only green goes "in steps of 4."

To shortly conclude, RECT is a 1-variable color code (designed to) provide 32, 64 and 32 red, green and blue color depths respectively. When representing in 1-D, red and green values are notated by steps of 2,048 and 32 units each.

Part 5 - Secrets Disclosed in Binary RECT

It is confusing to jump in 2,048 and 32 intervals to obtain the color depths. You may wonder is there a method to split the number into three parts, one base color each, as RGB do (324D9Ah is one hex number, but we can directly say it is R32h, G4Dh and B9Ah). Besides, you may want to learn more about why the available depths are allocated so strangely, why 32, 64, 32 but neither all-32 nor all-64.

For the first question, it is a matter of numerical base. RGB can do so because the cycle is 256, which can be written in powers of 16, the base it applied, therefore when it comes to division as in Part 3, it just looks the same as sticking all the digits into one number under base-16. For the acts of stages, both the base and cycle are 10, so using base-10 would obviously creates the similar effect. Now it is tricky when it comes to RECT. We need a base fits both the cycles of 32 and the cycle of 64. There is one -- considering 32 = 2^5 and 64 = 2^6 -- it is base-2, the binary system. You will see how it works after transforming RECT codes into binary. Let's see,

Code:
rect   R   G   B    rectBin (16 bits)    R' G' B'

------ --- --- ---  -------------------  -- -- --

Code:
0      7   7   7    0000 0000 0000 0000  0  0  0

32     7   11  7    0000 0000 0010 0000  0  1  0

2015   7   255 255  0000 0111 1101 1111  0  62 31

2016   8   3   7    0000 0111 1110 0000  0  63 0

2048   15  7   7    0000 1000 0000 0000  1  0  0

4032   15  255 7    0000 1111 1100 0000  1  62 0

4063   15  255 255  0000 1111 1101 1111  1  62 31

4064   16  3   7    0000 1111 1110 0000  1  63 0

4095   16  3   255  0000 1111 1111 1111  1  63 31

4096   23  7   7    0001 0000 0000 0000  2  0  0

65503  255 255 255  1111 1111 1101 1111  31 62 31

65504  0   3   7    1111 1111 1110 0000  31 63 0

65535  0   3   255  1111 1111 1111 1111  31 63 31

65536  7   7   7    0000 0000 0000 0000  0  0  0

71646  23  255 247  0001 0111 1101 1110  2  62 30

262144 7   7   7    0000 0000 0000 0000  0  0  0

From here, we first define another type of color code, R'G'B', used in RECT. It is just like RGB but with R' and B' ranged 0 to 31, and G' ranged 0 to 63 inclusive, instead of 0 to 255. 0 is the black end and their greatest number are their colored end. This system will be mentioned and used for quite a while, and no replacement until we discuss how to link R'G'B' to RGB.

Binary numbers are too long and normally divided into groups of 4. In the current case, for our purpose you may group them in to 5, 6, 5, which would be even clearer; e.g. 00001 111110 00000 for RECT: 4032. Under this division, you can clearly see the last three columns of the above table is just the decimal representation of the three parts of the binary number, which is transformed from RECT. For the example just given, 00001 is 1, 111110 is 62, and 00000 is 0. RECT only recognize 16 bits, thus for values starting from 65536 (2^16), the cycle is just repeating. The exceeded amounts are ignored, see the last three sets of data in the table.

Digital memories group 8 bits as 1 byte, thus it is normal to expect processing word sizes or the smallest memory units are in multiples of 8 bits, e.g. 8, 16, 24, 32, 64 or 128. If RECT adapts an all-32 allocation of color depths, only 15 bits will be used and 1 bit will be wasted. 1 bit means a lot -- a double of distinct colors available. I guess LF2 originally took this way in fact, until later changed green to have 64 levels, because we see all the starting points are 7 in RGB (see R'0 G'0 B'0 = R7 G7 B7), and G'63 = G3 which looks strange. If the authors were intended to use all 16 bits at the very start, the ranges RECT available in RGB should be 7 to 255, 3 to 255 and 7 to 255 as R'G'B' goes from 0 to 31, 0 to 63 and 0 to 31 respectively, instead of the current pattern of green that from 7 to 255 then completes on 3. If you acknowledge RECT runs in 16 bits, all-64 depths would be impossible since it requires 18 bits. Finally, for the reason why it is green being doubled in depth levels but not red or blue... other than the preferences of the authors it may be a matter of symmetry. Among all the combinations of two 5's and one 6, 5-6-5 looks better than 6-5-5 or 5-5-6.

So now, if we think in binary form of RECT or R'G'B', it is much more clearer to see the advancement from cycle completions. When B' completes a cycle of 0 to 31, when it back to 0 G' will increase by 1. In binary, 32 is 100000, where the 1 is the sixth digit (count from the right), it is over the bound of the "blue area". Listing the whole binary RECT, it is 00000 000001 00000. For the sixth to eleventh digits, it is the business of green; for the last five digits, it is for red. Maybe you remember I said before this "some blue points transform to one green point" "advancement" is nonsense (Part 3). The replacement system is to move 3-D-ly or cycle by cycle. Here when you adapt this system, you change either R', G' or B', or say the 12th to 16th, 6th to 11th or 1st to 5th digits of the binary RECT in groups. The purpose we break RECT down to binary is to enable direct base color changes as in hexadecimal RGB. Use it, or think in this way.

Recalling the basics; digital colors made up of three equally ranged base colors. We still have to transform R'G'B' code, which derived from RECT, to RGB in order to realize the colors digitally. When we have some concepts on RECT mechanism, we can now discuss how RECT related to RGB.

Part 6 - The Jackpot and R'G'B' to RGB

(For the meaning of R'G'B' which defined by me, please refer to the paragraph just below the table in Part 5 if you have skipped it.)

When you see the starting point R'0 G'0 B'0 represents R7 G7 B7, ever think of the 777 Jackpot? But it is a joke to say the authors were inspired by the Jackpot in developing RECT. I can't say the possibility is 0%, but there are just reasons which are much more logical and reasonable, also are likely to replace it.

In Part 4 we concluded RECT is a linear color representation designed to provide 32 red, 64 green and 32 blue color depths, and in Part 5 I proposed the depth levels available for green was originally also 32 as other colors, until further optimization. At this moment we ignore the 64 depths and assume the system adapting all-32 depths. We are going to discuss why and how a 0 to 31 scale transform into a 7 to 255 scale.

6.1

6.1 - 777 Jackpot

The RGB system has 256 depths for each color, which is exactly 8 times of the degree-32 one. Even its density is much lower than RGB, it still has to spread evenly on the full scale from black to the corresponding base color. Then although the colors are far less detail than RGB, it still provides a variety of colors. To spread, we just multiply it by how much times its scale is less denser, 8 times. In a quick calculation, the scale 0 to 31 would become 0 to 248, so now it represents absolute black (0) and nearly approach the full saturation (255). It was 0 to 31 in steps of 1, now becomes 0 to 248 in steps of 8; both have 32 steps. Comparing 0-248 and 7-255, there is a difference of 7 units. The reason why having a value of 0 in RGB scale is avoided, is that at least one color with 0 can be produced by using nothing in backgrounds -- absolute black (#000000), as said by YinYin. This is important because LF2 background files had a limit of 30 layers only before Ver 2.0. Saving one layer saves a lot. On the other hand, absolute white (#FFFFFF) is one of the most basic colors other than red, green and blue, so the scale is sticking to the 255 end to make this color available. When the right end is 255, the left end, 31 steps apart with 8 units each, is 7, so creating the Jackpot starting.

6.2

6.2 - B' and B Exchange

So now we have discussed why RECT is roughly representing degrees 7 to 255 in the RGB scale. Let's start to see how to exchange the two system. Out of the three base colors, only blue in the actual R'G'B' or RECT system is exactly the same as the degree-32 old system we have just discussed. But anyway let's see how to transform B' into B of RGB by a formula. I am giving it out first; it is

B = 8B' + 7

8 is the magnification, and 7 is the constant such that RECT could give out a depth of full saturation (255). When B' is 0, B is 7; when B' is 1, B is 15; when B' is 2, 23; and so on. Now suppose we have selected a color and want its RECT, we need a inverse formula. It could be easily got by changing its subject, as follows

8B' + 7 = B

8B' = B - 7

B' = (B - 7) / 8

Furthermore, we discover something; both RGB and RECT values are integers, so in this formula, we can see what is the condition for a certain color depth being available in RECT, using a mathematical method. RECT must be an integer, therefore B' must be also. By using the formula, the statement will be "(B - 7) / 8 must be an integer," and can be rewritten as "(B - 7) / 8 must be divisible by 1." Multiply the whole line by 8, we will get

(B - 7) must be divisible by 8.

This presents our concepts on only using 7, 15, 23, 31, ... for B' in terms of RGB in a generalized way.

6.3

6.3 - R' and R Exchange

Next, we will temporarily skip green and first move on to the red code. Referring to the table in Part 4 or your own samples, R' should represent at most 64 distinct color depths in normal cases. They can be grouped into two sequences: the first being 7, 15, 23, ..., 247, 255 the same as blue, another one is adding this sequence by 1, into 8, 16, 24, ..., 248, 0. Sorry to delay (very bit though), but this mysterious +1 is related to the green code and thus will be discussed later. For now, please ignore it, so 7 and 8 are both treated as 7, 15 and 16 are both 15, etc. If you can tell yourself to accept this, then the story will be extremely simple, because it is just a copy and paste with little altering:

R = 8R' + 7

R' = (R - 7) / 8

(R - 7) must be divisible by 8, under certain conditions.

They indeed look very familiar. Done, now the last color.

6.4

6.4 - G' and G Exchange

To be mentioned last, the green code must be the most complicated one, being it was optimized into a cycle differs from other base colors, in the development of RECT. There could be two interpretations of the green code; the more direct one is, similar to red and blue, spread the scale only instead in 64 intervals. The very first problem we face would be what the highest G' value represents in G of RGB -- G'62 is already G255, and then G'63 is G3. The formula can't work this way as far as we know now. But take a look, remember they are cycles, so it is not a great deal to use 259 to replace 3. If we say G'63 is G259, the problem is partly solved, and the formulas will be

G = 4G' + 7

G' = (G - 7) / 4, where 7 <= G <= 259 and

(G - 3) must be divisible by 4.

Our only concern now would be getting a 259 output for G when we input G' as 63 in the first equation, as mentioned before. In look for a mathematical representation, there is a solution, but first I have to introduce a pair of arithmetic operators. (Arithmetic operators are symbols marking arithmetic operations, e.g. +, -, * and /.) They are div and mod. They are division-related, while div returns only the dividend (in integer), and mod returns the remainder. For example,

15 / 8 = 1.875 or 1 ... 7

15 div 8 = 1

15 mod 8 = 7

In the above example, we can see only real values between 0 and 8 (include 0, exclude 8) will return for anything mod 8. Back to our case, now 259 mod 256 = 3, and anything else on the scale mod 256 = anything else on the scale. So by editing the equation to the following the problem is solved.

G = (4G' + 7) mod 256

However the inverse form is more tricky. You cannot move the mod operator to the another side, but since it outputs in cycles, we can write another formula which create the same results. Just like sin x = sin (x + 2pi), we transform the inner function by one cycle into

G = 4G' - 249

G' = (G + 249) / 4

Because mod works not as our purpose when the inputs go across positive and negative; now I make G' always positive in the equation just above. Our G input here should be a number of the sequence 3, 7, 11, 15, ..., 251, 255, then the G' outputs would be integers from 63 to 126. To transform this range back to 0 to 63 correctly (64 to 0, 65 to 1, ... instead of 63 to 0, 64 to 1, ...), just mod the G' (which equals to [G + 249] / 4; putting "mod 64" to the left side does not work) is fine, so

G' = [(G + 249) / 4] mod 64

This concludes the first interpretation.

The another one sounds more complicated; breaking down G' into two parts, into a scale ranged from 0 to 31, and another one only gives 0 or 1, then sum up their results. The principle of this interpretation is to include the very first intended RECT mechanics, as my theory in Part 5, and separate out the later modification. Recall the binary representation of RECT discussed in Part 5 again to show this new division; the binary RECT is now divided in the way like 00000 00000 0 00000 -- the 6 bits of green is further apart to become a group of 5 bits and 1 separated bit. What special about this system, is if you ignore the isolated bit by assuming it is always "0", the another three groups of 5 bits each, work all the same. All of them are in 32-step scales, from degree 7 to 255 of the RGB scale. Of course, nothing are to be ignored finally; the isolated bit actually represents an addition of a degree 4 of green. When it is 0, nothing happens; when it is 1, G will increase by 4.

The 6-bit G' system records G' in a range from 0 to 63. Now, its first bit from the right is isolated to a 0-or-1 field, the remaining 5 bits are in a 0-to-31 scale. In terms of numerical value, the new 0-to-31 scale is actually a double of the previous 0-to-63 scale, since moving one binary digit means multiplying by 2. So, in terms of the previous scale, the new scale is listing from 0 to 62, in steps of 2, then all even numbers from 0 to 62 are available. Adding up the 0 or 1 of the remaining bit, odd numbers from 1 to 63 are now also available. Combining the two sequences, all integers from 0 to 63 are present.

If we notate the transforming equation under this interpretation, it will be

G = (8g' + 7 + 4g'') mod 256

4 (2g' + g'') = G - 7

2g' + g'' = (G - 7) / 4

2g' + g'' = [(G + 249) / 4] mod 64

(G + 1) must be divisible by 4.

Where g' and g'' are the depth values in the 0-to-31 and 0-or-1 new green scales respectively. Pay attention to the first equation; I put the variable g'' to the last, is for you to compare this equation with those of red and blue. You see basically only 4g'' is extra. And for the next equation, actually the previous paragraph is concluding 2g' + g'' = G'. For the last statement of condition, you see "-" becomes the "+" sign. Actually it could be represented as an equation too,

(G + 1) mod 4 = 0

When it is "mod 4", now you see it is fine to add or subtract anything in multiples of the divisible-by number. All the other conditions would be

(R + 1) mod 8 = 0; (R + 1) must be divisible by 8, under certain conditions.

(B + 1) mod 8 = 0; (B + 1) must be divisible by 8.

6.5

6.5 - R'G'B' to RGB

So far, all the separate exchanging formulas are listed, then it is time to transform them as a whole, since both RECT and (hexadecimal) RGB are 1-D systems. First, let's recall how they are made up of R', G', B', R, G and B.

RGB = 65536R + 256G + B = R (16^4) + G (16^2) + B

RECT = 2048R' + 32G' + B' = R' [2^(6 + 5)] + G' (2^5) + B'

Using all the equations we have made up above, this complicated looking task is very easy. Just substitude and get ...

RGB *= 65536 (8R' + 7) + 256 [(4G' + 7) mod 256] + (8B' + 7) ... (1)

RECT *= [2048 (R - 7) / 8] + 32 {[(G + 249) / 4] mod 64} + (B - 7) / 8 ... (2)

No, I did not simplify or underline them, because these are not the truth. And also look at this section's subtitle, equation (2) is not our business now. Let's focus on equation (1)... and besides, we still have not explained yet why there are 64 colors on red, but not 32 as intended. Remember the reason for adding "mod 256", is because the G output of G' exceeds 255, and we have to limit it into the correct color cycle. But actually, the exceeded amount is just transformed into the next digit; for the digits responsible for green, they works the same. Here we should actually remove the operator, and (1) is now

RGB = 65536 (8R' + 7) + 256 (4G' + 7) + (8B' + 7) ... (1a)

As in Part 3 discussed, computers get the three base colors by performing division to the RGB code. This equation has deliberately broken down into the wanted three parts; (8R' + 7) is R, etc. We are ready to discuss the phoneme in red. Suppose we have R'0 G'63 B'0 (which is RECT: 2016, tested and shown in the table of Part 5), substitute in (1a)

RGB
= 65536 (7) + 256 (259) + (7)
= [65536 (7) + 256 (256)] + 256 (3) + 7
= 65536 (8) + 256 (3) + 7
= ...

You see when the green value exceeds the limit, one cycle of green becomes degree one of red. This strange action is the same as we move point-by-point on the linear RGB or RECT system instead of cycle-by-cycle. The system itself runs this weirdly, because defining the color cycles into 1-D already strays away from normal concepts. When using, we makes it looks normal by avoiding certain moves, but they look nothing special to computers, since they just perform mathematical calculations. It is humans who define the outputs as colors. Anyways, now we see the extra red degrees are come from color cycle exchanges. The demonstration also shows that the advancement takes place in RGB calculation, but not in RECT, or else the red degree will increase by 8. So R', G' and B' values lie in their own range, not overlapping others, only green with red after transforming into RGB due to the strange representation of G by G' (G'63 is G3).

Remember the second interpretation of G'-to-G formula? It is to make all R', G' and B' work fine without "advancements", and transfer the responsibility to the isolated bit g''. Equation (1) under this interpretation would be

RGB = 65536 (8R' + 7) + 256 (8g' + 7 + 4g'') + (8B' + 7)

RGB = 65536 (8R' + 7) + 256 (8g' + 7) + 256 (4g'') + (8B' + 7) ... (1b)

(To recall, G' = 2g' + g'', where g' and g'' are integers ranged 0 to 31 and 0 to 1 respectively.)

Now, if g' is saturated (g' = 31, 8g' + 7 = 255), g' with a fourth of g'' would be part of R, otherwise it is to be combined with g''. For the same RECT: 2016, the example using (1b) would have an outcome of

RGB
= 65536 (7) + 256 (255) + 256 (4) + (7)
= 65536 (7) + 256 (255 + 1) + 256 (4 - 1) + 7
= 65536 (8) + 256 (3) + 7
= ...

I guess now we have explained everything concerning converting R'G'B' to RGB ..., except one, which leads me still do not underline the equations -- mod. What if R and the advancement from G combineded together? Refer to the Part 5 table, RECT: 65503 is not the upper limit for distinct outputs as YinYin said, but continues shortly until RECT: 65535. R' is 31 but R is 0 since RECT: 65504. In fact -- you should get it yourself by now -- the 0 is just a cycled degree 256, so we need a mod operator for RGB too. The following are modified equations (1a) and (1b), which should be correct.

RGB = [(16^4) (8R' + 7) + (16^2) (4G' + 7) + (8B' + 7)] mod (16^6) ... (A)

RGB = [(16^4) (8R' + 7) + (16^2) (8g' + 7) + (16^2) (4g'') + (8B' + 7)] mod (16^6) ... (B)

We can now simplify them, to be

RGB = (524288R' + 1024G' + 8B' + 460551) mod (16^6)

RGB = (524288R' + 2048g' + 1024g'' + 8B' + 460551) mod (16^6)

Finally, here comes to an end, for exchanging the systems in terms of their components. Take a break for the completion of the long Part 6, and ready for long-awaited two-way formulas.

Part 7 - RECT to RGB and its Inverse

The real application of all we have discussed, is to understand what RECT means (RECT to RGB), and learn how to represent colors in RECT (RGB to RECT). Base on the concepts we have gone through, we can now talk about the transforming equations.

7.1

7.1 - RECT to RGB

RECT is not the same as R'G'B', so RECT to RGB differs from R'G'B' to RGB as above discussed. But of course R'G'B' is only derived from RECT, so there must be some transforming methods. We have listed something related to it at the beginning of Part 6.5, and described it long before, at the last sentence of Part 4:

RECT = 2048R' + 32G' + B' ... (3)

This is the R'G'B' to RECT formula, while in Part 6.5 ending, we have the R'G'B' to RGB formula; now we ultimately seek the RECT to RGB formula. By a principle similar to the Chain Rule of differentiation, RECT to RGB can be obtained by considering RECT to R'G'B' to RGB. The second "to" can be achieved by simple substitutions, while the first "to" requires an inverse formula of R'G'B' to RECT. For R'G'B' to RECT, it is a 3-variable-to-1 formula, so its inverse requires 3 equations, and look like

R' = RECT ... ???

G' = RECT ... ???

B' = RECT ... ???

It is not that difficult, we have done similar calculations before. See the ending of Part 3, we were decoding RGB into R, G, B separately through division. The process involves dividends and remainders, so using div and mod (for their operations, see Part 6.4) are exactly the way we are looking for. Now R', G' and B' move in steps of 2048, 32 and 1 unit respectively, so we just have to count how many steps they have taken, and ignore the remainders. Our first draft would be

R' *= RECT div 2048

G' *= RECT div 32

B' *= RECT

"div 1" means nothing as RECT must be integer. We can surely say at once that this draft is incorrect, just by considering B'. It should runs in cycles of 32 instead. Remember we successfully represent cycles by using mod, so it is to be applied here too. Therefore,

B' = RECT mod 32

For G', RECT div 32 gives you how many complete steps of 32 units each it has taken. Its cycle is 64 units, so to bound it within the range, we mod the result, leading to

G' = RECT div 32 mod 64

Both operators have to same level of priority, so the calculation will be done from left to the right, and no brackets are needed. The R' equation is marked incorrect since we can input RECT values over 65535, as shown in the tables of Part 4 and 5. To bound it, we need the same operation as in G' and B', which makes it

R' = RECT div 2048 mod 32 = RECT div 64 div 32 mod 32

Finally, we now obtained the three inverse equations of R'G'B' to RECT. It is time to substitute them into R'G'B' to RGB. For (A) at the ending of Part 6.5, after substitution it will be

RGB = {(16^4) [8 (RECT div 2048 mod 32) + 7] + (16^2) [4 (RECT div 32 mod 64) + 7] + [8 (RECT mod 32) + 7]} mod (16^6)

Even with the simplified form, (B), it is still very long.

RGB = [524288 (RECT div 2048 mod 32) + 1024 (RECT div 32 mod 64) + 8 (RECT mod 32) + 460551] mod (16^6)

You cannot simplify the div and mod operations, or you will alter the equation. They are not simple divisions. This concludes RECT to RGB, which presenting the way computers process our RECT input in background files to RGB code for displaying. It directly exchanges the two system linearly.

7.2

7.2 - RGB to RECT

For RGB to RECT, it is even more complicated, because not all RGB values are permitted. In fact, as RGB is 24-bit and RECT is 16-bit, only one-256th of RGB colors are available on RECT. Therefore, very first we can imagine it is something like every 256 units on the RGB line there is 1 block permitted, and in fact they are not even equally spread "256 units a step". It is really hard to exchange one line to one line backwards as we just did in RECT to RGB, and a bit pointless.

It is pointless because we usually read R, G, B separately. Even if it uses the linear form, it is still hexadecimal so that we can read the three colors two digits by two digits. We use them separately also. Our formulas are likely to be written in decimal, but no one bothers to transform three color depths into one huge decimal number up to 16 million, before the exchanging process. Actually what worth our discussion is the exchange between RECT and the set of R, G and B. We use only these two system, but not R'G'B' or RGB in decimal. Therefore, we should focus on what we need, and derive formulas in terms of them.

Up to this moment, we are now separating the terms R, G, B and RGB. "R, G, B" means the three numbers are presented one by one, instead of like RGB a single number under a linear system. While for R'G'B' or "R', G', B'," it does not bother since for sticking up R', G' and B' as a single number, the system is named RECT, so we do not have to differentiate them. In summary,

Code:
References of Color Notating Systems

               Linear   3-D

               system   system

RGB-related    RGB      R, G, B

RECT-related   RECT     R'G'B'

                      or R', G', B' occasionally

7.3

7.3 - R, G, B to RECT

R, G, B to RECT means an equation with one side of RECT output and one side of R, G, B inputs, so it is a 3-variable-to-1 formula, similar to R', G', B' to RECT as (3) in Part 7.1.

RECT = 2048R' + 32G' + B' ... (3)

Remember we have equation (2) in Part 6.5 left to be discussed:

RECT *= [2048 (R - 7) / 8] + 32 {[(G + 249) / 4] mod 64} + (B - 7) / 8 ... (2)

It is marked incorrect because it is substituted by separate base color cycles, without considering the green-to-red advancement discussed in later parts of that section. How about substituting the form without mod rounding? That is

R' = (R - 7) / 8

G' = (G - 7) / 4

B' = (B - 7) / 8

Into RECT and becomes

RECT = 2048 (R - 7) / 8 + 32 (G - 7) / 4 + (B - 7) / 8

RECT = 256R + 8G + (B / 8) - 1848.875

It seems that the advancement of green to red is considered since here R will increase if G' is 63, but actually, it is wrong because the conservation in the two systems are not equal. If we notate the green part without rounding the cycle, as above, one cycle of G', means one point of R', not R, will be lost if G' is 63. Then, R', not R, needs to be increased by 1 as a contradict action; now it is only R the scale increased. R is a scale 8 times more detailed than R', so even if R is advanced, R' would only increase by an eighth point. It needs to be a whole point if we need the formula works. On the other side, if we round the cycle by adding mod operations as (2), we need other operations to assume 8 is 7, ..., 0 is 255 in red mathematically. That means

R' = (R - 8) / 8 when G = 3,

else R' = (R - 7) / 8

One approach to combine the two equations, assuming only permitted inputs (0, 7, 8, 15, ...) are received, is using trunc( ), a rounding down function. Then

R' = trunc[(R - 7) / 8]

The only problem is we need to assume 0 as 255 too, but if R = 0 here, R' will output 0 (= trunc -0.875). We could use addition by a cycle and mod here again:

R' = trunc[(R + 249) / 8] mod 32

Which can avoid the process takes place across 0.

While for G', for mod cycling it should be

G' = [(G + 249) / 4] mod 64

Therefore, finally

RECT = 2048 {trunc[(R + 249) / 8] mod 32} + 32 {[(G + 249) / 4] mod 64} + (B - 7) / 8

This looks complex and time-consuming when operated by human. So, if we adjust the special red and green values in advance, we can use the basic equation. The whole R, G, B to RECT process would be

If G = 3, conduct

1) assign G = 259, and
2) subtract R by 1 or assign R = 255 if R = 0 originally.

Then, apply RECT = 256R + 8G + (B - 7) / 8 - 1848

7.4

7.4 - RECT to R, G, B

After then, we should talk about the inverse formula again. This is very similar to RECT to RGB, just being broken down into three parts. And this is easy to be obtained since we have discussed RECT to R'G'B' and all those R' to R and alike. They are

R *= 8R' + 7; R' = RECT div 2048 mod 32 = RECT div 64 div 32 mod 32

G = (4G' + 7) mod 256; G' = RECT div 32 mod 64

B = 8B' + 7; B' = RECT mod 32

The final concern would be the R' to R formula, as R will increase by 1 if G' = 63, reason discussed in Part 6.5. It has been concluded that the advancement is due to an absence of rounding G by mod. So, we can similarly apply the mechanics into the R' to R formula, i.e.

R = 8R' + (4G' + 7) div 256 + 7

Then, when and only when G' = 63, (4G' + 7) will reach 256 and thus (4G' + 7) div 256 will be 1. Finally, after substitution, the whole set of RECT to R, G, B equations are now derived:

R = 8 (RECT div 2048 mod 32) + [4 (RECT div 32 mod 64) + 7] div 256 + 7

G = [4 (RECT div 32 mod 64) + 7] mod 256

B = 8 (RECT mod 32) + 7

All the two-way formulas are derived, but they seem to spread apart quite much and need summarizing. I will do this later in Part 9, but not at once, because ... the calculations are not always true. There are a few preset RECT to RGB sets, which used in the official stage backgrounds. Only after discussing them, I could then show you the whole RECT and R, G, B converting algorithm. But before moving on, we have to tackle one last issue on the calculations.

7.5

7.5 - Handling Negative RECT

Although it is rare, but there might be people who playing tricks -- what if the RECT input is negative? For computers, usually they handle the negative values by Two's Compliment, that is moving the whole set of negative to above the positive numbers. For example in a 16-bit Two's Compliment, -32,768 to -1 will be represented by binary numbers from 1000 0000 0000 0000 to 1111 1111 1111 1111, which is primarily 32,768 to 65,535 in decimal. It is possible since digital numbers must have a range, here it is -32,768 to 32,767, therefore it is not a problem to input negative values into RECT for the computer, it just read the number in the designed range. But in mathematics, both positive and negative signs tend to infinity, there is no representation to transfer a negative number to be a certain positive number within the range.

The only method to handle negative inputs with our formulas is to write a conditional statement which makes use of infinity. This should be done:

If RECT < 0, repeat adding 65536 to RECT, until RECT >= 0.

After this final issue regarding the formulas is settled, we can finally close the file, and move on the RECT-R, G, B conversion which have nothing do with the formulas. Sounds horrifying.

Part 8 - Exceptional Cases

It is mentioned at the very beginning of this entire article, the official maps that used RECT codes. It is mentioned for showing how common, useful or important to learn and use RECT, but actually only a small portion of these background's RECT follow all the formulas we have discussed! Obtained in LF2 ver 2.0a, At the first time I found this out, I thought I was screwed for experimenting:

Code:
rect  R   G   B   bg  Exceptional

----- --- --- --- --- ---

Code:
4705  23  83  15

4706  16  79  16  lf  Yes

4707  23  83  31

...

16834 71  63  23

16835 66  56  24  qi  Yes

16836 71  63  39

...

21095 87  83  63

21096 90  78  75  sp  Yes

21097 87  83  79

...

25356 103 103 103 hkc

...

29582 119 119 119 hkc

...

34815 136 3   255

34816 143 7   7   ft

34817 143 7   15

...

37769 151 119 79

37770 154 110 90  gw  Yes

37771 151 119 95

...

40179 159 163 159 hkc

These cases are not common, but definitely worth notifying. Those marked "Yes" in the last column are values do not obey the exchange formulas, while the "bg" column specifies which background these RECT values are used in. There are four special values, RECT: 4706, 16835, 21096 and 37770. It is believed that there is a process, prior to the general exchange formulas, that check whether the RECT is one of the special values -- if yes, output the corresponding special RGB codes -- instead of hidden instructions exist in the official backgrounds. The evidence is that, the output is still irregular even if we use one of these RECT values in custom backgrounds. All the RECT adjacent to the special values are normal.

The RECT codes remained the same throughout LF2 ver 1.9 to 2.0, however, in versions since 1.9c only 32-bit color is expected, while in versions 1.9 and before only so for 16-bit color. The RECT to RGB process back in ver 1.9 is different, and has different outputs:

Code:
--- ----- 16-bit mode 32-bit mode -- -- --

bg  rect  R   G   B   R   G   B   R' G' B'

--- ----- --- --- --- --- --- --- -- -- --

lf  4706  16  77  16  0   18  98  2  19 2

sp  21096 82  77  66  0   82  104 10 19 8

gw  37770 148 113 82  0   147 138 18 28 10

qi  16835 66  56  24  0   65  195 8  14 3

ft  34816 140 0   0   0   136 0   17 0  0

hkc 40179 156 158 156 0   156 243 19 39 19

Shortly regarding the 32-bit mode -- running LF2 ver 1.9 in 32-bit color -- now you see why there were greenish and bluish areas in the old version backgrounds. Try putting R, G, B into the to-RGB formula (first formula in Part 6.5). For the normal range of RECT of 0 to 65535, red depth here will never change from 0.

Out of those in the 16-bit mode columns, Queen's Island has the perfect color match between the graphics and RECT-coded area, while Stanley Prison and The Great Wall match poorly; Forbidden Tower does not care since there is no need of matching. Compare the two tables in this section, we see the RGB values of the RECT-coded area of Queen's Island in the two versions are exactly the same, while in the poorly matched backgrounds there are nearly 20 points of difference in total, for each of them. None of the background .dat or .bmp files were edited, but the color matching was fixed. It maybe the easiest and most perfect method to match colors by adding special conditions into the compiling process from RECT to RGB. Now we see the RECT-coded areas match very well to the graphics in 32-bit versions, thanks to this edition. Remember there is strict limit of color availability under normal RECT to RGB formula, and all the four "perfect matching" colors are not available there. For the background does not require color matching, Forbidden Tower, there is no special color adjustment set for it as its RGB output follows the formula.

In summary, RECT-coded colors in four of the official backgrounds are optimized to match other graphics by modifying their RGB output, instead of re-coding the whole RECT to RGB mechanism and editing the background files. This could explain why there are a few RGB outputs are out-of-pattern. This leads to a special use of the four RECT values, and at the same time the shift of the four sets of permitted RGB: R16 G79 B16, R66 G56 B24, R90 G78 B75 and R154 G110 B90 are made available and can be directly link to the special RECT values; R23 G83 B23, R71 G63 B31, R87 G83 B71 and R151 G119 B87 are made unavailable dispute the other availability conditions.

Part 9 - Mechanical Summary and Applications

Every detailed cases regarding exchanging RECT and RGB have been mentioned so far. They should cover all the conditions we will face while exchanging the two systems. A lot of terms and converting formulas has been discussed and developed throughout this article, one by one about how they are derived. This section will summarize them by going through all the results once in an organized way, for an easier understanding of their usage.

9.1

9.1 - Overview of Formulas

First let's see what important component and final formulas we have derived. There are several categories based on both sides of the exchanging systems. The four systems we have made use of are (1) R, G, B, (2) RGB, (3) R'G'B', and (4) RECT.

- - Rules and system exchanges - -

R, G, B to RGB (Part 3, 6.5)
- RGB = 65536R + 256G + B
- Condition: 0 <= (R or G or B) < 256

R'G'B' and replacement (defined in Part 4, 6.4)
- Condition: R', G', B', g' and g'' are integers.
- Condition: 0 <= (R' or g' or B') < 32
- Condition: 0 <= G' < 64
- Condition: 0 <= g'' < 2
- Component: G' = 2g' + g''

R'G'B' to RECT (Part 4, 6.4, 6.5)
- RECT = 2048R' + 32G' + B'
- RECT = 2048R' + 64g' + 32g'' + B'

RECT to R'G'B' (Part 7.1)
- R' = RECT div 2048 mod 32
- G' = RECT div 32 mod 64
- B' = RECT mod 32

R'G'B' to R, G, B
- R = 8R' + (4G' + 7) div 256 + 7 (Part 6.3, 7.4)
- G = (4G' + 7) mod 256 (Part 6.4)
- B = 8B' + 7 (Part 6.2)

R, G, B available in RECT
- Condition: (R, G, B) are one of the four sets, which can be linked to RECT output directly: (16, 79, 16), (66, 56, 24), (90, 78, 75) or (154, 110, 90). (Part 8)
- Condition: (R, G, B) are not either one of the four sets: (23, 83, 23), (71, 63, 31), (87, 83, 71) or (151, 119, 87). (Part 8)
- Condition: When G <> 3, (R + 1) must be divisible by 8. (Part 6.3)
- Condition: When G = 3, R must be divisible by 8. (Part 7.3)
- Condition: (G + 1) must be divisible by 4. (Part 6.4)
- Condition: (B + 1) must be divisible by 8. (Part 6.2, 6.4)
- (If the first condition is met, the remaining are to be ignored; otherwise, check the remaining, and if either one of them is not met, the input will be rejected.)

R, G, B to R'G'B'
- R' = trunc[(R + 249) / 8] mod 32 (Part 6.3, 7.3)
- G' = [(G + 249) / 4] mod 64 (Part 6.4)
- B' = (B - 7) / 8 (Part 6.2)

RECT to R, G, B (Part 7.4)
- R = 8 (RECT div 2048 mod 32) + [4 (RECT div 32 mod 64) + 7] div 256 + 7
- G = [4 (RECT div 32 mod 64) + 7] mod 256
- B = 8 (RECT mod 32) + 7

R, G, B to RECT (Part 7.3)
- For all cases: RECT = 2048 {trunc[(R + 249) / 8] mod 32} + 32 {[(G + 249) / 4] mod 64} + (B - 7) / 8
- When G <> 3: RECT = 256R + 8G + (B - 7) / 8 - 1848

Negative RECT to positive (Part 7.5)
- If RECT < 0, repeat adding 65536 to RECT, until RECT >= 0.

Special RECT values (Part 8), assignments prior to all equations
- When RECT div 65536 = 4706, (R, G, B) = (16, 79, 16). When reversed, RECT = 4706.
- When RECT div 65536 = 16835, (R, G, B) = (66, 56, 24). When reversed, RECT = 16835.
- When RECT div 65536 = 21096, (R, G, B) = (90, 78, 75). When reversed, RECT = 21096.
- When RECT div 65536 = 37770, (R, G, B) = (154, 110, 90). When reversed, RECT = 37770.

9.2

9.2 - The Exchange Cycle

We have to spot on the final formulas out of these and make use of them. For the frame of the sequence of using the formulas, remember our purpose here, is "to understand what RECT means (RECT to RGB), and learn how to represent colors in RECT (RGB to RECT)" (Part 7). As we are not the original developers of LF2, everything of it were existed before our exploration. Therefore, we start from interpreting them, RECT to RGB, and be able to convert them back, RGB to RECT; the linked ends form the Exchange Cycle. Let's take a deeper look to this draft.

As discussed in Part 7.2, "RGB" is actually "R, G, B" since we do not use them as computers do -- a reminder. Breaking down the process from RECT to RGB; it would look like

Exchange Cycle Algorithm ... Wrote:Read RECT -> Break to R'G'B' -> Convert R'G'B' to R, G, B individually -> Get R, G, B

Under the standard calculations. However, we missed some the special cases which need to be checked beforehand: (1) the negative and (2) the four special RECT values. (1) should be prior to (2) since the conditions of (2) do not cover across zero. The whole flow is now drafted as

Exchange Cycle Algorithm ... Wrote:Read RECT -> Put it back to positive (if needed) -> Check if: It is one of the four special values

If: It is -> Check what RGB it refers to ->
If: It is not -> Break RECT to R'G'B' -> Convert R'G'B' to R, G, B individually ->

-> Get R, G, B

This is a more detailed version. Actually we can make use of some final equations to simplify it and get "Read RECT -> Convert to R, G, B -> Get R, G, B" by using RECT to R, G, B formulas (Part 7.4).

The another half of the cycle is converting some RGB we want to RECT, which should be probably more useful. Let's discuss the steps one by one. Starting off on RGB, we first need to check if it is permitted. This can be done by applying the condition checks listed in "R, G, B available in RECT" of Part 9.1. The first condition is special for handling the optimized colors (Part 8); if it is met, RECT result is got. For the remaining, the order of applying them does not bother much, since if either one of them does not satisfied, the whole RGB set will be rejected. The draft for this would be

Exchange Cycle Algorithm ... Wrote:Input and read R, G, B -> Check if: (R, G, B) is one of the four sets: (16, 79, 16), (66, 56, 24), (90, 78, 75) or (154, 110, 90)

If: It is one of them -> Check what RECT it refers to ->
If: It is not -> Check if: G <> 3

If: It is (G <> 3) -> Check if: (G + 1) is divisible by 4
--- If: It is not -> Reject the input
--- If: It is divisible -> Check if: (R + 1) is divisible by 8 --(Move on)-->
If: It is not (G = 3) -> Check if: R is divisible by 8 --(Move on)-->

If: It is not -> Reject the input
If: It is divisible -> Check if: (B + 1) is divisible by 8

If: It is not -> Reject the input
If: It is divisible -> Check if: (R, G, B) is one of the four sets: (23, 83, 23), (71, 63, 31), (87, 83, 71) or (151, 119, 87)

If: It is one of them -> Reject the input
If: It is not -> (Calculate R, G, B to RECT) ->

-> Get RECT

Looks complicated in text. Besides this, we can complete the cycle after filling up the calculation process. Similar to RECT to RGB, there are two algorithms, one with one step more, for being exchanging to R'G'B', finally then to RECT, instead of directly to RECT. The longer algorithm here is

Exchange Cycle Algorithm ... Wrote:(If: The color is permitted) -> Convert R, G, B to R'G'B' individually -> Combine R'G'B' into RECT -> Get RECT

For the shorter algorithm, this time it is not that simple since there are two alternatives. It can be that simple if we take the general formula, but it is a bit complex for manual calculations and there is replacement for most cases, so an alternative is developed.

Alternative 1: Exchange Cycle Algorithm ... Wrote:(If: The color is permitted) -> Apply the general R, G, B to RECT formula -> Get RECT

Alternative 2: Exchange Cycle Algorithm ... Wrote:(If: The color is permitted) -> Check if: G = 3

If: Yes -> Assign G = 259 -> Check if: R = 0
--- If: Yes -> Assign R = 255 ->
--- If: No -> Subtract R by 1 ->
If: No ->

-> Apply the R, G, B to RECT formula for G <> 3 -> Get RECT

The cycle is now completed, in text or algorithms or pseudo-codes or whatever. It is quite hard to read and confuses us, maybe a graphical representation would be better. Here I present the only picture of this article:

(click for zoom in options)

It is presented in a flowchart. Basically, rounded rectangles represent starting and ending points, parallelograms represent processes, and rhombuses represent conditional checks. Cases are one type of conditional check with multiple possibility, while normal checks only have "yes" or "no" -- "TRUE" or "FALSE" results. The "←" sign represents assignments, a process mentioned in Part 7.3, which set the value of the left-hand-side variable to the result of the right-hand-side. The symbol "=" with a "←" above means the same as "←" assignment, just to retain the equal sign since we have used it in all our equations discussed. By following this flowchart properly, you should be able to perform the necessary calculations.

9.3

9.3 - Formulas for Secondary Base Colors

At least, I have heard people asking for RECT values for perfect grey. From this, I also think about deriving perfect secondary base colors such as yellow (red + green), aqua (green + blue) and purple (red + blue). It is not complicated, only to assume two colors have the same depth, and one is always zero; or all colors have the same for grey. The only trick is to use g' instead of G'. Recall the R'g'B' to RECT formula,

RECT = 2048R' + 64g' + 32g'' + B'

For yellow, let it be Y', and Y' = R' = g', g'' = B' = 0. Formula:

RECT = 2112Y'

For aqua, let it be A', and A' = g' = B', R' = g'' = 0. Formula:

RECT = 65A'

For purple, let it be P', and P' = R' = B', g' = g'' = 0. Formula:

RECT = 2049P'

For grey, let it be Gr', and Gr' = R' = g' = B', g'' = 0. Formula:

RECT = 2113Gr'

Y', A', P' and Gr' are all integers in a scale ranged 0 to 31, as R', G' and B' do. Regarding the Y' to Y (in RGB scale), A' to A, etc. formulas, they are the same as the B' to B formula (Part 6.2),

B = 8B' + 7

With only a replacement of variable names.

Summary

This short passage summarizes our discussion so far.

RECT is a color code used in LF2 background files, uses integers ranged 0 to 65535 to represent three base colors linearly. The base colors are red, green and blue; there are 32, 64 and 32 distinct depths respectively available in RECT representation (Part 4). Representing colors linearly means combining the three variables into one, works like hexadecimal RGB (Part 3) or LF2 stage id: (Part 2). Component variables are stored in cycles. By performing division on RECT and consider the dividends and remainders, cycles and individual color depths can be "decrypted". By converting RECT into binary is also a possible method since the component ranges are in powers of 2 (Part 5). Due to the 32- and 64-depths sets nature, real RGB values jumps in 8 or in 4 as RECT changes (Part 6). Because of a need of pure white and system optimization in developing RECT codes, (R, G, B) starts from (7, 7, 7) as RECT starts from 0, and green ends a cycle at 3 in RGB scale weirdly as the green component of RECT reachs its peak (Part 6.1).

For the RECT and RGB exchanging formulas, they are discussed step by step. First from a derived system of R'G'B', from RECT (Part 5), lead to possibly discuss R' and R, G' and G, and B' and B exchanges (Part 6), then re-combined for exchanging RECT and R, G, B (Part 7), finally some special preset RECT to RGB linkages (Part 8). During these parts we gradually translate texts and ideas into mathematical equations, and repeatedly fixing them by considering wider possibilities of inputs. Towards the end, we are focusing on the systems RECT, and R, G, B separately as they are the two we data changers would use. To summarize all the mathematical discussions, all rules and formulas are listed (Part 9.1) and the Exchange Cycle has been drawn for the following of manually exchanging the two system (Part 9.2). Last but not least, at the very last part some other basic colors are also considered into deriving to-RECT formulas: perfect yellow, aqua, purple and grey (Part 9.3).

With completing the entire discussion, we now can understand how RECT works and is recorded, then make use of our understanding of the whole process to create our own backgrounds, or fix others'. However, due to the limitation of RECT, and digital storage is decreasingly being an issue nowadays, it is not a serious problem to use .bmp to replace the RECT-coded areas. Still, understanding one of the long-recognized more advanced coding systems in LF2 data changing in such extent, could be a nice satisfaction.

Tutorial For Measuring Coords. [EASIEST WAY]

Fri, 25 May 2012 15:33:39 +0200

In case you STILL don't know how to measure the values for x,y,w,h please refer to this tutorial of mine, thanx, hope it helps ya!

cursed itr [Signed 32-bit 2^32-1]

Thu, 23 Feb 2012 18:13:46 +0100

this is, what i will call a cursed itr
you have it implemented correctly when it hits a character twice (opponent/teammate/yourself whoever you want to curse)

DC-Code:

wait: 1
itr:
kind: 0 vrest: 4 fall: 70 bdefend: 100 injury: -2147483648
itr_end:

the effect is, that it first kills and then revives you back to the exact amount of hp you had (injury: 2147483648 will work as well)
you can do this with two separate itrs in different frames too but i thought this is the safest way

now after being hit twice with this injury there are either of these two things changed about the hit character:
either empty, unlimited mp and no hp regain
[better than F6 but no dark red hp]
or empty mp and unlimited hp regain
[regaining hp over the limit of 500]
i think i have also seen these two combined when using it multiple times
or in fact nullified again - it's all a bit random

help me test this to find out whether these effects are really random or have some kind of dependencies to get the one you want (a boss with truly unlimited mp or constant hp regain without some lousy hack anyone?)