Pathing and sensors

I suspect there is not a way to do this... I've come across many people who use the "walls" to direct a bot.

But I am building bots for running through a maze. If they collide with a wall, they figure out which direction, etc and turn away and zip off. However, many times there is another wall immediately to the left or right of where they turn, so I have been experimenting with sensors.

The biggest problem I have run into is that while I can sense objects, their llDetectedPos() returns the center of the object. But, I can't figure out how to get the objects length/ width - so I can't really determine if the object is in my way. Meaning if I detect there is a wall to my left and behind me by 3 meters - If the wall were 6 or more meters long - it's in my way. if it's less that 6 it isn't (Yes I have simplified out the size of the bot)

I could name all the walls in some fashion that would make the size more apparent - but I was really hoping to create the knowledge in the bot itself.


Any ideas or suggestions would be appreciated, this is a new area of scripting for me. Actually doing pathing is a new programming problem for me as well - which makes it fun, but I'm really kinda stuck atm.

Thanks

My guess is you would need a llDetectedPrimitiveParams() type function, but unfortunately that doesn't exist.

So, as an alternative, you can use llDetectedName(). I assume you are making the mazes yourself? Just name your walls including the scale. Like Wall <1.0,5.0,5.0>.

You can even go so far as to set the name on rez using llSetObjectName() and llGetScale().

on_rez(integer start_program)
{
     llSetObjectName("Wall:" + (string)llGetScale());
}

Then with a little string manipulation, you can get extract the parameters of your wall from its name.

Hope this helps...

Naming the walls is your best bet. You could also interrogate the wall to reveal its own size, but that requires a script per wall section.

If you really want it to be self-contained (and also very ambitious) then you can use multiple llSensors calls with a very narrow beam to figure out the approximate wall size.

-peekay

How would that work Peekay? The sensor only triggers if the center of the object it is scanning passes within its cone. All you'll ever get is the center of the object.

Yep, detectedPrimParams... would be great... but it'll never happen due to the reverse engineering possibilities. Well it might - but I think it's implementation would be quite tricky for the Lindens.

I suppose a small script that names the walls is the least impactful way of doing things.

Thanks for the input.

See llGetBoundingBox .

Ooo, nice. I didn't think of using that in such a manner. That will be useful for me later. Thanks

llGetBoundingBox works great for cube walls with no odd cuts/hollows and 90 degree rotations.

[edit]I misunderstood how llGetBoundingBox works. Seifart Surface has the detailed explanation below[/edit]



On a slight tangent to the original inquiry:


I've had some sucess using probes to tell a bot where obstacles nearby lie: the bot moves slowly (about .2m/s), and when it collides with something in front of it, it stops and shoots a probe out along both directions of each axis; after the probes travel a set distance (usually 3m) they report back to the bot; if the probe collides with something, it dies (just like the standard bullet script, only it stops after a certain distance). the bot then picks a new direction of travel from the probes that reported back.

So far the only major problems with this method are running into no-script and no new object land (easily worked around using llGetParcelFlags to check if where it's going allows running scripts and creating the probes. The other big problem is when the probe attempts to go into land you're banned from (thanks to those lovely auto-ban scripts that kick you out when you try to fly from point A to point B). I've made a semi-useful work around where if the probe doesn't reach it's 3m away mark it dies.

The bounding box vectors are in coordinates local to the rotation of the object, so one should always take into account the rotation of the object. If you don't, all you get is the right shape and size, but in the wrong orientation, which takes up neither more nor less space than the wall itself (assuming the wall itself is a cuboid).

Ezhar's bounding box visualizer script on the llGetBoundingBox wiki page shows how to rotate the bounding box appropriately.

Because maze walls are usually multiples of size n (and have corridors of size n), you can do some deductive reasoning.

Eg., suppose you find a wall centered x=0 and walls come in n or 2n widths. If you find another wall centered at x=n then you know you have two n-width walls next to each other. A wall at x=1.5*n means an n-wall next to a 2n-wall. A wall at x=2.5*n means there must be a passable gap between an n-wall and a 2n-wall. Repeat in the -x direction.

A wall at x plus/minus 2n is indeterminate, so you move the bot there or launch a probe and see if it bumps anything.

-peekay