Projectile/Decal Questions

#1 This might help, it cover decals.
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9349

#2 First Q: you could do two raycasts with different typemasks.

#3 @Michael - Thanks already been there. The bullet holes appearing are not the issue. I even have a working material mapping system created, I am just looking to add some more functions to it based upon flags. Also fixing the vehicle issues would be very nice.

@Orion- I a not sure I understand what you mean. Do you mean creating a raycast that looks for the collision mesh then another to look for the actual object itself? Not sure how you would even separate mesh from collision mesh with a raycast.

#4 You know, i was actually thinking of an Instantaneous weapon, like a sniper rifle.
if that case you could do one raycast to determine where to put the decal,
and another to determine where the bullet lands.

if you want to use a real projectile tho, i'd imagine you'd have to start modifying the projectile class.

- i haven't worked w/ projectiles at all tho, so there's probably someone with more useful ideas.

#5 Ron,

About your first question: From what I've seen, the TGE projectile code can't handle that "out of the box". You would need to hack around in game/projectile.cc.

I recently added a simple mechanism to allow projectiles to "bounce", even after their arming delay had passed. It boiled down to adding a script call ("OnAllowExplode") to projectile collision checking. You would need something similar, I think, but you would want to include an option to "penetrate" as well as "bounce". Still, the code changes aren't that extreme. You might run into issues, though, with the projectile getting stuck inside the collision box of the penetrated object.

On the second question: I did a lot of research/experimenting trying to get decals to stick to dynamic objects (like players and vehicles). I got static objects working pretty well (as described here), but I never got dynamic object decalling working, and eventually shelved the problem in favor of more pressing bullet items.

Your best bet might be to try some form of "dynamic texture layering" (there's a resource by that name) and just overlay the decal directly on the object's texture. If you get this solved, I'd love to hear about it.

Hope that helps.

-David

#6 Well how about armor piercing rounds? Anyone gotten that? I have been working with the projectile's process tick and trying with enable and disable collision but no luck so far.

#7 Well I also see now that trying too much in terms of emitters on a player object tends to crash your computer. I tried the blood resource and everytime i used with a firearm of the automatic variety, it crashes. HAs anyone come up with a better system?

#8 OK I see about dynamic texturing, going to be a heck of a lot of fun working that one out, but I would really like to know about armor piercing rounds. Has anyone done this successfully?? I am trying to get glass set up that bullets can leave the hole bu still pass through.

I have tried manipulating the disable collision functions but the funny thing is it still stops the bullet but by slowing it down and then it falls down after it passes through the glass but a little bit fiurther behind it.

I am considering setting it up to create a new projectile traveling at the same velocity and direction as the one that struck the glass but on the backside of it. However, I have no idea where to start in setting this up in the code. First I would need some way to figure out the distance from where the bullet impacts the glass to the point I would need it to appear and continue travelling. Second how the heck would I make the new projectile in code?

#9 Yes that is exactly what I would suggest. If you create the "new" projectile with the object you hit as it's sourceObject parameter, you should be able to create it where the old one hits and keep it moving and it will go through the glass. The sourceObject parameter holds a timeout to have it not collide with the sourceObject initially, and certainly with something as thin as glass, if not other things, will work fine. It just probably won't work for crashing through .dif objects, but you don't seem to need that anyways.

#10 Well that is good. Any idea on how to create a new projectile in the code? I am able to see how to set up the coordinates, velocity and direction of the projectile, just not how to get a copy of this one and have it added back into the scene in the code and not script. Heck how do you instantiate an object from code only?

#11 K I admit it, I am weak. I can't figure out how to make an object from code or even clone one. I tried and it laughed at me. Has anyone done this?

#12 Well I did come up with an almost working code with the exception of one extraordinary mistake that gave me a really good laugh. I managed to make an object that will appear after the projectile performs its oncollision function that will travel at the same speed and direction the projectile was going as if the the collision had never occured, so a bit past the collsion point, THAT part worked great. So I have a working collision, explosion, and decal placement and supposedly a new projectile as if the object passed through the glass.

Problem is I needed to make a copy of the original projectile to be created in my function. Yeah.....................mSourceObject is REALLY NOT the projectile, its the player object. So I shot the bullet, it hits the glass, next thing I know I have teleported just past the glass flying at the speed of the bullet right up until I hit a wall. It was like something out of a roadrunner cartoon and I was the coyote.

So, I ask this, could someone PLEASE tell me how to get the projectile in the processtick function in projectile.cc?

#13 ROFL, yes, sourceObject is generally a reference to the object that fired the projectile, so it doesn't hit that object. I'm not very good at C++, but if your working inside the objects methods, wouldn't it be "this" ?

#14

Quote:
So I shot the bullet, it hits the glass, next thing I know I have teleported just past the glass flying at the speed of the bullet right up until I hit a wall. It was like something out of a roadrunner cartoon and I was the coyote.

Haha!

Quote:
So, I ask this, could someone PLEASE tell me how to get the projectile in the processtick function in projectile.cc?

Hey, why don't you just spawn a new projectile when you hit the wall? Look at WeaponImage::onFire and Projectile::onCollision in script.

#15 Well truth is I want the procedure run entirely from code. That way I have a more universal solution that can yield armor piercing rounds and rounds that can pass through items that normally would not stop a projectile with nothing more than a simple flag in my material mapping system.

#16 Well I can see where the projectile is accessed or identified in the shapebase code. However I really need to get the current instance so I create a projectile of the same type that was fired initially, and again in code, not script.

#17 I wonder if it's plausible to sort of "reset" the existing projectile. Instead of making a new one, when it hits the passable object, make mSourceObject the object you hit, and have it run the checks where it ignores mSourceObject and passes through it, while still leaving a call to create an explosion effect where it hit.

#18 I see what you are syaing but consider an automatic gunfire situation. If you are firing many successive rounds and continually switch the msource object as either the collided object or the player character himself it seems that if there was a possible collision and fire at a fairly close timeframe there could be severe reprocussions. Just a thought.

Again all really need to make this work is the ability to get the projectile in a manner similar to that of how mSourceObject was determined to be the player. Considering the processtick is being based around the movement of the projectile you would think there would be some way to call upon what the projectile is.

#19 As far as performance is concerned, creating a new projectile is probably worse, as I think the mSourceObject could be updated in both the client and server sim without needing to haveany data reopened over the network. Not too sure about all that.

But anyways, I already said, in C++ when you're inside a member function of a class, don't you reference the object with "this"? I don't know C++ very well, but I thought it's something like that.

#20 Last time I was aware the %this functionality only worked in Torque script when the client or object was calling upon a function and it is that object calling the function that is %this. I actually did manage to get the C++ function to create another object, problem is now it isn't treating it as a projectile and it just causes the game to crash when it collides with an object. I am pretty sure I am going about it the wrong way. Basically I am going to have to tell it to create a projectile object within the code that is at a specified position and velocity.

The situation is beginning to look a bit bleak in that I may need to set up a torque script function that handles this. Unfortunately that will kill alot of the material mapping system I have in place that works perfectly for everything else.