[Switching to group owned land, shared object count and avoiding object returns.]

8 minutes ago, Qie Niangao said:

 

This is not guaranteed to work in every case, but sometimes ya get lucky.

 

In short.... pick up a copy of everything first 😉

[Switching to group owned land, shared object count and avoiding object returns.]

16 hours ago, Diablo Lioncourt said:

But if your friends donation stopped and they told you, you'd theoretically have time to make adjustments.

OK, that gives me some anxiety relief, even if it isn't the way I wished it worked.

 

6 hours ago, Qie Niangao said:

Yeah. If these are currently separate parcels owned by the same individual (you), it may be literally impossible to deed them individually to group with their current contents. (Deed an object-heavy parcel first, it won't have enough Land Impact so stuff gets returned. Deed an object-light parcel first, it takes away the spare capacity used by that object-heavy parcel and its stuff still gets returned.) So either lift some objects from the heavy parcel first or (better) link the parcels together before deeding them as a single parcel, which insures it'll all stay owned by a single entity and thereby all share Land Impact capacity throughout.

(It's no problem linking non-adjacent parcels as long as they're in the same region except if the agent doing the linking also has the ability to link any extraneous group parcels they'll drag across to make the link gesture. Then the viewer gets confused about which parcels are involved and fusses about how they all need the same owner to be linked. This can be handled with alts with only specific group land abilities, but it's probably nothing you'll face anyway.)

I was sort of hoping you would reply Qie, as 2 of the parcels in question you might have a hand in... 😉

I had it in my head that mainland couldn't be linked together by anyone but LL.

[Switching to group owned land, shared object count and avoiding object returns.]

I have 4 parcels on the same mainland region. Two of the parcels consume the majority of the total objects used.

Is my assumption correct that all 4 parcels would have to be deeded to the same group to continue to share object count?

I'm not quite sure what "Owner makes contribution with deed" means. Does that mean I have to already donate my land area to the group?

I want it to always pull 3072sqm from me and get the remainder from a group donation from another person. If they should ever not be able to donate, I want it to pull the full 4096 from me. If that happens will it automatically up my land use fee to the next tier? I assume I must be owner of the deed group to ensure that?

I am most concerned with auto-return kicking in during the transition.

[Help finding a log cabin near the water?]

Yeah, I think the only way is concierge atm.

 

[Help finding a log cabin near the water?]

Okay thank you so much!

 

[Help finding a log cabin near the water?]

If they are claimed cabins though that doesn't really help with the luck of the draw of getting one? Or am I missing something? (this is about the Linden home cabins)

[Help finding a log cabin near the water?]

I'm looking for a log cabin home and had found one long ago from someone on here that was ready to abandon their's and was able to therefore help me get ahold of one that had a most perfect location right by the water. Unfortunately I had to release it after many happy months there and I've been trying to get ahold of one again with a location I like but there are not many available to choose from so I keep winding up with ones I'm not interested in the location of. I know it's a real longshot so I'm not expecting any miracles but does anyone just happen to have a log cabin and a good location they are thinking of abandoning anytime soon? Or, does anyone have any tips other than waiting a bit between tries to see if by chance we just happen to draw a better one?

[Setting default attach point with script?]

49 minutes ago, Anna Salyx said:

Quite honestly I don't want a script (or creator) deciding where an object should attach. I find annoying enough that a couple of my HUDS want to revert to a "default" position every time I attach them rather than respecting the location I have moved them to before detach*. I know that's not the scope of the OPs question, but if we had that ability to set attach-points via script I just know in my bones that there's be creators out that would use that power a less than elegant or polite way.

 

==

(*tangent: when make HUDS I'll detect if the HUD point has changed from the last time it was worn and if so will reset the location to a neutral default for that new point since it's going move move around anyway and I don't want it potentially getting lost off the edge of the screen, but after that I don't touch the local position.

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.

[Setting default attach point with script?]

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.

[Curly Braces Indentation]

On 8/19/2023 at 7:27 AM, KT Kingsley said:

For what it's worth, the braces issue has been fixed in the latest Friestorm.

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"?

[Marketplace search regression? Can't search by store name again.]

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

[Marketplace search regression? Can't search by store name again.]

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.

 

[Login failure]

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

[Rotations.]

On 5/18/2022 at 6:24 PM, Quistess Alpha said:

It turns out converting rotations into Euler-vectors in strange orders is non-trivial.

I hope nobody ever has to actually use these for anything serious. . .

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?

 

[HTTP requests from outside stopped working]

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.

[Recent stack heap collisions]

10 hours ago, Quistess Alpha said:

I've seen some older scripts do weird shenanigins like

llParseString2List(body+(body=""), ["\n"], []);

or similar. Does that kind of trick still work?

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.

[Recent stack heap collisions]

16 hours ago, Qie Niangao said:

It would be handy to know which event it's processing when it gets the stack-heap collision. My hunch would be that it happens while handling that login attach, grinding lists, before it even sees the link_message from the other script. If so, the external server logs may reveal that it crashed before even issuing the llHTTPRequest.

I don't know why this would happen only at login, though. I'm not real sold on the idle region awakening theory unless this attachment is interacting with another, unattached script that's been stuck on the idle sim and that does something strange for being starved of processing time. I'm trying to make up a story about some events getting queued during logoff that clutter up the lists to be processed on login attach, but I can't come up with a mechanism for that to happen. (It's just that login is unique for being preceded by logoff.)

For normal purposes, it's the freemem prior to GC that does matter because if the script tries to use more than that, it crashes, it doesn't trigger GC. I suppose it's possible that the llOwnerSay somehow triggered a GC (or perhaps that statement added just enough code memory that something else triggered the GC), but the only way I know to force a GC is with the llSetMemoryLimit gambit described above. It is expensive, but maybe not a big deal if only done on attach. It would be real interesting to know if the problem will ever arise with a GC at the start of attach processing.

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.

[Recent stack heap collisions]

3 hours ago, Jenna Huntsman said:

You may wish to add a "Content-Range" header to your llHTTPRequest to ensure that if the server for whatever reason encounters an error, that it doesn't then send you a large error page (causing the script to crash). Some applications will respond with a 200 status code, even if they were unable to complete the request (instead, sending the user to an error page).

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

[Recent stack heap collisions]

12 hours ago, Profaitchikenz Haiku said:

I wonder if you could play around with CHANGED_REGION to try and make it do the same when you log in as when you attach it from inventory? As far as I know, attach from inventory restores all the saved script details from when you detached it last, but TP-ing (and hence logging in) might not have the same access to stored last state as attach. Just guessing, but I am struggling with similar problems in other Grids when Hypergrid arrival results in attached scripts arriving in a dead state, they only resume operation when detached and re-attached.

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.

 

10 hours ago, animats said:

Look for large messages being sent using llMessageLinked. That function can send any sized message to any and all prims in the linkset, which means  a giant message can blow up anything accepting link_message events.

Suggestion: Make a wearable with a script that listens to link_message events and checks for big ones. Print  sender_num, num, id, and the first part of msg with llOwnerSay(). If that finds something, you've located the problem.

Link messages ought to have some kind of filtering for length or source, but they don't.

Edit: No, can't send link messages between attachments. Has to be something in the same attachment. But I'd still look for something big being sent that way. There's no size limit.

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.

[Recent stack heap collisions]

9 minutes ago, Profaitchikenz Haiku said:

Is the culprit an attachment? All I can think of is that when you log in you effectively enter a region just as if you TP there when already logged in, and so there is an initial region loading as it tries to get all your scripts up and running.

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.

[Recent stack heap collisions]

12 hours ago, Lucia Nightfire said:

I had this happen a few months back after a roll, which was mysteriously rolled back and not much info was given.

The script had been running for months without issue, then repeated stack heaps after the roll, then none again after the rollback.

I had to create a debug channel listener and script pin injection setup to replace the script whenever it borked.

I'm weary that LL is screwing around with script memory or VM memory swapping/handling/priority or garbage collection protocols.

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.

[Recent stack heap collisions]

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...

[Getting the z orientation of an object at any arbitrary rotation]

21 minutes ago, Quistess Alpha said:

I'm still a bit in the dark as what it actually is you're trying to do. Trying a bunch of things and hammering on it until it "looks right" is fine in some cases, and I know I've done just that on occasion, but more often than not, it's more productive to figure out a technically exact definition of what you expect the result to be, perhaps working out some example inputs and expected outputs by hand, before throwing a bunch of different methods at it and seeing what sticks. When you have a specification laid out, it's a lot easier to go back and examine why function X didn't give output Y.

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).

[Getting the z orientation of an object at any arbitrary rotation]

1 hour ago, Lucia Nightfire said:

You have those names reversed, btw. 😉

Xan's was probably better. I pulled my example from an old test object I made and I think my reasoning for not using llRotBetween was due to bugs.

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.

[Getting the z orientation of an object at any arbitrary rotation]

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!