Jump to content

Sara Nova

Resident
  • Posts

    96
  • Joined

  • Last visited

Posts posted by Sara Nova

  1. Whenever I'm on SL, I'm connected to an access point in the same room as my laptop. And I have a pretty good Internet connection. What could be causing connection quality issues? Do you know of any way to prevent this from occurring?

    Why would it happen with manual edits? Aren't those applied immediately by the client, without waiting for an update from the server? Or do you mean then it's later updated, and you find that not all your edits went through?

    And yes, I know the second SLPPF could have the same problem. But it at least minimizes the chance of it occurring, as odds are at least one of them will work, and if the colors are similar enough, it doesn't really matter which one.

     

  2. 6 hours ago, Cinos Field said:

    Indeed there's nothing wrong with doing what you want with your own items. Purchasing something automatically includes the right to take it apart to whatever degree you wish. (and SL-specifically, though not legally - as long as doing so doesn't violate the "no modify" permission.)

    Any potential ethical dilemmas come from how you use the knowledge you've gained, but curiosity itself should never be shamed.

    What I mean is everything that a ToS-compliant viewer allows me to do with the item, plus everything allowed by the LSL architecture combined with that item's scripts.

    Here's an example I thought of that might not be obvious.

    Let's say I have an item that I want to apply my own textures to, but the item is no modify. It does come with a HUD to apply textures to it, but by design, it doesn't let me use my own textures, just the ones that came with it. If I were to figure out, through trial and error, how the HUD communicates with the item, and get it to accept my own UUID, then I'm in the clear, right? Even if I need to exploit a bug in the script? In other words, my understanding is that the burden is on the creator to ensure their scripts only do what they intend. Is that correct?

    In fact, that gives me an interesting idea. I don't have any plans to do this—not that I'd have any moral issues with doing it—but what if the creator sold other textures for the product using the same applier system, and they enjoyed a monopoly on it because only they know how to get the appliers to work. What if I figured it out, and then started selling my own compatible appliers that compete with the ones the creator put out? To be clear, I don't mean ripping off the creator's textures; I mean making my own textures that are entirely my work. Am I correct in assuming that would be allowed?

  3. Usually this happens when I'm changing large numbers of prims at once, e.g. with LINK_SET in a large linkset. Like I'll change the color, but a few of the prims get stuck on the old color. What's annoying is that calling llSLPPF an additional time with the same color (or whatever parameter) doesn't get the rest of them; I assume from the server's perspective it already changed to that color so it doesn't send an update. What I've found works as a workaround is to change it to an almost-identical but still different color the second time, e.g. 0.99*color.

    Interestingly, sometimes when changing scale in this way, the numbers that appear in the editor dialog update properly, but the actual size doesn't appear to update until I make it update again by changing the numbers and changing them back.

    This only happens when I do it via a script, not with manual edits.

    I know this is a clientside effect, as it'll catch up if I teleport somewhere or relog, and I showed someone else just now to test and she said it looked correct for her. I am using Firestorm; I don't know whether she is though or if that has anything to do with it. Also I've been getting a message saying my HUD uses a lot of texture memory; is that known to cause the issue I described? Or is there something else that's known to cause it?

    Thanks.

  4. On 2/9/2020 at 5:53 PM, Arduenn Schwartzman said:

    You could break a lot of content in SL with the answer. That's why I always change to another random channel every 'now and then'.

    I don't doubt that. :) I like experimenting with stuff.

    15 hours ago, Pussycat Catnap said:

    It sounds like you're trying to hack applier systems...

    I didn't specifically have that in mind, but if I can, then sure, why not?

    15 hours ago, Pussycat Catnap said:

    But actually cracking somebody's applier system also sounds like a direct line to getting in trouble with the service...

    What service? Second Life? Would that be against the ToS?

    15 hours ago, Pussycat Catnap said:

    And if your goal is to crack into some other system - you've even less legitimate reasons... as most other things that would be using hidden channels will be communicating less public knowledge...

    How do you know that? One thing I had in mind was exploiting attachments from the same creator that interact with each other, for the purpose of using them in unintended ways. If it's my own attachment, what's illegitimate about that? I can't think of anything "illegitimate" one could do with their attachments unless they're copybotting them or something. My understanding is that if you're the owner of something, then you're allowed to do anything you want with it that's alllowed by the built-in scripting system—not counting things like spamming which you wouldn't be allowed to do even with your own self-created item. Is my understanding incorrect?

  5. I was pleased to hear that they were going to add a way to change your username, as while I know about (and use) the display name feature, this account hasn't been an alt for quite some time, and I'd like to change my actual name to something else.

    Last I heard was in November 2019, the Lindens announced it would be ready by February 2020. Well, it's February 2020 now—has there been any other word?

  6. 1 minute ago, Wulfie Reanimator said:

    I've already helped you as much as I'm going to, I'm not that interested in actually accomplishing what you're trying, I'm just interested in the technical theory.

    That said, you can't just "choose a random number" because you need to pair the other objects somehow. For example, if you have a product and a control HUD, the HUD can't just llFrand(999999999) and use that, because how is the product going to know which number was chosen? At some point, there must be some kind of static or statically-generated channel between the two, and that's what you want to catch.

    That's fine; I was just pointing that out. Though I actually meant choosing a random number beforehand, that no one else knows.

    https://xkcd.com/221/

  7. 2 minutes ago, Wulfie Reanimator said:

    It's only going to take months if you don't try to narrow things down before you begin.

    But what if the creator specifically chose a random 32-bit number cause they don't want people poking around and doing something unintended? What I'm looking for is something that can't be "hidden from" in such a trivial way. If there's something unintended I want to do, that doesn't violate the ToS, then if at all possible I want to be able to do it.

  8. 46 minutes ago, Lucia Nightfire said:

    There is a cap on the number of scripts a region can have.

    There is a cap on the number of scripts an object can have.

    There are restrictions that prevent you from copying mass scripted objects that would hit the region cap.

    It would take over a month of 24/7 non-stop checks with what you can have out at any one time and then resetting or moving on to another range of listens.

    And to listen to what? An applier or something?

    Sounds like a major waste of time.

    The cap for object scripts is 10,000, right? What's the cap for region scripts?

    What are those restrictions specifically?

  9. That's actually what I was thinking I'd do, with the auto-incremented number at the end of the duplicated script name. Thanks though! :)

    So it's 10,000 inventory items per prim, huh? I find that kind of interesting! The fact that it's a power of 10 suggests it was chosen intentionally; if it were a technical limitation it would more likely be a power of 2. I wonder if they ever thought anyone would need that many? I guess it's better to err on the more permissive side.

    If it causes lag, I'd actually say LL deserves at least some of the blame, for making such a resource-intensive, but easily optimizeable, process necessary. Still not an excuse to lag a sim with people who had nothing to do with it, of course. (A sim full of Lindens on the other hand...😜)

    2 hours ago, Lindal Kidd said:

    Hmmm.

    All I will say is,

    "There are some things man was not meant to know."

    Good thing I'm not a man then. ;)

    • Haha 2
  10. I'm well aware that there might not be a good way to do this. I'm simply asking about the best way, however well or poorly it may work. What I currently know:

    • There are 2^32 = 4,294,967,296 channels total. Two of them (0 and DEBUG_CHANNEL) are already visible, so I'll need some way of monitoring 4294967294 channels. (All at once would be ideal, but I wouldn't be surprised if that's not feasible.)
    • A single script can listen to a maximum of 65 channels at once.
    • Hence, listening to all of them simultaneously would require 66,076,419 scripts total.
    • Scripts can be copied en masse within an object using llGiveInventory, but they'll be set to not running by default.
    • Using Firestorm's bulk recompile feature (not sure whether it's in the official viewer) will also set scripts to running as they're recompiled, but the recompilation itself is an unnecessary step that takes too long. There's no "set all scripts to running" feature, but I could probably add one in a custom-compiled viewer. (Might as well submit it upstream as well.)

    What I don't know is how many scripts I can feasibly get running at once, and therefore how many channels I can feasibly scan at once. There's probably some kind of per-prim inventory limit, and I know there's limits for how many prims I can have, single-triangle meshes probably being most efficient. I'm not sure if lag will be an issue, but I can make sure I do it in a sim without anyone else nearby.

    And yes, I'm well aware I can ask the person who wrote the script, and they might just tell me. But even if they're okay with me knowing, I might not be able to reach them. And even if they don't want me to know...well, I'm sorry, but if I buy something, I'm going to do what I want with it, to the maximum extent permitted by the Linden ToS. I know some people here may take issue with that, but I'm not looking for a debate, so please try to keep this on topic—thanks.

  11. Thank you. A few more questions:

    1. How do I copy the weights in Blender?
    2. Does Blender import FBX by default? If not, where can I find a plugin for it?

    Actually, just starting with the standard sizing mesh (i.e. not my exported avatar mesh) gave me the effect I wanted. In case anyone was curious, all I did was move the vertices along their normals to make it appear a bit thicker, and flip the normals on the faces to make it inside-out. Then it gives my avatar a nice outline. (Had to remove it from the head though, or it made my face look really ugly.)

    Thanks again!

  12. So according to the wiki, llShout doesn't have a forced delay. However, in practice it seems to. Strange thing is, llRegionSay doesn't.

    When I run this script, this is the output I get:

    [00:09:26] Object: 0.020564
    [00:09:35] Object: 8.756221
    [00:09:36] Object: 0.555780

    Now the first output is the time it takes to iterate through a list of 500 values when it just gets each value from the list (as a string) and does nothing with it. The second time it also llShouts the value on a negative channel. The third time it llRegionSays it on the same channel. I think it's strange that llShout would have a forced delay when it's not supposed to, and that llRegionSay either doesn't have a forced delay or has a much smaller one.

    What do you think about this?

  13. So from my understanding, llSetPrimitiveParams and llSetLinkPrimitiveParams came first, and delayed the script by 0.2 seconds when called, probably to help prevent lag. Later on, I assume there was some change that made things more efficient, and llSetLinkPrimitiveParamsFast was introduced since the delay was no longer needed. Simply removing the delay from llSetPrimitiveParams and llSetLinkPrimitiveParams wouldn't work, as that would break scripts that were programmed to expect the delay.

    My question is what reason is there to still use llSetPrimitiveParams and llSetLinkPrimitiveParams? Shouldn't these functions be deprecated in favor of llSetLinkPrimitiveParamsFast? If you still want a delay there, you can use llSleep.

    (Come to think of it, why isn't there an llSetPrimitiveParamsFast if there's a regular llSetPrimitiveParams?)

  14. One of my biggest SL pet peeves is items in boxes. Rather than immediately getting my items as would make the most sense, instead I have to rez a box, open the box, copy the items to my inventory, and delete the box. It gets very annoying. Why isn't there a rule saying all items on the marketplace need to just put a folder with the items in your Received Items, rather than a folder with a box with the items? There's no reason this step should be necessary. Your thoughts?

×
×
  • Create New...