T2D 1.1 alpha - how to set the new materials?
by Adam Johnston · in Torque Game Builder · 11/30/2005 (1:37 pm) · 7 replies
I'm still unable to find the correct combination of
factors in order to make bullets that can't affect
the movement of the main actors using the new 1.1 alpha
Here is more info about what I've tryed:
thread
Somebody using bullets in his game that tryed something different?
factors in order to make bullets that can't affect
the movement of the main actors using the new 1.1 alpha
Here is more info about what I've tryed:
thread
Somebody using bullets in his game that tryed something different?
#2
Well, my idea was to assign a material to my arm projectils, because if you are
launching a grenade then those must to be affected by gravity and
make a little bounce, of course this is not necesary for bullets
If you don't assign a material a standar material is assigned if you activate
the physics using: setCollisionPhysics (true, false); OK?
So this was the reason a assigned a "light material" that was working
before, but now even if I put:
setCollisionPhysics (false, false); // I dont want this because as I said a want "grenades"
sometimes (randomly) the projectils in collision stops the "actors" that are moving using
setLinearVelocityX ()... As you see this happens randomly (but very frequently)
that was the reason that I first thought this was a bug in the physics collision...
In resume, how can I do a "feather" bullet?
I don't know how to explain better... hope you could understand me.
NOTE: I'm using CLAMP for all objects && setCollisionMaxIterations (2)
but I remember have tested with the other types.
11/30/2005 (3:47 pm)
Hi Melv, glad you answered:Well, my idea was to assign a material to my arm projectils, because if you are
launching a grenade then those must to be affected by gravity and
make a little bounce, of course this is not necesary for bullets
If you don't assign a material a standar material is assigned if you activate
the physics using: setCollisionPhysics (true, false); OK?
So this was the reason a assigned a "light material" that was working
before, but now even if I put:
setCollisionPhysics (false, false); // I dont want this because as I said a want "grenades"
sometimes (randomly) the projectils in collision stops the "actors" that are moving using
setLinearVelocityX ()... As you see this happens randomly (but very frequently)
that was the reason that I first thought this was a bug in the physics collision...
In resume, how can I do a "feather" bullet?
I don't know how to explain better... hope you could understand me.
NOTE: I'm using CLAMP for all objects && setCollisionMaxIterations (2)
but I remember have tested with the other types.
#3
Materials control aspects of the physics but not whether they are applied or not so talking about materials confuses everything really so let's just ignore those for now.
If you have an object A (projectile), object B (enemy) and when object A colides with object B you don't want object B to be affected then you are describing a situation where at a point in time, A is colliding with B and B is potentially also colliding with A (if A isn't destroyed upon collision).
In this case, you don't want object Bs physics to be affected by received collisions so you turn it off with...
This will stop object Bs physics being altered by anything colliding with it. If object B itself collides with something then it will be altered. As I mentioned above, if the projectile is still active after its collision, Object B may well collide with it therefore Object Bs physics will be altered.
If this doesn't help at all then maybe you should post an image rather than try to describe what you're getting.
- Melv.
12/01/2005 (2:39 am)
Adam,Materials control aspects of the physics but not whether they are applied or not so talking about materials confuses everything really so let's just ignore those for now.
If you have an object A (projectile), object B (enemy) and when object A colides with object B you don't want object B to be affected then you are describing a situation where at a point in time, A is colliding with B and B is potentially also colliding with A (if A isn't destroyed upon collision).
In this case, you don't want object Bs physics to be affected by received collisions so you turn it off with...
%objectB.setCollisionPhysics( true, false );
This will stop object Bs physics being altered by anything colliding with it. If object B itself collides with something then it will be altered. As I mentioned above, if the projectile is still active after its collision, Object B may well collide with it therefore Object Bs physics will be altered.
If this doesn't help at all then maybe you should post an image rather than try to describe what you're getting.
- Melv.
#4
Here is how I set the actors physics:
stopped by the projectiles in impact, so this is not working, I don't know why.
I don't know if would be possible for me to make a simple test, using the platformer TDN
and throwing a projectil over a simple entity that is walking along the x axis
using setLinearVelocityX() and see if the entity is stopped sometimes or not.
Like I said, this was working before but now is broken.
12/01/2005 (8:18 am)
OK Mel, but this is the way I was doing it:Here is how I set the actors physics:
function SetEnemyCollision (%gpxActor)
{
%gpxActor.setGroup ($gn_enemyGroup);
%gpxActor.setLayer ($gn_enemyLayer);
%gpxActor.setCollisionActive (true, true);
%gpxActor.setCollisionPhysics (true, false); // <-- here
%gpxActor.setCollisionMaterial (standardMaterial);
%gpxActor.setCollisionMasks ($go_playerGroups | $go_platformGroups,
$go_playerLayers | $go_platformLayers);
%gpxActor.setCollisionCallback (true);
%gpxActor.idCollision = $JT_COLL_ENEMY;
%gpxActor.setCollisionResponse (CLAMP);
%gpxActor.setCollisionMaxIterations (2);
}And the projectils:function SetPlayerFireCollision (%bullet)
{
%bullet.setGroup ($gn_playerFireGroup);
%bullet.setLayer ($gn_playerFireLayer);
%bullet.setCollisionActive (true, true);
%bullet.setCollisionPhysics (false, false); // <--- Here
%bullet.setCollisionMaterial (lightMaterial);
%bullet.setCollisionMasks (BIT($gn_enemyGroup) | BIT($gn_platformGroup),
BIT($gn_enemyLayer) | BIT($gn_platformLayer));
%bullet.setCollisionCallback (true);
%bullet.idCollision = $JT_COLL_FIRE_PLAYER;
%bullet.setCollisionResponse (CLAMP);
%bullet.setCollisionMaxIterations (2);
}As you see all is arranged to obtain this effect, but I get the actors gettingstopped by the projectiles in impact, so this is not working, I don't know why.
I don't know if would be possible for me to make a simple test, using the platformer TDN
and throwing a projectil over a simple entity that is walking along the x axis
using setLinearVelocityX() and see if the entity is stopped sometimes or not.
Like I said, this was working before but now is broken.
#5
I've looked at the code and I don't see a problem apart from not knowing why certain calls are being made such as "max-iterations" and "collision material". The collision materials are primarily for rigid-body physics although damping is commonly used. It's much easier to just select "setDamping()" than using a collision-material outside of rigid-body. The "max iterations" is only really used if you want to spend more time going following the frame-integration time (tick-time) after each sucessive collision. This is for more specialised uses. There's certain no real use when using simple objects such as projectiles and it just slows things down.
Back to your original problem though; as far as I can see, actors cannot collide with projectiles so the fact that collision-send-physics is on for actors rules that out. Projectiles though can collide with actors but the collision-received-physics is disabled for actors so that's ruled out. I therefore don't see how the projectile affects the actors physics.
Here's a bit of code that I just tried that is essentially the same as yours that can be pasted in the alpha#1 codebase...
The projectile moving right hits the actor moving left and is clamped but the actor continues moving left as normal "pushing" the projectile due to overlaps.
I tried some code that pumped-out the projectiles but the actor continues to move left. I'm sure you're getting a problem but without being able to see a simple example, I'm pretty helpless. Just a hint, if you want to paste some code, make it very simple with no external functions/callbacks being used; I'm really pushed to wade through pages of code/functions! ;)
- Melv.
12/01/2005 (8:55 am)
Well,I've looked at the code and I don't see a problem apart from not knowing why certain calls are being made such as "max-iterations" and "collision material". The collision materials are primarily for rigid-body physics although damping is commonly used. It's much easier to just select "setDamping()" than using a collision-material outside of rigid-body. The "max iterations" is only really used if you want to spend more time going following the frame-integration time (tick-time) after each sucessive collision. This is for more specialised uses. There's certain no real use when using simple objects such as projectiles and it just slows things down.
Back to your original problem though; as far as I can see, actors cannot collide with projectiles so the fact that collision-send-physics is on for actors rules that out. Projectiles though can collide with actors but the collision-received-physics is disabled for actors so that's ruled out. I therefore don't see how the projectile affects the actors physics.
Here's a bit of code that I just tried that is essentially the same as yours that can be pasted in the alpha#1 codebase...
t2dBeginScene( t2dScene );
%sprite1 = new t2dStaticSprite();
%sprite1.setImageMap( tileMapImageMap );
%sprite1.setPositionX( 20 );
%sprite1.setSize( 10 );
%sprite1.setLinearVelocityX( -5 );
%sprite1.setLayer( 1 );
%sprite1.setGroup( 1 );
%sprite1.setCollisionActive(true, true);
%sprite1.setCollisionPhysics(true, false);
%sprite1.setCollisionMasks( bits("10 11"), bits("10 11") );
%sprite1.setCollisionResponse( CLAMP );
%sprite2 = new t2dStaticSprite();
%sprite2.setImageMap( ggLogoImageMap );
%sprite2.setPositionX( -20 );
%sprite2.setSize( 2 );
%sprite2.setLinearVelocityX( 10 );
%sprite2.setLayer( 2 );
%sprite2.setGroup( 2 );
%sprite2.setCollisionActive(true, true);
%sprite2.setCollisionPhysics(true, false);
%sprite2.setCollisionMasks( bits("1 10"), bits("1 10") );
%sprite2.setCollisionResponse( CLAMP );
t2dEndScene();The projectile moving right hits the actor moving left and is clamped but the actor continues moving left as normal "pushing" the projectile due to overlaps.
I tried some code that pumped-out the projectiles but the actor continues to move left. I'm sure you're getting a problem but without being able to see a simple example, I'm pretty helpless. Just a hint, if you want to paste some code, make it very simple with no external functions/callbacks being used; I'm really pushed to wade through pages of code/functions! ;)
- Melv.
#6
I can't understand why I'm having this behavior too :(
the CLAMP and maxterations where there just because
I was using materials for bullets, I'm not using it anymore.
But they are absolutely necessary for the actors because if not
they will be stuck in the ground.
I think there is a problem in the interaction between
projectile + actor + tile.
Well I'm really in a hurry now, and I've added a horrible hack to my code
to check the velocity of actors in the state of moving and if is different
apply again the velocity call... is working now but using more
script time :'(
Sorry I can test anymore, as long as I have a little time
I would test a simple platformer and see if I can reproduce this behavior
or is a bug of my side...
cya.
[EDIT] I applied the fix to t2dPhysics::resolveClampCollision that you suggest in other
thread with no success.
12/01/2005 (9:17 am)
Ok Melv, thank you for your interest ^_^, right knowI can't understand why I'm having this behavior too :(
the CLAMP and maxterations where there just because
I was using materials for bullets, I'm not using it anymore.
But they are absolutely necessary for the actors because if not
they will be stuck in the ground.
I think there is a problem in the interaction between
projectile + actor + tile.
Well I'm really in a hurry now, and I've added a horrible hack to my code
to check the velocity of actors in the state of moving and if is different
apply again the velocity call... is working now but using more
script time :'(
Sorry I can test anymore, as long as I have a little time
I would test a simple platformer and see if I can reproduce this behavior
or is a bug of my side...
cya.
[EDIT] I applied the fix to t2dPhysics::resolveClampCollision that you suggest in other
thread with no success.
#7
That thread isn't anything to do with stopping problem though Adam (is that what you meant)? Either way, it definatley solves the problem in that thread as I found the root cause.
If you can duplicate a simple-case of your problem then I can look into this further. I'll see if I get some more time in the morning and I'll make my example "actor" move along a tile-layer surface with gravity using "clamp".
- Melv.
12/01/2005 (9:47 am)
Quote:"I applied the fix to t2dPhysics::resolveClampCollision that you suggest in other
thread with no success"
That thread isn't anything to do with stopping problem though Adam (is that what you meant)? Either way, it definatley solves the problem in that thread as I found the root cause.
If you can duplicate a simple-case of your problem then I can look into this further. I'll see if I get some more time in the morning and I'll make my example "actor" move along a tile-layer surface with gravity using "clamp".
- Melv.
Associate Melv May
Also, if you're not using rigid-body physics, you don't need all the complexity of collision-materials; restitution, friction etc.
Is this what you're asking for?
- Melv.