Jump to content

BlowSUp

Resident
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

1 Neutral

About BlowSUp

  • Rank
    Member

Recent Profile Visitors

166 profile views
  1. Stellar info here, explains very much an issue I was stumbling into earlier and wondering the root of. Thank you kindly, once again.
  2. Great information Nova, will take it under advisement, thank you.
  3. Hah. 🤣 All good lol, been smashing my head against a wall at this long enough to discover what does and doesn't work. Sorta.
  4. 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.
  5. Good day, Looking for an experienced scriptor to assist with the implementation of a multi-move system(Multiple, separate linksets moving as one). The target criterion are rather strict. Movement must appear fluid, singular. Not segmented as older examples may be. I have acquired MultiMove v5.1 and updated all functions to the newest standards possible, trimmed down Listener scripts and script load on the server- and still there is a delay from the other linksets in tracking and following the root's movements. My objective is minimizing, or visually eliminating, this delay. Please only consider this if you have a solution you are ready to present as a final product, or are confident fluidity matching or exceeding the above standards can be achieved. Wiling to pay whatever you think fair, for your time. -Z
  6. 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.
  7. BlowSUp

    Multimove v5.1

    Heyo all, Trying to track down the v5.0 (or later?) versions of Multimove to use as a reference for a modernized script of mine I'm working on. Cheeers!
  8. Will do, cheers!
  9. 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
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. 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
  15. I basically need a scripter who can create a prim that I can rez, and when I click it it fives me an lldialogue box with the names of all avatars within the maximum scan range... 96 meters?
×
×
  • Create New...