[solved] "Bouncing" fall effect.

[D137Pi]

Hello (again).

I shall begin with an explanation of what I mean by "bouncing".
"Bouncing": When Henry uses his multiple arrow shot (DJA), or Rudolf - multiple shurikens (D->A), and all those projectiles hit the same character at the same time (most trivial example is when they're standing right where the projectiles are spawned), instead of falling to the ground - that character goes into the "dance of pain" in mid-air, takes a short leap backwards and is able to stand once more.

What I wish to do is replicate this effect without the opointing taking place all within the same frame (as I want it to happen whenever a hit takes place).

The problems: (1) I'm doing this with character spawning rather than projectiles. It appears that whenever I try to opoint two characters with the same location(xy) & facing values within one frame, it will simply take just one of those. Regardless of whether two opoint tags or a single one with two codelines is used.
(2) So if not in a single frame, then take two frames with the shortest wait time possible (by spawning a few coordinated "character spawners" as well). This doesn't seem to work due to even the minor 1/30s time difference - hits don't take place at the same time, you get a regular fall.

If you have any idea how problems (1) or (2) could be overcome, or some other solution, then please - do share.

Solution: opoint 101.

Regards and thanks ahead,
D.

[Silverthorn]

Try changing the "facing"-value to 20

[D137Pi]

Try changing the "facing"-value to 20

Could you elaborate on the code for it? I've tried this (with 5, actually, and using an opoint similar to Ruldolf's +man with different x/y values) but it gives a rather large distance in-between them, rather than them spawning in the exact same spot.

Also... uh... I'd still like to spawn 3 more behind the character. With the same direction. If that's possible.

[Silverthorn]

DC-Code: opoint: kind: 1 x: 40 y: 79 action: 0 dvx: 0 dvy: 0 oid: 5 facing: 20 opoint_end:

This is the opoint from rudolf's +man-sequence. The facing-value tells the app to create two objects with the id: 5 and let them face the same direction as your char (1 would turn the object around). So you will not need to change that part for having them all into the same direction.

However, what I'd do is the following: in one frame of your attacking sequence, you opoint out the 3 objects behind your characters. In the next frame, the two additional ones in front (or whereever you want to have them). Link these two frames together with a certain wait-value, let's say "1". The opointed objects will have to run through different frames, similar to this little illustration here:

This way, you can time your stuff, even when you create objects at different frames.

Now, since facing will let your objects move apart from each other, you might want to try adding a "dvz: 550" into your opointed object-frames. That should prevent them from moving along the z-axis.

[D137Pi]

DC-Code: opoint: kind: 1 x: 40 y: 79 action: 0 dvx: 0 dvy: 0 oid: 5 facing: 20 opoint_end:

This is the opoint from rudolf's +man-sequence. The facing-value tells the app to create two objects with the id: 5 and let them face the same direction as your char (1 would turn the object around). So you will not need to change that part for having them all into the same direction.

However, what I'd do is the following: in one frame of your attacking sequence, you opoint out the 3 objects behind your characters. In the next frame, the two additional ones in front (or whereever you want to have them). Link these two frames together with a certain wait-value, let's say "1". The opointed objects will have to run through different frames, similar to this little illustration here:

This way, you can time your stuff, even when you create objects at different frames.

Now, since facing will let your objects move apart from each other, you might want to try adding a "dvz: 550" into your opointed object-frames. That should prevent them from moving along the z-axis.

Wow, that's a downright impressive illustration...

- Would it work with a wait value of 0? It is quite crucial to the sequence I'm using. Difference is, I'm not sure whether the opoint takes place immediately as you enter the frame.

- I shall test this dvz trick in a moment and see if it works.
Well, doing this in the opoint didn't work... shall I add the code and a screenshot?

[Silverthorn]

Try the dvz in the actual frame-header of the opointed objects. Also, opoint creates objects at the beginning of a frame. You can easily test it out by using a "measurable" wait-value (aka. something far over 30). Thing is, wait: 0 sometimes causes unwanted bugs. In 99.9% of the cases it's save to go with wait: 1.

[D137Pi]

Try the dvz in the actual frame-header of the opointed objects. Also, opoint creates objects at the beginning of a frame. You can easily test it out by using a "measurable" wait-value (aka. something far over 30). Thing is, wait: 0 sometimes causes unwanted bugs. In 99.9% of the cases it's save to go with wait: 1.

- dvz in actual frame-header - worked.
I do find it somewhat strange that the opointed object seems to have absolutely nothing to do with opoint's given coordinate values.

- Wait: 0 - indeed caused a bug. Namely, did not let the object be opointed...

I think this solves the problem, once the previous timing thing is added.

...Seeing as this has managed to replicate the bouncing effect, it is indeed solved.

Thank you very much.

[Alblaka]

- Wait: 0 - indeed caused a bug. Namely, did not let the object be opointed...

Whatever the bug (cause) was, opoints are NOT influenced by wait:0.
You can see enough examples in my chars, opointing many objects "at once" with using a couple of wait:0's

[D137Pi]

- Wait: 0 - indeed caused a bug. Namely, did not let the object be opointed...

Whatever the bug (cause) was, opoints are NOT influenced by wait:0.
You can see enough examples in my chars, opointing many objects "at once" with using a couple of wait:0's

The opoint-ed's action frame had wait 1, which I test-changed to 0 and then suddenly it did not appear at all (not the 'com' writing nor the effects it was supposed to have).

[Alblaka]

- Wait: 0 - indeed caused a bug. Namely, did not let the object be opointed...

Whatever the bug (cause) was, opoints are NOT influenced by wait:0.
You can see enough examples in my chars, opointing many objects "at once" with using a couple of wait:0's

The opoint-ed's action frame had wait 1, which I test-changed to 0 and then suddenly it did not appear at all (not the 'com' writing nor the effects it was supposed to have).

Then you just messed something additionally up.

Trust me, opoints even work with wait:0
They only don't work in "first" frames.