Bug in Physical Response on Tiled Actors ?
Posted: Sat Mar 18, 2006 9:02 amIt seems that if you try to use Physical Response in a collision event on a tiled actor strange things happen.
http://www.darkspiregames.com/physResp_demo.zip
The sample .ged demonstrates four scenarios for using Physical Response.
To interact with demo simply click somewhere to make player_base move to that location.
There are two ways to use physical response: on the actor you want to bounce or on the actor you want to bounce off of.
scenario 1: (on the actor you want to bounce)
wall_A is setup so that a collision event on player_base executes a physical response causing the player_base bounce off of wall_A. This works great.
scenario 2: (on the actor you want to bounce off of)
wall_B is setup so that a collision event on wall_B executes a physical response and causes the player to bounce off wall_B. This works great.
In the next two scenarios we introduce tiled actors. wall_C and wall_D are both tiled.
scenario 3: (on the actor you want to bounce off of)
wall_C is setup so that a collision event on wall_C executes a physical response and attempts to cause the player to bounce off wall_C. This however rarely happens. Instead player_base gets pulled inside wall_C and then trapped. bogus. The only difference between this and scenario 2 is that wall_C is tiled and wall_B is not.
scenario 4: (on the actor you want to bounce)
wall_D is setup so that a collision event on player_base executes a physical response and causes the player to bounce off wall_D. This works great.
The Point:
for my particular project the setup in scenario three is the most code/time effective. Unfortunately it does not seem to behave as expected. The above tests establish the method by which physical response is employed should work. (as indicated by scenario 2) My game contains many wall objects and it will be a pain to setup a physical response on player_base for each one of them especially when I should only have to do it once on a source_wall actor. Then all other walls could just inherit events from source_wall.
So...
Is the behavior in scenario 3 a bug?
P.S.
Sorry if this is a rambling question, answered elsewhere, or doesn’t make sense. Its like 3:00AM and I doubt I am thinking clearly.
Thanks.
http://www.darkspiregames.com/physResp_demo.zip
The sample .ged demonstrates four scenarios for using Physical Response.
To interact with demo simply click somewhere to make player_base move to that location.
There are two ways to use physical response: on the actor you want to bounce or on the actor you want to bounce off of.
scenario 1: (on the actor you want to bounce)
wall_A is setup so that a collision event on player_base executes a physical response causing the player_base bounce off of wall_A. This works great.
scenario 2: (on the actor you want to bounce off of)
wall_B is setup so that a collision event on wall_B executes a physical response and causes the player to bounce off wall_B. This works great.
In the next two scenarios we introduce tiled actors. wall_C and wall_D are both tiled.
scenario 3: (on the actor you want to bounce off of)
wall_C is setup so that a collision event on wall_C executes a physical response and attempts to cause the player to bounce off wall_C. This however rarely happens. Instead player_base gets pulled inside wall_C and then trapped. bogus. The only difference between this and scenario 2 is that wall_C is tiled and wall_B is not.
scenario 4: (on the actor you want to bounce)
wall_D is setup so that a collision event on player_base executes a physical response and causes the player to bounce off wall_D. This works great.
The Point:
for my particular project the setup in scenario three is the most code/time effective. Unfortunately it does not seem to behave as expected. The above tests establish the method by which physical response is employed should work. (as indicated by scenario 2) My game contains many wall objects and it will be a pain to setup a physical response on player_base for each one of them especially when I should only have to do it once on a source_wall actor. Then all other walls could just inherit events from source_wall.
So...
Is the behavior in scenario 3 a bug?
P.S.
Sorry if this is a rambling question, answered elsewhere, or doesn’t make sense. Its like 3:00AM and I doubt I am thinking clearly.
Thanks.