Question about the "ground" in OpenBOR

M

Matute2175

New member
Hi, I have a question and I'm hoping someone can help me: how does OpenBOR work with the ground when an enemy is grabbed?

Let me explain: I have a character who grabs an enemy in mid-air and initiates a slam start with:
@cmd slamstart
@cmd position 2 20 -35 0 1
@cmd screenBound 57 0 0 0 1
hitfx data/sounds/empty.wav
frame data/chars/players/cody/0102.png
etc....

The position is associated with the enemies' fall4:

anim fall4
flipframe 0
loop 0
offset 130 187
bbox 0 0 0 0
delay 999
@cmd depost 0
@cmd clearL
frame data/chars/1streetguy12/pain03.gif
offset 137 225
delay 999
frame data/chars/1streetguy12/slamck15.gif
offset 104 221
delay 999
frame data/chars/1streetguy12/pain03.gif
offset 121 249
delay 999
frame data/chars/1streetguy12/slamck15.gif
offset 186 210
delay 999
frame data/chars/1streetguy12/slamck12.gif
offset 170 194
delay 999
frame data/chars/1streetguy12/pain04.gif
offset 124 221
delay 999
frame data/chars/1streetguy12/slamck12.gif
offset 74 147
delay 999
frame data/chars/1streetguy12/slamck15.gif
offset 74 212
delay 999
frame data/chars/1streetguy12/fall1.gif
delay 999
frame data/chars/1streetguy12/pain0.gif
frame data/chars/1streetguy12/slamck15.gif
offset 114 207
delay 999
frame data/chars/1streetguy12/slamck15.gif
offset 114 174
delay 999
frame data/chars/1streetguy12/slamck15.gif
offset 146 226
delay 999
frame data/chars/1streetguy12/pain9.gif
offset 172 226
delay 999
frame data/chars/1streetguy12/pain9.gif
offset 99 209
delay 999
frame data/chars/1streetguy12/pain03.gif
offset 109 220

delay 999
frame data/chars/1streetguy12/pain03.gif

offset 54 205

delay 999
frame data/chars/1streetguy12/pain0.gif

offset 114 259

delay 999
frame data/chars/1streetguy12/slamck9.gif

offset 114 171

delay 999
frame data/chars/1streetguy12/slamck9.gif

The problem is that the grab works fine; both the player and the enemy are positioned correctly. However, the dust and fall sounds of the enemy's fall activate before they physically touch the ground (even though they haven't physically hit the ground yet), and of course, it doesn't look quite right. Does anyone know why this is happening? Thanks.
 
Sort by date Sort by votes
I believe this is the cause:
@cmd position 2 20 -35 0 1
Click to expand...

This function binds opponent at 0 altitude difference or IOW if the grabbed is on the ground, the opponent would be on the ground as well.
This causes opponent (which is playing FALL animation) to spawn dust and fall sound as if he/she/it has landed on ground.
The solution is to set slightly higher altitude like this:
@cmd position 2 20 -35 2 1
Click to expand...
 
Upvote 0 Downvote
Bloodbane said:
I believe this is the cause:


This function binds opponent at 0 altitude difference or IOW if the grabbed is on the ground, the opponent would be on the ground as well.
This causes opponent (which is playing FALL animation) to spawn dust and fall sound as if he/she/it has landed on ground.
The solution is to set slightly higher altitude like this:
Click to expand...
Theoretically, that zero should correspond to the z-axis instead of the y-axis, according to this

void position(int Frame, float dx, float dy, float dz, int face)

In contrast, -35 would be equivalent to the y-axis, but the fact is that in fall4, where it chooses the frame for position, the offset is well above the ground.
So, does OpenBOR interpret the enemy as touching the ground, even though they don't physically step on it during the animation?
 
Upvote 0 Downvote
O Ilusionista said:
That is the problem: Y axis is not negative in OpenBOR like on other engines (like Mugen). If something must be 35 pixels from the reference point (the ground in this case), it should be 35
Click to expand...

This. It is of course possible to have negative Y values, but OpenBOR will treat them as "below ground" unless you also have a negative basemap, and that's how you make pits.


DC
 
Upvote 0 Downvote
Matute2175 said:
The problem is that the grab works fine; both the player and the enemy are positioned correctly. However, the dust and fall sounds of the enemy's fall activate before they physically touch the ground (even though they haven't physically hit the ground yet), and of course, it doesn't look quite right. Does anyone know why this is happening? Thanks.
Click to expand...
@Matute2175 To avoid dust during the grab animation, I recommend adjusting the grabbed opponent at least with 1px above the ground in the Y parameter, like @Bloodbane mentioned, otherwise the engine will see it as a landing (since usually during a fall animation the character is on the air).

I only use zero in the first frame because this is where the grab starts and usually works fine. Even if you need to simulate like if the grabbed opponent is touching the ground (usually during slams), I suggest faking it directly in the fall animation sprites (commonly fall7) or even changing the offset.

As an example, in the part marked in red/yellow I put 1px as Y value and then adjusted the grabbed opponent fall7 frame like if he is really touching the ground, but in fact it's not.

1786584142019.png
 
Upvote 0 Downvote
Matute2175 said:
Theoretically, that zero should correspond to the z-axis instead of the y-axis, according to this

void position(int Frame, float dx, float dy, float dz, int face)
Click to expand...

Sorry about that. Multitasking made me forgot my old scripts.
Anyways, to solve your negative altitude issue, I suggest making clone of grabbed pose in FALL4 whose offset is lower than the actual one. With this clone frame, the set altitude for position function would be higher and positive.
 
Upvote 0 Downvote
Kratus said:
@Matute2175 To avoid dust during the grab animation, I recommend adjusting the grabbed opponent at least with 1px above the ground in the Y parameter, like @Bloodbane mentioned, otherwise the engine will see it as a landing (since usually during a fall animation the character is on the air).

I only use zero in the first frame because this is where the grab starts and usually works fine. Even if you need to simulate like if the grabbed opponent is touching the ground (usually during slams), I suggest faking it directly in the fall animation sprites (commonly fall7) or even changing the offset.

As an example, in the part marked in red/yellow I put 1px as Y value and then adjusted the grabbed opponent fall7 frame like if he is really touching the ground, but in fact it's not.

View attachment 15710
Click to expand...
Bloodbane said:
Sorry about that. Multitasking made me forgot my old scripts.
Anyways, to solve your negative altitude issue, I suggest making clone of grabbed pose in FALL4 whose offset is lower than the actual one. With this clone frame, the set altitude for position function would be higher and positive.
Click to expand...
Ah, okay, so the idea is to lower the offset a bit in fall4, and then position the enemy while they're grabbed at a positive altitude, that is, the Y value.

Thanks a lot, guys, you always learn something new on this forum!
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top Bottom