Strange Attractors

I've searched the forms and have only had a few hints of solutions to this challenge. Here is the conceptual framework.

I'd like to have as many as a half-dozen objects floating in the air with the following strange tendency. The objects should show a gentle independent, yet persistent attraction to a particular point in space (or a stationary object). but after reaching their target, (and sometimes each other) they get weary of this attraction and repel each other in random directions tumbling out to a distance of perhaps 50 meters or so, with the effect slowly damping, only to have the process repeat itself like a bad habit. It will not be necessary for the viewer to interact with these objects at all. I'm open to a certain amount of regularity, but the point of this is to demonstrate a subtle order in what on the surface appears to be a random event. I've seen cautions about trying to implement Brownian motion, but that isn't what I'm after. Essentially this should apear to be a weak magnetic attraction followed by a sudden reversal of poles.

First, is this even possible, and second, how lag inducing would it be? I'm very new at scripting, but I've learned a lot from my past two requests. I'd like to build this myself, but frankly I'm going to need some serious guidance with the components of the script and patience from the advanced scripters to help me work through putting it together.

Possible, yes, though you're likely going to have to play with it quite a bit to tune the performance such that you get the oscillation you want without objects overshooting their destinations and such.

Likely functions to play with for this kind of behavior are:

http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSetForce
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llApplyImpulse (for specific change in velocity/momentum)
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llGetMass
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llMoveToTarget (maybe, but less control over specific force/acceleration)
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llGetPos
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSetTimerEvent

You are going to have to compute the forces or velocity/momentum changes yourself. It's pretty basic physics to decide on a potential field and figure out the resulting force, so I'll assume you don't need help there unless you ask for it.

The tricky bit is going to be figuring out how often to run your timer to re-compute the potential and the resulting acceleration, especially if you want to try to do something like approximate the integral of the effects since the last computation. That's the unfortunate bit about digital technology (including computation) applied to physics.

As for lag, it depends on how accurate you want to be; how often those timers are going to have to run to make things accurate enough. Adding half a dozen physical objects to the sim is going to create some burden, but what forces you have acting on them PROBABLY won't impose a great deal more cost. The rest is the user script time it takes for your script to gain control of the processor for a bit and do the computation.

The 1st bit, moving towards a central target, seems easy enough. I think the real trick will be in how the 2nd bit, having all the objects repel each other, works.

Maybe, if you didn't need it to be _too_ real, something with a series of invisble prims around each moving object (edit: that is, the moving object being N-link set with one visible prim in the middle and a series of child prim spheres around it) that detect collisions and apply force in the other direction. Or maybe have the moving prims be fairly stupid animals and have all the smarts in the central prim to cut down on chat/listen costs..

/me would be interested in seeing this if you get it to work.. Please post again if you make progress!

Well Hewee, I know just enough about this to be dangerous. Thanks for the advice and the leads. Something I should make clear is that the ONLY accuracy I'm interested in is the center point of the sphere of influence and the maximum radius in which the event takes place.

Essentially picture a sphere approximately 50 meters in diameter. The core of the sphere is at X the surface of the sphere is Y. The objects are attracted and tumble toward X and upon reaching it are then repulsed on any random vector tumbling toward Y. They might reach Y they might not, they might hit one of the other objects on the way or not. Essentially all motion is random (including the object's tumbling) except that the objects always return to X and are max limited by Y.

Everything else is uncontrolled (or I guess FFrandomly controlled to pick the best oxymoron)

I'm thinking that llMoveToTarget would be the heart of the script since it also includes a damping characteristic. From what you've highlighted, I'm afraid I might be so far over my head that I would be better off paying someone to write it. I'm not schooled in physics and my math skills are decades away from college.

Can I get away from complicated physics computations by allowing this sort of freedom?

Not so long ago a "Swarm" script was posted in this forum. It could do something similar, if not exactly what you ask. Go search for "Swarm"

Certainly. You might start with something like this:

default/state_entry - Position the physical object at the boundary (Y) and use llMoveToTarget() to start it moving toward the center (X), probably with a randomly computed time constant (tau). Also use llTarget/at_target (http://www.lslwiki.net/lslwiki/wakka.php?wakka=llTarget) to detect when you are "close enough" to the center to turn around and move outward.

collision - Either let these take care of themselves with the physics engine, or apply some kind of random impulse using llApplyImpulse(). Or maybe randomly decide to move the object back toward a random point on the boundary (Y) or toward the center (X) again using llMoveToTarget().

at_target - When moving toward the center, use this to pick a random point around the boundary to move toward using llMoveToTarget() and apply llTarget()/not_at_target to detect when you have gone far enough from the center to turn around again

not_at_target - When moving toward a point on the boundary (Y), use this to decide when you have moved far enough to turn around and move back toward the center (X) again using llMoveToTarget(), just like in default/state_entry.

Swarm Script:

/54/0c/9803/1.html

the interesting question... should proximity to the the attractor accelerate the prims, even if only by a fractional amount?

Hi Jesse,

Thank you for your swarm suggestion. I have already looked at it before starting this topic. The behavior I'm looking for won't be reflected with a swarm script. The center point of my hypothetical sphere is the one uniting factor I am looking to establish and the objects I want to animate should appear totally blissful and ignorant of the others in the group. Just a single minded attraction to the center that can't be escaped. That doesn't occur in a swam.

@Hewee...

I'm beginning to wonder if this would be easier if the center of the sphere would contain an unmoving object as a focal point. That object would have an identity and could be rezzed first, and then all the special "enchanted" objects would have something to anchor to. I still haven't written a line of code yet. I want to strip the concept down to the absolute minimum necessary to achieve the desired effect to make the code as simple as possible to generate.
Would what I just suggested simplify things still further?

I've only written a couple of scripts from scratch and am not coming from a programming background. I have the vision, but the tools are still being learned.

Since yesterday I've tracked back into the forum and llooked at other uses of llMoveToTarget and have noticed that it is commonly used in scripts that get pets to follow avies around. Along the lines of what I asked in my last post about using a prim as a central object, I'm wondering if the a modification of such a script might be the easiest most elegant solution to the problem.

One thing I noticed in such scripts, though is that they make use of llGetOwner and from what I've read it seems to assume that an "owner" must be an avatar. Is there some special quality of an avatar that is different from a simple object? If all that is involved is a UUID, couldn't a follow script be manipulated to do all that I ask with only the need of a central object to use as an anchor.

I have to be honest. I've spent several hours wading through the forum since yesterday and I'm on the verge of realizing that this may simply be beyond my ability to create from scratch. I've written a couple of simple scripts and modified a few more with the generous help of people here, but when I start wading into topics like this one:

/54/0a/235123/1.html

that only involves a simple back and forth movement, I get very discouraged.