Jump to content

Qie Niangao

  • Posts

  • Joined

  • Last visited


5,725 Excellent


  • Member Title

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.
  4. Many SL radios went out of commission a month or so ago when SomaFM started blocking access to all its streams. (That may be irrelevant here, though.)
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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).
  10. 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. 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.
  11. 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.
  12. Maybe if we could figure out the meaning of "profile link of the owner's name". I mean, whatever a profile link is, it's of the owner of what? of the script itself? We must be missing something.
  13. Yeah, I figured, but I think we're all totally at a loss as to what you did mean. Trying to unpack the original post: in what object would this script live, what would it take as input, and what would it generate as output?
  14. The furniture itself would contain [AV]prop (and for the usual attach-on-pose effect, the AVpos notecard would need to have PROP1 lines for the relevant poses); it's the attachable props inside the furniture that must contain the Experience-compiled [AV]object script.
  • Create New...