Physical movement bumps sideways

I have a critter-object that wanders around my parcel using llMoveToTarget() to get smooth motion. Before each move, I call llGetParcelDetails to make sure I am staying inside my parcel. But the physics engine often (far more often than I would have thought possible) bumps my critter sideways a little and it ends up off my parcel. I think this only happens if there is something in the way, like another critter.

If I'm unlucky, my neighbors don't have PARCEL_FLAG_ALLOW_SCRIPTS set and my critter can never recover. If I'm REALLY UNLUCKY, scripts are allowed but PARCEL_FLAG_ALLOW_ALL_OBJECT_ENTRY is not. In this case my critter recovers, but I'm IM'ed a message “Can't move object ... because your objects are not allowed on this parcel.” A blue dialog box with this message appears for a second if I'm around, but wherever I am in SL my chat box gets these messages (with an added warning that these messages are temporarily deactivated, I only wish that was true). When I log into SL after being gone for a while I find my chat box overflowing with these messages.

I'm considering calling llGetParcelDetails on either side of my critter to get an idea of how close it is to the border. Then staying far away! But I feel guilty lagging down the server making all these extra calls. I notice that this routine has an energy cost of 10.0 to discourage me from calling it too often. Is there a better way of preventing physical objects from bumping themselves across a border?

Have you tried making your critters phantom? Also, it could be that the critters are bumping against ground that they can't move through, so they drift in order to get to the next destination without moving "through" the ground.

If you're looking for alternate functions, try llGetLandOwnerAt() and you won't have to handle a list at least. But, I don't think the energy cost of 10.0 means that llGetParcelDetails() is a high-cost function. 10.0 seems to be the baseline energy cost for most functions.

Give your critter a notecard with the boundary co-ordinates on it. That way it only has to check it's staying in-bounds, not what might, or might not, be around it.
If you're leaving a physics-enabled object wandering around and occassionally wandering 'abroad' you've introduced the lag and hassle anyway, I wouldn't worry about the overhead of a few extras LSL calls.

Dang, I've been obsessing on finding out how to keep critters in parcels, safe areas, or staked out areas and I never noticed llGetLandOwnerAt() !! Thanks for pointing it out. I've been doing the same thing with llList2Key(llGetParcelDetails(pos,[PARCEL_DETAILS_OWNER]),0)
I'll one up you, Indeterminate, on your notecard. I built an object called a Fent. You put several of them on your parcel and they communicate with each other, choose one of their number to be a server, and create a Fents(r)(tm)(c) which replies to requests from critters for boundaries to stay within. Two of them define a rectangle, actually a cube for flying critters. It's still a pain in the behind to set up, I thought it would be easier to just stay inside the boundaries of the owners parcel.
Well, I made all the extra calls to llGetParcelDetails() (hadn't read DoteDote's note yet) and tried to make the critters turn away from boundaries. With a 1 meter turn-away buffer, I still got a few error messages. I widened the buffer at the boundary to 2 meters and so far no errors! I think this will make it happen infrequently enough.

I was in a similar game a while ago. With a physical, phantom object to travel across a parcel only using llSetForce() to accelerate and decelerate. I used llGetParcelDetails and the region size to determine if the destination was safe before the object started.
I learned two things:
1. Even when the logic is right the physical machine will let you down at some point and the object will leave the parcel. Just wait and see.
2. Never leave an object controlled by the physical machine, alone.