Fenix Eldritch

What you are describing is a pretty common thing. A group of face/material slots combined to show one character of text per face. Recently, an old thread was revived and has links to some example and freebie applications on the market place that could be along this train of thought. See it here. Speaking in very general terms, you place your characters on a texture, evenly divided into cells or frames as if it were an animation. Then for each face in sequence, you manually set the texture offsets to display the desired character for that face. If you're just using numbers, you can simplify the process greatly and use the actual number as part of an index into your texture's frames. Not a direct index of course, you'll need to use a formula to get the right offsets. But it's not extraordinarily hard to accomplish. Assuming you set up your texture such that you have a single horizontal row of ten characters (one for each number, starting with 0 as the first frame), then you only need two things to calculate the offset (assuming we stick to the same horizontal row): the size of a single frame, and the offset for showing frame zero centered on the face. Find the offset that will center frame 0 on your target face. Let's call it the leftEdge (assuming it's the leftmost frame). This is your starting point. To that, add the horizontal size of a frame multiplied by X, where X is the number 0-9 you wish to display on that face. We're basically saying "shift X frames to the right". If the number is zero, then we're effectively adding zero to the leftEdge so we stay displaying frame zero. This example only works with one single digit at a time, so you'd have to break the number up into each digit. I will cryptically mention that it is possible to make this work on a full number without breaking it apart, but that's a tad advanced using additional math to manipulate the number. For now, I would focus on getting a single digit to work and build up from there. I leave the rest to you. Good luck!

I would assume that the script you saw is probably using one of the llSetLinkPrimitiveParams functions to update the orientation of the avatar once they sit (since avatars are considered part of the linkset when they sit on an object). From my own experience, single use of the function in this case will cause the avatar to snap to the new orientation, sometimes with the viewer showing you a tiny bit of interpolation - though I wouldn't depend on that to be consistent. If you want to have the effect of a slower swivel from the sit target to a new orientation, one approach would be to divide up the rotation into parts and call llSetLinkPrimitiveParams (or llSetLinkPrimitiveParamsFast ) multiple times, each one using a portion until you get to the desired final orientation. How many steps you divide this up into and what (if any) delays you use between each step will affect how smooth it looks. Even so, it still may look somewhat jerky. If your build is stationary, another way would be have the prim the avatar sits on be unlinked and invisible and rotate that whole thing once the avatar sits on it. You could adapt some of the smooth rotating door script examples in this case. Alternatively, yet another approach would be to create a custom non-looping animation that rotates to the desired orientation at the desired speed and have that animation be applied when the avatar sits down. That would be the most lightweight and smoothest solution, but it requires the creation of a custom animation asset outside of SL. And it could limit the flexibility of the project depending on how it is intended to be used.

That is how the timer is designed. When you call llSetTimerEvent() with a positive number, the timer event will trigger after the specified interval has elapsed. It's like a countdown. Specifying a zero will cancel the timer's internal countdown. See the function's wiki page for details. If you want your actions to happen immediately, before the timer goes through its countdown, then you must explicitly perform them outside the timer event as well. You can do that several ways. The most straightforward way would be to literally copy the code you have in the timer event and place it in the appropriate spot in your touch_start event (like just after you start the timer countdown with llSetTimerEvent(10.0)) Another way of doing that is to move your action to a user defined function and then call that in the touch_start event and then in the timer. customFunction() { //stuff to do } default { touch_start(integer total_number) { llSetTimerEvent(10.0); customFunction(); //do the thing right away } timer() { customFunction(); //do the thing every 10 seconds } }

Regarding the Solid vs Surface mesh physics decomposition, I see a short blurb on the wiki that seems relevant in retrospect: I have no idea of the internal workings of these methods, but having a clearly defined interior and exterior definitely makes solid seem like the go to choice to select. It's interesting that using surface seemed to contribute to the ray cast problems. Also, I went digging through my own jumbled notes and found this interesting blurb - which regrettably, I didn't write down the source. But I can vouch to having personally used it on several models whose physics shape was smaller than the other LODs. And it seems to hold true - at least as far as I can tell. Glad you got it sorted!

Would the next-owner permissions apply here? If you create an object and uncheck the next-owner-copy permission in the build tool, would that make the item no-copy only as it is transferred to the new owner via llGiveInventory? I haven't used that much so I don't know off the top of my head, but glancing over the next owner permissions test page makes me think it might be an option?

I doubt that. According to the wiki page, the beta grid has limited capacity, so regions come and go as needed for testing. It also lists several permanent sandboxes residents can use, which include Astutula, Exemplar, Pristina, and Verenda. These are of particular interest because their counterparts on the main grid are in fact actual premium sandboxs - which are indeed supposed to be for premium members only. These were introduced around the time of the first Linden Homes specifically for premium members. If these four Aditi regions were previously open to all as you say, then it may be a simple case that those regions were refreshed on the beta grid and carried over their premium-only status. It could be an honest mistake. I'd suggest opening a JIRA ticket to see if those beta grid regions can be restored to open status again. Edit: Qie posted as I was writing this, but his hunch also has merit. The Lab may have switched Verenda over to premium only for their own testing for the upcoming premium-plus plans.

The way I initially read the OP, I thought you were saying that you had already saved changes to the notecard/script and then encountered a crash. And when you came back, you found those recently saved changes had been lost so to speak. Is that correct? Or did the crash happen while you were editing both of them and hadn't committed any changes yet? If you had committed the changes in the previous session, how soon after did the crash occur? And was this a viewer crash or a region crash? (I'm assuming viewer?)

Apologies, I stand corrected.

That doesn't sound right to me... I admit I haven't explicitly looked at this but I don't recall ever encountering a scenario where changes I made to a worn attachment's contents were lost if i didn't detach before logging out. Is it possible you're thinking of the prim description - which can lose changes made (by a script) as per the caveats listed on llSetObjectDescription: I'm still combing through the wiki, but so far that's the only instance I've come across regarding lost changes. I'll update if I find anything else, and will also try to do some inworld tests later this evening.

Granted, you consciousness is now trapped in your digital avatar in some Black Mirror-esque scenario. I wish I hadn't skipped breakfast today.

I gave this a quick test with no AO and using a random animation - and it worked for the most part (setting aside the lack of a run_time_permissions event for now). I can think of four possible reasons why you might not be seeing anything even without your AO running: Firstly, are you in an area that has scripts enabled? Land owners can disable outside scripts from running (with a few exceptions). You can check in the About Land popup (right click the terrain) and look at the options tab to see if "Run Scripts" is checked for Everyone. Or look in the top URL bar on the viewer and see if the parcel properties icons are visible (if not, right click the bar > show parcel properties). Those will show you what options are disabled. Secondly, are you sure you've removed all other objects that can potentially animate your avatar? To be absolutely sure, remove all attachments and even click the menu option Me > Movement > Stop Animating Me. This should help ensure you're in a clean state with no animations playing. After doing that, attach your test object. Did you place your animation into the object's inventory? The animation must exist in the same prim as the script in order for the script to find it. Though it's pretty obvious if this is the problem because you'll get a torrent of Script Waring/Error messages saying it "Could not find animation ''." The other possibility is that the holding animation you are starting isn't a single frame pose - or it has a lengthy ease-in period. Meaning it might be taking longer for the animation to actually visibly affect your avatar. Since you are running on such a short timer, you may be stopping it before it has a chance to visibly play. As a test, try lengthening the timer duration It should be noted that you may still encounter problems when running with an AO due to the animations' priorities. If the AO animation's priorities are higher than your hold animation, it won't show through regardless.

That is a for loop. It is a method of making a block of code repeat itself, to iterate over a range of values. As I mentioned above, your code as written in the second script is going to blindly loop with no regard to what button was actually clicked. It's inspecting every prim in the linkset and doing those IF tests on each prim. Which means it's going to do everything instead of just acting on a specific button's code. I suggest you revisit your first script, as it is a simple matter to convert it to use link names instead of pure link numbers. You would essentially follow the exact same logic. No need for a loop. In the touch_start event, change the button variable to a string instead of an integer. This will be the variable to contain the name of whatever child prim was clicked and then we will do the same IF checks, without a loop, and updated to work with your specified names. You would use a combination of llGetLinkName and feed it the return value of llDetectedLinkNumber(0). This essentially is saying "get the name of the link that was just clicked". This would be the template: string button = llGetLinkName(llDetectedLinkNumber(0)); if (button == "button1") { //do stuff for button1 }

Even after you get your variables cleared up, there is still a lingering flaw in your second script that will cause undesirable behavior (as I understand it). In your touch_start event, you are going to loop over every prim in the hud's linkset. On each iteration of the loop, your script will perform a series of checks to see what the name of the current child pim is... and then stop all animations and start the one that corresponds to a given name. Do you see the problem here? You aren't checking what link number was clicked. Your loop is going to inspect EVERY prim in the linkset, so all of those IF tests will eventually pass. Even the "stop" one. Depending on the order of your links, one of those bits of code is always going to be the last one executed, no matter what.

At the top of your second script, you defined the string variables as button1, button2, etc. but those are just the names of the variables. You still need to give those variables a value. If the names of the child prims are "button1", "button2", etc, then you need to assign that to the string variables. For example: string button1 = "button1"; //the variable identified as button1 contains the value "buton1"

As another aside, the link_message event will tell you from what child prim the message originated from. So you can use that in your test instead of the message - perhaps that's what you meant to do originally? Example: link_message(integer link, integer num, string msg, key id) { if(link == 5) //the message came from link number 5 { //stuff } else if(link == 4) //the message came form link number 4 { //stuff } ... }

The scripts provided don't appear to be telling the full story... I'm not sure how this would even work with what's shown above alone. Are there other scripts in the object? Currently as written, this is the sequence I am seeing: The button script in each child prim will set the host child prim's name to its link number. When clicked, the button script will send a link message to the root with the integer parameter populated to the child's link number, the message parameter populated to "Clicked" and the key parameter empty. Then the script in the root will receive the linked message and will then issue a llRegionSayTo based on the value of the message parameter. However... the message parameter in the linked message sent by the first script is hardcoded to "Clicked" so it will never be anything else. So all the IF tests in the root script will always fail. Additionally, I don't think it's valid to define a locally scoped variable to have the same name as a variable in the event handler - namely the id variable in the link_message event. Normally if you try to edit the value of an event handler variable, it will silently fail. And llDetectedKey won't return meaningful results in that event. The detected functions only work in the collision, collision_start, collision_end, sensor, touch, touch_start, touch_end events. For anything else, they will silently fail and return unusable values. Are you sure there aren't other scripts running here? There must be more going on....

If you're new to LSL scripting (or programming in general), it would be a good idea to brush up on the basics. I recommend taking an afternoon and going through some tutorials. The LSL 101 wikibook might be a good place to start. It will introduce you to all the basics.

Your countdown is continuing into the negatives because you never reset the giRounds variable to 0 when the game ends. Edit: and it jumps from 10 to -1 because on the touch event, you set the hovertext to giCountDowntime, which is always 10, but then when the timer event fires, the text is set to (giCountDowntime - giRounds) which at that point is (10-11) or -1

You could move the script into a different child prim - anything other than the root should suffice in this scenario. I am a bit puzzled why you're using an unpacking mechanism if you don't want the contents of the root prim to be given to the user. Are there other contents in the HUD's root that you do want transferred during the unpack? If not... is unpacking even necessary? I don't have a complete picture of what's going on, so I can't really suggest more beyond moving the script to a child prim.

At first glance, it sounds like the script was placed into the package's inventory instead of the HUD's inventory.

Additional control inputs are sorely needed. Of the ten controls detected by LSL, I'd say about eight of them are needed for basic navigation. That doesn't leave us much room for additional actions and we usually have to resort to sacrificing existing controls for them instead. I made a feature suggestion a while back that proposed adding LSL hooks to detect the F, Q, Z, and X keys and right-click when in mouselook. The jira hasn't been rejected but has instead been in "Been Triaged" for a long time. I'm... optimistic that's a positive sign.

If I may suggest another approach: Give your target prims the same name but then differentiate them by giving each one a unique description i.e. "left" or "right". That way, you could set your sensor to look for all objects named "Corner Setter" and then inspect each detected prim's description with llGetObjectDetails to figure out if it was the left or right variant.

I just tried creating/saving a script on the PATH9 region in the Aditi grid and had no issue. Perhaps the problem is with the specific region(s) you are in when attempting to save the script... have you seen this on multiple different regions? Based on that error message, my guess is that the region is having some kind of network issues with the asset server. If this has been going on for some time, you might want to consider creating a bug report on the JIRA to let the developers know.

A poor choice on my part. You are of course, right. I'll try better next time.

No idea to be honest... it just irked me a bit