Ione Lameth in-game. An easily amused meddler wasting time mostly scripting. I don't have any mentors, but have had plenty smart and friendly help.

Feel free to drop me a line here.

---

Ione likes references in which a few glances are enough.

Ione think references to redirect pages that do not redirect (eg. page to groups to group, page to radians to radian, avatar to AgentAndAvatar) are silly and will alias-link referencing pages when found. It saves a click, you know:)

Ione has a bad habit of clicking 'store' instead of 'preview'. She is trying to mend her ways.

Ione isn't a very bashful editor; do complain to me if you think I edit things too easily. I just think stirring up some dust is a good way to get some work going on a page.

Ione stares in the SL font's general direction for making people think her name is 'lone'.

According to googlism, 'ione is approximately 255'.

---

Notes

Using on_rez for initialisation can be useful when you don't want objects' persistant state to bug you. For example, you can llResetScript (see that page for a reason to do so and for details).

Self-question: What exactly does selection do to objects? They do not participate in physics, and apparently will also not be detected by sensors - or apparently, it will change their being detected (or just the order?): move something into range while selected and it won't detect it, but have it be in range and select it and it still will be. (tested by using (0), which is usually (not always) the closest)

Communication

Communication within a linkset should be done with link messages.Aside from being more efficient than using channels, are useful because they are object-local and won't interfere with multiply rezzed objects. Also, messages don't start getting through until linked, which can be handy while building something that's not supposed to start partially working before you're done and linked (and you may want to consider using on_rez to avoid things working until the next rez).

There seems to be no way to check whether a channel is taken, but you can choose a random one every rez (e.g. integer channel=1+(integer)llFrand(2000000000.)). On cooperating objects, try to make one rez the other so that you can hand this channel to the other in the rez event.

I wonder whether there is any practical way to query specific objects (e.g. those that llSensor sees), other than using llDetectedKey, a fixed channel and making each object filter an llListen on their own key - as that may be a little hard on the sim on larger projects.

XML-RPC

SL seems extremely picky about the format a client hands it. That's the only reason I can think of to explain the fact that it just started to work for me. I use one of the python XML-RPC clients scripts right now, the one of which the code is:


The LSL script this sends to is the one listed on the XMLRPC page.
I've yet to nicely solve the hardcoded UUID thing. Don't know what to do about that yet.

State

A number of things are prim state, and can often only be changed with a script, though most also through the edit window. This includes the rotation, scale, position, particle system (llParticleSystem), sit target (llSitTarget), hover text (llSetText), flags (whether it participates in physics, is phantom, will phsyically rotate and a few other things; llSetStatus), the color, texture, and alpha (see texture). Many of these can alternatively be set through llSetPrimitiveParams (usually slower through a delay), which additionally lets you set things like material and TemporaryOnRez-ness).

These things will not change when the script that set them is removed.


Other things will, which seems to be anything in dynamics/interacts with the energy system, such as buoyancy (llSetBuoyancy), force (llSetForce). It seems these revert to their regular state, usually a zero value. (Since physics is necessary for many but is a flag and as such persists, that usually means deleting the script will make the object drop)

Persisting

There are two types of persistance:
* prim state and script state persistance while things are in your inventory (only until a script reset)
* script continuity while changing active script state.

For example, prim state will persist into your inventory (and script state does not affect it).
Script variables and scriptstate will persist into your inventory too.
llListeners will stop both while changing scriptstate and inventorizing. (seems a little odd as it makes using the states slightly more verbose sometimes)

(note to self: make list of interesting things here)
(note to others: I use 'state' in the more technical/general sense, not to mean prim parameters, prim status or script machine-state. Sorry:)

Experiment: Clock arms

Because when you use quats you cannot create a single operation (and lsl doesn't really provide much help) that does rotation at the same time as anything else (like you can with matrices) rotation about anything not the object's center seems not directly possible, so eg. making a clock's hands is hard - but possible. (Most clocks, e.g. the hub clocks, are simpler: they use mostly-transparent textures on the top face of a cylinder to emulate separate hands).

One solution is to communicate both position and rotation to the child via (preferably) link messages and set both at the same time using llSetPrimitiveParams which adds a 0.2sec delay, but that should be generally survivable. (using llSetPos and llSetLocalRot separately will introduce a visible delay between these two calls.) Note, though, that (script) lag can make the seconds only correct on average, as with anything updating state so often. Stripped-down example code:

Physics

There is an index of sorts at physics, and energy got a lot more detailed (so I removed some notes here).

Some functions, such as llSetForce (also llSetBuoyancy, llSetHoverHeight, llSetForce and likely llMoveToTarget), cause constant use of energy, which means that it is possible that objects use energy faster than it is supplied and so will make it easier to run the prim out of energy, or completely do so themselves if they try to do too much.

Running out of energy at all is a bad idea as even when it works it'll run into odd shocks. Additionally, whenever anything else acts on an object, more energy may be sucked out than in ideal situations, so don't depend on the exact limit. Buoyancy and other constant-use functions do not work on large objects. In simple tests, this seemed to happen for things with more volume than 10 cubic meters.

(I'm not sure how energy is received/used in linksets - it doesn't seem linear)


Material type (set in the 'Object' tab of the edit window) have effect on the physics engine, but apparently only in friction and possibly collisions.

Particles

You make these by handing llParticleSystem a variable-length list of commands and their parameters. (An llParticleSystem call seems to set a static (fully persisting) state collection after clearing it to defaults so that you don't need to override anything.)

Setting target key to something nonexistant may have the effect of not changing, rather than setting the emitter as target as mentioned in llParticleSystem; check this.

Vehicles

Vehicles look like default behaviour that should probably be seen like a similar but separate set of dynamics functions (probably using the same lower-level interaction tuned for the purpose). It seems to come down to channeling movement into preferred axes of motion, two types of motor (one for propulsion, one for turning), a separate hovering system, some tuned flying things such as banking, some pre-made convenience vehicle types that the docs suggest are mostly just a combination of vehicle parameter sets.

Control is done via scripts, though steering can also be done via mouselook. Potentially it can be separate from you, though it often just makes sense to react to direct input controls via llRequestPermissions, llTakeControls, usually once people sit on something (since your avatar is incapacitated when you steer). However, there is no direct need for an avatar at all.

Links: Vehicles, the apparently somewhat outdated LindenVehicleTutorial and the likely better TutorialVehicle.

Pitfalls/hints

See also listed Annoyances.

I once relinked an object differently not noticing that that meant I had two different versions of the script in the linkset which made it act quite weirdly. You can check this without checking everything by stopping all scripts (Tool menu); it'll list each script as it shuts it down.

Object center is not (necessarily) the same thing as center of gravity, and eg. llLookAt will rotate about the latter, llSetRot around object center (position coordinate).

Sitting changes various things, including
vehicles' (maybe objects' in general? *check*) center of mass,
the avatar's susceptibility to physics - probably depending on object's physics status (*check*) as the avatar acts like a linkset child (the way you detect sitting is through detecting al link change).
check the mass implications.


Sim borders seem to be slightly unpredictable. Internally, I would guess a hopefully-identical process is created on another computer, which has its imperfections in practice. It is apparently not as simple as a script reset or re-rez (it does neither) but details do change unlike you may expect, and I think it does just work except if you use sim-dependant functions that are either so per definition (e.g. apparently llGetTime) or per bugness.

Wiki

ACLs: § means logged in person, * means anyone, including anonymous users. Named users are positive filters, ! negate them. ACLs seem to be a first-match thing.

---

Backlinks, for reference of what I've meddled with in here:

brace CamelCase collision_end Contributors Debate IoneLameth llSetHoverHeight quaternion RemovalPetition value VehicleTutorial WikiUsers