Jump to content

Qie Niangao

  • Posts

  • Joined

  • Last visited

Posts posted by Qie Niangao

  1. 13 hours ago, Isobeast said:

    The plan was this: the avatar clicks on the prim, and if the group matches, then the avatar has, say, ten seconds to sit down. if the group does not match, then there is no way to sit. and then I realized that the avatar can also sit with the right mouse button ... and then I got stuck.

    Is it important to the scenario that there be two separate actions here, the touch and then the sit? If it's just as good for touch to automatically seat group members, there's a handy function llSitOnLink() that could go in a touch-related event handler, conditionalized on llDetectedGroup(), and with seating on the object itself limited by PRIM_SCRIPTED_SIT_ONLY.

    (Incidentally, in addition to llDetectedGroup(), similar functionality is offered by llSameGroup() inside function or events (such as changed) where Detected functions aren't available. It's also possible to test for different groups, but that's tangential even to this tangent.)

    [EDIT: Of course I meant to mention that llSitOnLink() is an Experience-based function, so that limits its applicability unless every group member is sure to belong to the venue's Experience. Even without that, or if the two separate actions are necessary, the PRIM_SCRIPTED_SIT_ONLY could reduce confusion for non-group members: They touch and nothing happens, but group members enable seating. There still should to be a test in CHANGED_LINK in case a non-group member sneaks in between when the group member touches and when they sit.]

    • Thanks 1
  2. On 10/25/2021 at 7:07 PM, Coffee Pancake said:

    Function are allocated in 512b blocks

    How LSL memory is allocated in Mono is a mystery to me. Here's a dopey sample script to play with:

    //string GLOBAL_VARIABLE;
    fun() {}
        touch_start(integer total_number)
            state dead; 
    state dead

    Yeah, it doesn't do anything so the function and state definitions might get optimized-out in some cases, but that doesn't seem to be where the weirdness arises.

    1. As shown, it'll report 3364 bytes memory used.
    2. Comment out the function definition, the state definition, the state invocation, even the whole touch_start event handler: still 3364 bytes used, so maybe that's just the floor for a script.
    3. With all that commented out, add the GLOBAL_VARIABLE definition: 3386 bytes, up by 22, so that's plausible.
    4. Back to the original version with the GLOBAL_VARIABLE commented out, but this time with the function call enabled: 3876, up by 512 from original.
    5. Put back the GLOBAL_VARIABLE definition: 3898, adding back those 22 bytes again
    6. Comment-out the function call so the script is back to where it was at step 3, but the memory reported is still 3898.
    • Thanks 1
  3. Yeah. Sure it's more efficient to use preprocessor directives (and we might do that with our favorite IDE even if it's not the Firestorm thing) I think about the most we could hope to suggest to posters is one level of indirection from good ol' llOwnerSay(), just a function call, something like the Dout @Profaitchikenz Haikusuggests, so there's just that one function definition to change to turn debugging on or off, route output to a different channel, send it to email, etc.

    For those with programming experience, we could suggest something like "verbose", either a debug "level" or a bitfield to select individual debugging flags, but if they're that sophisticated they'll have already adopted their favorite method with no prompting from any of us.

    • Like 2
  4. 24 minutes ago, Dourden Blindside said:

    So far scripts i read are usually just a sequence of event handlers without anything semantic in it.

    LSL is an event-driven language. Event handlers are the semantics; everything else is syntactic sugar.

    Functions are expensive, as @Coffee Pancake says, but not nearly as expensive as running multiple scripts. As long as a script is resident in a rezzed object it uses sim memory; if it's explicitly stopped, it will keep using memory (although it will annoyingly lose state values if the region restarts while the script is stopped), but it will go off the scheduler queue, so that reduces sim lag on script-bound regions—until it gets started again, which incurs a bunch of overhead, so it's a bad idea to stop a script unless it'll be idle for some time. And again, each running script incurs some overhead whether it has anything to do or not, and linked_message communication between scripts is (even) slower than function calls.

    Generally suppress any consideration of "parallel processing" with multiple scripts. Scripts in the same region run in a single scheduled thread; multiple scripts may "cheat" so each gets a chance at reaching the front of that queue per simulation frame, but that's only rarely worth the communications overhead. Some built-in function delays, however, are still practical to defeat using multiple service scripts.

    Scripts that use states can almost always be made more efficient by replacing the states with a global variable and some conditionals. The main exception is, as @LoneWolfiNTjsays, if different events have different relevance to the script part of the time, so segregating those handlers to a separate state can make sense (and, in the case of touch-related handlers, manage the appearance of the mouse cursor). They can also be handy for closing a bunch of open listens all at once, or for state_entry / state_exit clean-up.

    • Like 2
    • Thanks 1
  5. The parcel audio stream can be set by a script owned by the same account that owns the land. (That means on group-owned land, the script needs to be in a group-deeded object.)

    Then it's up to the script to get stream links from wherever it's handy in the application. If, for example, literally anybody should be able to set the stream to anything at all, the script could take input from llTextBox() perhaps in a touch_start() event handler, then maybe llEscapeURL() of the response string it gets in listen(), and llSetParcelMusicURL() with that tidied-up string.

    Another common scenario is for the stream-changing script, owned by the landowner, to communicate with "remote control" scripted objects owned by tenants; there are surely commercial products that do this, and maybe some open source scripts.

    • Like 1
    • Thanks 1
  6. 3 hours ago, Mollymews said:

    i got this error today on Linden Viewer Second Life Release (64bit)

    Not sure what to test here. That station URL worked fine as parcel audio for me, running that same Linden viewer. I could try it on MoaP but it also works pasted into Chrome and Edge (Firefox not installed now) so I must be missing the point.

  7. 4 hours ago, Coffee Pancake said:

    This is an unmitigated PR disaster.

    Yeah. But I'm confused what real role Linden Lab / Second Life has in any of this, other than a little branding and a blog post. I mean, is the Lab vouching for the unique authenticity of Epik's Zenescope-linked NFTs? If not, then what value does LL add—and what liability does it incur? Seems much ado about multi-layer nothing.

  8. Besides the 10% tier bonus, group-deeded land also permits finer-grained control of permissions you can grant other group members to do stuff on the land. Much of the "Abilities" that can be set for different "Roles" of a group are about those land-related permissions.

    In practice, this can be useful for running a group-operated venue, or for renting out Mainland parcels, each with their own unique land ownership group, to give the tenants almost as much control of their rental as they can have on an Estate.

    • Like 1
  9. 11 hours ago, Silent Mistwalker said:

    My old tower has a GTX 1050 OC 4GB the CPU is an AMD 3.2 GHz and I never had any issues with SL. So you have to wait a few seconds for everything to load fully. That's not LL's fault. 

    Right, but it's really not the user's machine, either, nor the network connection. Texture downloads take longer the bigger the textures being downloaded, even for the fastest hardware on the fattest pipes.

    Yes, one big texture beats many little textures (especially after download, when rendering) but there's still a problem that many SL textures are way higher resolution than they'd be if designed by the Central Committee of SL Graphics Excellence, long may she wave.

    And in lieu of that Committee, the proposal is an economic incentive to only spend pixels where they matter.

    Would it work? Probably, but would it work well enough to justify all the development and drama? I'm dubious.

    But would it constrain creativity? Meh. Does Land Impact accounting constrain creativity? Sure does. And it's the nature of the medium now. If texture-upload economics were tweaked, it wouldn't affect the medium as much as the raised LI limits or last tier pricing change.

    But if it actually changed anything, I'd be interested to see how creative SL artists would take advantage of the proposed lower fees on very small textures. Wouldn't you?

  10. 1 hour ago, Profaitchikenz Haiku said:

    But not for clothing items where you would need Bake on Mesh?

    No, I think that's the same texture-picker, or at least I use local textures all the time for testing alpha masks to use in BoM.

    There are some other uses of textures that I'm not sure about, purely scripted applications such as particle systems for example. There may be a way to reference the un-uploaded local texture by its temporary UUID, hence making it available for script use, but I've never tried to figure that out. On the other hand, textures only ever referenced by UUID can be snuck into SL for free permanently through the web interface to Profiles, as long as it's okay to have it as a profile pic for a while. I guess that little loophole might close when the viewer loses web profiles altogether (which might also b0rk all the creepy greeting boards that ask to use your picture on a poster of most recent customers).

  11. On 10/18/2021 at 1:36 PM, Ayeleeon said:

    There are several Sims dedicated to art, full of art galleries run by SL artists. I doubt all of these would continue if suddenly it cost 64L to upload a 1024x1024 texture, that already is reducing the resolution of the original quite a bit.

    If the fate of SL art truly depends on whether a texture upload costs a nickel or a quarter, it's doomed and best to put it out of its misery already.

    (Also, IMHO, SL art would be vastly improved if it weren't so focused on 2D textures anyway. Sure, there are accomplished SL image artists, but in general the genre so underappreciates the medium.)

    That said, I have no idea if the proposal would have the desired effect. Certainly there are plenty of occasions where a 1024x1024 image is simply needed, and certainly there are many more where it's a complete waste of download bandwidth (whatever it does to rendering, which seems much less a problem than everybody fusses about: un-downloaded textures render fast enough, but it's not very satisfying).

    Someone mentioned the beta grid being inaccessible for a long time, which was indeed annoying, but for the purposes of testing textures there's almost always an option of using local textures without any upload cost—nor delay: after it's incorporated in a practiced workflow, it's both faster and more convenient to use local session textures.

    On 10/18/2021 at 5:03 PM, Katherine Heartsong said:

    And as an aside, the textures I upload for my artworks are 1024x683 (as all my work is done is a 3:2 format for SL). I spend a lot of time on my original works getting the textures right, I don't want them pixelated.

    I found this confusing. All SL textures are converted on upload to power-of-two resolutions, so a 1024x683 image will be stored at 1024x1024. I'm not sure now if the original aspect ratio is stored with the texture when the uploader performs the conversion; that might make this worth doing even though I'm skeptical that uploader scaling is as good as the several options offered by Gimp.

  12. One thing to try, if you haven't already, is to get yourself a copy of a known working auto-attach-rezzer (e.g., that free "Donut Plate" I tried to link in an earlier post*) and see if it works on the parcel.

    Another option would be to test using a copy of one of the ones that are NOT working on that current parcel, placed instead on another parcel that has the AVsitter Experience enabled and working (and allows Build with some reasonable auto-return).

    Or, if the product has a demo at the creator's store, maybe try at that location to make sure the items are working properly there.

    * I see now that something ate my URI, so there's no way to see what I was rambling-on about. The "Donut Plate" is at http://maps.secondlife.com/secondlife/Bay City - Dennis/131/240/25 and there, as at all my locations, everything is free of charge. It also has a couple hundred prims to spare so for now I set a reasonable auto-return interval for short tests of other objects.

    • Thanks 1
  13. 12 minutes ago, So Whimsy said:

    The creator of the script must be Code Violet or it won't work.

    Yes of course; hence I noted that the [AV]object script "must have been compiled with the Experience" but there's no restriction on redistributing that pre-compiled script, and as a practical matter, every auto-attaching object comes with a redistributable copy of that pre-compiled script.

    [ETA: Technically, the script creator needn't be Code Violet, but it must have been compiled by somebody enrolled as a contributor to the "AVsitter" Experience in order to work with that Experience. So in theory, anyone could write a script and have Code Violet or another AVsitter developer compile it to that Experience. It's also worth noting that the exact same code can be used by anybody to compile scripts that auto-attach as part of their own Experience. That's not as handy in most use-cases because many folks have already enabled the AVsitter Experience for use elsewhere on the grid, but in settings that have their own Experiences anyway, it may be preferable to use a venue-specific Experience instead.]

    • Thanks 1
  14. I'm not seeing any restriction on redistributing full perm* the Experience-enabled version of AVsitter, and certainly for your own use you are free to copy any AVsitter scripts that perform auto-attach from one product to another. There's only the one script, [AV]object that goes in the to-be-attached object itself, that must have been compiled with the Experience in order for auto-attach to work.

    A product creator, on the other hand, may well want to have the paid-for version, for the support and to support further development. (I have a copy myself, although I don't create products for sale.)

    [ETA: This in-world viewer URI links to a sample "Donut Plate" object that, on touch, rezzes an auto-attaching donut; the plate itself is free, too, as a simple example of using the AVsitter Experience.]


    *It kinda must be distributed with both copy and transfer permissions, in order for it to be used inside props that are transferred to sitters on furniture that is itself transferred. I think there are "slam bit" tricks that a creator might use to give that prop more restrictive permissions once rezzed, but that's a very involved process and I don't recall seeing it being required for use of AVsitter.

    • Thanks 1
  15. Meh. The GUI for Linux is a combination of stackexchange, askubuntu, and a sudo-run emacs browsing the system configuration directories.

    And it's all exactly as clumsy as Windows system administration—for example, try getting filesharing set up correctly and securely in either environment; then try again in a week to fix what you did wrong, and repeat until the next system update when it all may change but you'll only know when it breaks (if you're lucky), your machine is attacked, or you read all the security bulletins. (But you can't read all the security bulletins because there's not enough time in the day, never mind having time to do anything else.)

    Never scratch the surface. It's all dragons down there.

    • Like 1
  16. It's fine to use llAvatarOnSitTarget if a sit target was set for the scripted link (or llAvatarOnLinkSitTarget for a different link from the one that contains the script) but of course avatars can also sit on objects with no sit target set. Either way, they'll be included as links at the end of the object's linkset, so keys for every avatar seated on the object are available with llGetLinkKey() counting back from llGetNumberOfPrims() until you reach a link that's not an avatar—i.e., one that reports ZERO_VECTOR as llGetAgentSize().

    (In passing, a user can generate touch-related events for click-to-sit objects using the right-click menu.)

  17. Ah, I understand now. Not sure this would be acceptable, but something that might "work" would be to abandon physics altogether and resort to a non-physical vehicle script instead. No idea if that's what the armored combat vehicles use, but they probably could get by without the intuitive responsiveness of physics—and back in pre-mesh days, could contain many more prims than the 32 limit of physical linksets.

  18. 15 hours ago, AnitaLaDodyx said:

    And again, I'm using avsitter to override the vehicle sit position.  But either way, even if I was using the vehicle's "sit", the issue is the avatar's hitbox pushing the car off the ground once it turns physical (as shown in the pics).  The sit target/position won't matter if the animation's hip height is too low once placed in position.  

    AVsitter is fine for this (although it's kinda script-heavy to be adding to an actual vehicle, which should have the absolute fewest scripts possible). But I think there may still be some confusion here. It doesn't matter where the animated avatar appears; all that matters is where the agent's "hitbox" ends up. So the animations should push the avatar far below the agent's origin, so when it appears down in the seat the agent is still far above and out of the way.

    Temporarily, in place of "drive" animations, groundsit anims should have much the same effect. Or, even more temporaily, the sitting position for a normal non-ground sit anim can be adjusted (as in AVpos) to perch on the roof of the car, just to make sure the problem really is collision with agent physics.

  • Create New...