Jump to content

Wulfie Reanimator

  • Posts

  • Joined

  • Last visited

Everything posted by Wulfie Reanimator

  1. There is a distinct difference in the way LSO and Mono scripts are handled. LSO scripts will always take up 16KB memory.. even if there are no variables or events. They are always allocated the full 16KB of memory. Mono scripts have dynamic memory. While the maximum memory capacity is 64KB, the script will only take up a fraction of that in most cases. This is significant when a script needs to be transferred from one sim to the next. To do that, the current sim needs to figure out the current size of a script so that it can be stored for transfer (don't forget bytecode sharing, heap/stack memory). For LSO scripts, it's very easy since they're always guaranteed to be exactly 16KB. The destination sim suffers even more since they have to receive that information, allocate the space, and then initialize those scripts. Mono scripts are very slow to initialize and start up compared to LSO and it can be easily observed in your day-to-day interaction with scripts. No, there are quite a few things that are memory intensive without doing any long-term storage. HTTP requests, large llSetLinkPrimitiveParamsFast calls, multiple raycasts (I'm sure @animats's NPCs would benefit from more memory), general data processing, etc.
  2. Almost certainly, due to the process of how scripts are transferred between sims (and why LSO scripts are much faster than Mono scripts for that).
  3. Possible solution: Current and future scripts stay 64KB by default, but llSetMemoryLimit can be used to increase the size up to some new maximum, such as 128KB. (Seems like a safe increase as a first experiment, and we'll be able to know when scripts might be using more memory than normal.) This way, most scripters won't be using any more memory than usual. I'm all for increasing memory capacity somehow (I wish KVP wasn't Premium), but what I'd be concerned about is "what if something does go wrong?" And I don't mean things like bugs, I mean long-term real use-cases. If it does start causing significant degradation of sim performance across the grid and LL is unwilling or unable to improve their hardware with Amazon, going back to 64KB is equivalent to pulling out a barbed arrow. It's gonna hurt more coming out than going in.
  4. As someone who does not currently host a web server, I'm gonna go out on a limb and say any LSL script connecting to your server will look like that. All regions are hosted on Amazon now.
  5. A simple way to implement arbitrarily large integers (google that) is to store them in a list, then calculate/display them as strings. For example, the largest number you will deal with is 1 billion. If you need to display a number like 4.2 billion, you have a list of [200'000'000, 4] and you build a string such that it reads "4'200'000'000" or "4.2 B" or whatever format you wish (I recommend separators for all our sanity). And if you get into even bigger numbers, your list could simply grow like [200'000'000, 999'999'999, 6] to create "6'999'999'999'200'000'000" or "6.9 Quint" or whatever. If you're fluent in Java, here's an example implementation: https://gist.github.com/rgb-24bit/931e45660d8826fce2053c943d0b2c99 If you're not fluent in Java but have general programming knowledge, that's still a workable example of how to implement the basic stuff like add/dec/mul and building a string. Edit: I gave the reverse-order example because of the example code, but if you can store the numbers in the correct order instead, you can simply typecast the list to string to get the full number readout.
  6. First things first: The "size" of a script is just the maximum capacity that script could take. It doesn't mean the script is actively using that much. There's no way to measure the actual usage as an outside observer. By default, a script's maximum capacity is 64 KB. This can be lowered (but not increased), though people don't bother doing that 99% of the time. The total size of 848 KB suggests that there are more than 5 scripts on you, too. And yes, all scripts in all of your attachments will "activate" as soon as you log in, and stay active until you log out, detach them, or disable them (which generally isn't possible if they're no-modify). That said, here's a good way to think about it: "Does this script do something useful for me? Am I going to be resizing this object regularly?" If the answer is no, you should remove it (after making a copy). All scripts -- even those that are doing literally nothing -- take up resources on the sim you're in. It's not catastrophic, especially in your situation, but having 100+ scripts is quite awful. The worst part about scripts happens when you move from one sim to the next, whether that's teleporting or by crossing a sim border. When that happens, both sims need to do a lot of work to transfer your scripts from one to the other, which causes the sim you're arriving at to lag (in every aspect) very noticeably to everyone. The more scripts you have, the worse it gets, so having few scripts on your avatar makes your teleports faster! Personally I aim to stick below 30-40 scripts, but that can be challenging depending on what you're wearing, like most mesh bodies/heads and their clothing alphas. That's why I make an effort to only buy anything from creators who still let you have modify permissions, rather than wearing an ankle bracelet with four HUD scripts in it.
  7. A mono script can use 64k and a LSL script can use 16k - the 2 statements are not possible. The correct terms are Mono and LSO. They are both LSL, which stands for "Linden Scripting Language." Also, while Mono scripts have four times the memory capacity, things also take up about four times as much memory. You can assign an empty list (stats = [];) to your list of stats to remove them from memory. There are also functions like llDeleteSubList to remove parts of a list.
  8. It won't really work the way you'd generally want, because of how alpha-masking is rendered compared to alpha-blending. This is very apparent if you've ever seen a texture with lots of transparent holes in it, such as lace/fishnet clothing. The further you zoom out, the smaller those holes get, and eventually the texture appears completely solid. I can't put it into simple terms, but I believe it's just a byproduct of how the texture is sampled for rendering. Smaller area on screen means less precise alpha checking. For example, alpha masking: Compared with alpha blending: But I digress. One major difference between transparent texture vs 100% transparency is that transparent textures can still display materials. Here's a fully transparent texture with a blank (80 gloss, 255 environment) specular/shiny map on it: I think this is very relevant when we're talking about glass.
  9. They have two bodies. One body with a head already attached to it, and then a second "normal" (headless) body. They've hidden all but the head of the first body, so that they can use the second one with the head from the first one. The problem is that the first body changes the bones of the avatar's skeleton. The solution is to use an (un)deformer after wearing the first body. It can be difficult to find/create one, depending on how crazy the body is. You'll probably want to ask the creator for one.
  10. Can you show what this "cracking" looks like? It might be because you're resizing the object with the "edit linked" option enabled, possibly with Ctrl + Shift held while resizing. This would resize the individual parts of the linkset, rather than the whole linkset.
  11. I'm not a huge camera person, but probably the most important aspect of composing two different shots together is focal length, or the field of view. The RL camera you're using indoors will most likely not match the focal length of the default SL camera. You should be able to press Alt P to bring up Phototools in your viewer to tweak the relevant settings, or adjust your RL camera. There's a bunch of things beyond that (like lighting, depth of field, the tracking, etc.), but I don't want to get into those right now. Hopefully someone else can.
  12. That style of head is more unique than any of the furry heads currently on market. Since the head is closer to man than animal, your best bet (for accuracy) would be to just find a masculine human male head, hope you can squish (or replace) the nose, add some whiskers, and get some custom textures done for it.
  13. As long as your mesh body is using the Left Arm/Leg BOM channel, you can do asymmetric tattoos no problem. That was one of the biggest features of the Universal Layer / avatar bakes update.
  14. I seem a bit confused. The original script does work as-is. Assuming that the channel is -1, if you type "/-1 Firstname Lastname1", the script will set the texture. Maybe there's some detail @Altier Verwood is misunderstanding? For example, if they want to be able to type "/-1 FirstName Lastname 1", the only change needed is a space before the 1: if (msg == name + " 1") P.S. When you redefine a variable, it "hides" the previous one and you no longer have access to it. In this case, the values will be identical so the name variable is totally redundant, it can be removed without breaking the logic.
  15. I can't think of any breakage that would result from being able to read longer lines than before, as long as the scripts and the notecards stay the same.* * Unless, like @Quistess Alpha pointed out, the notecard already contained lines longer than 255 bytes and relied on not being able to read more than that... which I think must be very very niche. I would vote yes for it. And while we're at it, I wish for being able to read multiple lines in one call. (Lines returned as a list, without the ending newline.) C-strings 😉
  16. Sensors have a maximum limit of 16 closest objects they can detect. Also, the way your repeating sensor is set up, it will always use the same radius. The radius will not change if x or y are changed after state_entry. (Also, the result of VecMag will be very large because REZPOS has Z over 1000. Sensors have a max limit of 96.) What is the context of this script? Why are you trying to check the position before rezzing on it?
  17. For a 'regular sofa,' you need to pay attention to more than just the lowest LOD. For example, I made this intentionally unoptimized (30K tris) mesh with autogenerated LODs... ...with the lowest LOD like this (14 tris), the Download Cost is still 20.9 for a 3x1x1.3 object. Even if it was a single tri, it wouldn't get respectably lower (if at all). The scale of the object affects how much influence each of the LOD levels have on the download cost. This is why you should build your models to-scale for SL, so you can get more accurate estimates in the uploader for faster iterations. The basket you're comparing to is much smaller than a sofa, so it benefits a lot more from zeroing out the low/lowest LODs because they have much greater influence than the higher ones. (Because the object is small, the low/lowest LODs are expected to be most visible...) Since you're working on a larger object, zeroing out Lowest, or even Low LOD won't be enough to solve your LI problems. For the kinds of scales we're probably talking about, you need to spread your focus across each LOD. Only very large or very small objects are "simple" to solve, since you generally only need to focus on High or Lowest. One good thing about auto-generated LODs is that you can use them to figure out what your triangle budget should be to get the LI you want. In my case, zeroing out Low/Lowest would get me 20-4 LI, depending on what I do with the Medium LOD. Optimizing my High LOD to 7.5k tris (intentionally high again) gets me to 2 LI with auto-generated LODs. This already gives me a very good idea of what my budgets should be. I can now create custom LODs such that my Medium and Low levels match the given triangle counts. I could go even lower to hit that 1 LI without ruining the model.
  18. You don't have access to object-inventory descriptions from LSL. You would have to use the name. Related wiki page: http://wiki.secondlife.com/wiki/Category:LSL_Inventory Basically, you would loop through all of the inventory items, check their names (possibly with llGetSubString), sum those values, then finally set the object's description with llSetText.
  19. Do you have examples of your own work and the LODs that are giving you trouble? Are you sure your LI cost is caused by the LODs, or maybe the physics? Also, what size is the object you're having trouble with? Different scale objects require different LOD budgets if you're going for LI.
  20. All object-change related events are listed here, which is to say, no event triggers when the description is changed. You'd have to use a timer or some other mechanism (touch, for example) for the script to check the description.
  21. Your screenshot is showing a physics weight of 0.360 for the Base Hull. That would be the weight if you left the Physics Shape Type at the default Convex Hull in the Features tab of the Edit floater. The arch would be closed. When the Physics Shape Type is changed to Prim (archway open) then the weight would be equal to the Mesh value of 2.178 as indicated in the little Physics panel of the uploader window. Thanks for pointing that out! Also thanks for linking those threads. I'm familiar with other things he's investigated, so I know they will be an interesting read.
  22. So far there is only one preprocessor, and it's the one in Firestorm. For now it *is* the standard. The Preprocessor simply replaces text with other text before the script is finally compiled. It's all just sleight-of-hand with plain LSL. The code above converts into this: list lazy_list_set(list L, integer i, list v) { while (llGetListLength(L) < i) L = L + 0; return llListReplaceList(L, v, i, i); } // ... list items; items=lazy_list_set(items,0,[1]); items=lazy_list_set(items,1,["second"]); llOwnerSay(llList2CSV(items)); integer num = llList2Integer(items,0); string str = llList2String(items,1); llOwnerSay(llList2CSV([num, str])); From that you might be able to tell what happens in your test-case. There is no error, the list simply extends (with zero-values) up to the given index. Both versions of the code are immediately accessible, the in-viewer script editor has a second tab for the post-processed code (which is also what you'll see if you don't have the Preprocessor enabled). Here's what the full script looks like.
  23. Firestorm's LSL Preprocessor tries to give you this ability. list items; items[0] = 1; items[1] = "second"; llOwnerSay(llList2CSV(items)); integer num = (integer)items[0]; string str = (string)items[1]; llOwnerSay(llList2CSV([num, str]));
  24. I'm familiar with Vim, unfortunately!
  • Create New...