Phate Shepherd

I don't want to force a specific location for the HUD, I just wanted the default not to be the hand. This is in a builders tool where I am trying to automate as much as possible. As for your tangent, that is exactly what I did in my pose tool. It only defaults the position if it detects you have picked a new attachment point. otherwise it leaves position and scale alone.

Is it possible to set the default attach point of a linkset via a script? Digging through LLSLPP, I don't see anything. I want the user to be able to drop a script into a basic cube, and the attach point get set to one of the HUD positions. If I weren't starting out with a raw prim, I'd just wear it to set it, but can't do that in this case. I don't want the script to attach the linkset to the user during the configure process.

Wait.... first we get the option to remove alphas from image uploads that don't need them, and now we get a fix for brace indention? Someone is actually fixing stuff from "r/MildyInfuriating"?

I agree, store names can be misleading.... I guess I'm just old and don't like change!

Some time back, marketplace changes were made, and for a brief amount of time you couldn't search for store names in the main search. It appears that bug is back. For example, if you search for Dust Bunny, it doesn't turn up any of that stores products. Of course you can search the Merchants/Stores tab, but not the main tab.

And grid status updates a minute after I can't login 😉

If you have ever had to deal with BVH files, those routines would be VERY useful. BVH files can use arbitrary rotation orders, and these routines are something I had to ask for help with many years back... and that was just for a single variation of rot to a specific order. Thanks for pointing out the LL reverse order and the check routines that also show a better way to construct a rot from arbitrarily ordered Eulers! BTW, is it LL is using a reverse order, or is it that evaluation order is right to left?

Belated response.... I can tell you one provider NOT to use. Fatcow.com. They firewalled many of the SL regions prior to the uplift to the cloud, and it always took an hour on chat to get them removed (and I had a typed up script to say to them with all the details.) They have since been bought up by one of the big name hosting services and it is no better.

I might give it a try, just to see what the final freemem looks like. Would be nice to have the speed back. Edit: Unfortunately, as Mollymews suggested, it didn't work in Mono. I would have thought that construct would have pulled off a post parse nulling of the body, but it didn't. I guess I shouldn't be surprised since a similar construct is used to detect which VM you are using on the LSL_Hacks page.

OK, the problem has been solved. Thanks to all that made suggestions. It was crashing in the http_request event handler. In the end, it did turn out to be the http response was JUST big enough to trip up the script at login. I made the response just a tiny bit bigger, and it crashed with a stack-heap collision every time, not just at login. Why it only happened at login with the original http body is still a mystery, but apparently it was just a few bytes shy of crashing anyway. Originally, the http response body was parsed into a list with llParseString2List(body, ["\n"], []), and those lines parsed and appended to sublists. This meant that the full body text, the parsed body and the resulting sublists were all in memory at the same time. I experimented with 2 ways to get rid of the list of lines. The first was to search for a linefeed, and just parse the body from 0 to the linefeed. Then use llDeleteSubString to chop off that bit from the body and repeat until the body was empty. That worked, but it was dog slow. The final method was to implement a sliding window on the body text. Essentially a form of llGetSubStringIndex, but with start and end character indexes. So I just moved my window through the body line by line, and never needed more than 256 characters for the resulting sliding window string. With those changes, I can now parse a full 16k http body and still have plenty of memory left over. It isn't as fast as parsing the body into lines with llParseString2List, but the penalty is worth it.

I do have HTTP_BODY_MAXLENGTH set. I believe that should do it?

That is probably a better alternative that logging out and in over and over. I can't get it to repeat on demand. I suspect it may take logging in to a region that has been empty for a long time. I thought I read that it takes a while before a region goes into a semi-sleep state and that may contribute to script misbehavior when a region is in this state. If that is the case, then using your idea and wandering around mainland going from empty sim to empty sim might be the closest I can get to replicating a login. Thanks for your replies. In this case, the link messages are pretty short, under 1k and it is the sender that is crashing not the receiver. At the moment, it is really looking like the list handling is at fault. I was waiting to make sure the HTTP received data was valid before clearing the existing list and re-populating it (Not any sort of list growing out of control issue.) I may have to accept that simply getting an http 200 response is sufficient for valid data, and clear the list before parsing the http data and repopulating the global list.

Yes, it is a worn hud. The script that is doing a stack heap does a lot of list manipulation when attached... and therefore also at login. Thing is, it never throws the error when attached from inventory. The only event handlers in it are state_entry, link_message, http_response and changed. It is the on_rez event in another script that triggers the HTTP get in the one that crashes. I'm going to have to keep increasing the size of the http response to see if I am just close to a memory limit, or if it is really a script startup issue at login.

I'm at a loss... it only happens on login. I hear you about using a script injector to fix dead scripts. I've done that on a mission critical object. Is there any way to force garbage collection in a script to see true free memory? The llGetFreeMemory wiki says "amount of free memory available to the script prior to garbage collection being run." OK... I want to know what the freemem post garbage collection is. Not sure what the point of knowing what it is prior. I do find it amusing that just adding an llOwnerSay freemem line in my script stopped the stack heap crash on login. I guess it is time to see if LlScriptProfiler is useful in this case.

Has anything changed recently as far as LSL goes? A product that has been running stable for months is now throwing stack heap collision on login. Is does pull http data from outworld, but the size of that data has not changed...

I agree. The issue was I was having a really tough time putting into words exactly what I wanted it to do. When I tried on BB, I think I just created even more confusion. Seeing the various solutions helped me to grasp better how to go about it, but it still doesn't help with my limited math vocab to explain what I was going for. So it wasn't so much trying random things until it works, it was more about seeing different ways to approach the problem that I was then able to attack it. In the end, I realized that what I wanted was a rotation that pointed in the same direction on the XY plane as the up vector if the object is tilted at all. If the object is not tilted, then I use the rotation of the forward vector on the XY plane. (Z is zeroed out in all rotated vectors used).

Ooops... thanks. Edited it. I'm still playing around with it. My use case is a little odd and in the end it is a bit overkill to worry about... but hey, we like a challenge. Looking over everyones solutions, I started to mess around with yet another way to do what I want. rotation heading; vector t = <1, 0, 0>; vector v1 = <1, 0, 0> * llGetRootRotation(); vector v2 = <0, 0, -1> * llGetRootRotation(); if (llVecDist(<v2.x, v2.y, 0>, ZERO_VECTOR) < .1) heading = llRotBetween(t, <v1.x, v1.y, 0>); else heading = llRotBetween(t, <v2.x, v2.y, 0>); Now I have to look at the jira to see if that will blow up.

I had asked on Builders Brewery and after thinking nobody was around I posted here... and then Lucia and Xan offered their solutions too.... Xan vector pos = llGetPos(); vector tgt = pos + <1, 0, 0> * llGetRot(); rotation heading = llRotBetween(<1.0, 0.0, 0.0>, llVecNorm(<tgt.x - pos.x, tgt.y - pos.y, 0>)); // I then used the heading to set the rotation of the child prim by subtracting the root rot: heading / llGetRootRot() Lucia integer link = llGetLinkNumber(); vector r2f = llRot2Fwd(llGetRot()); llSetLinkPrimitiveParamsFast(link,[PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,llAtan2(r2f.y,r2f.x)>) / llList2Rot([llGetRootRotation(),ZERO_ROTATION],link < 2)]); Now I'm off to see how Quistess's works. Thanks all!

I recall seeing this asked before, but I can't find it again. I'm trying to get just the z rotation of an object that is in any given orientation. Imagine a prim avatar that could be in any orientation, I want to be able to have a prim that always faces forward, ignoring the avatars tilt forward/back, or twist side to side. I tried the obvious of: vector rot = llRot2Euler(llGetRot()); rotation just_z = llEuler2Rot(<0 ,0, rot.z>); But that only sort of works, and if I recall, that was one of the methods tried in the other post that I can't find. I'm figuring there is some llRot2Forward stuff involved, but I am just drawing a blank.

Yeah... About that... Family member doesn't have premium. Thanks for giving us hope that it can be recovered!

Has anyone run across an issue when rezzing a coalesced group resulting in the group getting returned to inventory silently, but in the debug log there is this: WARNING: LLInventoryModel::accountForUpdate : Accounting failed for '(Name of folder that the grouped item resides in)' version:2 due to mismatched descendent count: server == 1, viewer == 0 I'm helping a family member, and we have tried on a different computer, as well as using the LL viewer. They don't have aditi access, so we can't try there. The group contains lots of no-copy items they really want to get back. There is plenty of LI available, and the error doesn't suggest an LI issue anyway. Is there anything we can try, or is this only fixable by submitting a ticket?

I know this is an old thread, but I just fought with this. In my case, I had renamed all the objects and meshes in blender with LOD in the name, and after that, SL lost its mind and wouldn't upload them. i suspect there is some system of naming that lets you save your DAEs to have all LODs embedded in one file, but I have no idea what that naming system is. So for now, I just stripped out all mention of LOD in my object/mesh names in Blender, and manually load each LOD in the uploader.

Very true. I do have to think about scripts that reset themselves and now crash without any new user intervention because of the change. I think it comes down to this: Does extending the functionality of the existing function provide any benefit to existing scripts in the wild? If not, and a recompile will be needed to take advantage of the new functionality, then there is no penalty and ultimate compatibility in using a new function call.

The biggest issue I see with using the existing function: Any script that relies on NC line lengths <256 chars could stack-heap with longer lines. The last thing you want is a long line causing a stack-heap collision because the script that is running close to the memory wall and suddenly reads a longer than expected line and POOF.... dead. Honestly, any function that has the potential to read 64k in one shot without user controlled constraints is fraught with potential problems. NC's are frequently used for end-user configuration, and what might have once been reas as a truncated paragraph could now be a super long line read by a script that simply doesn't have the memory left to deal with it.

I have a few personal NC reader scripts that interpret a 255 length string as a line that most likely couldn't be read to completion, and mark it as an error in reading the NC. So, I can imagine there may be a few scripts out there that may be confused by lines >= 255 besides just the potential for script overflow. I lean toward Quistess's or Wulfie's proposal for a new function call to play it safe.