Fenix Eldritch

I don't think that's the case anymore. I recently tested in-world on the official viewer and people nearby (also using the official viewer) didn't report seeing anything sent to DEBUG_CHANNEL from my scripted objects. Wulfie did a similar test with FS and saw the same result. This was mentioned briefly at the server meeting and I don't think anyone commented on it (conversation was deep on something else at the time) : But... I've been having a heck of a time getting it to work. I made a bunch of entries with keys named firstkey01, firstkey02, etc. and am struggling to get anything with a basic regex returned. default { state_entry() { llLinksetDataReset(); llLinksetDataWrite("firstkey01","testdata"); llLinksetDataWrite("firstkey02","testdata"); llLinksetDataWrite("firstkey03","testdata"); llLinksetDataWrite("firstkey04","testdata"); llLinksetDataWrite("secondkey01","testdata"); llLinksetDataWrite("secondkey02","testdata"); llLinksetDataWrite("secondkey03","testdata"); llLinksetDataWrite("secondkey04","testdata"); llOwnerSay("LinksetData stats:\n" +(string)llLinksetDataCountKeys()+" keys used, " +(string)llLinksetDataAvailable()+" bytes available"); //llOwnerSay("result: '"+llList2CSV(llLinksetDataListKeys(0, 10))+"'"); string regex = "/key/g"; llOwnerSay("regex result: '"+llList2CSV(llLinksetDataFindKeys(regex, 0, 10))+"'"); } } Admittedly, I'm not very experienced in regex, but from the online aids I've found, a regex of "/key/g" should find all instances of the string "key" amongst the KVP key names. I've tried other examples, but am always getting an empty result. Am I missing something really basic? (probably)

I opened up a JIRA on the matter and Rider kindly provided some insight as to what is going on under the hood and why it works this way. TLDR: the keys aren't actually ordered internally, they only appear to be because the ListKeys and FindKeys function will do the sorting of the data they return.

Same thing happens if you change regions, or take to inventory and re-rez. BUG-232744

Also, small update on key/value size limits. I'm fairly sure there aren't any at present. So long as you stay within the 64KB store size and don't cause a stack-heap collision, you're seemingly fine. I was able to create a single KVP with either the key or the value at 30k and it worked. I was increasing the test string by 1024 each time and after 30K, I got a stack-heap collision. So I think that's close enough.

Looks like it tries to combine them, but silently drops whatever won't fit. As before, the prim that will become the root gets priority. Interestingly, the combining seems to be done from the end of the data stores resulting in the earlier entries of the other stores getting dropped... here's my setup: two prims, each with a script to create 5 KVPs. Each KVP has a 1 character key and 10k of data prim1 has keys: 1,2,3,4,5 prim2 has keys: 7,8,9,a,b linking them together shows that the resulting data store has keys 1,2,3,4,5,b Of the second prim's data store, only the last entry "b" got added to the new store. ETA: Trying the above again, but with each data store creating one less 10k KVP (so prim1 has keys 1,2,3,4 and prim2 has keys 7,8,9,a. Similar results, the new combined data store will have keys 1,2,3,4,9,a

Oooh, so the functions are live on the beta grid right now. I've been experimenting and here's what I'm seeing so far: The size limits for key and value are pretty large - possibly non existent. I had a key size of 4095 bytes and a value size of 20479 bytes before I moved on to other stuff. Also, the data stores appear to be merged when linking multiple ones together, and all others are cleared when de-linking. Here's my setup for that test: created 3 prims, 2 of which had a script that created a unique KVP. linked all 3 together and found the new data store contained both KVPs from step1 unlinked everything and the old root retained the data store, but the other scripted child prim was empty. ETA: in the case of a key collision when merging two stores together, it looks like the link that will become the root gets priority and it will overwrite any KVPs with duplicate keys.

Would it make sense to also include the link number in the event header for whatever child link raised the event?

This is very exciting news - especially the part about the read/write being synchronous! My guess is that it would be associated with the root: so as long as the linkset's root remains in place, the "data" is maintained. As far as security goes, I suspect there won't be many issues from simply sitting on the object. Because even though the avatar is considered a linked "prim", the avatar itself doesn't contain scripts that could be used to access this data. Worn attachments can't access link stuff for objects the avatar is sitting on (without explicit framework), so I think there is a pretty clear boundary. At most, an attachment would just be able to see its own link data.

I agree. What about applying a quick push to the avatar as it stands? Perhaps that might be close enough to an input to shake the avatar out of that odd state. I recall that being common in the past for guarding against the avatar getting caught in the linkset upon standing...

Not quite the same, but maybe related... I've observed something similar happen a lot with my own walk/run animations when standing up from some objects. In my case, I use llSetAnimationOverride to remotely apply the anim overdrives when I logon so they remain in effect for my session without needing to wear the script. I don't recall what priority they are, but it's definitely higher than the default ones. When standing up from some objects with sit targets defined, I appear to walk or run in place until I actually nudge myself. Standing up from a simple cube prim with llSitTarget(<0.25,0.0,0.5>,ZERO_ROTATION); seems to produce this reliably - but only if I have my walk/run animation overrides in place. Either moving myself with a control input, or tapping the space bar seems to jostle my avatar out of that odd state. Not sure if this is helpful/applicable to your case...

What you describe would be setting the position and/or rotation of a worn attachment multiple times in sequence - basically animating it manually in a loop, or on a repeating timer. Before jumping right to that though, it would be advisable to first spend some time learning the very basics of LSL. The wiki has a load of tutorials you can read through to get an introduction to scripting. These ones in particular would likely be a good place to start: "Getting started with LSL" intro for absolute beginners "A beginner's guide to LSL" another shorter introduction for those new to scripting "LSL 101" a wikibook that goes into much more depth.

That's how it starts out, you have to click it to activate. Remember, this is mostly an illusion... the platform is being made to look like it's sitting on the floor with your avatar on top of that. But in reality, the platform is a carefully positioned attachment that only looks right when the avatar is lifted up slightly to pull the whole thing together. It's also important that this thing always restart when used because it needs to get the most up to date position of the avatar before it tries to set the hover. If it uses an old position, you might get some very unexpected results. For example, suppose you are at a club at 500 meters in the air and use thing thing. The hover height it will use will be 500.4 meters. Now let's say you remove it without turning it off and go to another club at ground level, let's say 25 meters in elevation. If you put the dance platform back on now without resetting it, it will still retain the previous calculated height of 500.4 and will attempt to hover you to that altitude. I didn't provide a full solution, only a basic example that you could expand on. If you want this to be as automated as possible, I suppose you could have the activation and deactivation happen on an attach event, rather than a touch_start.

Ok, so this is meant to be a dance platform wearable for no-rez areas. Like Lucia says, we don't have any functions that can modify an avatar's body hover height property by script. But you may be able to achieve the desired effect to some degree using the initial example I referred to and llSetHoverHeight. Here are my thoughts on what it would entail: Attach the dance box/platform to "Avatar Center" and position it with the base below your feet. This is a special attachment point that is linked to the agent's global position/rotation and doesn't move with any body parts. It will be static no matter what animations are playing. Also, attachments remember the point and position they were last attached to, so once you attach it to the avatar center and position it as desired, it will always go there even if you select "add" next time. Use the llSetHoverHeight example script to make the avatar "hover" up from their current position. The example on the wiki adds 5 meters, but you can experiment to see what looks right. Make it such that the base of your dance box attachment looks to be close the the ground when the avatar is hovering. When an avatar is made to hover this way, it will pay the falling animation. You can override that with a dance animation that has a priority of 3 or higher. Also when in this "hovering" state you are essentially falling - which means if you get bumped or move, you will continue to slowly slide around without stopping. You can counteract this by explicitly setting your velocity to zero. Edit: or by pressing the Space key: that will stop you in place (and cause you to levitate down a little, but the hover of the script will pop you back up once you release the key). Below is a bare-bones proof of concept: //DEMO integer toggle = FALSE; float offset = 0.4; //height above current pos to hover default { state_entry() { llStopHover(); } touch_start(integer total_number) { if(toggle = !toggle) { //turn on vector sPos = llGetPos(); llSetHoverHeight(sPos.z - llGround(ZERO_VECTOR) + offset, FALSE, 0.1); llSetTimerEvent(3.0); } else { //turn off llStopHover(); llSetTimerEvent(0.0); } } timer() { llSetVelocity( ZERO_VECTOR, FALSE ); //counteract any bumps or moves } } Edit: and a picture of the attachment in action. A high priority dance animation is playing over the falling animation. I suppose you could get fancy and actually use llSetAnimationOverride to change the falling down animation to a dance while the attachment is worn (and then clear the override upon detaching the object). Note I've modified the base size to be stretched to meet my feet and the ground. Other users may need to fine tune these positions for the first time.

I guess I misunderstood your intent. What are you trying to achieve here? Provide more context and examples. Because when I read the initial post, my understanding was that you wanted an attachment that causes the avatar to float in the air when worn. The bit about the avatar appearing to float above the attachment seemed like a cosmetic visual that I assumed you would achieve by positioning the attachment appropriately (i.e., below your feet). Is this meant to be some kind of animation override? Like, you could have the attachment play a high priority animation that makes your avatar appear to be higher off the ground than normal and fake the effect of it "hovering" over the attachment by positioning it below your feet. I should point out that when you "add" and object, you are basically wearing it like a hat on your avatar (depending on which attachment point you choose). Since this object is being worn, it moves relative to the avatar and its attachment point - not the other way around. So you have to manually position the attachment to the desired location on your avatar. If you want the avatar to be moved relative to the object, then making it a vehicle as KT suggests might be a better approach...

Yes, there are several ways to accomplish this. llSetHoverHeight will force a physical object to hover at the specified static altitude. The linked page even has an example script you can use and tinker with that largely does what you want from the start. Alternatively, llGroundRepel can be used to make the object hover a set distance above the current terrain (and optionally water) level directly below. Both functions work when in attachments and will apply the hover to the wearing avatar. And for future reference, every forum now has a pinned posting guideline post which gives guidance on acceptable content. To summarize the one for this forum: If you're looking to try writing the script yourself and need advice, this is the place to post. If you're looking for something that already exists, ask in the Wanted forum. If you're looking to hire someone to write the script for you, ask in the Inworld Employment forum.

Since the prim name is the string you are passing to the function, you can simplify that to just: customfunction(llGetLinkName(DetectedLinkNumber(0))); If you want to filter out other non-button linked prims, another approach would be prefixing the button prims' names with a special bit of text to identify them as such. Then in the touch_start event, you would first inspect the name of the clicked prim and see if it contains the special text at the beginning. If it does, strip that out and pass the remainder to the custom function. Something like // name button prims something like "KEYWORD_button1" default { touch_start(integer total_number) { string s = llGetLinkName(llDetectedLinkNumber(0)); integer x = llSubStringIndex(s,"KEYWORD"); if(x==0) { s = llDeleteSubString(s,0,6); //adjust end to encompase whatever keyword you use llOwnerSay("'"+s+"'"); //example output would be "_button1" //customfunction(s); } } }

Halloween seems to be the one holiday I usually decorate for - though it is minimal. The extent of the decoration is a little candy giver at the front door of my workshop. Said giver will randomly dispense a SL-themed pun candy object, or execute a preprogrammed "trick". I need to add more to it...

Just as an fyi, in addition to needing an actual sit target defined for llAvatarOnSitTarget to work, you also need to make sure an avatar is sitting on the object before calling that function - otherwise you'll get a null key as well. It's not exactly clear from the code snippet you posted, but generally speaking it looks like you tried to set up the listen right as the script starts in state_entry. Assuming you're not resetting the script, or switching to a new state after an avatar sits, then when that code runs, it's very likely noone is currently sitting, and thus llAvatarOnSitTarget returns null, giving you an open listen filter.

Ah, that's good to know. I tried this in-world with another user who is on the official viewer (took forever to find one, lol) and they didn't see my messages sent to the debug channel either. So the wiki is out of date in that regard... The following was typed out before Love had made their last post, but I'll keep it here anyway. More severe in what way? Keep in mind that once the throttle engages, any dropped messages still count against the total, so you have to stop the output to let it cool off before starting again. I did a quick in-world test and saw that once I get throttled, if I stop the messaging and wait for about 10 seconds, I can resume it and will see another 200 messages of output (until the throttle re-engages) integer x=0; integer toggle=FALSE; default { timer() { x++; llWhisper(DEBUG_CHANNEL,"beep boop this is a debug message - "+(string)x); } touch_start(integer total_number) { if (toggle = !toggle) { x=0; llOwnerSay("starting - "+(string)x); llSetTimerEvent(0.001); } else { llSetTimerEvent(0.0); llOwnerSay("stopped - "+(string)x); x=0; } } } As another test, I changed the stopped portion to instead drop the timer down to 0.06 seconds, which is just under the 200 per 10 seconds threshold. Once the throttle hits and I drop the rate to the slower interval, I begin to see messages again after about 17 seconds. This lower message rate seems to fly just under the throttle and will go indefinitely. Also, note that the throttle is per owner, so if you have other scripts/objects outputting to the debug channel in the same region, I assume that's going to hit the throttle faster, and make it harder to relax it as well.

Yes it's expected - it is the very first caveat on the llSay function's wiki page. Further down the page in the notes section, it recommends using llOwnerSay as an alternative for debug purposes. Also be aware that the debug channel is not private: anyone nearby will see it in the same script error section. If your object is talking on the debug channel so much it's getting throttled, you're kinda spamming anyone within llSay range. That's another reason why llOwnerSay might be preferable...

llSetTextureAnim works by telling the viewer to silently alter the texture repeats and offsets of a surface automatically. So in all but one edge case, it will override any manual face repeats/offsets. Like Quitess says, you need to design the texture to be compatible with llSetTextureAnim prior to uploading for best results. Otherwise it will be much more difficult to work with. Having said that, depending on what the texture looks like, you may be able to exploit some caveats. For example, changing the slice-end parameters of a prim will vertically "shorten" it without actually altering the texture repeats/offsets. So if the portion of the texture you wish to animate is on the lower area of the face, you might be able to fiddle with those settings to lop off part of the prim to "hide" that area from being seen while the animation it running. (Note this only helps you out with the sides of the prim - the top and bottom faces would need to be hidden entirely) We'd need to see the texture in question to get a better idea.

A while back I made a thrown object that would "stick" to static surfaces on collision. This required grabbing the region coordinates of the collision. I used llCastRay to get both the position and surface normal of the impact site. Initially I had a problem of not reliably getting the coordinates on collision. The script wouldn't be fast enough to stop the physics of the projectile and it would bounce off before being able to fire the ray and record the position. The solution we reached was to perform a series of quick, short range ray casts during the projectile's flight. The idea is that it would be looking ahead of itself to anticipate the upcoming collision and have a much better chance of recording the position.

This looks like an invocation of the Viewer URI namespace. It allows you to construct text hyperlinks that can resolve to various things, like a user's full, display, or legacy name. It can also resolve to a clickable link that when clicked within the viewer, can perform various viewer actions. All of what you experienced can be accomplished with Viewer URI Namespace links: opening the search window with a search term pre-filled in requesting friendship with a target avatar muting a target avatar initiating a voice call with a target avatar offering a teleport request to a target avatar opening the map with a destination pre-filled and more as described on the wiki page. You can do some formatting to put a label on the hyperlink so it looks like an innocuous clickable bit of text, but hovering the mouse over them will show a tooltip that says what it will do (offer friend request, mute, offer tp, etc), or give you a generic "Click to run secondlife:// command". The thing is... as far as I'm aware, you need to actually click on the URI links within the viewer in order for them to do anything. And I don't think it's possible to combine multiple actions into one link. I find it unlikely that all three of you clicked the numerous links to bring up each of those various actions, so I'm guessing there is some kind of bug or exploit happening that can auto trigger URIs as if they were clicked. Perhaps it is related to the crash. Either way, definitely Abuse report it as soon as possible with as much info as you can provide. Also consider filing a bug report on the SL JIRA system.

I think using llApplyImpulse to either augment or counteract an avatar's movement is one way to do it. There's a quick example of doing it to reduce an avatar's speed in this thread. The thing is, it needs to be done from a worn attachment that has taken the avatar's controls and acts on each one as appropriate. The attachment could be scripted to listen for signals emitted from companion objects rezzed in world. So in your scenario, when an avatar collides with an object, that object can send a message to the entity that hit it. Since attachments can hear messages sent to the avatar, it can therefore hear the message and set the speed value to be higher or lower when applying impulses.

With ordinary text, usually one character equals one byte. For fancy unicode characters, the character may take up more than one byte. I'm not sure what encoding the profiles use (UTF-8, UTF-16, etc) but the bottom line is that the 2nd life, 1st life and notes sections have been given considerably more space.