Wulfie Reanimator

I'm looking at my non-stick pan and it doesn't look like either of those... both of those look like they're smooth porcelain. But I can see that one of them definitely looks more shiny, but I can't tell how much of that is because of the sun difference like you said. I'm yet to really look at EEP besides the things I've been hearing on the forum, and consistency is not one of those things.

I'm not a contrarian to what you say, Prokofy. It's not that personal. I didn't respond to like 90% of what you wrote, which I agree with, I only quoted a couple very small bits of what you said because I like trying to correct misconceptions. You weren't the main reason I posted either -- when I originally read your post, I just went "yeah that's about right, moving on..." I sometimes even make the conscious effort to not respond to some of your posts because I don't want to annoy you because you'll be like this, so I can say for a fact that I'm not "always one." Or maybe I'm just being a contrarian yet again. Apparently so. You can get to "Inspect Object" by: Right-click > Object Profile > Details, but it shows no useful info compared to Firestorm. But I did find this instead: Ctrl+Alt+Q to enable the Developer menu (top bar) Select an object Develop > Rendering > Selected Texture Info Basis (Ctrl+Alt+Shift+T) This will give you a popup for each texture on the object and tell you the exact size/face they are on. (The below is the result for my bed, which is a linkset.) It may be showing a popup for the same texture multiple times if it's used in multiple links, but I don't have time to check that right now. It's something at least. And of course, this is on the LL viewer.

If you need right now, shouldn't you be the one offering as high as possible, not haggle? 🤔

Wanting to prevent noobs from littering is no excuse to massively inconvenience long-time users (never mind paying customers in general). Newbies can eventually learn how to use SL. The people who have already been here for years won't be reduced back to "how 2 i rezz?? where mything go?"

Setting physics shape to none isn't a "trick." Having no physics shape means the sim doesn't have to consider the object's components for physics calculations. (Besides the root, which must have a physics shape.) It's an objective benefit and doesn't lower LI unless the object had higher physics weight than download (render) weight. So, if it worked for that object, it was a fixable problem. You can right-click an object and "inspect" it. The inspect window will show you the Texture Memory being used by that object's components, which you can use to estimate what size the textures might be. With a little experience it becomes very easy to tell. Asking "are you sure you removed the scripts," if that really happens, makes me think that the 'matron' is checking the contents of every object by hand, which I wouldn't recommend because it's slow and error-prone. You can right-click on an object and get "Script Info" to instantly get an exact count of all scripts in every component of the object, how much CPU time they're averaging, and how many of them are turned on/off. (I'm pretty sure it's not LL Viewer functionality, but anyway.) Removing lights also seems extreme, they can be turned off in the viewer's settings and have no effect on sim performance.

Perfect.

[insert 3 hour tutorial video explaining only the basics here]

While it's completely valid to feel upset by unsolicited interaction (literally harassment), I don't think there's any practical solution that LL can implement that wouldn't adversely affect normal use and/or break existing content. Invisprims are not a solution to privacy. Anything you rez or attach can be derendered. Any kind of user-made product that's supposed to give you privacy is an illusion that can be broken pretty easily by anyone SL-savvy, the only people they'll protect you from are people who don't spend much time with computers and/or video games. When it comes to attachment interaction (clicking on things), it's the scripter's job to impose a(n optional) limit.

I will report your passive-aggressive and dramatic (since you felt necessary to let them know you're going to report them) response, so ha! Also, it's your not you're. Have a g'day.

Some mesh objects are built poorly. It's a permanent problem for those specific objects. You could possibly work around it by rezzing a prim and placing it over the floor with a transparent texture, so you don't see it.

In the DoF/Glow tab, under "Glow Settings," press the little D button next to all the values. That will set them back to default.

Anything that isn't a mesh surface. If you're on Firestorm, you can type "rezplat" in local chat to rez a prim platform, and use that.

If you are trying to rez onto a mesh surface like a house floor, you may get thst error because the sim can't figure out if there's enough space for the object. Try rezzing somewhere else, for example onto LL ground.

Reset your glow settings in Phototools in your viewer. I can't give more details right now since I can't log in to check.

Even disregarding the yellow arrows and details on the map... There is no case to be made here. The presentation of the map is very different, it was clearly made from scratch (unless the original was full-perm, which I somehow doubt) and there is nothing that protects "ideas." Any "original" idea you have/make can be reproduced by anyone else without issues. The other map even shows a much greater area...

But to be fair, the height slider is not the sole dictator of your avatar's height. Other sliders factor into it too. (Like leg/hip/neck length if I recall.) And there IS a height number on the shape editor, for meters and feet.

Speedlight works on anything with a browser.

Yeah... Case in point. When you have a script that only does some initialization in state_entry before calling llSetTimerEvent and never does anything outside of that timer, you get magnitudes greater performance with a single loop+sleep instead of generating an entirely new event each interval. There are costs you have to pay for events. It's the reason your helicopter can't cope. Same with guns. Often, the gun would send linked messages to rezzer-scripts while firing -- one message per rez, all rezzers are usually in the same prim so it creates n events -- which greatly limits the effective fire rate and you end up with event queues so long you won't stop firing even if you let go of the trigger. A rezzer-script which has an infinite loop, rezzing per iteration, can be controlled exactly by simply turning it on/off with llSetScriptState. No messages, no events, no resets, and it stops firing exactly when it needs to. When I say "infinite loop," I don't mean a loop that just goes as fast as it can forever. You treat it like a timer with a controlled delay. It's a tool no different from your method of reducing events. Only the bytecode is shared for Mono scripts. (Also, non-Mono is LSO, not LSL...) Bytecode is all the constant stuff, variable names, operators, literal values, function names, etc... What data the variables actually hold is entirely independent. One instance could use 1K, while another is doing something that increases it memory usage. Are you sure you're not thinking about CPU time? It's an average of the past up to 30 mins, or since the script reset/rezzed(/teleported), whichever is smaller. It's not that Mono scripted objects rez slower, just that the scripts don't do anything for a while. The biggest benefit of Mono is also its biggest problem -- dynamic memory. When the script is rezzed (or teleports), the sim needs to calculate how much memory of its maximum limit it's actually using. (This is why an avatar entering a sim is basically a performance nuke.) Even the simplest script will take its time, at least with the default limit of 64K. Lowering that limit guarantees the script won't use more than that, or it will crash. I would imagine a lower limit would also make the script initialize faster, but I haven't checked.

Probably something like that on MP. This subforum is for actual scripting advice, you should post into the Wanted section. Doing it from scratch is complicated without an external database. (Even then it's complicated.)

I tend to agree, and although I'm very aware of everything you mentioned, it's good to have it all listed here where some new people can be aware of it. But some of these "defensive techniques" would normally be considered "bad practice" and often invites a lot of "don't do that / do it another way" when you try asking related advice in public. (eg. Infinite loops to avoid event overhead.) The biggest recommendation I would make specifically for weapons and anything that needs to rez fast and/or has a short lifetime: Don't use Mono. Mono takes a long time to initialize even when there's no lag. Never use Mono for "bullets" (any projectile or effect), what ever you do. The "rez early" method is pretty niche and only really works for slow, single-attack weapons. It would not work, for example, for a 600-1000+ RPM gun. In other engines, one optimization you could do is "re-using" bullets, instead of having them be destroyed (llDie) on contact. There would exist some set number of bullets, and the oldest one would be placed at the front of the gun each time it fires. That's not really possible in SL, at least not with the LL Combat System (llSetDamage) and without lots of listen events per avatar.

You're like a perfect sphere. Nothing but edge.

You nailed the point I was making. I understand what your suggestion is. It has some merit but how many presets were you planning on? How high is "tall?" How high is "small?" Do we have 3, 4, 5 presets or more? What's the UI for that gonna look like? And if none of those work (or need further adjusting), then what? I would definitely rather see the debug settings implemented in regular preferences along with the current options. I would be actually shocked if it turned out most people know about Ctrl/Shift + scroll. It's a completely obscure thing you might do by accident without even realizing that's what you did. No, I said applicable. As in, the developers ask themselves "what's the best thing we can do that will work in most cases (that's easy to implement)?" and the answer they've come up is "just move it further back." It 'works' in most situations, short or tall, big or small, one-size-fits-all... but it's not particularly good for any of them. I think we agree on the goal, just not how to get there.

I still can't decide if I should've gone for Rounded Float from the previous batch... Unfortunately I'm a sucker for gimmick names!

This already exists. See the three little buttons on the top-left of the camera controls? There are three presets. Front-to-back, over-the-shoulder, and the default. Also, you can control your default camera position by holding Ctrl (height) or Shift (angle) and scrolling your mouse while your camera is "resting" (press Esc so it's not focused on anything). Any changes you make this way will stick until you relog. You also adjust the default camera distance without going into debug settings. Defaults can only do so much. With SL being as customizable as it is, no default will work for a lot of people. If you're tall, you get ass-cam. If you're small, you won't even see yourself. (Sometimes I wonder if SL kids just wander around without realizing they could fix their camera...) If you're non-human, all bets are off. The most generally-applicable solution is to have the camera far away with a wide field of view, which is what we have in SL.

That makes more sense. In that case it's not really a new issue, just the same ongoing one (that's why I asked about sim stats). Scripts Run % has been in the gutter for the better part of a year by now. Who knows when/how LL is going to fix it.