+- Little Fighter Empire - Forums (https://lf-empire.de/forum)
+-- Forum: Little Fighter 2 Zone (https://lf-empire.de/forum/forumdisplay.php?fid=7)
+--- Forum: Data Changing (https://lf-empire.de/forum/forumdisplay.php?fid=11)
+---- Forum: Solved Problems (https://lf-empire.de/forum/forumdisplay.php?fid=14)
+---- Thread: Z-Axis Blink "teleporting" (/showthread.php?tid=10085)
Z-Axis Blink "teleporting" - STM1993 - 09-30-2015
EDIT: Problem solved: use dvz >500; 501-549 move up, 550 stops, 551-599 move down.
Because Steiner has such a move, but in reality its a trick based on directional key input, so its far from perfect, I decided I'd experiment with an alternative.
The trick is very simply using state 8xxx to transform the character into a ball, which then has a hit_j: value to make it move up(<50) or down(>50). The code below is for a modified jack.dat & jack_ball.dat.
|
DC-Code:
<frame> 0 standing pic: 0 state: 100 wait: 5 next: 1 dvx: 0 dvy: 0 dvz: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 hit_Fa: 240 hit_Ua: 300 hit_Dj: 350 bpoint: x: 38 y: 34 bpoint_end: wpoint: kind: 1 x: 23 y: 44 weaponact: 22 attacking: 0 cover: 0 dvx: 0 dvy: 0 dvz: 0 wpoint_end: bdy: kind: 0 x: 21 y: 18 w: 43 h: 62 bdy_end: <frame_end> <frame> 94 heavy_obj_walk pic: 23 state: 1 wait: 3 next: 0 dvx: 0 dvy: 0 dvz: 0 centerx: 36 centery: 80 hit_a: 0 hit_d: 0 hit_j: 0 bpoint: x: 38 y: 34 bpoint_end: wpoint: kind: 1 x: 37 y: 24 weaponact: 10 attacking: 0 cover: 0 dvx: 0 dvy: 0 dvz: 0 wpoint_end: bdy: kind: 0 x: 29 y: 15 w: 28 h: 64 bdy_end: <frame_end> <frame> 350 transform pic: 0 state: 3 wait: 0 next: 351 dvx: 0 dvy: 0 dvz: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 mp: 0 <frame_end> <frame> 351 transform pic: 0 state: 8216 wait: 0 next: 999 dvx: 0 dvy: 0 dvz: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 <frame_end> <bmp_begin> head: sprite\sys\jack_f.bmp small: sprite\sys\jack_s.bmp file(0-11): sprite\sys\jack_b.bmp w: 81 h: 82 row: 4 col: 2 ... <frame> 0 flying pic: 0 state: 3005 wait: 1 next: 1 dvx: 0 dvy: 0 dvz: 0 centerx: 40 centery: 41 hit_a: 0 hit_d: 0 hit_j: 90 <frame_end> <frame> 1 flying pic: 1 state: 8033 wait: 1 next: 999 dvx: 0 dvy: 0 dvz: 0 centerx: 40 centery: 41 hit_a: 0 hit_d: 0 hit_j: 90 <frame_end> |
Nothing new here actually, but there are 4 notable issues with this solution:
1) One ID can only work for 3 transformations - normal, getting hit by a ball (20 hit), or getting rebounded (30 hit) - which can be buggy if you have multiples of the same character. 10 hitting isn't realistically doable since that requires opointing a char and that'd be messy. To completely avoid bugs, you have to use 1 transformation for 1 ID.
2) Because 8xxx is used, you will have to use b sprites (+140 to pic number), so its not a good idea for characters like Bandit. I also couldn't see the ball sprite for some reason.
3) While the character is momentarily a ball, the game thinks you are gone and the results board timer will tick down. Do it often enough and it'd show up. This means you will have to opoint a character before transforming to serve as a placeholder to prevent the results board from showing up, which means a possible unwanted "com" showing up.
4) There is no way to detect if you are on the ground as a ball (hit_Fa: 7 doesn't seem to work here). Even though the char will automatically get back on level ground on transforming back, he will end up in frame 219 crouch2. You could counteract this by making frame 0 have state 100 leading to frame 94 and avoiding having next: 999 altogether, though at the start of the game when you spawn, you'd inevitably go to frame 94.
I don't know of any better solution. I have tried simply using a ball to catch the char and have the ball move on z-axis with hit_j, but that didn't work at all, don't know if its just my code. (Note: I know the ball won't grab yourself here, but it didn't move the enemy Jack on z-axis like I wanted).
|
DC-Code:
<frame> 360 picked_caught pic: 0 state: 3 wait: 0 next: 361 dvx: 0 dvy: 0 dvz: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 mp: 0 <frame_end> <frame> 361 spawn_grabber pic: 0 state: 18 wait: 0 next: 362 dvx: 0 dvy: 0 dvz: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 opoint: kind: 1 x: 39 y: 39 action: 2 dvx: 0 dvy: 0 oid: 216 facing: 0 opoint_end: bdy: kind: 0 x: 21 y: 18 w: 43 h: 62 bdy_end: <frame_end> <frame> 362 spawn_grabber pic: 0 state: 15 wait: 0 next: 1 dvx: 0 dvy: 0 dvz: 0 centerx: 39 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 bdy: kind: 0 x: 21 y: 18 w: 43 h: 62 bdy_end: <frame_end> <frame> 363 picked_caught pic: 53 state: 10 wait: 1 next: 0 dvx: 0 dvy: 0 dvz: 0 centerx: 40 centery: 79 hit_a: 0 hit_d: 0 hit_j: 0 cpoint: kind: 2 x: 42 y: 39 fronthurtact: 132 backhurtact: 131 cpoint_end: wpoint: kind: 1 x: 26 y: 50 weaponact: 31 attacking: 0 cover: 0 dvx: 0 dvy: 0 dvz: 0 wpoint_end: bdy: kind: 0 x: 26 y: 14 w: 28 h: 66 bdy_end: <frame_end> ... <frame> 2 grabber pic: 0 state: 3005 wait: 1 next: 1000 dvx: 0 dvy: 0 centerx: 40 centery: 41 hit_a: 0 hit_d: 0 hit_j: 0 itr: kind: 3 x: 22 y: 27 w: 55 h: 27 vrest: 7 catchingact: 3 3 caughtact: 353 353 itr_end: <frame_end> <frame> 3 grabber pic: 5 state: 3005 wait: 15 next: 4 dvx: 0 dvy: 0 centerx: 40 centery: 41 hit_a: 0 hit_d: 0 hit_j: 1 cpoint: kind: 1 x: 61 y: 39 vaction: 353 hurtable: 0 cpoint_end: <frame_end> <frame> 4 grabber pic: 6 state: 3005 wait: 1 next: 1000 dvx: 0 dvy: 0 dvz: 550 centerx: 40 centery: 41 hit_a: 0 hit_d: 0 hit_j: 550 cpoint: kind: 1 x: 61 y: 39 vaction: 353 hurtable: 0 cpoint_end: <frame_end> |
RE: Z-Axis Blink "teleporting" - YinYin - 09-30-2015
dvz on a v/^ move is still best - even if it does allow a teleport in place, so what.
RE: Z-Axis Blink "teleporting" - STM1993 - 09-30-2015
(09-30-2015, 11:26 PM)YinYin Wrote: dvz on a v/^ move is still best - even if it does allow a teleport in place, so what.Well, I find that I never want to teleport in place, and more often than not screw up because I attempt to chain a teleport into another move (in this case, DvA or D^A for the burst attack) or panic. Could simply swap the A/J respectively to eliminate the issue altogether (DvAJ = teleport and burst), but that wouldn't make sense control-wise.
While I'm at it I'm also thinking of taking out the dvz movement from D>J for the same reason because DJA isn't working out very well either.
RE: Z-Axis Blink "teleporting" - YinYin - 10-01-2015
(09-30-2015, 11:45 PM)STM1993 Wrote: Well, I find that I never want to teleport in place, and more often than not screw up because I attempt to chain a teleport into another move (in this case, DvA or D^A for the burst attack) or panic. Could simply swap the A/J respectively to eliminate the issue altogether (DvAJ = teleport and burst), but that wouldn't make sense control-wise.While I'm at it I'm also thinking of taking out the dvz movement from D>J for the same reason because DJA isn't working out very well either.How does switching A/J solve any problem? DvJA would word just the same (similar to woody D>AJ). Chaining anything quick with crucial positioning will always be difficult. Granted the input of one should better not overlap with the positioning of the other.
(09-30-2015, 11:45 PM)STM1993 Wrote: While I'm at it I'm also thinking of taking out the dvz movement from D>J for the same reason because DJA isn't working out very well either.Adjusting things for the most common/effective use is always a good thing.
RE: Z-Axis Blink "teleporting" - STM1993 - 10-01-2015
(10-01-2015, 12:33 AM)YinYin Wrote: How does switching A/J solve any problem? DvJA would word just the same (similar to woody D>AJ). Chaining anything quick with crucial positioning will always be difficult. Granted the input of one should better not overlap with the positioning of the other.It only works from A to J (D>AJ = D>A D>J), doesn't work from J to A (= D>J A). And yes, the main issue is the input overlapping with positioning, though not just for DvJ DvA but also D>J Dv/^A/DJA (where I find DJA is cumbersome).
I suppose I could make hitting A at the end of the teleport use the burst, though it would mean having to either delay regular punching, making the input window for burst very short, and possible clashing with D>A. Either way will test out how it goes eventually; like you said its best to adjust for most common/effective use.
Finally found out the problem with the 1st ball cpoint method I used, no more having to rely on the extremely buggy state 8000 method (I now learned that a lot of things default to frame 0 than I expected).
Turns out the ball I used didn't enter state 9 when grabbing the character, which is why the character got stuck in place instead of following the ball that grabs it. So here's the (EDITTED) steps:
1) Steiner opoints ball at 1000+ y
2) Ball state 18 with 1000+ centery with ik3 grabs Steiner (self-hit + hide burning smoke without needing to do a full mod)
3) Ball state 9(important for the moving grab to work), vaction Steiner to frame with cpoint k2 with state 15 (not 10 to avoid weapon drop). Move along predetermined z-direction via hit_j.
4) Ball uses vaction Steiner to frame with no cpoint k2, with state 100 & high dvy, next 94 in case already on ground.
5) Ball deletes itself, Steiner lands in frame 94. End.
Only 2 flaws I can see now:
A) The shadows, nothing much I can do about it since I can't use state 3005 anywhere during the grabbing, at best I mitigate the pixels clumping together into a solid shadow by using cover: 12, and make sure to factor in this 2 pixel z-axis difference for the ball's hit_j. There isn't a cover value where the z aligns exactly.
B) Since I have to use cover: 12 (no such thing as cover: x-y or -xy), that means Steiner will actually be 1-2 pixels off the top border of the map, similar to the Julian anti-Rudolf fix where the image would end up a pixel lower than the top border. Using ik8(ball carries type 0 with wpoint in act 1200, Steiner with ik8) won't solve the issue since ik8 will still be off by 1 pixel downwards.
(EDIT) C - Does NOT work when under the effects of invisibility or getting up from lying.
I can live with both flaws considering this is the most bug-free solution I have, though ideas to solve them are welcome.
Perhaps the most bugfree solution would involve creating a custom AI for a type 0 solely for the purpose of carrying Steiner through the use of ik7 + wpoint + state 1004, but uhh... yeah.
(unrelated: LF2 is REALLY determined to let interrupted grab victims hop above y=0 directly into frame 212, looks like there's nothing I can do and I don't wish to resort to opointing a ball that detects frame 212).
RE: Z-Axis Blink "teleporting" - STM1993 - 09-10-2016
Bump because @zort found a solution to this problem.
Take a look at this code:
Code:
frame_id1_2 = dude_p->frame1;
dvx = filePointer->frames[frame_id1_2].dvx;
frames = (sDataFile *)((char *)filePointer + frame_id1_2 * 376);
if ( dvx <= 500 )
{
if ( dvx > 0 )
{
// if facing right then buff x speed to dvx
dvx_double = (double)dvx;
if ( dvx_double > dude_p->x_velocity && !dude_p->facing )
dude_p->x_velocity = dvx_double;
}
dvx_1 = frames->frames[0].dvx;
if ( frames->frames[0].dvx > 0 )
{
// if facing left then buff x speed
v112 = (double)dvx_1;
if ( -dude_p->x_velocity < v112 && dude_p->facing == 1 )
dude_p->x_velocity = -v112;
}
v123 = frames->frames[0].dvx;
if ( frames->frames[0].dvx < 0 )
{
v113 = (double)v123;
if ( v113 < dude_p->x_velocity && !dude_p->facing )
dude_p->x_velocity = v113;
}
v124 = frames->frames[0].dvx;
if ( frames->frames[0].dvx < 0 )
{
v114 = (double)v124;
if ( -dude_p->x_velocity > v114 && dude_p->facing == 1 )
dude_p->x_velocity = -v114;
}
}
else // else if dvx > 500
{
dude_p->x_velocity = (double)(dvx - 550);
}This also applies to dvz movement - if I use dvz 501-549, I can force Steiner to move UP on the z-axis between 49-1px.
If I use dvz 551-599, I can force Steiner to move DOWN on the z-axis between 1-49px.