How to set a material that doesn't apply a force?

#1 Choose not to assign materials to the projectile? I haven't used materials in any of my projects, and the bullets just hit the target without imparting any forces to it.

#2 Hmm how is this related to materials?
Wouldn't it just be enough to do a setCollisionPhysics(false,false); to prevent the collision having any physical consequences?

#3 Sorry guys those didn't work...
at the end I needed to create a different material

// Standard Collision Material.
datablock fxCollisionMaterialDatablock2D(standardMaterial)
{
	friction = 0.0;
	restitution = 0.0;
	relaxation = 0.5;
	density = 0.1;
	forceScale = 1;
	damping = 0.0;
};
// light Collision Material.
datablock fxCollisionMaterialDatablock2D(lightMaterial)
{
	friction = 0.0;
	restitution = 0.0;
	relaxation = 0.5;
	density = 0.01;
	forceScale = 1;
	damping = 0.0;
};

even when deactivated the collision with:
%bullet.setCollisionPhysics (false, false);
the enemy is affected, and don't using materials
give me a standar "by default" material with friction...
Is this a bug?

#4 ......

Usually projectiles are done by using SFX.
Emitters will be treated as projectiles.
You will be in charged of changing the emitters properties when hitting your target.

=)

#5 Interestingly, in my current game I use setCollisionPhysics( false, false ) on a "paddle" and when it moves into a "ball" it does in fact transmit force. Somehow.... Here's the section of code that sets collision properties for my paddle:

$paddle[%a].setGroup( 1 );
$paddle[%a].setLayer( 1 );
$paddle[%a].setCollisionMasks( BIT(2), BIT(2) );
$paddle[%a].setCollisionActive( false, true );
$paddle[%a].setCollisionPhysics( false, false );
$paddle[%a].setCollisionMaterial( standardMaterial );
$paddle[%a].setCollisionPolyPrimitive(12);
$paddle[%a].setCollisionScale(0.8);
$paddle[%a].setCollisionCallback( true );

Notice that the paddle doesn't "send" physics but does "receive" them. And yet, it does transmit its motion to the objects it strikes. I'm not sure why it works, but it does.

#6 In the alpha 1.1a1 I'm still unable to get this fixed.
link
What version are you using?

#7 I'm using 1.02, and as it happens setCollisionPhysics( true, false ) works just as well as setCollisionPhysics( false, false ) in my particular case.

#8 Just to be clear; "setCollisionPhysics()" doesn't control whether the object sends/receives physics, it controls whether this object when sending/receiving collisions reacts to either sent/received collisions. It doesn't control whether the object to which it collides with reacts or not; that's controlled by the objects "setCollisionPhysics()" settings.

- Melv.

#9 ... or at least it shouldn't. ;)

#10 Ok. So one thing confuses - and amuses - me. I believe I understand how an object could react to a collision received. For example, it might get knocked away from the object sending the collision. But how for example does an object "react" in the event of its sending a collision?

(If this is covered in thorough detail in the docs, feel free to just tell me to RTFM!)

You have clarified one thing for me though. If I understand you correctly, the reason the send? parameter makes no difference in my particular setCollisionPhysics case is because I set send? to false in my setCollisionActive call. No collision being sent :. no send event to which to apply physics.

One more thing related to the send/receive paradigm...

My onCollision callback receives two events for every collision with my paddle object, one in which the paddle is the sender, and another in which it is the receiver. Is this always the case, and just the way onCollision is meant to work? Basically I just use the callback to play appropriate sounds in response to collisions of different relative velocities, and if every collision generates two calls to this function I need to work around that.

#11 Scott,

There wasn't a document released with v1.0.2 or the alpha#1 so it's definately not RTFM time. ;)

Essentially whether an object can send or receive a collision is determined by "setCollisionActive()". If a collision doesn't pass this stage, it's ignored and all the other settings are redundant. For instance, if an object A attempts to send a collision to object B but object B is set to not receive collisions, nothing happens to either object; It doesn't matter what the physics settings are on object B. So this collision 'event' checked if object A could send (which it could) and then checked if the 'other' object (object B) could receive them (which it couldn't) so nothing else happened to either object.

What this means is that the "setCollisionActive()" is simply a switch for the bidirectional collisions that happen during a game. To further refine whether an object can send/receive collisions, you set the collision group(s)/layer(s) to determine which objects you send objects to. Received collisions are controlled by the 'other' object, in other words, the 'other' object used its collision group(s)/layer(s) to configure which objects it sent collisions to and therefere are received by our object therefore an objects collision group(s)/layer(s) determine a unidirectional collision only. Two objects together detemine the bidirectional collisions.

When a collision 'event' passes the above rules, there are a number of things that can then happen, none of which are mutually exclusive. First, you can get the object to issue a callback to allow you to do a custom action. Second, you can get T2D to calculate an autonomous response (physics) e.g. clamp, kill, bounce, rigid etc. Importantly, you may not want any autonomous response and this is what "setCollisionPhysics()" is for. In a similar manner, you can specify whether the object has an autonomous response for sent/received collisions. This could allow you to ensure an object reacts when it hits objects (send) but doesn't when objects hit it (receive) for instance. Quite often though, you'll just allow both ways to work. This is different from the "setCollisionActive()" call in that if the object has a successful send collision then it'll check to see if the send physics is active at which point, it'll work out the response. Unlike the "setCollisionActive()" call, it doesn't matter if the 'other' object has its receive physics off.

What I mean by this is that the "setCollisionActive()" call determines whether a collision gets processed any further for both objects. If it does, all other configurations per-object determine the action for that object only.

With regards to the "onCollision" returning two callbacks; this equates to object A colliding with object B e.g. the send collision and therefore object B being hit by object A e.g. the receive collision. Whilst this sounds crazy, it's actually quite handy because you don't need to differentiate between the collision direction when you write callback-code. For instance, in your callback, if you were to write a test for your player colliding with something, you can simply monitor the source-object as you'll get both direction callbacks. If this weren't the case, you'd need to test both the source and destination objects to see if they were the player.

If you don't like this model, have a look at the new system variables in the reference doco, there's now one called "$pref::T2D::dualCollisionCallbacks" (see the "t2d/prefs.cs" file). The default for this is "1"; set it to "0" to enforce only a single callback; that is, process strictly according to the direction of the collision e.g. if the player collides with an asteroid you'll get the player as the source and the asteroid as the destination and no other. You'll obviously then have to be careful if the asteroid collides with the player as they will then be reversed and you'll have to test for this direction in your script.

Hope this helps,

- Melv.

#12 I thought I'd also mention again that I am currently working on a document to detail collisions / physics that goes through all this in lots of detail with examples etc.

- Melv.

#13 Oh Melv, this doco would be very handy.
Still waiting here, because I'm still unable to get
my bullets don't affect my entities. Now that I
did a laser beam this is more serious hehe.
Maybe is just some flag I'm missing, even when
I think I tested everything...

#14 If you need your entities to have physics with respect to other kinds of collisions (i.e., other than bullets) then you can't make them not physically react to bullets. If you set SetCollisionPhysics receive to true on your entities then they will receive physics from all the objects that collide with them. The best you can do is to set your bullets' density to a very low value to get the least amount of physical reaction.

This thread gets into more detail about the physics system as well.

What would be nice is if, in the onCollision callback you could return false - for example - to say "collision handled, so don't do any physics to the object which is getting this collision."