Getting a projectile to ignore a certain object

[Sir_Skurpsalot]

Any method for making a projectile ignore a collision with a specific object? Looking through the scripts/script manual not finding any hints

[Duion]

There exist several methods/resources that may do what you need, but you need to be more specific about what you need.

For example on Garagegames someone posted a resource for an invisible wall: http://www.garagegames.com/community/resources/view/23096

It blocks players, but no idea what it does to projectiles.

If you need projectiles to pass though some materials, you can try implementing the armor piercing resource where you can specify how far bullets penetrate through each material.

Those are the two areas of application I can think of, for invisible walls that keep the player out, but not projectiles I used physical zones in my game that apply enough force to keep the player out, but not projectiles., kind of a workaround but works fine.

[Sir_Skurpsalot]

I'm looking for a way to do bullet penetration. The way I've done it in other engines is basically:

1.Projectile (or raycast) hits object, gets variable (an armor rating) from object it collides with so it knows it can penetrate (no problem in Torque).

2.Get point of impact, spawn another projectile of same type at that point (again should be no problem)

3.Set projectile to ignore the previously collided with object and fire it off in the same direction the previous one was going. <--- this I do not know how to do in Torque

This is the way I would like to do it, I don't need things to be as specific as getting materials and all that.

Alternative idea is this:

2.Spawn a raycast a set short distance ahead of the impact point, and shoot it back towards the front impact point so it collides with the backside of the object. Ideally I would be able to set the raycast to ignore all collisions except for this specific object so I do not run into problems if objects are close together.

3.Spawn the duplicate projectile at that impact point with the same heading as the previous one and send it on it's way.

[Duion]

Yes forget all of this and look into the resources that already do everything, you don't need to re-invent the wheel:

First we have armor piercing bullets resource: http://www.garagegames.com/community/resources/view/18147

Then I also found this, it seems to be newer and has more features:

http://www.garagegames.com/community/blogs/view/19943

In case of dead links check the archive: https://forums.torque3d.org/viewtopic.php?f=9&t=1705&p=12708&hilit=abighole#p12708

The archive was dead, but someone re-uploaded it.

So I recommend you downloading the archive and going through all the resources on garagames.com to see which is the latest, best and most complete implementation and then try to implement that.

I planned to integrate that into my game at some point as well, but so far it was too complex of a change so I delayed it and I'm not really that good at C++ and all that stuff, but I can offer you to help testing and fixing in case you want to implement that.

Further I suggest to team up with others and finally bring those features into the main engine branch, which also adds more people who will test and hopefully fix it.

[fLUnKnhaXYU]

this is in the scripts/server/projectile .cs file , dealing with the projectile collision . I think youll find the $typemask of interest . The radiusDamage file in the same folder also has good stuff to check out . Maybe it'll help , just get what info that you need from the %col (the object that the projectile is colliding with) variable . This is just an example to study .

 

function ProjectileData::onCollision(%data, %proj, %col, %fade, %pos, %normal)
{
   //echo("ProjectileData::onCollision("@%data.getName()@", "@%proj@", "@%col.getClassName()@", "@%fade@", "@%pos@", "@%normal@")");
 
   // Apply damage to the object all shape base objects
   if (%data.directDamage > 0)
   {
      if (%col.getType() & ($TypeMasks::ShapeBaseObjectType))
         %col.damage(%proj, %pos, %data.directDamage, %data.damageType);
   }
}
 
function ProjectileData::onExplode(%data, %proj, %position, %mod)
{
   //echo("ProjectileData::onExplode("@%data.getName()@", "@%proj@", "@%position@", "@%mod@")");
 
   // Damage objects within the projectiles damage radius
   if (%data.damageRadius > 0)
      radiusDamage(%proj, %position, %data.damageRadius, %data.radiusDamage, %data.damageType, %data.areaImpulse);
}

[Sir_Skurpsalot]

Thanks for the replies.

I'm in the process of working on something based on my second idea which is progressing good so far and is actually pretty simple.

One thing to ask before I continue down this route is: How reliable are fast moving projectiles in Torque3D? If you give them the muzzle velocities of real guns, does it have problems missing collisions? I've gotten a handle on how raycasts work in Torque, and am considering just having my guns shoot raycasts instead of projectile objects.

[Duion]

Why you want to waste time to create a bad workaround, if someone else already made a perfect solution?

The projectiles in my game are fast moving, not directly realistic speed, but somewhat on the low end of the spectrum what would be realistic and I have no issues. If you make them totally realistic speed, it would make no sense, since you just waste resources and you cannot even notice a difference.

[fLUnKnhaXYU]

this is a somewhat similar thread on these forums by Steve YorkshireRifles

https://forums.torque3d.org/viewtopic.php?f=23&t=1392&p=10388#p10388

[Jason Campbell]

Why you want to waste time to create a bad workaround, if someone else already made a perfect solution?

The projectiles in my game are fast moving, not directly realistic speed, but somewhat on the low end of the spectrum what would be realistic and I have no issues. If you make them totally realistic speed, it would make no sense, since you just waste resources and you cannot even notice a difference.

 

How would this be a bad work around?

I doubt a raycast is anymore of a hit then spawning a projectile and checking for a collision.

I think it's great that someone is interested in Torque and is checking out it's capabilities. Sometimes it's good to try your own way and even if it doesn't work out, then you have still learned from it.

[Duion]

@Jason Campbell

First workarounds in itself are bad, I mostly only do workarounds, when I don't want to spend more than one day on a feature or bugfix, but I know that in the long run, they will not be sufficient.

Let me give you some reasons why spawning another projectile is just a bad solution:

1. Costs more resources.

2. Does not account for material thickness.

3. Does not account for material type.

4. Does not recalculate the projectile speed and piercing power after penetration.

5. Does not account for different decals depending on material.

6. Does not account for different particles depending on material.

7. Does not account for material piercing resistance.

8. Does not account for different sounds depending on material on projectile.

And those are just the ones I could come up in 5 minutes, there will be more in the long run.

In fact the armor piercing resource already does it similar to spawning another projectile, so you just need to use that, which is even more reason to just use that instead of inventing your own solution.

[Caleb]

Let me give you some reasons why spawning another projectile is just a bad solution:

The resource you linked literally spawns another projectile.

 

In fact the armor piercing resource already does it similar to spawning another projectile. . .

So spawning another projectile isn't a bad solution?

Handling decals, sounds, and particles is why you WOULD want to create another projectile so you're not "reinventing the wheel" having to manually perform those steps. Accounting for material thickness and projectile deceleration is a matter of flavoring as far as I'm concerned. Not everyone's project will need that.

@Sir_Skurpsalot

If I remember correctly, the engine's projectiles use a series of raycasts to predict collision. Failing collision due to high speeds shouldn't be an issue. Using a single raycast from the muzzle is a perfectly viable solution to replacing bullets, but there is a trade off. In an online setting over long distances, it isn't crazy to think that a player may move out of a bullet's path after being shot at. It might be rare and no one may notice the difference, but a "real" bullet with "real" speed will account for these kind of scenarios.

[Sir_Skurpsalot]

So I've been working on my own script the past few days and I've got something I'm pretty happy with for now that adds about 60 lines to ProjectileData::onCollision in server/projectile.cs. It's pretty simple but you can set different "armor" ratings for objects and penetration ratings for projectiles, and max allowable thickness to penetrate. Does decals and dust "explosions" on both sides. Can penetrate multiple objects. Still uses projectiles. Have not tested it on players though, just TSStatic objects. That other resource, while appreciated, was many pages of C++ that I did not understand and I'd rather just do what I need and do it myself.

@Caleb thanks that's what I needed to know, I'll be sticking with projectiles then.

[Duion]

As far as I can see the C++ stuff is a custom projectile class, that adds a bunch of new variables, for example if the projectile is armor piercing and if then how much and how much for each material etc.

I was hoping someone with a better understanding can tell what it does exactly and which resource is the best, so we can add it to the main engine, so not everyone needs to bother with it individually.