non-physcial collision

alright i asked in world and everybody kept saying llVolumeDetect (which i know is wrong), im trying to get my object bullet so that when it collides with object brick, they both die, but collision, collision_start, collision_end, and llvolumedetect dont work

every second the bullet moves forward .02 meters and it is a non-physical temporary prim, what can i do to make this work, without making anything physical.

Why is llVolumeDetect wrong?

because on the wiki page it says:
Caveats

* Must be applied to the root prim.
* Does not work on attachments.
* Only detects physical objects



so it cant work for non-physical detection

Where is the script containing the collision-related event handler, the brick or the bullet?
(Can't actually recall trying to detect collisions where neither object was physical, though, myself.)

its in the brick, and i think collisions only work if the colliding is physical, so i cant figure out how to do this...

You know the bullet position. You can use a short range narrow beam sensor to detect the bricks positions.

If the vector distance between both is below a defined value, a collision has happened.

Why use the lag of a sensor, if the bullet can just llRegionSay and ask the brick where it is?

What if there is a brick wall made of hundreds of bricks?

a short range directed sensor is best in such a case ^^

Well it really depends on how you want to implement it and the scenarios that could be applied to its use.

A sensor would have to be repeatedly called, whereas a regionsay message could be filtered in such a way as the bricks would know where the bullet is and which way it's heading. Hell, you could really have the brick decide if it's going to get hit or not and then only that brick tells the bullet where it's at so the bullet knows when it's going to hit.

A well-designed sensor script is not all that laggy, being essentially a point-in-sphere intersection test, which is one of the fastest intersection tests that can be performed. Even when it's done as an angled cone it's pretty darned fast and efficient.

llRegionSay, on the other hand, could potentially (as in the wall of bricks example above) involve a great many more objects (anything in the entire region listening on that channel) plus involve two-way communication. And chat can get delayed by a very noticeable amount, making it's use for a well-synchronized system iffy at best.

I wonder how a sensor ping and llRegionSay stack up? I don't know whether either is useful for the OP's problem, but my suspicion is that llSensor() is the more efficient way to go.

Why the insistence on not having the bullet be physical? I'm just curious. You could make it a phantom, physical, temporary object if you wanted to have it only interact with certain objects like the brick, I think... And if you want the slow precise movement of 0.02 meters per second, you can use llMoveToTarget in a physical object, specifying the speed in the tau param.

[Edit] I've never used llMoveToTarget for something that slow, you might have to set bouyancy just to keep it aloft at that speed, or keep updating the target pos to something just ahead of the bullet... I am not sure. Might be worth experimenting with?

Or the "bullet" is just a particle effect in the brick: Aim gun, press trigger, figure out "ballistics" for which if any brick will be hit, tell brick to go kablooey. Add a whiff of smoke from the barrel, and everyone will swear they saw a bullet.

becasue the wind takes the bullet and pushes it a considersable distance off course, a well aimed shot to win the game could make you lose if the wind picks up and snags a bullet.

ts a .01 by .01 by .01, and has a buoyancy of 1.02, so the wind would take it off course.

Well I'll admit to only having limited experience with sensors, however, my approach was aimed more to the fact that his 'bullet' is moving relatively slow. Also, the chances of another object in the sim listening on the same channel is rather moot unless you use channel 1 or something similarly overused.

Also the lag from the sensor is really going to depend on how narrow of a band is being scanned and how often. If he constrains the sensor to look for all objects named "Brick", then he could obviously get several returns that do not apply since Brick would be a common item name that could be applied to anything.

I had, in part, assumed that this was meant to be more than just a weapon (I mean 0.02m per sec is literally crawling), and perhaps part of a game of some kind. Unless there was some authorization done beyond just a sensor, then it could be easily fooled by the player throwing an object in the way, so having them communicate from the start instead of sensing and then communicating seemed like a smarter option to me.

As I said...this was an assumption so I could very well just be making an "assume" without the U.

its all part of a game, there are probably going to be about 20 brick objects, so 20 sensors could be pretty laggy, also, the say functions could also cause lag, all the objects are no more then 2 meters away from each other, so the least laggy would be a llWhisper, or if i did some more research on a sensor, that might be it.

lol, 20 sensors or 1 whisper and 20 listens..... i will have to test

I can tell you right now that the 20 sensors will be more detrimental than 20 listens, simple because of the amount of data that is returned in a sensor (DetectedName,DetectedKey,DetectedRot,DetectedVel,DetectePos, etc.) for every object found versus the 4 data points returned just once in a listen (channel, name, key, message)

Are we talking about a "Breakout" type game here: "Bullett" strikes brick, brick disappears?

[Edit: Disregard, re-read the OP. What if the "bricks" were all linked, and each one "struck," would unlink and then die. Then you only need one listener/sensor for the entire linkset (preferably in a prim outside of "play" ]