• ItrKind:1 (ik1)
kind:1 in itr: tag are used in the game to 'catch' an object that has state:16 in it's current frame.
{ik1 can only be activated by type:0 that pressing > or < button}

Once the itr are success, the 'catcher' will "transform" it's current frame into the number that being preferred by catchingact:% % in 'catcher''s data, while the object that being 'caught' will "transform" it's current frame into the number that being preferred by caughtact:% % in 'catcher''s data.
Then, the 'catcher' may control the 'caught' object using cpoint: tag that immediately start working/immediately working after the "frame transformation" by the ik1.

("%" meaning a certain value / variable, usually i use this because it's way more noticeable than "x".)
(Not sure why there's a double value that being used for both catchingact: and caughtact:.)

• ItrKind:3 (ik3)
kind:1 in itr: tag are used in the game to 'catch' a type:0 object.. is it works for type:5 too?

Just same like ik1, once the itr are success, the 'catcher' will "transform" it's current frame into the number that being preferred by catchingact:% % in 'catcher''s data, while the object that being 'caught' will "transform" it's current frame into the number that being preferred by caughtact:% % in 'catcher''s data.
Then, the 'catcher' may control the 'caught' object using cpoint: tag that immediately start working/immediately working after the "frame transformation" by the ik3.

(The "frame transformation" of the ik1 and ik3 is the "frame transformation lv4".)
(The "frame transformation" of the cpoint: is same like wpoint:'s "frame transformation" which is "frame transformation lv5" which are the weakest "frame transformation".)

• Cpoint: tag
cpoint: is a feature that allow an object to control other object after successfully being 'catch' by ik1 or ik3.

I don't think i need to explain much about cpoint:..
(Basic description about cpoint:; https://lf-empire.de/lf2-empire/data-changing/frame-elements/177-cpoint-catch-point)

But! It doesn't explain anything about CpointKind:0 right?!

Cpoint actually always exist in any frame even if you don't insert Cpoint: in a frame. The default value of Cpoint is

DC-Code: cpoint: kind: 0 x: 0 y: 0 vaction: 0 cpoint_end:

Another value also valued 0 by default.
The basic function of CpointKind:0 is to allow you to end the catch. Technically there's CpointKind:0 in injured or falling frame by default you know.. that's why the catch of your character will ends if your character cast a skill or being injured.

---

"But why the enemy doesn't dropped in frame0 since the vaction: are 0?"
Because the caught object use CpointKind:2 in it's frame which will hijack the dropped frame.

---

When the CpointKind:0 are used by the caught object, it'll ends the catch too, the catcher will goto frame0 (if the catcher using CpointKind:1) while the caught object will continue with it's next:.

Actually I prefer to call it "ik3's recall" but.. well.. "cpoint's recall" is more relevant.

If you know, there's a variable in AI, named ctimer, idk why it's being named as "timer" even tho it doesn't count anything {I think the address was messed up, it shouldn't be "ctimer" right?}. Instead of works as a "timer", it's actually an ObjNum of the thing that recently catch your character/an object.

Cpoint's recall is a bug that when you using a Cpoint with kind:1 that followed with throwx, throwy, and throwy was ≠ 0, the last catched object in ctimer will be totally forced to move/teleport to the preferred location and frame in that Cpoint.
The only problem is.. if the last caught ObjNum were being caught by other ObjNum/the number changed, the .exe will stopped working, which is it's the big flaw of this tech.

Except from that flaw, the only flaw is this tech won't applying/affecting the Called ObjNum's Z-axis and must be affected by throwxyz.

Anyway, the function of this tech are kind like ik8 but instead of doesn't affecting the Y-axis, this tech won't affecting the Z-axis...

Study Example... hmm... this tech are quite risky if it being used for a single Mod...

By using these steps, the end up position of ik1 and ik3 should be changed into "(catcher.x + caught.x)/2".
Do note that the cpoint: of the caught object is like this. (Ofc you can adjust the value to Control the postion.)

DC-Code: cpoint: kind: 2 x: (€) cpoint_end:   #(€ was the centerx:.)(Another value can use any value as you wish.)

== ItrKind:3 (ik3) ==
• Consider the value(named %) as the frame that will be sacrificed. Let's say % is 399.... means frame399 will be sacrificed.
• Set every caughtact: that use ik3 in Catcher's data into %.
• Add frame% in the Catcher's data a

DC-Code: cpoint: kind: 1 x: (€ - 43) y: (£) cpoint_end:   #(€ was the centerx: of frame% while £ was the centery: of frame%.)

Done. *You can adjust that 43 in the cpoint to get into more advanced with this.
{For example change the value into (€ - 45) for an object that will catch yourself(your char) and you won't move/got a shift from your position}

== ItrKind:1 (ik1) ==
• Consider the value(named %) as the frame that will be sacrificed. Let's say % is 398.... means frame398 will be sacrificed.
{you can also set it on frame399 (a same frame with ik3 fixer) but the magical value will be changed significantly}
• Set every caughtact: that use ik1 in Catcher's data into %.
• Set x: value in the cpoint: in the frame that being referred from every catchingact: that use ik1 into €. € was the value of centerx: of the frame.
• Add frame% in the Catcher's data a

DC-Code: cpoint: kind: 1 x: (€ + 1) y: (£) cpoint_end:   #(€ was the centerx: of frame% while £ was the centery: of frame%.)

Done, but if you want both fixer are works, then you need change something in the steps of ik1;
• Set x: value in the cpoint: in the frame that being referred from every catchingact: that use ik1 into (€ - 40). € was the value of centerx: of the frame.
• Add frame% in the Catcher's data a

DC-Code: cpoint: kind: 1 x: (€ - 43) y: (£) cpoint_end:   #(€ was the centerx: of frame% while £ was the centery: of frame%.)

It's a condition.. when an object trying to change it's frame. There's 5 levels to indicating the what is left from the current frame and what's come from the next frame.
The text that colored with Red(yes it's orange) means from current frame, while White means it's come from the preferred/next frame. Especially for centerx: and centery:, it'll works for both current and preferred frame.

Level 1
Ways;
≈ Negative mp:
Tags;
pic: state: wait: next: dvx: dvy: dvz: hit_%%: mp: sound:
bpoint: cpoint: wpoint: itr: opoint: bdy:

Level 2
Ways;
≈ Hardcoded effect (st3000, st100, etc..)
Tags;
pic: state: wait: next: dvx: dvy: dvz: hit_%%: mp: sound:
bpoint: cpoint: wpoint: itr: opoint: bdy:

Level 3
Ways;
≈ hit_%%:
Tags;
pic: state: wait: next: dvx: dvy: dvz: hit_%%: mp: sound:
bpoint: cpoint: wpoint: itr: opoint: bdy:

Level 4
Ways;
≈ itr: (hit or being hit)
Tags;
pic: state: wait: next: dvx: dvy: dvz: hit_%%: mp: sound:
bpoint: cpoint: wpoint: itr: opoint: bdy:

Level 5
Ways;
≈ cpoint:
≈ wpoint: (wpoint are kinda different but technically it's level 5.)
Tags;
pic: state: wait: next: dvx: dvy: dvz: hit_%%: mp: sound:
bpoint: cpoint: wpoint: itr: opoint: bdy:

Well, actually wpoint use Level 6... but 5 levels are enough.