DC Solutions/Explanations for some LF2 bugs

[STM1993]

#7: Davis super high D^A (Click to View)

If Davis' DvA 3rd punch hits something such as an arrow, he will get hit lag. If Davis does D^A while in that state, he would fly extra high.
Possible Fix: Using D^A should go to a wait 0 frame that has no dvx/y before going into frame 300.

wait: 0 does induce a considerable wait (1/3 I think). So this would delay all his dragon punches. You could split the first wait 1 frame into three wait 0 frames, but then the upwards motion still comes one frame too late. I would rather try to change the rest on the effect 4 itrs in the shrafe, but I am not skilled enough to reliably reproduce this bug (does it actually still exist in 2.0a?) to debug it.

Yes, bug exists in 2.0a.
Reliable way to test: You can set Davis' frame 278 to have no next and hit_a: 300, then set dvx: 0. While in LF2, have player 1 control Davis and player 2 control Henry. Davis uses DvA, wait for him to get stuck at 278. Position Henry have him shoot one arrow at Davis, and then Davis presses A just as the arrow hits. Timing is just as the hit spark appears; its easier if you position Henry further away from Davis.

I've found exactly 2 different jump heights: one shoots through the ceiling which happens if your timing is absolutely perfect(3rd on screenshot), the other one is a slightly higher uppercut which happens if your timing is off by just a bit but still within hit lag(2nd on screenshot). 1st on screenshot is normal uppercut. Yes, the jump heights are the same as if I did it on an unmodded shrafe, so this is definitely a reliable way to test.

If the hitlag occurs as a result of being hit(state 7) as opposed to hitting something(itr), it has the opposite effect as you seem to lose movement and get stuck in that frame momentarily for a longer period of time, resulting in a shorter uppercut(4th on screenshot).

#36: No pink smoke transform - no solution, not even dvy: 550 works.

My bunny hopping might be related. We should test this with LEX/Firzen being in a different data.txt spot. I don't think I have a solution either though.

Tested. Nothing to do with data.txt location, but strongly related to the game's problem with handling objects landing on the floor. Trevor's holy water DvJ uses Firzen's overwhelming disaster hit_Fa to make it land on the floor. During tests however, I found that depending on how high Trevor is before using the move, the ball sometimes lands slightly higher or slightly lower than usual.

Same problem. This bug only ever happens to Louis, LouisEX & Firzen. What they all have in common is a different jump value from -16.299999, but somehow only these 3 characters are affected by the bug. Other characters with a different jump value(or the ability to make themselves jump higher like Henry's arrow or Davis' super high uppercut) seem unaffected.

The moment I put in a jump value of "-17.000000"(Firzen) or "-18.699999"(Louis) on an otherwise unaffected character and use transform after jumping, they too will experience the no pink smoke bug.

One problem with using another id is that the arrows will loose their ability to free criminals. I've manually scripted that back in for the alf2 Henry.

Updated bug #15 solution.

The best fix is to just use an ID other than 201. The downside however, is that the arrows will appear to be deflected even if it hits the opponent and do not free criminals. The freeing criminal problem can be fixed by making the arrows themselves create & carry a hidden ID 201 weapon which will use a hidden itr to hit a hidden bdy in criminals. Study example for normal arrows(not DJA) and mid-air arrows attached:
<see first post for attachments>
id: 201 type: 1 file: data\henry_arrowfake.dat
id: 995 type: 1 file: data\henry_arrow1.dat
I can't fix the hit opponent problem; itrk8 is too buggy a solution to consider in this case. A weapon in ID 201 will automatically destroy itself when it hits an opponent even if the weapon is being held on_hand.

You can also remove the bdy from the arrows, but then it'd make arrows immune to deflecting unless you decide to mod the entire LF2 to hit a hidden bdy in the arrows with a hidden itr, which is a very troublesome solution.

---

EDIT:
Update on the just_on_ground frames.

#29: Non-damaging hit spot, thrown weapons (just_on_ground) (Click to View)

Unlike what main site suggests, just_on_ground frames are the cause of this. Don't believe me? Set the itr on Henry's arrow frame 70 to have effect: 2; at the end of the range the arrow will burn.

I don't see effect 2 in my data, but misread that. These frames do have an itr without injury in some weapons. However the animation that follows frame 70 never runs through and I also don't recall ever managing to view this frame paused. I think at an early stage this might've been used for weapon bouncing and it is still called, but the real solution has been moved into the weapon type (bottles and throwing items bounce, light weapons don't).

Actually, I've managed to get frame 70-72 on weapon0 and even henry_arrow1 to work. It is still occasionally being called.

DC-Code: <frame> 70 just_on_ground pic: 16 state: 1003 wait: 15 next: 71 dvx: 0 dvy: 0 dvz: 0 centerx: 24 centery: 40 hit_a: 0 hit_d: 0 hit_j: 0 sound: data\011.wav itr: kind: 0 x: 1 y: 19 w: 46 h: 15 dvx: 2 fall: 40 arest: 16 bdefend: 16 itr_end: <frame_end>   <frame> 71 just_on_on_ground pic: 17 state: 1003 wait: 15 next: 72 dvx: 0 dvy: 0 dvz: 0 centerx: 24 centery: 36 hit_a: 0 hit_d: 0 hit_j: 0 itr: kind: 0 x: 1 y: 19 w: 46 h: 15 dvx: 2 fall: 40 arest: 16 bdefend: 16 itr_end: <frame_end>   <frame> 72 just_on_on_ground pic: 18 state: 1003 wait: 15 next: 64 dvx: 0 dvy: 0 dvz: 0 centerx: 24 centery: 34 hit_a: 0 hit_d: 0 hit_j: 0 sound: data\011.wav itr: kind: 0 x: 1 y: 19 w: 46 h: 15 dvx: 2 fall: 40 arest: 16 bdefend: 16 itr_end: <frame_end>

The code is for weapon0 (baseball bat). All I did is change the pics to some unused sprites, added some sprites to those unused areas, and then changed the wait to 15. Interestingly, sometimes the frames play from 70 all the way to 64, other times they don't. It seems to be specific to the angle or frame the weapon is thrown or dropped; when I used Henry to throw the bat straight forward, it would land on frame 70. If I threw it in mid-air, it would only land on frame 70 if I threw it very close to the ground.

Deleting just_on_ground WILL actually cause problems; should the weapon land in the specific conditions, the weapon would simply disappear but leave a shadow behind, just like if a character went into a non-existent frame. This also applies even if the weapon does not use default IDs.