Current state of NPC/BOT scripting in SL?

Not so much a 'scripting tip' as a general query - having wandered around in SL for a while, it appears to me to be surprisingly devoid of the NPC (non player character) agents that infest/enrich (delete as appropriate) other VR environments. Those that I have seen have typically also been relatively simple objects, usually non-physical, and those that do alter their shape appear mostly to use selective prim hiding, rather than actual child prim (arm/leg etc) movement.

I was wondering whether (a) I am mistaken, and in fact there is a whole population of complex bots which I just haven't come across, or (b) is there some underlying reason for their scarcity, such as (for example) deficiencies in the underlying scripting or physics engines, or possibly just a general lack of interest in them amongst inhabitants. Any thoughts on this from more experienced SL residents and scripters would be most welcome.

the single biggest hurdle i've come accross in any attempts to do this are that a prims center of rotation can't be changed, give me sub group linking and let the games commence

My official status is: Working on it.

I have a long list of things I am tweaking first, once I get those done I will have learned enough to get started. I am already in the planning stages, learning what is and is not possible.

Modifyable, dynamic body structure is part of my plans.

Done: simplistic AI animals with moving body
Doing: neural network based AI
Projected: autonomous, self-growing tree with no theoretical limit on end size

The biggest problem is that there's no hierarchical linking that works worth a damn. The support for hinges in SL is primitive, buggy, and in the process of being removed (temporarily, at least) to allow for the update to Havok 3.

Thanks to all, it sounds from the feedback like it is mainly the absence of built-in support for joint/limb hierarchies within link sets that accounts for the absence of avatar-like NPCs. I guess LL could easily allow scripted (as opposed to user-driven) avatars if they wanted to, they presumably have some reason for not supporting these. Hmmm, sounds like an interesting scripting challenge

Jesrad, what sort of neural net AI are you looking at, can I ask? Would it be purely for realistic 'animation' motions in a link set, or for higher level goal seeking?

Oh, it's only for higher-level decision making. Animation is fine as it is, I made a set of scripts that allows hierarchical joint movement with animation frames read from a central notecard. I'll be using a weird mix of Kohonen self-organising map and Hopfield network.

If you want to read about AI in SL you must check this thread about Surina's fishes

The biggest hurtle I've run across is 3d space awareness. an NPC can detect where it is by running into things, or using sensors. both of which only tell you the center of an object. Collisions one at a time, sensors 15 at a time organized closes to farthest and I've had some trouble detecting completely inert objects. Also there is not enough script memory to record much more than a few past successfull paths in any detail. All of which makes it very hard to get an npc object to follow a natural or efficient path from point A to point B through any kind of obstacle.

Amen.

I am severely hampered by being unable to do even basic raycasting and only able to sense an object's position via center with no way to find its extent.

For example, it's possible for my bots to determine if they "see" one or another. I can use a sensor, but that won't tell me if that bot is directly in front of me with no obstruction or there's a wall between us. The only way I can tell is have my bot try to move towards the wall and BAM. I trigger some simple avoidance in the collision.

I could rez a "probe" and have it tell me if there is something in front of me, but IMHO this very ugly solution and not very sim-load friendly. Plus it slows down path processing to the point that if you want to do anything more than just snail-pace along, too bad... Besides, that doesn't help me if I want to do line of sight calculations. Unless you don't mind my bots running around spraying invisible, tiny physical prims out continuously in an arc around them...

Worse, since sensors cannot be rotated except by moving the prim itself, I have to waste valuable physical-set prims just to do things like angled sensors. It would be nice if I could offset the sensor's cone. (The same with particle emitters, but that's another story...)

OK, I will add 'inadequate sensor support' to the list of bot implementation issues. Are there any feature proposal polls where we can add votes for enhanced sensor capability?

Thanks for the fishy link Jesrad, made fascinating reading If I understand correctly, your scripts effectively support a BVH-type animation description file for reconfiguring joints in a link-set?

Yes, you input the local position of each joints, their rotation for each animation frame, and you plug the hierarchical order of the joints they attach to in each prim of the linkset.

The inadequacy of sensors has forced me to make my AIs ignore other objects apart from other AIs, they just use the ground and water functions / collision to move.

BTW you should be able to use llGetBoundingBox to evaluate the extent of any object by key.

Interesting, have you considered writing a converter to create your notecards from raw BVH files? There seems to be quite a buzz around Avimator at the moment, it might provide a useful GUI for defining the rotations/translations for your bot animations.

I must confess I only started thinking about NPCs while I was working on the statutory 'door' script that I guess every coder writes when they first arrive in SL. Someone asked me how they could put a cat-flap into it, which got me tangled up in the whole 'hierarchical structure within a single link set' issue. Just for fun, I then tried enabling physics on one of my more complex door arrangements, at which point it occurred to me it looked a lot like an avatar trying desperately to stand up. Hence the initial post.

I think in view of the feedback, I might have a go at implementing some simple robotics-type algorithms, to see if I can get arbitrary prim assemblages to (a) stand, and (b) walk, autonomously.

Thanks to all who responded, I will let you know how I get on.

Get bounding box includes the entire link set and doesn't rotate with the object, making it the case that the bounding box usually takes up a lot more space than the actual object. and perfectly useless for detecting the surface you should be moving along.

I think bounding box does rotate with the prim, at least if it's a vanilla cuboid unlinked prim. Perhaps if you had an environment made only of such cuboids something could be done.

hm... I'll have ot retest, however what I thought I saw was this. A zero rotated cube, bounding box = cube, rotate it PI / 4 around z, your bounding box is now wider and deeper than it is tall.