Triggers and Projectiles

#1 Bump
I discovered that shotgun and crossbow is not affected by this so I set ballistic on an off, no change set projectile speed on and off, no change. No one else have this problem?

#2 Bump, Still no help ?

#3 What is the trigger proggramed to do?

#4 Nothing, just echo("you entered trigger 1")
it's not what it does its the fact it exists and my character runs through it or shoots through it.

#5 Bump Still no help ?

#6 Well, there's really absolutely no reason that should happen. And you said this only happens with one of your weapons or something? If so it's probably a problem with the weapon, not the trigger. It's pretty hard to help without knowing more of what's going on.

#7 What other information would you like? What could the weapon have to do with an invisible trigger?

#8 What could an invisible trigger have to do with a weapon? You did say other weapons were working fine, right?

#9 Take stock torque fps demo, I use the lighting pack so I used that one. Open the crossbow.cs file and set correctMuzzleVector to true. Create a default trigger, scale it 5,5,5 or so. Go stand inside the trigger and fire the crossbow. It fires but bolts dont go out of the trigger area. Move out of the trigger and bolts fly. Thats the easiest way to show the problem.
I fixed things by hacking the standard methods a bit and they work but this just seems broke to me.

#10 @Paul:

Quote:
What could an invisible trigger have to do with a weapon? You did say other weapons were working fine, right?

There's nothing you can do wrong in your weapon scripts that will make it behave this way.
If you can, then it is a bug.

@Howard:

Quote:
Has anyone seen odd behavior when standing inside a trigger area and shoot out?

This is a known bug, perhaps not confirmed, but it has been mentioned before.

#11 I've never experienced this bug, indeed I've never used the ShapeBaseImage class at all. Nevertheless, this bug peaked my curiosity; So I took a brief look through the code. At first glance "correctMuzzleVector" seemed like a likely culprit, so I started there, and found this:

In shapeImage.cc line 1215, the muzzle vector is adjusted as a result of this ray cast:

if (getContainer()->castRay(eyePos, aheadPoint, 0xFFFFFFFF, &rinfo))

Note the TypeMask: 0xFFFFFFFF. In other words, everything! Including... you guessed it, triggers.

Now, this wasn't a problem in the past, because In Torque v1.3 triggers did not implement a castRay function. However, they do now. Apparently, a castRay was added to the Trigger class between (my copy of) 1.3 and 1.4. So this is a new bug in v1.4.

To fix this: I suppose you could try to remove the castRay function from the Trigger class, but that might be needed for something. At the very least it may be useful to have down the road. Besides, do we really want the muzzle vector correction checking against everything? What if you decide you want to add a ray cast to your Explosion class? There's potential for so many future headaches there. So, I think it would be preferable to fix the TypeMask in shapeImage.cc, like so:

if (getContainer()->castRay(eyePos, aheadPoint, [b]InteriorObjectType | StaticObjectType | ShapeBaseObjectType[/b], &rinfo))

| WhateverOtherObjectType as you may deem necessary.

(I haven't actually tested any of this, I'm just reading the code, but I'm pretty sure that's what's going on here.)

#12 @Stefan and Scott, thanks guys for the input.
One thing I did notice and I can't make it happen with the crossbow is if you create a trigger and walk up to it then get in fly mode (ALT c) and look at your character the gun ( used the assault rifle from Jill pak for this) is pushed back like it collides with the trigger as tho it's a wall. Edit mode only... so the col - 1 or collision -1 (confuses me still on this ) is acting on the trigger somehow.

#13 Yeah, same problem. castRay calls that use the indiscriminate TypeMask 0xFFFFFFFF. In player.cc, see lines 3055, 3100, and 3761. Or search player.cc for "0xFFFFFFFF". Replace those with more appropriate TypeMasks.

Also, fx/lightening.cc uses a similar castRay against 0xFFFFFFFF on line 763. That probably should be fixed as well.