Charge-Up Blasts with Input Holding

[Silverthorn]

Download link for Sinow's Justin:
http://www.mediafire.com/download.php?mnxuhdnmqnw
(courtesy of Some1Else from this post)

Well, I'm finally about done with this little tutorial I've been working on for the past month or so especially for you guys: all the members of the LFE-Forums, who are incredibly awesome and extremely good-looking. ^.^

Basically, the idea was to create a charge-up blast move (like in KateLF2), but with input holding.

As an example, I made a small Justin modification. When I press D>A, he does a normal blast:
D>A


However, I press D>A and hold down A for a little, then let go, Justin charges up and shoots a long range blast:
D>(A)


If I hold down A even longer, eventually there will be a tone. If I then let go of A...
D>((A))


Additionally, if, instead of holding A, I rapidly press it, Justin will shoot multiple blasts:
D>A (+A +A +A...)


Now, there are definitely some bugs with this technique, I'll be the first to admit that, but they're at least partially fixable, and they don't usually occur unless you're really trying to get them to happen smilie

I haven't quite finished writing the tutorial yet, its a little complicated, and I need to clean up the study example a little bit, but I'll do my best to post it either today or sometime this weekend.

[...]

@ApOcAlIpSiS:
Its a little complicated, i suppose. When you understand it, its not so bad, but the dc work is still a bit tedious. It'd probably be difficult for beginners to understand as its important to know some of the basics of dc for this.

Code:

YinYin: you should really really try to use the kind8 thing less in that (cause i myself dont like it being used in a game that still shows "com")

Originally, I was not opointing any type: 0 dummy frames at all, just using the kind: 8 ball to opoint the various blasts. I decided against this in the end, however, and chose to do it this way as this allows you to control the blast's z-movement a bit. Some of the type: 0 usage is necessary anyway. I suppose that's worth fixing though... I'll edit it a bit and get rid of the coms.

Code:

YinYin: also this moves your char down even more than it does in my killer lf2 right?
and its shaking him in a strange way - try to get the x values right at least (and maybe decrease the amount of times using that extra type0 object ...)

The char doesn't move down, as you can see in the gifs (notice justin isn't all the way at the bottom of the field and that the "Com" is on a slightly different part of the z-axis). Simply having the ball move up one pixel before spawning the character fixed this.

The shaking is actually intentional and necessary. There needs to be some forward movement in order for the key holding to work, so unless you don't mind having the character move forward (which could be fine for some applications, although you'd have to deal with something else if that were the case), you have to live with the 1 pixel oscillation. Its not really that bad :P


Heheh, I'm not pleased that there are still some minor issues with this technique. They're all relatively fixed; whenever one occurs, it is quickly rectified. However, it is still rather annoying.
There are a couple things I might be able touch up a bit, but some things don't appear to be fixable.

Code:

Sinow: I decided against this in the end, however, and chose to do it this way as this allows you to control the blast's z-movement a bit.

ah ic the zmovement

Code:

Sinow: The char doesn't move down, as you can see in the gifs (notice justin isn't all the way at the bottom of the field and that the "Com" is on a slightly different part of the z-axis). Simply having the ball move up one pixel before spawning the character fixed this.

screw this ive been trying to fix it that way all the time and it didn work T_T
anyway it still looks like you are all the way down on those gifs ...

Code:

Sinow: The shaking is actually intentional and necessary. There needs to be some forward movement in order for the key holding to work, so unless you don't mind having the character move forward (which could be fine for some applications, although you'd have to deal with something else if that were the case), you have to live with the 1 pixel oscillation. Its not really that bad smilie

i think it looks stupid - if you do something about the sprites it might be ok but not this way

Code:

Sinow: Heheh, I'm not pleased that there are still some minor issues with this technique. They're all relatively fixed; whenever one occurs, it is quickly rectified. However, it is still rather annoying.
There are a couple things I might be able touch up a bit, but some things don't appear to be fixable.

well i think ill ditch the zmovement and try to see how smooth and "bug-free" i can get it

Ditching the z-movement won't change any of the buggyness. :P
The only thing that it'll change, other than disabling the z-axis control, is the fact that your character won't move down 1 pixel on the z-axis when s/he's all the way at the top of the fighting area. Sure, even having that minor thing is annoying, but its better than not being able to control the directions of the blasts.

fixing the z-axis adjustment because of itr/kind 8 is quite simple. Opoint a ball, have the first frame wait: 1 hit_j: 47, and opoint the type: 0 dummy in the next frame.

DC-Code: <frame> 18 lvl3 pic: 999 state: 3005 wait: 1 next: 19 dvx: 0 dvy: 0 centerx: 35 centery: 41 hit_a: 0 hit_d: 0 hit_j: 47 <frame_end>   <frame> 19 lvl3 pic: 999 state: 3005 wait: 1 next: 1000 dvx: 0 dvy: 0 centerx: 35 centery: 41 hit_a: 0 hit_d: 0 hit_j: 50 opoint: kind: 1 x: 35 y: 41 action: 398 dvx: 0 dvy: 0 oid: 39 facing: 0 opoint_end: <frame_end>

And he's not at the bottom, try moving a character all the way to the bottom on Lee on Road, take a screenshot and compare if you don't believe me. Even if he was, the Com still appears slightly above (1 pixel) where it would if it was on the same z-axis.

I suppose the oscillation of the sprite might be somewhat fixable with some centerx adjustment, but the name (and screen or background layers, depending on the situation) would still move back and forth and there's nothing that can change that in this application of this technique.


[...]


Well, I suppose I'll post this older version so you guys can play with it a bit. The method I'm working on now is a slightly different way to get the same effect and it should ultimately work out better than this one.
[download link has been deleted]

[...]

*bump*

Here's my version. I'm still working on it, has bugs. I didn't base this one on Sinow's data (though I think if I looked at it i'd have made it work faster). This one:
-hold A = charge meter
-release A = shoot missile based on how long u've charged for

still to do:
-dirchange while charging

[...]

state 4. State 5 is reserved for another charging up thing :P. (so u can have 2 moves which both have input holding). You don't need state 4 to be on a certain frame, but i think u do need it for state 5 (all dash/backdash frames are pre-programmed) but maybe u don't need it (haven't tested).

next update:
-dirchange is possible
-meter always charges to the right

bugs:
-sometimes you don't shoot.

[...]

!wooooooooooooooooooooooooooooooooooooooo I've done it! right now:

stuff:
-charge meter always faces the right
-while charging, u can face different directions, and shoot (release A) in the direction u face.

bugs fixed
-missile didn't shoot at certain times
-missile always shot at lowest

new features:
-missile splits in midair
-explosion sprites done

video comes tomorrow =\

[...]


there we go.

[...]

just a note: this disables jumping 100%. (to allow jumping will be very very coomplicated to work around, which is why Sinow used state: 5 instead of state: 4 i think). Anyways, It's possible to enable jumping and still do this stuff but I think it's not worth the trouble =\. Plus, I just thought of something right now ---> variations of input holding. I think it's possible to have 4 different moves that use input holding, but it'll take some time to work out.

STM1993 edited this post 06-06-2018 08:47 PM because:

Editted the formatting and fixed a few links.

[Bamboori]

sorry for this reviving, but i need the study example of this. the link doesnt work anymore.

help me pls :P

[no one]

http://www.lf-empire.de/forum/showthread.php?tid=2672