Fenix Eldritch

I gave my copy+paste keys a workout to see what the new profile text limits appear to be. This is what I found: 2nd Life Bio: 65000 bytes 1st Life Bio: 65000 bytes My Notes Tab: 65530 bytes Picks Title: 254 bytes Picks Entry: 1023 bytes Classified Title: 30 bytes Classified Entry: 256 bytes Feed Posting: 1024 characters Feed Comment: 512 characters The feed post/comments are interesting, as pasting regular ascii as well as multi-byte unicode characters like "❤" seemed to yield the same number of characters allowed.

@Da5id Weatherwax sure, but my bringing up the IRL info bit was more to drive home the point that these experiences aren't being created by random griefers and there is some actual accountability in effect. I suspect some folks' inherent distrust of granting a laundry list of permissions might relate to a belief to the contrary. I'm torn, because I do think having an upfront list of what an experience can do is useful, but at the same time I can see how it may seem alarming to users. It's an extremely hard thing to make informative, but concise. I recently visited Welcome Back Island and saw the new F1 floater for the first time. I thought that was interesting. Could something like that be worked into the experience request dialog? Like, have the list of each thing an experience can do be a button itself which when interacted with (or maybe moused over) can expand to reveal a more detailed bit of into on that section?

Correct. However, there are LSL functions you can use which can do things to other prims in the linkset when clicking on any prim. The suggestion about using llSetLinkPrimitiveParamsFast is one way in which you can trigger an action that can affect multiple links on the linkset. For example, rez three or more cubes and link them together. Drop this script into the root. Clicking on any part of the object will pass the touch event to the root (default behavior). The root's script as shown below will react to the touch event, but it can modify all other links in the linkset with ease. integer toggle = FALSE; default { touch_start(integer total_number) { if(toggle = !toggle) { llSetLinkPrimitiveParamsFast(LINK_ALL_OTHERS, [PRIM_SLICE, <0.95, 1.0, 0.0>]); } else { llSetLinkPrimitiveParamsFast(LINK_ALL_OTHERS, [PRIM_SLICE, <0.0, 1.0, 0.0>]); } } }

Definitely. The permissions auto-granted when wearing or sitting on an object persist after detaching, dropping, or standing up. Whereas leaving an experience is guaranteed to revoke all EXP perms. Moreover, experiences are ultimately tied to premium accounts which means Linden Lab has their IRL information. I imagine this makes abuse reports have much more weight to them, as it's a lot less likely for these to be anonymous throw-away accounts. An experience owner has a lot to lose if they decide to go rogue or even allow griefer contributes to their experience, so I presume the default is for them to be extremely careful in that regard. So I'd echo what Quartz said on the previous page about trying to educate new users about EXPs. If nothing else, a short blurb on how they always have the power to forget/block/report an abusive experience, and how that will instantly remove any hold it may have had over them. Knowing this may make them feel more confident about trying it out - if temporarily.

Yes, a script can hear its own llMessageLinked if directed to itself. The wiki page for the function explicitly warns about that. There are a few additional special link constants that are useful for scenarios like that. LINK_ALL_OTHERS would omit the prim containing the current script that issued the llMessageLinked Flag Description LINK_ROOT 1 sends to the root prim in a multi-prim linked set[1] LINK_SET -1 sends to all prims LINK_ALL_OTHERS -2 sends to all other prims LINK_ALL_CHILDREN -3 sends to all children, (everything but the root) LINK_THIS -4 sends to the prim the script is in As for the original question, no it's to possible to trigger touch events in other linked prims like that. If you have modify access to the scripts, it may be possible to edit them to respond to linked messages instead of touchs. Ideally, I would consider replacing the scripts with a single one in the root that can perform the action on all link targets without the need for scripts in the links themselves.

If you are that new to scripting, then you need to take a step back and brush up on the basics. Trying random things or suggestions without understanding how they work is going to make even the simplest of tasks far harder than they need to be. The wiki is a wealth of information and has many tutorials for the taking. I would suggest you read through a couple to get a more solid baseline on scripting in general. These two pages are fairly quick to read through and I think are good introductions: https://wiki.secondlife.com/wiki/Getting_started_with_LSL https://wiki.secondlife.com/wiki/A_Basic_LSL_Tutorial Once you've read through those two pages, try experimenting with just an isolated listen example before returning to your project. Also consider reading the wiki pages for the functions you want to use, as they explain their use thoroughly and provide further examples. I think once you've practiced with that, it will make much more sense. And of of course, do come back if you have more questions. While we're here, I will point out that your receiver script isn't responding to chat spoken by the HUD because you are missing half of the setup required for it. There are two sections of code needed in the receiver script: setting up the listen filter with llListen function. This defines what channel to listen on, what entity (object or avatar) to listen for (either by name, uuid, or both) and finally what explicit message to listen for. If any of the parameters are blank, they are considered "open" and the script will listen to anybody, or for any message. (except the channel, that must always be specified) setting up the listen event. It is in this event where the script will actually do things (like return data) when it "hears" things which fulfill the defined llListen filter. It is similar to how the code you have placed in a touch_start event will run whenever the object is clicked. The receiver you've created thus far is lacking the listen event, so it won't do anything even if it does hear something,. You've also used the llListen function incorrectly. The function itself does not return the data it heard. The function just sets up the script to be able to hear based on what you define in the function parameters. The number it does return is an identifier which can later be used to close that specific listen when or if it is no longer needed (a script can have multiple different listen filters active at once). You can't feed that identifier number into llGetItemName, as it's never going to be compatible. The thing about the listen event is that it doesn't do anything by itself - it's just the area of the script that activates when something is heard. You tell the script what to do upon hearing something by programming code within the listen event. In your case, it would be in the listen event that you receive the message spoken by the HUD, and then decide what to do with that message. Namely, checking if the message is the name of a texture in the receiver's inventory and if so, applying that named texture to the object.

Having a script in each button is considered less than ideal - especially if said scripts are functionally the same. I think it would be preferable to use a single script in the HUD and code it to handle all buttons by itself. This makes it easier to maintain if everything important is going on in one central place. For your scenario, if you want to send a specific message based on what HUD button was clicked, consider this approach: name each HUD button prim as the keyword you wish to send. A simple script in the HUD root would when use functions to determine the link number of the button that was clicked, discover the name of that linked prim button, and then speak that name over the desired channel. This way, you can edit the names of the buttons, or even add/remove buttons entirely without needing to change the code. default { touch_start(integer total_number) { llSay(0, llGetLinkName(llDetectedLinkNumber(0))); //speak the name of the clicked prim } } And as for the receiving object, a single script would be listening for messages from the HUD and react accordingly. To have any script listen for messages, you must define a listening filter with the llListen function. The parameters you supply to it help filter out talk from other objects. In your case, you would specify the channel to listen on, and perhaps the name of the HUD object. Something like: llListen(-67892, "HUD NAME", "", ""); //listen for chat on channel -67892 from objects named "HUD NAME" With -67892 being the channel you used in your first post and "HUD NAME" being whatever name given to your HUD object. The other two parameters, UUID and Message are left blank in this example because the hud's uuid changes each time it's attached from inventory and your are wanting to act on multiple different messages so you don't want to filter out all but one. See the linked wiki page for more information on the function. In addition to setting up the receiving object script's listen filter, you must also have an accompanying listen event - for that is where the code executes when the script hears something. It is similar to how whenever you click an object, the code within the touch_start event will run. This is where you will translate the message transmitted into what action you wish to take. The listen event has its own variables defined that contain information about what triggered that specific event: the channel the message was spoken on, the name of the speaker, the uuid of the speaker, and the message that was spoken. Profaitchikenz's suggestion to send the texture name would greatly simplify the process, as it would be as simple as taking the string the script just heard, checking to see if it's in the object's inventory, and if so, treating it as the texture name. You can use llGetInventoryType to check if the item exists within the object's inventory: the function takes the name of an inventory asset and returns that type it is (represented as a number). If the returned type is INVENTORY_TEXTURE, then you know the named asset exists and can just set that as the texture.

Regarding screen height, 1 meter seems to represent the full height of a viewer's screen - and I believe that includes the menu and toolbars. If you edit-select a HUD, you can scroll the mouse wheel to zoom the HUD view out. There will be a white rectangle that shows the borders of the screen under normal circumstances and a 1m tall prim vertically centered in the view will line up with the bottom, and ever so slightly expand past the top (I'm guessing that being the bit normally covered by the menu bar). Interestingly, a 10 meter tall prim will appear to fully cover the screen's height when the HUD view is edit-zoomed all the way out.

It might be another hidden function, similar to print. Trying to define a variable as that name similarly causes a syntax error.

If I remember correctly, bouncing violently in a corner of the region is what happens when you eject someone off your land and they have no valid nearby spot to be placed in. Such was the case with regions that had no other adjacent connecting regions. Are you certain your script is indeed calling llTeleportAgentHome when it acts upon the target avatar? As an aside, does anyone remember what happens when an avatar doesn't have a home location set? Are they shunted to the nearest "safe" zone? Edit: forgot to add, if this is ongoing, you might want to consider temporarily locking down your land to public access. Or restrict it to avatars with payment info on file. Or set the land to charge an entrance fee.

The problem is that gotWidth and gotHeight are still zero by the time you attempt to construct desiredSize and subsequently call llSetSize(desiredSize). And since 0.01 is the smallest valid size for a prim dimension, that is what it gets forced to in lieu of anything smaller. When you read from a notecard, that data not instantly available - instead it is retrieved in the dataserver event. But that event won't occur until after the current event you're in has finished. In this case, you have to complete state_entry before the dataserver can even have a chance to start. So you would have to only try to set the scale after you have read both values. You could do this by putting the relevant code block inside the else if (query_id == notecardQueryId2){} section. else if (query_id == notecardQueryId2) { gotWidth = (string)data; desiredSize = <String2Float(gotWidth), 0.75, String2Float(gotHeight)>; llOwnerSay((string)desiredSize); //debug check if(1 == 2) { llSleep(1); llSetScale(desiredSize); llSay(0, "Projector Online 1!"); origScale = llGetScale(); origPos = llGetPos(); } else { llSetScale(<8, 0.065, 4.5>); llSay(0, "Projector Online 2!"); origScale = llGetScale(); origPos = llGetPos(); } } Edit: actually, it may be safer to daisy chain the reads as well, calling "notecardQueryId2 = llGetNotecardLine(notecardName, 3);" from inside the "if (query_id == notecardQueryId1)" section as well. This wold guarantee the dataserver events happen in the expected order. Secondly, your test of if(1 == 2) will ALWAYS evaluate to false, and thus the else code block will run. What were you trying to test there?

Shameless self plug: https://jira.secondlife.com/browse/BUG-5307 (While it is "accepted" that doesn't necessarily mean it's a done deal. I can only hope...)

I recently binged that series and I have to say he is not shy about giving praise and credit when it's due. There have been many episodes where he genuinely finds enjoyment and appreciation in aspects of the games critiqued - flawed as they may be overall. In fact, his multi-part series on Otherland culminates with him affectionately calling it a flawed masterpiece. Also, his criticisms are directed at the products of professional game devs and since much of the content in SL is created by non-professionals, I imagine he would be aware of that and take it into account.

Unless you are creating the chairs yourself and have them conform to a standard, I don't think there's any way to reliably discern a seat and/or backrest from an arbitrary potential chair made by another resident. As an aside, raycast's hit detection is based on physical shapes - and those will vary wildly from the visual representation. Whether they're using the default convex shape or an explicit simplified shape, I think that would make it even harder to figure out what you're looking at through raycasts alone. If you have modify access to the target objects you are intending this NPC to fake-sit on, then you could store a copy (or approximation) of the sit target data within the object's description field and have the NPC query that. Alternatively, you could set up a small communication protocol in which the NPC sends a message to the object and it responds with the sit target data over a private channel. This could be further expanded to also include an inventory transfer of a copy of the object's sit animation (permissions willing) that the NPC could temporarily use for the sit duration, discarding afterwards.

Yeah, given how llGetTexture and llGetPrimitiveParams([ PRIM_TEXTURE,...]) already work, I would have assumed PRIM_PROJECTOR would have followed suit.

Unfortunately not a bug. The release notes when this parameter was added vaguely state as such: https://releasenotes.secondlife.com/simulator/2021-10-25.565008.html And the Devs have commented on it being write only, as well: I presume it will eventually be added to llGetPrimitiveParams. But yes, it being listed on the function's wiki page without that current caveat is quite misleading. As an aside, there are several accepted JIRAs for adding a form of bypass constant, or at least decoupling some of the llSLPPF parameter groups like PRIM_TEXTURE and PRIM_PROJECTOR. Though no ETA yet on when they will be worked on.

Yep, PRIM_FRLLBRIGHT is an all-or-nothing deal: either you have the prim's surface(s) be subject to the scene's environmental lighting, or you don't. There is no in-between. Fullbright is useful for things that one would expect to emit their own light, like a tv or computer screen (objects worn as HUDs are rendered as if they were fullbright). The wiki mentions that fullbright is a replacement for the now deprecated PRIM_MATERIAL_LIGHT and there is a brief little blurb regarding its history on the linked page. If the coloring of your prim's surface is too dull, I suppose you can try to compensate by making the textures brighter and more vibrant before uploading them to SL. You may also want to look into using normal or specular maps on your project - if such things are applicable.

Huh... my mistake, I tested it before posting, and could have sworn it was the case. But double checking now and I get a different behavior. rez a prim drop a default script into it set click action to "none" Standard left clicks do not work on this object, and the cursor doesn't change when hovering over it. However, I can still verify that if you right click the object and select "Touch" from the context menu, that still works. Perhaps that is what I was thinking of.

I did a quick search for "Kool RP door" and found what I assume is the product you're referencing. The marketplace page indicates that it has a customization system built in and specifically mentions it can disable most chat messages the door outputs. How exactly you do this should hopefully be explained in the product's documentation. Or failing that, you could probably reach out to the creator and ask them - as they would know better than anyone else. On the generic subject of creating a secret door, here's a neat little trick: Whenever you hover your mouse over an object with a clickable script in it, the cursor changes to a pointing hand graphic. This is a dead giveaway that the object is clickable and might be undesirable towards the goal of hiding the object's purpose. If you want to make the door really well hidden, you can suppress the cursor's graphical change by setting the default click action to "none" (either via script, or from the build editor window). The object will still be clickable* but the cursor won't indicate it is. * Correction: left mouse button clicks on the object will not trigger the touch events, but right clicking and choosing "Touch" from the context menu will still function.

Just for clarification, messages sent by llSay, llShout, llWhisper, llRegionSay, llRegionSayTo, etc. will always be sent as strings. This includes llTextBox, which is actually sending the contents entered into the textbox as a chat message originating from the avatar itself. Similarly, any message a listening script hears in its listen event will always be received as a string. That's how the listen event is setup. It is up to the receiving script to parse that string and convert it (or a portion of it) to the desired variable type. Conversion is done via the concept of typecasting as mentioned above. Since you're letting the user type in the number, you'll likely want to add some error checking to ensure the script doesn't lose its mind if the user sends something that isn't a number (or isn't within your range of expected values). As an aside, llMessageLinked can send messages to linked prims within a linkset and has specific parameters for sending an integer, string, and key all in one message. The link_message event is this function's counterpart and can receive and distinguish those integer/string/key components from each other.

From the caveats section of the function's wiki page: Child prims can have their own scripts with their own money events that will process the transaction if you try to pay that child prim specifically. However, as the documentation above specifies, the llSetPayPrice function only works when called from a script in the root. And the price(s) set by it will affect all prims in the linkset. If the root has multiple instances of llSetPayPrice, then whichever one was most recently executed will be what you see.

This looked interesting, so I threw together a very rough proof of concept. This demo only works with one seated avatar. More work would be required to support multiple seated avatars at once. As others have mentioned above, it makes use of PRIM_OMEGA to rotate the root which in turn rotates everything else in the linkset with it: including seated avatars. I then use a llSetLinkPirmitiveParamsFast to oscillate the seat prim up and down on a timer. And if there is a seated avatar present, the SLPPF list is expanded to include that avatar as well (plus some magic numbers to recrete the sit offset). I suppose doing something with a sin curve would be more elegant than brute forcing it with a list of local offsets, but this was just a quick demo. //Carousel proof of concept. Link 2 prims together and add this script to it. Only supports one rider. //Assumptions: link 1 is the carousel, link 2 is the seat, link 3 is the porpsective avatar rider list oscillate = [.375,.425,.475,.525,.575,.625,.575,.525,.475,.425]; //local z offsets integer x = 0; //index for above list default { state_entry() { llSetLinkPrimitiveParamsFast(1,[ PRIM_SIZE, <2,2,0.25>, //configure root prim PRIM_OMEGA, <0,0,0.1>, TWO_PI, 1.0, PRIM_LINK_TARGET, 2, //configure seat prim PRIM_POS_LOCAL, <0.65, 0, 0.375>, PRIM_ROT_LOCAL, llEuler2Rot( <0,0,90>*DEG_TO_RAD ), PRIM_SIT_TARGET, TRUE, <0.25,0,0.5>, ZERO_ROTATION ]); llSetClickAction(CLICK_ACTION_SIT); llSetTimerEvent(0.15); } timer() { x = (x+1) % 10; //looping the index within range 0-9 list tempList = [PRIM_POS_LOCAL, <0.65, 0.0, llList2Float(oscillate,x)>]; //move seat up/down key av = llAvatarOnLinkSitTarget(2); if (av) { //extend SLPPF list to include seated avatar to oscillate as well (if they're actually seated) tempList += [PRIM_LINK_TARGET, 3 ,PRIM_POS_LOCAL, <0.65, 0.25, 0.875+llList2Float(oscillate,x)>]; } llSetLinkPrimitiveParamsFast(2, tempList); } }

The wiki page for this constant outlines how PRIM_SCRIPTED_SIT_ONLY behaves when you have a mixture of links with and without sit targets defined: The act of setting PRIM_SCRIPTED_SIT_ONLY to TRUE on a subset of prims within the linkset will indeed block manual sit attempts targeting those prims. It will also block manual sit attempts for all prims in the link set that do not have a sit target defined. However, if valid sit targets are defined on some links within the linkset, then PRIM_SCRIPTED_SIT_ONLY will only block manual sit attempts on the links which you explicitly set PRIM_SCRIPTED_SIT_ONLY to TRUE. So the phenomena I think you're experiencing is that the presence of a valid and unoccupied sit target will override manual sit attempts and sit you on the first available target - even if you clicked on a link that was otherwise invalid to sit on (whether due to no sit target, PRIM_SCRIPTED_SIT_ONLY set to TRUE on that link, or both). This can be demonstrated with the following: // Sit demo. Link 4 prims together and drop this script in it. default { state_entry() { llSetLinkPrimitiveParams(LINK_SET,[ //start with fresh linkset, no sit targets or scripted_sit PRIM_SCRIPTED_SIT_ONLY, FALSE, PRIM_SIT_TARGET, FALSE, ZERO_VECTOR, ZERO_ROTATION ]); llSetLinkPrimitiveParams(1,[ PRIM_SCRIPTED_SIT_ONLY, TRUE, //can't sit on link 1 because scripted_sit is set here PRIM_SIT_TARGET, TRUE, <0,0,.25>, ZERO_ROTATION, //but attempts to sit will be redirected to links 3 or 4 instead PRIM_LINK_TARGET, 3, //can sit on this link because scripted_sit wasn't set here PRIM_SIT_TARGET, TRUE, <0,0,.25>, ZERO_ROTATION, PRIM_LINK_TARGET, 4, //can sit on this link because scripted_sit wasn't set here PRIM_SIT_TARGET, TRUE, <0,0,.25>, ZERO_ROTATION ]); } Links 1, 3, and 4 have sit targets defined. Link 1 has PRIM_SCRIPTED_SIT_ONLY set to TRUE. When you attempt to sit on link 1 or 2, you will instead be sat on the first unoccupied link with a sit target: in this case link 3. If you were to deactivate the sit targets on links 3 and 4, then you would not be able to manually sit on any part of the object. Similarly, if you left the sit targets active, but added PRIM_SCRIPTED_SIT_ONLY, TRUE to links 3 and 4, then you also wouldn't be able to sit anywhere because PRIM_SCRIPTED_SIT_ONLY would be set to TRUE on all links with a sit target defined. And the llSetClickAction(CLICK_ACTION_SIT); does not have any bearing on this, it would be exactly the same if you instead right clicked to select the individual links to sit on. I hope this makes more sense.

I get what you're saying, it's likely to maintain a sense of continuity between instances. You started with one notecard and edited it to add additional text. You naturally want to assume this is the "same" notecard you created yesterday, just with more stuff added to it. So we expect it to retain the creation date/time of the original instance. Despite the fact that given how editing notecards work under the covers, it's technically a brand new asset. I think a more apt analogy might be comparing it to the transporters of Star Trek, and the debate on whether they kill the user and fabricate a perfect duplicate on the other end.

Suppose you have a texture in which the left half is fully opaque, and the right half fully transparent. I've experienced instances where even at 1x1 repeats and 0x0 offsets, the edges of the left side will wrap around and be barely visible on the far right side of the face. The effect is more pronounced at lower texture resolutions stretched across large surfaces (faces). I believe it has to do with the filtering applied to textures when rendered on faces combined with the natural wrapping mode that can cause some bleed through on edges. As others have pointed out, using a slightly smaller repeats value can help hide that. Having said that, I went and took a look at the actual texture being used in the above code. And the reason becomes immediately apparent: the source image was poorly cropped and there are white pixels around the corners. The reduced repeats was probably done to hide that. Here's an inworld picture of the texture, displayed at 3x3 repeats: