Quistess Alpha

Are you sure the issue is with the embedding in a notecard and not the landmarks themselves? If you give the friends the landmarks say, in a folder are the same ones still broken?

FWIW, I usually see this sort of post in the commerce-> wanted section.

I have a pair my alt wears constantly, lemme find a link. . . https://marketplace.secondlife.com/p/EQUAL-Gracie-Kitten-Heels-BLACK/20184249

Hard to say. Funny enough though, in that particular script, it llSetMemoryLimit's to max memory-1 and then to max memory again, which should trigger garbage collection (OTOH, if it's in a lso script. . .) and records the used memory before and after: no difference.

Wildly off-topic, but that sounds like one of its 'canned responses' that it uses when it's asked a question it's not supposed to answer.

I have a set of scripts I've been tracking in different regions that reliably hit 300~800 bytes of free memory, when checked on a weekly basis. (they were designed to have much more free mem than that, it turns out the issue was they were set to lso instead of mono). I'm not the one testing them, but I take it on good faith they fail, but it's rather rare. 1k or more should be safer from 'blue moon failure'.

16k~32k at startup would be my goal as well, usually that's where I end around when I have a large script I actually need to look at memory usage for. 1k is what I would regard as a 'minimum safety buffer' for if/when your scripts are actually using memory. mono can get a bit 'fuzzy' with memory allotment, but I wouldn't toe too close to the line.

It wouldn't be delivered by SL if they followed directions and applied via the (presumably reliable) google form.

the system doesn't take into account 'bytecode memory' I.E. memory taken up by the actual "script" part of the script. If for sake of argument, we say that those 3 scripts are really beefy and take up half of their available space as bytecode, and assuming the wiki is accurate (we residents can't really know anything about back-end implementation directly) then: Avatar 1: .5 meg shared and .5 meg available script memory Avatar 2-3: ditto 12 scripts, 2 megs available memory, 2 megs shared bytecode /4 = .5 'static memory'. 2 + .5 = 2.5 megs total allocated memory. Of course, the actual memory ~used will be strictly lower than that, depending on how much data the scripts need to store in those 2 megs of 'free space'.

I got all of Scandalize's stuff they had for free, a few years back, and it took a good long while to get around to unpacking. I actually, don't like most of their outfits as outfits, but some of the individual pieces are real keepers.

Yes, I believe so. Back when I was working with a race-car group, they used the nearby method to zoom in on drivers (who go very fast and are hard to cam onto) for filming purposes, as unfortunately, there's no good way to set your camera-follow object by script.

In the 'nearby' floater, you can right-click people's names and select 'zoom in'. I find it useful when someone says something from far away. If you know where the person is though, It's not much more convenient than ctrl+alt+click on a person and move the scroll wheel up. *shrug*.

Yeah, my second take was that perhaps there was a mirror hidden a bit out of view, which could have evoked a bit more of a 'self love' theme. Great piece regardless!

Whoever stood you up doesn't know what they're missing!

I was lazy and didn't read the documentation, just went off my intuition from previous experiences. llSLPPF is well, faster (but more annoying to type) than its "legacy" functions. llSetPos(direction); should actually work in a child prim, even if it's not the "best" solution for this use-case.

There are a lot of fundamental issues which demonstrate a lack of fundamental knowledge on how the logic is supposed to work. . . but putting that to the side for a moment, the reason it doesn't move at all is because llSetPos(llGetPos() + direction); doesn't really work for linked prims. fixing only that problem and leaving the rest mostly alone: list gAvWhitelist = ["","",""]; integer toggle = -1; integer toggle2 = -1; move(vector direction) { llOwnerSay("Move! "+(string)direction); integer p = 0; integer n = 10; for (; p < n; ++p) { // this wasn't working, needs to be changed for linked prim: llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_POS_LOCAL, llList2Vector(llGetLinkPrimitiveParams(LINK_THIS,[PRIM_POS_LOCAL]),0) + direction ]); } } default { touch_start(integer total_number) { llOwnerSay("Touch!"); // this part isn't useful: //list Properties = llGetObjectDetails(llGetKey(),[OBJECT_CLICK_ACTION]); //integer Click = llList2Integer(Properties,0); if ( (~llListFindList(gAvWhitelist,[(string)llDetectedKey(0)])) ) { llOwnerSay("Whitelist!"); llPlaySound(llGetInventoryName(INVENTORY_SOUND,0), 1); } //{ // remove non-functional brackets. toggle = ~ toggle; if(toggle) { llSetTimerEvent(1); }else { llSetTimerEvent(0); } //} } timer() { toggle2 = ~ toggle2; llOwnerSay("Timer!"); if(toggle2) move(<0,0,-0.5>); else move(<0,0,0.5>); } }

No. Do not put a RLV relay in anything that is not a dedicated RLV relay, or maybe a collar. Do not put opencollar scripts in an object that is not a collar, without a rigorous understanding of how those scripts will interact if someone is also wearing an opencollar as well as your object. To make a 'RLV item' you have to consider whether the object is intended to be worn by the user, or is rezzed out like a piece of furniture. Worn: For worn items, all you have to do is add 'RLV command' statements to a script, like llOwnerSay("@detach=n"); the RLV API spec can be found here: LSL Protocol/RestrainedLoveAPI - Second Life Wiki . The RLV system usually works on the model of 'restrictions'. You generally add a restriction with llOwnerSay("@restriction:parameter=n") and remove it with llOwnerSay("@restriction:parameter=y"); or llOwnerSay("@clear"); to reset everything your item may have restricted. It's a good idea to play around with the RLV console in your viewer to get a feeling for what each RLV restriction you might want to use does, and to be familiar with other RLV products and what restrictions they use (you can list all RLV restrictions you're under in the RLV menu 'RLV->RLV Status...') Furniture: Furniture is a bit different in that it needs to communicate with a RLV Relay via the RLV Relay Protocol: LSL Protocol/Restrained Love Relay/Specification - Second Life Wiki It's not too complicated on the furniture side, you do not need to implement a RLV relay, just expect the user to have one, or direct them to a free one to use, such as the one I posted a few days ago or the DEM relay It can be a bit challenging getting everything correct on your first try though. It's not as straight forward as it is with a worn item. Everything you need to know is in the spec, but as an example, here's a basic 'RLV Volume' which adds restrictions when someone enters the 'phantom'(llVolumeDetect) object, releases them when they leave, and correctly responds to ping requests from the relay: string restrict= "@tploc=n|@tplm=n|@tplocal=n|@camdistmax:5=n|@fartouch:3=n|@showloc=n|@showminimap=n|@sittp=n"; default { state_entry() { llVolumeDetect(TRUE); llListen(-1812221819,"","","ping,"+(string)llGetKey()+",ping,ping"); } listen(integer Channel, string Name, key ID, string Text) { llSay(-1812221819,"ping,"+(string)llGetOwnerKey(ID)+",!pong"); } collision_start(integer n) { while(~--n) { key ID = llDetectedKey(n); if(ID!=llGetOwner()) { llRegionSayTo(ID,-1812221819,"RLV Volume,"+(string)(ID)+","+restrict); } } } collision_end(integer n) { while(~--n) { key ID = llDetectedKey(n); llRegionSayTo(ID,-1812221819,"RLV Volume,"+(string)(ID)+",!release"); } } } I should also mention AVsitter has some RLV plugins (I don't know where you'd buy them). On the consumer-side of AVsitter+RLV objects, I find them much less desirable than objects that were hand-scripted with RLV in-mind, but it is an option.

if they're all playing the same sound, you probably want to use LlPlaySoundSlave() even though that function is a bit weird.

tl;dr. GACHA was a set of systems that gave you a random item from a set, and then people would re-sell items individually. a bit ago LL banned the systems but the objects from the systems are still allowed, and people can still re-sell them. so, basically anything labeled "gacha" now is just a no-copy item, which you can kindof think of like a 'real' item. the seller can't give you a new one because they didn't make it, and because they only have a limited number of copies to sell.

Have you tried making a 'minimum broken example' to see if that's really the issue? I have a hard time imagining how this could be an issue, but, I haven't tried setting experience keys from temp attachments, and I have no knowledge of the experience database implementation.

Actually this was changed a while back. You are only charged the maximum amount of tier you actually used in a given month. if you downgrade from 8192 to 4096 say, 2 days before your billing date, 2 days later you will pay for the 8192, and then a month after that you'll only pay for the 4096 if you don't get any more land.

Not to mention IIRC, OBJECT_SCRIPT_MEMORY doesn't even accurately represent memory usage, just the maximum memory available after llSetMemoryLimit() is taken into account.

Unfortunately, I think that's basically impossible at the moment. Also, in terms of resource usage, OBJECT_SCRIPT_MEMORY is not a particularly useful metric. IMHO OBJECT_SCRIPT_TIME would be more fair.

Kindof, but not really. you still have that name 'reserved' for you. If you pay the name change fee (again) you can change back to any old name you've had in the past. Calling cards may or may not change to your new name. You will still be friends with your friends, and it will be obvious enough that you're you if your profile doesn't change and you still talk the same etc. If your friends not being suspicious is important to you, you can tell them in advance you plan to change your name so they won't get confused when you do so. If someone searches your old name in the right way, they can link it to your new name, (I changed my name from 'quistessa' to 'quistess alpha'; https://my.secondlife.com/quistessa redirects to my new name) but I don't think there's an easy way to go the other direction. Still, I wouldn't rely on it if you need a clean break from your old self; in that case, you'd be better off making another account (hard to say whether that would be more or less expensive than the name change fee) I don't think there's any indication, but in an abundance of caution, I'd think about it as 'very little' rather than 'zero'. ETA: I have a friend who changed her name twice, the first time she changed her name, my chat logs got stuck together, (my chat log for the new name has all the chat history form the old name) the second time, the chat logs didn't connect (new file for the conversation log). People who have IM'd with you prior to the name change may or may not be able to 'scroll up' and see whatever they were talking about with you last.

Since auto-attach comes up a fair bit and is slightly harder than trivial, but, not too-too hard, there are some free examples out there: