Z-Axis Blink "teleporting"

[STM1993]

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>

[YinYin]

dvz on a v/^ move is still best - even if it does allow a teleport in place, so what.

[STM1993]

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.

[YinYin]

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.

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.

[STM1993]

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).

[STM1993]

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);
  }

The last line is the most important thing.

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.