Coordinate questions...

Okay, this is probably way too deep for discussion on a forum rather then some formal education in this direction, but, maybe not either...

First, I am an amateur scripter at best, took some C++ at University, understand things like declaring variables, using operators, functions, function calls, basic loops, nested loops, long, short, integer, floats, simple things like that...How to take that across to work in LSL is another book altogether for me, although, when opening freebie scripts to take the opportunity to understand how they work, seeing things like For i >=5, i++...Right..or, On touch, On Rez...pretty standard stuff and fairly straightforward to navigate...I even have Particle Wizard and it's about the same to build a particle type using that and then look at the code created to see what its doing, albeit even that is starting to run away from me SOMEWHAT...Now comes the deep part...,Sorry, Noob I know...

Im 45...In my RL job, I'm a Robotics Engineer, working with industrial robots and CNC machining centers, so, I completely understand the concepts of Cartesian and orbital coordinates...3D space and all of that...That statement sets up my questions...

I see alot of ads where people selling LARGE PRIM items, like yachts, will add that these are NOT meant to move (I assume because they have built features into them that HAVE to rely on the stock SL Cartesian coordinate system to work or for placement to be correct and attempts to move the whole thing would "disturb" the linked items within the build (For lack of better wording there...)...and, lately, I have also seen ads for things like aircraft that are described as using a "Physics" engine that frees them of the bounds (or, limitations...) of your standard X,Y,Z coordinate system...

Okay, now, the questions:

1. Does everything in SL HAVE to rely on the stock X,Y,Z coordinate system?

2. Either way, is it possible to have a moveable object that can freely move...no...wait...not quite...Is it possible to have a LINKED item to a MOVING PARENT ITEM, wherein the LINKED ATTACHMENT (?..Not to be confused with avatar attachments), can ALSO move, or, be INDEPENDENTLY cycled?

As an example, can I have a moving ship (Any given direction) and script a cannon to auto aim at an incoming target and hold that target, cycling itself to do so, irrespective of the parent ships movements (Provided the target is within the field of view, or, Work Envelope, of the cannon)?

Is there a way to script something to always get an update of the ships coordinates, maybe have a given offset in X,Y,Z from the parent center to the cannon (For instance) and given that constant, use that to stay in place within the parent, but, independently hold the target lock on the incoming object?

Would that cause a load of lag because if I DO undestand that much, Im basically asking if the CHILD object (Cannon) would be scripted in a variant of a "LISTEN" function, which I think I heard DOES cause lag because its holding the channel open to "Hear" a repeating coordinate update?

How then are the folks using these "Physics" engines getting around using these types of scripts in a way that doesn't cause a lag hog?

IS that too deep? Confusing I know, but, Im trying not to be...I'm really trying to be thorough enough to convey the concept without subjecting you to the obvious discrepancies in my ability to script and understanding of exactly how to do it...

Anyway, if anyone is willing to tackle this and help me understand how that works, or not, if it simply can't be done, but, nothing just CAN'T be done...

I appreciate any constructive feedback...positive or negative, as long as I come out knowing the limitations I am facing in attmepting it...or not...

Thanks for your time and assistance...

See ya IW maybe...

Quik Taurog

There is quite a bit there. It would be hard to describe the entire system of how one positions objects in SL by various different methods in one post. It might be better for you to narrow it down to specific examples.

Having said that: everything in SL has an XYZ position. This is always returned relative to the sim corner by functions, but can be translated into a global position, so in practice everything has a global position vector. This vector can be easily transmitted to other prims via listens; the lag of this will depend on how often you send messages out and on how popular the particular channel is, but as long as you don't have dozens of prims shouting every 0.05s it likely won't be too bad.

Moving things within a set of linked prims is a pain. The function llSetLinkPrimitiveParams helps there, or, when called from a prim that is not the root in a linkset, llSetPos. There are also other functions which can simulate, say, rotation, client-side.

For the idea of a giant object moving about you may wish to google for "Multimove" (or search within this forum, though google will probably be more efficent) as that is a script which illustrates how to have several linksets following a central one.

I think sometimes the seller gets tired of people IMing him to ask how to make the yacht go, and, when he tells them it doesn't, getting yelled at.

Also, are you familiar with the linking limitations wrt distance and size? Are you familiar with the number of prims limitation wrt physical/vehicles? Both these things limit how easy it is to make a very complex object move cleanly.

Im not really trying to make anything BIG, I want to build auto targeting turrets (To tell you the truth) that can be modded to ships (Space or aircraft) anyone else is building, or, can be added to BASE CAMPS as a defensive thing, in which case its simpler given the X,Y,Z, stays constant then...

I appreciate the help...

multimove:

/54/7c/94178/1.html

"As always, this set of scripts is designed to allow turning a big build composed of multiple objects (=multiple linksets) into a vehicle."

I have built some auto-aiming turrets... I have never tried to put them on a moving platform but they work great on a static platform.... It'd be a neat idea to get the platform moving though and see how they fare. Hmm, next time I'm in-world I'll have to test and see what happens when the turrets are moving, if it impedes their effectiveness or not.

My turrets don't actually 'move' themselves, they 'cheat' in that when they lock on to a target they stay perfectly still, but their shots are always on-target. They do not calculate target velocity and do not 'lead' the target, but the velocity of their ammunition vs. the velocity of the targets is such that they are very accurate. (I've had complaints that they're too good actually, that when they're active it spoils things for everyone else.)

All I've done is used the sensors, with about a 120 degree arc infront of the turret, looking for a vehicle with a certain name. When they detect a target, the detected position is used to calculate the trajectory of the shot and a suitable velocity is added, then the projectile is rezzed just infront of the barrel and off it goes. The velocity is modified based on the distance of the target, to get a somewhat consistent projectile velocity regardless of the target's distance.

-Atashi

if I understand right, you are wanting the turrets to move, but not be tied to sim position?

tie the movement to the root prim, and poof, problem gone....

making that moddable to vehicles, your issue becomes the offset of the root prim it's linked to, but it should be possible to get that info, ofest it to where your turret calculates root from, and proceed as normal

the issue with being tied to region coordinates, is not the coordinates so much as multiple separate link sets (link sets are limited in # of prims, and distance between farthest linked parts) so that each linkset is really separate for movement calculations... this is where multiMove is your friend... but shouldn't be an issue for your turrets