Profaitchikenz Haiku

Avatars cannot sit on another avatar's attachments, this is somewhere in the wiki but I'm not sure if it's in the entry for llSitTarget or llAttachToAvatar. The workaround most people employ is for the passenger to sit on a prim with a follow script that tracks the other object or avatar. It sort of works... But don't expect it to manage sim-crossings well or survive TPs. I am guessing that you have two scripts, one of which will go into an attachment you wear, and the other will go into a prim which the passenger sits on. I think the best place for you to ask about setting them up is in the LSL library forum here, but to help you, look through the scripts for a line like "llSitTarget", which will have to be inside the prim which is to track the saddle that you wear. The major problem I see you your requirement though is that if you want to use such a system in sims which do not allow rezzing, your passenger must have already be sitting on the prim before you both enter, and if the sim or parcel additionally does not allow object entry for all avatars, I don't think the follower prim will work.

Try these two things In your preferences, under network, decrease the bandwidth setting. Typically try values no more than 60% of your internet connection download speed. In the graphics tab of preferences, find the draw-distance and reduce it to 96 metres or less.

I don't do the " Prof will discover there's some simple "rule" that relates scale and rotation to the desired offse", I do the "get hit on the head by debris falling from the shattered hypotheses". I'm more interested in when exactly these flips occur. Running a script yesterday I was getting the feeling that X leads it, as soon as an X value is reached for which there is a simpler set of XYZ eulers, the re-arrangement occurs. I've got to turn the loops around and run the Y or the Z first to see if that hypothesis stands or falls. If you haven''t done so, I do suggest popping over to see what Yamil's been doing.

ETA it is far easier for you to modify the first script on that page you linked to for what you want to do. It is already using llSensorRepeat, so you move that line out of the state_entry into the new touch_start event you will be creating. Create the global variables as already mentioned, set status physics to false in state_entry, set startPos by calling llGetPos, and set following to 0. create a touch_start event as already suggested above, and move the llSensorRepeat line down from state entry into the touch event where you have tested the value of following and found it to be 0. Instead of llGetOwner() in the sensorRepeat, use llDetectedKey(0), so that the key of the person who touches the object becomes the target. In the touch event, when following is 1, call llSensorRemove() to stop the sensor, set status physics to false, call llStopMoveToTarget(), set following to 0, anmd finally call llRegionSetPos(startPos) to move the object back to the beginning ready to start all over again. Important: Add a no_sensor even()t, and within it, issue an llSensorRemove() call, followed by llStopMoveToTarget(),set Status_Physics to false, following to 0, then llSetRegionPos(startPos) to go back to the beginning and wait for the next toucher. As you come to each of the stages above, look through the LSL wiki for no_sensor, etc, to see the layour and syntax of what you are supposed to be doing. You will find snippets of code you can copy and paste into the script you are modifying, which will give you less syntax errors that just typing them in straight from the keyboard. I'm TP-ing out for sleep, post what you've managed and hopefully a night-owl will come to your aid

You will have to add two global variables, a vector startPos and an integer following, and in the state_entry, set startPos by a call to llGetPos(), and set following to 0. then set the TimerEvent to 0.0, and set the styatus_physics to False. You then need to add a touch_event. Inside the touch event, check the variable following, and if it is 0, set the physics status to TRUE, set following to 1, and set the timer event to 1.0. If following on the other hand is 1, you need to set the timer event to 0.0, call llStopMoveToTarget, set status Physics to false, and finally set following to 0.

Maths equations are fine for continuously-varying relationships, but you have touched on an area where there are special significances to some of the values, such as 0, 90, 180, 270, and in effect you have moved from what is linear solving to integer solving. There are discontinuities created by the special-significance values that cannot be easily handled by normal functions. As I said right at the beginning, I thought your code was find as it was, and the only simolification I saw was to the cauclation of the offsets. The list-based lookup table that the other posters have discussed is actually a better solution in that much of the calculations can be done at an initialisation stage and not on the fly, so it would improve run-time performance. I probably will pop across and see what you're working on, it's got my curiousity ramped up past cat-mode, I'm active UK time so possibly a couple of hours ahead of this time tomorrow, it that's OK with you?

OK, if you are claiming to be a total noob in scripting, then I think you should step away from the complicated task of chopping around somebody else's combat system and start again in small chunks. You need to study collision events, listen events and timer events. Start with a very simple two-prim system. Make a wall from a prim. Make a sphere called armour, and wear it. In the script inside it, have a global variable called health with an intial assignment. Inside the wall put a script that when it has a collision event, gets the key of the object colliding with it, calculates a random damage number, and sends that as a message on a channel, in the form "UUID, damage value, number"; inside the sphere put a listen event that listens on the channel in question. When it receives a message that begins with its own UUID, it looks at the second part of the message, and if it says "damage value" it converts the third part of the message to a float, and subtracts that from the health value. If the new value is zero or less, the script starts a timer on a 20 second count, and after 20 seconds, when the timer event triggers, it resets the health value in the sphere to the initial value. Walk into the wall several times, possibly with llOwnerSay lines telling you the wall's reactions to the collision event and the sphere's reactions to the message, and you should be able to knock yourself out for twenty seconds, then start again. Once you have it working, then add in your health bar, with the sphere telling the health bar by messages what the current value is, and the health bar displaying that. There, in a simplified form, is a test harness to investigate pretty much what you have been puzzling over, and if you follow those steps you should gain enough experience to go back to the system you have been trying to work with and get it working properly. The alternative, as irihapeti mentioned in another thread where you asked about health bars, is to use one of the score or so combat systems already available, but you won't be learning scripting that way, so I hope you'll persevere with the suggestions I have given above.

In your notecard it does give you a clue in the part "targetUUID )( command )( modifier )( sendername", and a little below that, it seems to list example commands that it can be given. It is a formatted message telling a certain UUID what damage it is to suffer and where this damage is originating from. Therefore the HUD or script is acting as a central coordinator for messages coming in from all sorts of scripted objects around it, and relaying them out again to other objects. All external objects to the HUD such as swords and armour are going to need a script inside them to listen to and speak on this channel, sending messages according to the specified format. The system probably also has such scripts, which you might not have recognised for what they are yet. The /9 channel you mentioned in another post suggests there is a second script inside that listens to a wearer for commands such as "reset". You need to look for this, and see how it transfers the information given to it on channel 9 out to the main channel. In a post above I commented that there was an llDetectedKey() function in the Listen event that could not work, From the wiki entry for llDetectedKey() "llDetected* functions only work if called from within Detection events (collision, collision_start, collision_end, sensor, touch, touch_start, touch_end) or in functions called by Detection events." In the heal example in the notecard, in order for that example to actually work, the lines have to be inside one of the detection events, such as a collision, sensor or touch. Therefore, in order to implement the example heal function, you would have aprim somewhere with a touch event inside it, and the person touching that prim would cause that block of code to send the formatted message, targetted at the UUID of the toucher. The block of code you have pasted inside the listen event with the llDetectedKey(0) call can not operate reliably in there, and it needs to be moved into some other event.

The only thing I can think of is rather like a hud. Imagine you have an object rezzed consisting of a circle and cross-hairs, which you an move around my means of the cursor key. Also imagine that it is rotating around you using one of the techniques mentioned in the wiki for rotating an object around a fixed point. You can therefore at any moment obtain from this object it's rotation relative to you, and possibly therefore the information that you want? ETA I just tried this very quickly inworld with an attachment. I turned to face the four cardinal compass directions and got the llPos() and llRot() recordings from the attachment and they did seem to change as I turned. Therefore you can get the avatar rotation easily. If you then have an item such as I described which is set to rotate around you in a circle according to some form of control, you can at any time get it's rotation realtive to your own rotation using the individual rots of each. I'm proposing this because I think we've all got side-tracked on the issue of raising an arm, but I see what you wanted originally was to use the LookAt target, which implies you want to move the pointer around the screen under mouse control, and when you click it, get the relative angle from yourself that the mouse pointer is at. Something like that already happens if you use double-click-auto-pilot, but as with the lookat, that is also not available to us via LSL.

I've also been intruiged by what the script is actually trying to do. The sort of thing I can see it being useful for is making a dice that is set to physical when tossed, and bounces around a while. When it finally stops bouncing it needs to then be settled onto whichever of the six faces has the closest orientation to the flat plane.

Go gallivanting around the whole of SL Bring up the search floater, set it to places, pick a random word and type it in, then take one of the returned results and TP there. Explore for a bit, until something you see makes you think of a new random word. Type that into the search floater, and off you go again.

/me hums "You can't see forward-jutting-motherly-glands on the radio"

There are two issues here spring out at me Firstly, there is nothing in the listen to react to any other keyword than the UPDATE one, so any other message will be ignored. Secondly, the presence in a listen event of the llDetectedKey() function suggests a chunk of code has been lifted out of another event and dumped in a listen event without appreciating what is happening. As it stands, I can see no way to make this script implement a death, because there is no description of the other messages being sent to it. As a starting point, I suggest you add the line llOwnerSay("Heard <" + name + "< say >" + msg + "<"); inside the listen event before the list2csv line, and then watch the output. It will tell you what other messages are being sent, and you can determine then which ones to write blocks of script for. Have a look in the wiki at llListen() and the listen event and look in particular at what the key passed to it signifies, then have a look at llDetectedKey() and see where they state it should be used. If this script is in a prim with another script which is detecting objects by collisions, that other script will have to pass the armour key into this script by means of a link message, or, if in a seperate prim, by chatting it on this channel. One final point. llListen() returns an integer handle which is necessary sometimes when several channels are being used, both for working out which channel has been heard, and also for removing the listen in the event of ownership change, so declare a global integer chandle at the top of the script and add thandle = jujst in front of the llListen call

I think the issue here is conversion between the Euler representation you see in the build floater and the internal representation as a quaternion. If you feed 90, 90, 90 into a rot variable, then convert that rot variable back into a vector expressed as degrees, you get 0, 90, -180 reported as the values. The rotation itself is <0.70711, 0.0, 0.70711, 0.0>, (whick my early tables suggest is 90 degrees X, 0 degrees y, 90 degrees z), so I suspect there is some internal process of simplifying the rotations along each of the three axes. Why it should say -180 is a bit of a puzzle to me, it suggests to me that when converting from rot back to Euler and then degrees, there should perhaps be a normalisation stage where negative values are subtracted from 360.

Have a look in the wiki at llRezObject, it is the starting point for what you want to do.

There is one more little gotcha you need to know about attachToAvatarTemp, which I struggled with, as well as having to call request permisions to attach the object to the avatar, you have to specifically call requestPermissions to detach it from the avatar,. I spent an hour banging my fingers round the keyboard before I got that sorted. So, you need to have a global string or integer somewhere that is set to attach or detach, 1 or 0, before calling requestPermissions, Inside run_time_permissions, when you check if you have been granted attach permissions, look at the variable to see if you are to attach or detach the object. The first time you call it, to actually attach, the avatar will get the dialog asking them to OK the action, but when you make the call to detach, there is no dialog becuase it knows it already has the permissions.

I think you've only got part of the system there, becauses there's nothing in there which rezzes an object, or aquires a target. If this is part of a linkset youlre working on,. look through the rest of the prims for more scripts.

That's because you have run_time_permissions and some other event handlers inside what looks like to be part of a function, it needs to be outside, at the same level as the attach, touch, and other events The attach event will occur just like a touch, listen, etc. So your script needs event handlers for all such events, which cannot be inside loops or functions, but must be in the current state. State_entry is such an event.

You have a parenthesis where there should be a comma in the temp line, but also you should be rezzing the object inworld so that the avatar can touch it in order for a temp attach to work. Also, you have not requested any permissions, without which the object will not be allowed to attach. The wiki entry for llAttachToAvatarTemp gives several good examples, and shows how to request permissions and where to attach them. In the run-time-permissions event, check the permission has been granted, and if it has, then issue the attach statement. if instead you want to give out objects that the avatar recieves into their inventory, and can attach from there by clicking, then the simplest way is to attach the object to your right hand, edit it uintil satiosfied, take it back into your inventory, and then drag it into the prim from which it will be given out. When the recepient gets it and clicks on it from their inventory, it will rememebr the attachment you set when you saved it in the first place. In that case, you do not need to call the llAttachToAvatarTemp function, as it will not work for that type of object.

Try this as a simple example of how to touch a face and toggle it's glow value, it should show you what you are going to have to do in your build to get specific faces to glow or not. default{ state_entry() { } touch_start(integer touches) { integer tFace = llDetectedTouchFace(touches - 1); float glowVal = llList2Float( llGetLinkPrimitiveParams(LINK_THIS, [PRIM_GLOW, tFace]), 0); if( glowVal > 0.0) glowVal = 0.0; else glowVal = 0.2; llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_GLOW, tFace, glowVal]); }} I am using the link version of set PP in order to give you a pointer to where to look further. It is simply toggling the glow value of any face by first getting the current value, then setting it off or on depending on what it finds.

Have a look at lllAttachToAvatarTemp() in the wiki, it has an example showing exactly how to attach an object to the right hand without having to give it to an avatar or load from inventory.

I didn't realise this thread was still running, so I read back. I am concerned that people are confusing a character identity for SL with an RL persona. The character Pixaleen Mistral was one of their creations, but my reading of the posts in this thread suggest that many people here view the character as being the person behind it. I viewed the Pix character as a sort of Hunter S Thompson (with **bleep**), but when the gonzo journalism slipped into taking a side, I think the similarity ended, and the last few articles didn't really have the old bite to them. I felt relieved when the AH stopped posting new articles, because as has been mentioned above, it not only "jumped the shark". It also seemed to have nothing to say once the events of 2010/2011 had settled down, and so it ran out of a purpose, look at the page 6 grrrrl posts for a good example of that. ETA I got bleeped! My first ever. Ok, the offending word was an FLA for those forward-jutting motherly glands, in case you're curious.

There is a bit more to developing a script from a snippet or simple example than looking through the wiki at definitions. For example, the names of the linkset, and the scripts inside them, and storing versions as you try changing things. Why does this matter? Because if you just leave things set to "object" and "new script", you'll get lost when the changes you try don't do what you hoped they might. So, first of all, give the script a proper name, such as "greetings card". Then, drag a copy of it back to your inventory. Then, make a change, drag a copy of it back to your inventory, test the changes, if necessary, make another change... But there's another trap here to do with the way the inventory works which came to light last week, to do with keeping track of all the versions of the script created when different things are tried. If, when you build, you leave the default name "object" in each prim you create, how do you know what it is when you later on look in your inventory? Ok, says my friend, it doesn't matter about the children in the linset because the linkset name is what I'll see in the inventory. That's fine, until you accidentally unlink the object when it is in a physical state, and suddenly you are using object area search to scour the sim for "object" belonging to "doh". Just like renaming the script from the default "new script" to something you can later on search for. What my friend did with the scripts was to drag a copy of the script back to their objects folder each time they made a change, and also take-copy the object itself. They relied upon the inventory sort order by date to be able to pick the latest version of all the identically-named scripts for that object by taking the name which came at the top of the list. Then, when they thought we had finished the build, they did a cut and past, moving all the scripts and objects from the objects folder into a sub-folder. Then, when we discovered a bug, they went to the new folder, took the third instance of the script because they assumed it was the third-most recent, and we found it wasn't. All the identically-named scripts in their folder were showing the same date and time now in the properties field, the date and time they had been pasted into the new folder. It took them half a day of going through each script in the folder until they spotted the version we actually needed. So, name each part of your build, name each script, and append a version number to the end of the script name, then drag the renamed script accross into your inventory. When you get totally lost in some changes which no longer seem to make sense, go back to an earlier number that did work, and start again. Hopefully in this case, the change will be a simple oone of copying the block of statements in the initialisation function which set the card to closed down to the touch event, and adding an else if so that the touch event also works when the variable in question is 1.

Have a look at how the variable openClosed is used. Initially it starts off at -1 and is only set to 0 when both parts of the linkset have been identified. if 0 when touched, the alphas are switched over, and openClosed then set to 1. Therefore you need to add an else if clause to test if it is set to 1, and iff so, to change the link alphas again, and then set the value to 0. You will be repeating the three statements that occur within the "else" block of the function that checks for the names and sets the book to closed if all the parts have been found. It is important to note that you cannot just stick an else... test after the test for 0 in the touch event, becuase if the variable has been left at -1 because of mis-named parts, no action should happen when touched. (Alternatively, of course, in the touch event you could just reset the script if the variable is set to 1 when touched.)

Link the two cards together, then name each individually "open card" and "closed card". integer openCard = -1;integer closedCard = -1;integer openClosed = -1;getCards(){ integer ii; integer iiMax = llGetNumberOfPrims(); for( ii = 1; ii <= iiMax; ++ii) { string sName = llGetLinkName(ii); if( sName == "open card") openCard = ii; else if( sName == "closed card") closedCard = ii; } if( openCard == -1 || closedCard == -1) llWhisper(0, "Check my names!"); else { llSetLinkAlpha(openCard, 0.0, ALL_SIDES); llSetLinkAlpha(closedCard, 1.0, ALL_SIDES); openClosed = 0; }}default{ state_entry() { getCards(); } touch_start( integer touches) { if( openClosed == 0) { llSetLinkAlpha(closedCard, 0.0, ALL_SIDES); llSetLinkAlpha(openCard, 1.0, ALL_SIDES); openClosed = 1; } }} Not checked inworld, be prepared to de-typo it ETA sighs, Rolig, you did it to me again