Multi-Linkset Movement

[BlowSUp]

Heyo all,

Looking to kick off a personal project- a big ship. Lots of hurdles I'd like not to get into, that are being worked on simultaneously but there is something I'd like to ask the community that is more immediately pressing.

Some time ago, to "overcome" bounding-sphere/linkability limitations a larger vehicle would be broken up into multiple linksets, with each attempting to monitor and then match/mirror movement of a "root", or "parent" linkset- usually the one the avatar was seated on/piloting from.

However, as some of you may know, the nature of this configuration tended to, in practice, yield a "caterpillar-like" or "cascade" effect where the root linkset would move, and then another set would move to follow that movement, and another, so on.

I'm wondering if there has been any innovation in this field, to avoid this effect, these days. Particularly, the very un-appealing "stacking" that would occur attempting to cross sim borders, where each of the linksets would pile up at the sim edge until the root set arrived and crossed the border, where they would snap back to proper position.

I believe those previous systems worked by constantly checking the positional, rotational values of the root set, and updating the offsets for the remainder accordingly. Would there be any benefit(ie reduction in caterpillar effect, I assume the sim cross stacking would still occur) in abandoning the follower methodology in that former script and instead sending translational/rotational commands to all linksets simultaneously?

 

Thanks for reading,

Z

[Qie Niangao]

Depends how far back "some time ago" was, and just how big this big ship is supposed to be. In the earliest SL, normal (non-megaprim) objects were limited to 10m and the old linkability rules were obscure. Now an individual link can be 64m on any axis and their origins can be anywhere within a 54m radius.

But maybe you need even bigger (in which case I got nothin').

[Fenix Eldritch]

Reminds me of the old non-pyhsical "Multi-Move" systems. Adding to what Qie said, from what I recall, two things contributed to their caterpillar-like movements: the 0.2 second delay imposed by llSetPos and the ripple effect of communication relays from the "root" linkset if the overall thing was larger than the llShout distance. This is because it would be the "root" that would be sending out commands for the other parts to move themselves - and have some parts echo the commands to linksets outside the root's shout range.

There have since been new LSL functions added for positioning objects that do not have a forced delay. llSetRegionPos is one option, and allows for an overflow of ten meters outside the current region. That should be enough to get the piece to cross the region threshold if it's using relative movements and continue on without much hassle. llSetLinkPrimitiveParamsFast is another option, which you can use to set the position and orientation all at once, through I'm not immediately sure how well it would perform for crossing regions boundaries. It's probably fine, but I can't say off the top of my head for sure.

Regarding the actual communication, llRegionSay is very handy as it allows you to broadcast on a channel to everything in the current region. But as the name implies, it's got a hard limit of only being able to reach anything within the same region. This would pose problems for crossing region borders. For that, you might be stuck using a chat relay system still - as least as far as I'm aware.

Edit: Also, even if you had everything communicating and operating in perfect synchronization, you still might get some hiccups due to the overall status of the region's health. Multi-Move solutions were notoriously resource heavy, with each linkset having multiple scripts - likely to try to get around the 0.2 second delay. Now that we don't need to resort to that, things might be a little better on that front.

Edited July 17, 2019 by Fenix Eldritch

[BlowSUp]

2 hours ago, Qie Niangao said:

Depends how far back "some time ago" was, and just how big this big ship is supposed to be. In the earliest SL, normal (non-megaprim) objects were limited to 10m and the old linkability rules were obscure. Now an individual link can be 64m on any axis and their origins can be anywhere within a 54m radius.

But maybe you need even bigger (in which case I got nothin').

Just so, the days I'm thinking of are since, or rather in the wake of, the 64m adjustment.

If we put real-world scale and naval classes of ships to use(and there to lies another problem as SL, particuarly the avatars, are regularly >30% oversized compared to even the most generous RL averages) I'm looking at frigate/destroyer scales which are often >125m in Length Overall(LOA).

With object centers constrained by that 54m limit, using offset tris to cheat the SL uploader's Object Center calculation, offset pivot points for all my rotating assets, and doing all of that- in my testing the maximum achievable length is ~116m(Give or take very little, 1 meter at most) end to end... which disqualifies a vast number of naval assets from this initiative, sad to say.

Edited July 17, 2019 by BlowSUp
F7

[Fenix Eldritch]

Personally, I'd not worry about upcalling to compensate for some of SL's oversized avatars. If you're looking to follow a real world scale, go ahead and do just that. In the end, it'll help keep things consistent as you build. And avatars can very easily change their shape to a smaller more realistic scale to explore your build.

Edited July 17, 2019 by Fenix Eldritch

[BlowSUp]

1 hour ago, Fenix Eldritch said:

Reminds me of the old non-pyhsical "Multi-Move" systems. Adding to what Qie said, from what I recall, two things contributed to their caterpillar-like movements: the 0.2 second delay imposed by llSetPos and the ripple effect of communication relays from the "root" linkset if the overall thing was larger than the llShout distance. This is because it would be the "root" that would be sending out commands for the other parts to move themselves - and have some parts echo the commands to linksets outside the root's shout range.

There have since been new LSL functions added for positioning objects that do not have a forced delay. llSetRegionPos is one option, and allows for an overflow of ten meters outside the current region. That should be enough to get the piece to cross the region threshold if it's using relative movements and continue on without much hassle. llSetLinkPrimitiveParamsFast is another option, which you can use to set the position and orientation all at once, through I'm not immediately sure how well it would perform for crossing regions boundaries. It's probably fine, but I can't say off the top of my head for sure.

Regarding the actual communication, llRegionSay is very handy as it allows you to broadcast on a channel to everything in the current region. But as the name implies, it's got a hard limit of only being able to reach anything within the same region. This would pose problems for crossing region borders. For that, you might be stuck using a chat relay system still - as least as far as I'm aware.

Edit: Also, even if you had everything communicating and operating in perfect synchronization, you still might get some hiccups due to the overall status of the region's health. Multi-Move solutions were notoriously resource heavy, with each linkset having multiple scripts - likely to try to get around the 0.2 second delay. Now that we don't need to resort to that, things might be a little better on that front.

This is very good news, exactly what I was wondering about. Much obliged.

I can have a quick raw mesh built to scale, pumped out and imported in-world in short order. Minus textures and LODs, with a bit of math to make sure I have the right number of linksets I should be grand to go-

But now we come to the issue of being an intermediate programmer with LSL, and that only a number of years ago when I was more active.

May I ask, if you or anyone reading this, knows of a reliable resource to start from- for basic Multi-Move movement?

Additionally, out of curiosity- would it be redundant to consider physicalizing each linkset? Weights and limits pending that is. Large train of thought on that but the gist is that, given the likelihood of encountering external forces(read running aground, collisions, etc), and sim crossing wizardry on the hull segments/linksets they, at least occasionally, ought to run a check to make sure they are appropriately aligned with the root set/rest of the ship and then make any necessary adjustments in position/rotation accordingly. In that regard they are being securely held or hard-moved in 3d space every once in a while by the script rather than being "left" to the forces/simulations at play(as a sub-115m vessel might, and likely for me will, be). This would seem somewhat redundant in the same way allowing a Remote Controlled boat to float under the influence of its own forces and those of the water it is in- but then deciding every 10 seconds or so "Actually I'll grab you and move you over here, come to think about it".

Still. Saves a lot of scripting, not to have to simulate buoyancy, gravity, all that, no? I notice you've said "old non-phys" to boot, so I'm not sure if this was implied or.

Edited July 17, 2019 by BlowSUp
Because a second read always gives a fresh outlook.

[BlowSUp]

8 minutes ago, Fenix Eldritch said:

Personally, I'd not worry about upcalling to compensate for some of SL's oversized avatars. If you're looking to follow a real world scale, go ahead and do just that. In the end, it'll help keep things consistent as you build. And avatars can very easily change their shape to a smaller more realistic scale to explore your build.

Fair point, cheers.

I think at present, I'm going to build to scale, a smaller testbed(Fast Attack Craft, Patrol Boat, hell a RHIB)- but import two final versions. The to-scale, and the TBD ~30% ish bumped up one. Then take a stroll about them myself, invite some friends- note how many times heads hit what, and so on. Whether the size feels appropriately visceral, all that.

Will make a call from there I reckon.

Edited July 17, 2019 by BlowSUp
Revision

[Fenix Eldritch]

6 minutes ago, BlowSUp said:

would it be redundant to consider physicalizing each linkset?

If by "physicalizing" you mean turning on physics status for each linkset, then yes, I would strongly advise against that. Trying to move multiple linksets as one unit is hard enough, but if you try to do that while they have physics enabled, it would be worse than herding cats on speed.

When I referred to the old method as non-physical, that was only in regards to not using the phyiscs engine as most traditional single linkset vehicles do. The objects themselves are still solid and in the case of mesh, would still have a physics shape for you to walk around on. But they would not use the physics status. Scripted positioning would be how they move and how they maintain their relative positioning.

While this does mean the parts would easily move through most objects, you could create a simplistic form of collision detection with llCastRay to check for approaching obstacles and have that affect the craft's ability to proceed.

[BlowSUp]

10 hours ago, Fenix Eldritch said:

, it would be worse than herding cats on speed.

Hah what in the hell, where ever did you hear that expression 🤣

Noted on the physics though, thankya. I get the impression I may want to consider enabling physics(read setting in-world; not custom hitbox) for the root linkset though, yeah?

Any thoughts on where to start, in regards to writing some code to test those newer functions with multi-linkset movement and all that? Could hash up something but I'm trying to keep focused on making sure I nail the 3D creative side of things, and tackle the particular LSL hurdles later. Maybe hire a coder? Hm

[Fenix Eldritch]

Heh, I chose that expression deliberately because that's what I felt the result of using physics enabled linksets would probably look like. Allow me to back track a bit to further illustrate my reasoning. And I feel I should point out that these are just my own observations. Don't take what I say as the final word - I'm just one point of view.

Physical objects/vehicles are able to make updates to their position/orientation in a much faster and smoother way when compared to the other LSL functions. They can be acted upon by outside forces like gravity, friction, collisions, or internal (scripted) forces like impulses and motors. This all happens very "naturally" and the user doesn't need to get bogged down in the gory details thanks to the physics engine doing that heavy lifting. For example, the user doesn't have to worry about scripting the vehicle to angle up as it rolls over an obstacle, it will naturally do that. This is all well and good for typical applications like an independent self contained object. But when you want to make multiple objects move in tandem, then the physics engine starts working against you...

Because you effectively have multiple vehicles flying in extremely tight formation. Remember, physical objects can just as easily be shoved by outside forces. They can drift. They can get snagged. They can lag. They can be swatted aside by a powerful enough collision which could come form someone taking a potshot at you, or from bumping into another part of the multi-linkset mega object. And when that invariably does happen, you have to detect that and force the errant part back into formation. But since it's physical, it could just as easily disrupt the entire multi-linkset in the process. And then they have to try and get back into formation. You no longer have a set of vehicles flying in formation, you have a swarm - all pushing and shoving against each other to try and get back into place. I suppose you could selectively turn out-of-place parts phantom while they try to get back into formation, but that's not my main point... the point is that you have to constantly monitor and correct the relative positions of every linkset and that gets expensive real fast. Because you're not just using a lot of script resources, you're also impacting the physics engine (phantom objects with physics enable still must be processed by the physics engine). So it's a double whammy to the server.

Even if you just had the "root" linkset physical, you'd still have the issue of it moving much smoother than the other linksets. They would also not be able to update as fast as the root, which could lead to internal collisions as the "root" bumps into the other parts. That could in turn cause the "root" to skew and slide against other parts and thus cause the whole collective to move in odd unpredictable ways as the other parts try to follow the leader. Or, more likely, there would be a massive desynchronization between where the "root" is and where the other linksets think the "root" is.

Lastly, region crossings for physical vehicles is dicey enough (though it has been getting better to be honest) - I can only imagine the chaos of trying to keep multiple physical parts crossing at the same time in formation.

For these reasons, I personally feel that trying to move multiple linksets as one is better fulfilled by sticking to non-physical movement. You avoid so many headaches and uncertainties  and have a near guarantee of where the parts will be and how they will move. I believe it makes the whole endeavor much more manageable at the cost of whatever fluidity of moment physical status may have initially appeared to grant.

Whew. Ok, regarding your other questions, the best place to start would be reading up on the LSL functions from the wiki. Try setting up small proof of concept tests. Start with just getting a "root" to move around under your control via non-physical movement. Once you have that down, move on to working on the follower script and a communication relay between the root and a child linkset. As you go, keep your scope limited to moving within a single region. Only after you've got it working well in that scope should you move on to look at taking region crossing into account.

I did a little googling and actually managed to find the original MultiMove script I was thinking about created by Jesrad Seraph. You can see version 3 in the archives here. There are supposedly newer versions up to v5, but I had trouble actually finding them. These scripts are using the OLD methods and don't utilize the newer LSL functions. But if nothing else, they could give you a starting point on how to approach the equations for calculating offsets of child linksets. Please do not use them as is - only as a reference. They use a number of helper sciprts, but in today's LSL envrionment, you can definitely accomplish the same feat with a single script in each object.

Edit: and if you'd rather not do the scripting, then you can try hiring someone in the Wanted or Inworld Employment forums.

Edited July 18, 2019 by Fenix Eldritch
typos

[Mollymews]

another thing that affects this is where these can be rezzed. Were it to be rezzed on say the Blake Sea for example then there will need to be an avatar sitting on each piece, or parts of the vehicle will be auto-returned

personally I think that this is more trouble than its worth. A linked 108 meters about, is a pretty big ship already

 

[Mollymews]

i gave this some more thought because I was bit naysay before

given the limitations of linking and auto-return then how might we go about building a massively massive boat that a number of people could work together as a team

we could make independent boats vehicle phys enabled of about 108 meters each, one for each avatar/sailor. Then we could design them to interlock when stationary (go non-phys) to make a massive integrated fighting platform. Like if lined up lengthwise then the bows and sterns could visibly change shape to do the interlock.  When a boat withdraws from the fighting platform then the other boats close up the gap, changing shape to suit