Multimove v5.1

[BlowSUp]

Good day everyone,

Hoping to ask if anyone has any links to the above mentioned Multimove script. I've been able to track down v3.0 in the archives:

http://forums-archive.secondlife.com/54/7c/94178/1.html

But despite many mentions of v5.1, v.5 being released, et cetera- any links bounce back to the stock marketplace page or fail to load. I can't actually find, or purchase, the code for those versions.

 

Any suggestions?

Thanks

[Rolig Loon]

The best way to find out, I imagine, would be to post in the Wanted forum.  The person who wrote that script is long gone. Anyone posting in this forum now is a scripter looking for ways to improve her/his own script, or to share insights and questions with other scripters.  We're not likely to know about what has happened with someone else's work, but perhaps someone who still has it in inventory might see a post in Wanted.  Give it a shot.

Edited July 21, 2019 by Rolig Loon
typos. as always.

[BlowSUp]

10 minutes ago, Rolig Loon said:

The best way to find out, I imagine, would be to post in the Wanted forum.  The person who wrote that script is long gone. Anyone posing in this forum now is a scripter looking for ways to improve her/his own script, or to share insights and questions with other scripters.  We're not likely to know about what has happened with someone else's work, but perhaps someone who still has it in inventory might see a post in Wanted.  Give it a shot.

Will do, cheers!

[Innula Zenovka]

20 hours ago, BlowSUp said:

Good day everyone,

Hoping to ask if anyone has any links to the above mentioned Multimove script. I've been able to track down v3.0 in the archives:

http://forums-archive.secondlife.com/54/7c/94178/1.html

But despite many mentions of v5.1, v.5 being released, et cetera- any links bounce back to the stock marketplace page or fail to load. I can't actually find, or purchase, the code for those versions.

 

Any suggestions?

Thanks

Passed you a copy of 5.1 inworld.

However, I probably wouldn't use it myself, since it was written as a work-around for a problem that can frequently now more readily be solved by using functions we didn't have back then, such as llSetKeyFramedMotion, and by setting the prim physics shape to none where appropriate.   Both of those help avoid the restrictions that used to be imposed on physical movement.

I don't say it's necessarily outdated but I would now definitely think twice about using those scripts since there are now much better tools available as part of LSL than there were back when the Multimove scripts were written.

Edited July 22, 2019 by Innula Zenovka

[BlowSUp]

22 hours ago, Innula Zenovka said:

Passed you a copy of 5.1 inworld.

However, I probably wouldn't use it myself, since it was written as a work-around for a problem that can frequently now more readily be solved by using functions we didn't have back then, such as llSetKeyFramedMotion, and by setting the prim physics shape to none where appropriate.   Both of those help avoid the restrictions that used to be imposed on physical movement.

I don't say it's necessarily outdated but I would now definitely think twice about using those scripts since there are now much better tools available as part of LSL than there were back when the Multimove scripts were written.

Definitely, will do. And thank you again for passing this along.

My intent is to understand how Multi-Move worked, at some point, identify dated functions/procedures- then update them with modern tools accordingly. I had thought about doing it from scratch, but I think as old as these tools may be, better to start from them and figure where I can improve, than dream up a way to do it all on my own. Will see the truth of it soon enough.

[Wulfie Reanimator]

On 7/22/2019 at 3:55 PM, Innula Zenovka said:

Passed you a copy of 5.1 inworld.

However, I probably wouldn't use it myself, since it was written as a work-around for a problem that can frequently now more readily be solved by using functions we didn't have back then, such as llSetKeyFramedMotion, and by setting the prim physics shape to none where appropriate.   Both of those help avoid the restrictions that used to be imposed on physical movement.

I don't say it's necessarily outdated but I would now definitely think twice about using those scripts since there are now much better tools available as part of LSL than there were back when the Multimove scripts were written.

I'm slightly confused. Having read the "3.0" version, there don't seem to be any functions used that have since then be superseded besides llShout by llRegionSay. Maybe PRIM_POSITION of llSetLinkPrimitiveParams by llSetRegionPos too, but the default timer is very frequent and over 10 meter changes should be unlikely.

There are no "restrictions imposed on physical movement" at all though. As it is/was, the prims will completely ignore walls and such. Switching to llSetKeyFramedMotion would just break the vehicle horribly while each section tries to physically move to a new spot while being able to be blocked by walls (but not blocking rotation of the "root" linkset).

The main thing that may have made the multi-move system slightly obsolete is the linkability changes, allowing for bigger linksets.

[BlowSUp]

2 hours ago, Wulfie Reanimator said:

I'm slightly confused. Having read the "3.0" version, there don't seem to be any functions used that have since then be superseded besides llShout by llRegionSay. Maybe PRIM_POSITION of llSetLinkPrimitiveParams by llSetRegionPos too, but the default timer is very frequent and over 10 meter changes should be unlikely.

There are no "restrictions imposed on physical movement" at all though. As it is/was, the prims will completely ignore walls and such. Switching to llSetKeyFramedMotion would just break the vehicle horribly while each section tries to physically move to a new spot while being able to be blocked by walls (but not blocking rotation of the "root" linkset).

The main thing that may have made the multi-move system slightly obsolete is the linkability changes, allowing for bigger linksets.

RegionSay may(did not test for this reason) fail on region crossings, as communication is limited to the current region. If you've piloted multi-move systems of old you may recall the tendency for child linksets to "stack up" on the sim border, until the root crossed into the new region. llRegionSay appears to guarantee those linksets will never cross over, as the root cannot communicate to them across the border(theory). No interest in being bound to one sim, especially given the implied size of this project, and all that. llShout and RegionSay use the same energy, have the same delay(none), sofar as I can tell hold the same weight to them. As none of my assets are greater than 100m from each other, Shout suffices, with the benefit of working cross-sim.

SetLinkPrimParams has a forced delay of .2s

This contributes heavily to the caterpillar like effect seen in prior builds. This function was updated with llSetLinkPrimitiveParamsFast. 

Edited July 23, 2019 by BlowSUp
Spelling

[Wulfie Reanimator]

1 minute ago, BlowSUp said:

RegionSay may(did not test for this reason) fail on region crossings. No interest in being bound to one sim, especially given the implied size of this project, and all that. llShout and RegionSay use the same energy, have the same delay(none), sofar as I can tell hold the same weight to them. As none of my assets are greater than 100m from each other, Shout suffices, with the benefit of working cross-sim.

SetLinkPrimParams has a forced delay of .2s

This contributes heavily to the caterpillar like effect seen in prior builds. This function was updated with llSetLinkPrimitiveParamsFast. 

Ah yes, I didn't think of region crossings.

I also misread llSetPrimitiveParams AND misspelled llSetLinkPrimitiveParamsFast, I've blocked out the delayed ones' existence out of my head. 😂  You're correct there too.

[BlowSUp]

2 minutes ago, Wulfie Reanimator said:

I've blocked out the delayed ones' existence out of my head. 😂 

Hah. 🤣

All good lol, been smashing my head against a wall at this long enough to discover what does and doesn't work. Sorta.

Edited July 23, 2019 by BlowSUp
Editing.

[Nova Convair]

1 hour ago, BlowSUp said:

llSetKeyFramedMotion

Some remarks:

llRegionSay can not be used if you want to cross a region border - llShout will do - but some math required for the crossing like usage of global coordinates.

llSetRegionPos is too slow by my observations and inaccurate - but may be handy in case your vehicle got desintegrated and scattered over the place

llSetLinkPrimitiveParamsFast can be executed up to 45 times per second - but - waste of resources since you will never see it. The sim does not update your viewer 45 times per second. That depends on object size, your distance, how busy the sim is. Under good conditions you seem to get max 15.

A script can send 1000 messages per second but a listen event receives usually less than 15 messages. If the sim is busy - less or much less. You will need more than one receiver script.

llSetKeyFramedMotion has perfect movement for that purpose but no way to sync it between the objects. Maybe needs some testing though.

llGetObjectDetails is useable for region crossings (reaches 34m into adjacent regions according to wiki) and has no delay. Could be a candidate. Maybe needs some testing.

Smooth movement is only possible with a combination of server side movement plus viewer side interpolation and that works only for physical objects and llSetKeyFramedMotion and both are not useable here. So it will always rattle a bit. In case script execution is NOT at 100% only a part of the scripts is executed in every frame. You can imagine what that means.

[BlowSUp]

57 minutes ago, Nova Convair said:

Smooth movement is only possible with a combination of server side movement plus viewer side interpolation and that works only for physical objects and llSetKeyFramedMotion and both are not useable here. So it will always rattle a bit. In case script execution is NOT at 100% only a part of the scripts is executed in every frame. You can imagine what that means.

Great information Nova, will take it under advisement, thank you.

[BlowSUp]

1 hour ago, Nova Convair said:

llSetLinkPrimitiveParamsFast can be executed up to 45 times per second - but - waste of resources since you will never see it. The sim does not update your viewer 45 times per second. That depends on object size, your distance, how busy the sim is. Under good conditions you seem to get max 15.

A script can send 1000 messages per second but a listen event receives usually less than 15 messages. If the sim is busy - less or much less. You will need more than one receiver script.

Stellar info here, explains very much an issue I was stumbling into earlier and wondering the root of. Thank you kindly, once again.

Edited July 23, 2019 by BlowSUp
F7

[Wulfie Reanimator]

1 hour ago, Nova Convair said:

A script can send 1000 messages per second but a listen event receives usually less than 15 messages. If the sim is busy - less or much less. You will need more than one receiver script.

I can't comment on object update speed, but based on this statement I doubt that you are correct on it either.

Scripts don't have a limit on how many messages they can detect per second, inherently. There is a practical limit based on the event queue, which can hold up to 64 unprocessed events before new ones are discarded, but the event queue is irrelevant for listen events. Each script will poll for new messages from the sim regularly, and generate events for messages it hasn't processed yet. This means that even if the event queue is full and an event is discarded for a new message, that same message will be requested again later.

You can easily test this by using llSay on a loop with another object listening and printing to chat. In a laggy sim (70% of scripts running per frame), my object didn't miss a single message out of 1000 from a loop with no delays. (script 1, script 2)

Edited July 23, 2019 by Wulfie Reanimator

[Nova Convair]

32 minutes ago, Wulfie Reanimator said:

You can easily test this by using llSay on a loop with another object listening and printing to chat. In a laggy sim (70% of scripts running per frame), my object didn't miss a single message out of 1000 from a loop with no delays. (script 1, script 2)

You repeat what i said b4. A script can send about 1000 messages per second. (depends on script usage of course)

And a script can receive 12-15 messages per second. (depends on script usage)

That works because the sim buffers the messages. In this case we don't want buffering - we need to process the messages when they arrive and so we will need at least 2 receiver scripts to have enough receive capacity. (not for 1000! of course - but a stable 15-20 receives)

Edited July 23, 2019 by Nova Convair

[Wulfie Reanimator]

48 minutes ago, Nova Convair said:

You repeat what i said b4. A script can send about 1000 messages per second. (depends on script usage of course)

And a script can receive 12-15 messages per second. (depends on script usage)

That works because the sim buffers the messages. In this case we don't want buffering - we need to process the messages when they arrive and so we will need at least 2 receiver scripts to have enough receive capacity. (not for 1000! of course - but a stable 15-20 receives)

I don't think I was repeating what you said, but I definitely misunderstood the context.

I changed the scripts a little bit (added timing restrictions) and went to a near-empty sim with 100% scripts running. Sender manages about 590-690 messages in one second, receiver gets 16-23 messages (15 or less very rarely), depending on if I wait a few seconds between resetting the script/loop. (script 1, script 2)

So yes, receiving chat messages is a lot slower than sending them.

Now, whether or not you need to update at or faster than ~15 times a second (timer of 0.066) is another question.

Edited July 23, 2019 by Wulfie Reanimator

[Innula Zenovka]

On 7/23/2019 at 3:46 PM, Wulfie Reanimator said:

I'm slightly confused. Having read the "3.0" version, there don't seem to be any functions used that have since then be superseded besides llShout by llRegionSay. Maybe PRIM_POSITION of llSetLinkPrimitiveParams by llSetRegionPos too, but the default timer is very frequent and over 10 meter changes should be unlikely.

There are no "restrictions imposed on physical movement" at all though. As it is/was, the prims will completely ignore walls and such. Switching to llSetKeyFramedMotion would just break the vehicleIt  horribly while each section tries to physically move to a new spot while being able to be blocked by walls (but not blocking rotation of the "root" linkset).

The main thing that may have made the multi-move system slightly obsolete is the linkability changes, allowing for bigger linksets.

I was thinking primarily of the linkability rules plus llSetLinkPPFast.    I haven't done much with Multimove for a long time, but when I did, it was primarily because I was trying to move a large vehicle (so linkability rules) with more than 32 prims (so physical movement issues, cured by setting appropriate links to PRIM_PHYSICS_NONE.

Probably I'm mistaken, but when I was looking out the copy of Mulitmove I recalled what I'd last used it for and thought that, if I were making a similar vehicle now, I'd probably try to do it with a single script in a large linkset rather than Multimove, at least until I discovered my brilliant idea didn't work as well as I had hoped (admittedly, that all too frequently turns out to be the case).    That's what was behind my note of caution.