Jump to content

Fenix Eldritch

Resident
 View Profile  See their activity

  • Posts

    771

  • Joined

 Content Type 

Everything posted by Fenix Eldritch

  1. Fenix Eldritch
    I would expect the results to be the same in three dimensions. Using the same group from above, one at a time, I linked a target prim to the scanner prim and then rotated about the root randomly. I then unlinked and repeated the process for the next target prim. Eventually I had a cloud of target prims clustered around the scanner at arbitrarily XYZ positions - but because I essentially orbited them round the scanner, their distance from it remained constant and thus easy to verify the order. Lo and behold, the sensor reported everything in the same order as before.
  2. Fenix Eldritch
    I set up a test with 24 prim cubes as shown in the attached image. The 20 green cubes had an active script and the remaining red ones had no script. All cubes were named "Target" and all had a unique description text which I could use to identify in the sensor results. The green cubes' descriptions were essentially "ok x" where x was 1-20 in sequential, increasing order. The others were similarly "bad x" with x being 1-4 again, in ascending order from the left where the sensor prim was. My scanner used the same senor command as your example and when I looped over the num_detected range and spoke the detected prims' descriptions, I got "ok 1" through "ok 16" in the expected ascending order. Then, as a second test, I put a valid script into that red cube just over the line of green ones. The resulting sensor event gave me the expected "ok 1" through "ok 5", followed by "bad 4" and then continued with "ok 6" to "ok 15". This is what I was expecting to see. It's a simplistic test, as far as I can tell, it appears that the sensor will pick up the first 16 scripted objects named "Target" and nothing more. It'll ignore other similarly named prims that don't have an active script and it didn't pick up the extra ones beyond the nearest 16. Something to note is that my first attempt at this failed because I was using the default "hello world" scripts in my target prims. I neglected to realize that the script had to be actively doing something for the sensor to pick it up using just SCRIPTED. If it was running, but idle, the sensor wouldn't flag it. So my new target test script was just a while(true) loop. Is it possible that some of the target scripts you're using are idle at the time of the sensor sweep?
  3. Fenix Eldritch
    Yes and no... there is a way to attach using the inventory menu and not have it ignore previous settings. I mentioned it briefly in my previous response, but I'll go into deeper detail here. When you right click an object in your personal inventory, there will be several options on how to attach it: Selecting the "Attach To..." menu item will present a list of attachment points and attach the object to whatever you select - thus overriding any script or previous attach point history the object had. Naturally, you don't want this option for your scenario. Selecting "Wear" on the other hand, does not present you with a list to choose from. Instead, it attaches the the object to whatever point (and positional and rotational offset) that it previously had. The object remembers where it was last attached to and will continue to use that if you choose the "Wear" menu option. I believe there are also "Add" and "Add To..." options which work similarly to "Wear" and "Attach To..." except they don't detach stuff which already occupies the target attachment point. If the object was never attached before, it will default to the right hand. So you can set up the object by manually attaching it to the desired point, and from then on, it will ways go to that same point when you select "Wear". Combined with the scripting option mentioned above, you can devise a way to reset the default worn position via script in the event the user accidentally overrides the attachment point. But again, that would only work if the object lets the script attach. Additionally, you can also write a script to detect where the object is attached to and speak a warning message if it's not where you as the creator intended it to be. See the example code on the wiki page for llGetAttached(). That example goes so far as to detach the object if it detects its worn on the wrong spot. Though I would wager most of the time, people will expect HUDs to be worn on the HUD points and won't try to explicitly attach them elsewhere. I think setting up the object beforehand (either by manually attaching the original copy to a HUD point or using the attach script) would be reasonable coverage.
  4. Fenix Eldritch
    llSetPrimitiveParams has two other variants, llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast. Since they're so closely related, they're all stored on the same wiki page... which unfortunately can make it seem daunting - especially with the plethora of options already available to the commands. The short version is that the "linked" variants contain an extra parameter: an integer which denotes the linknumber of the child prim you wish to target in the linkset. Additionally, llSetLinkPrimitiveParams and llSetLinkPrimitiveParamsFast are identical save for how long they take to execute. The first command has a built in delay of 0.2 seconds, while the "fast" variant has no such delay. For finding link numbers, you can temporarily add a touch event that runs a command which will speak the link number of the child prim clicked. See this page for the example: http://wiki.secondlife.com/wiki/LlDetectedLinkNumber
  5. Fenix Eldritch
    Before you close this thread, I have a couple long-shot ideas... Firstly, have you tried moving to different simulators and attempting to compile there? Perhaps you're on a release candidate server and have encountered some strange new bug... You can check what server version you're on by going to Help > About Second Life > Info tab. I forget the exact wording , but if you see something like Magnum, LeTigre, or BlueSteel, then the sim you're in is running on RC code. Secondly, does your code have any special unicode characters in it? Maybe some strange formatting getting copied from the repository? Under normal circumstances, I would think that the viewer's interface for writing scripts would be able to handle and scrub whatever is thrown at it, but doing a sanity check can't hurt. Something like copying+pasting the code to notepad and then copying+pasting that into the viewer. Again, I'd be surprised if this did anything, but it's better to be sure. Lastly, definitely followup and write a jira as Whirly suggests. Internal Server errors generally sound like something out of the users' hands so the devs should take a look.
  6. Fenix Eldritch
    Hold up. This all stemmed from you getting upset over an example of writing out a vector with integers vs floats. My comment was that is didn't matter if said vector was being used as a literal. As in not put into a variable, but typed straight into the code. My reasoning was that saying something like llSetScale(<1,1,1>) is no different than llSetScale(<1.0,1.0,1.0>) because when the compiler is turning everything into bytecode, those two lines are static. There is no variable present, so they will never change. Thus, the compiler coverts that text to static bytecode which will always execute the same no matter what. No additional typecasting or whatever is done after the initial compile, because nothing in those two statements ever change. That's what I was getting at. Anyhow, no hard feelings. Hope you have a good day too.
  7. Fenix Eldritch
    *sigh* Fine, I'll bite. The OP's question appears answered anyhow. For an example of how compilers can (and do) modify code, refer to what implicit typecasting is. Here's one such example from the LSL wiki: http://wiki.secondlife.com/wiki/Typecast
  8. Fenix Eldritch
    I'm going to disagree with you and leave it at that. I do not wish to derail Ainst's thread with an argument of this subject. If you want to continue this side topic, feel free to message me.
  9. Fenix Eldritch
    Any extra work that must be done to convert an integer literal to a float literal is only incurred at compile time. Once the script is compiled, the conversion is not done again. I'm reasonably sure that's how compilers work. Similarly, the LSL compiler will accept a vector of integers and quietly convert it during compile time to a vector of floats without error or issue. Again, this is with literals. Variables are something else. If you have examples that say otherwise, please direct me to them. Otherwise I will say no more on this tangent. Sorry, I don't understand what is being asked. Can you rephrase?
  10. Fenix Eldritch
    It was a shorthand example, take it easy. Besides, if you're using literals, those will automatically get converted during compile time anyway. Variables are another matter.
  11. Fenix Eldritch
    Same way you moved them in the first place, another llSLPPF() call using values that negate the original movement. If you moved one locally by <0, 1, 0>, simply using <0, -1, 0> would effectively undo the original move. How you trigger it can be done many ways, on touch (using a toggle variable to flip flop between opening and closing actions), or a timer are two examples.
  12. Fenix Eldritch
    Sorry, I had an error in my previous post. I had incorrectly posted my example with things in the wrong order. I did edit it, but I might not have been fast enough. Re-check my post and try what's currently there.
  13. Fenix Eldritch
    Close, the format is a little off, and you're missing the start of the list "[" llSLPPF() takes two inputs, a link number and a list of stuff to alter. That format must be adhered to, so your first link number can be the first prim of your target set. Then the list starts, so your first entry would be the prim pos local keyword followed by the value to apply - for that first child prim (DOOR_PRIM in this case). Then after that, you get into the pattern of specifying additional prim link targets, the attribute keyword, and the associated value, etc, etc. llSetLinkPrimitiveParamsFast( DOOR_PRIM, [ PRIM_POS_LOCAL, <0,0,0>, PRIM_LINK_TARGET,DOOR_PRIM_2, PRIM_POS_LOCAL, <0,0,0>, PRIM_LINK_TARGET,DOOR_PRIM_3, PRIM_POS_LOCAL, <0,0,0>, PRIM_LINK_TARGET,DOOR_PRIM_4, PRIM_POS_LOCAL, <0,0,0>]);
  14. Fenix Eldritch
    I think it's a matter of taste... Yes, fewer prims are generally preferable, but perhaps the OP wants the aesthetics of a four-paneled sliding door. 4 vs 1 is relatively low in terms of impact, and from a Land Impact perspective, you can knock that down to 2 if you change the prims to use convex hull. As for using the command, do note that the list follows the format "CONSTANT, value". So PRIM_LINK_TARGET must be followed by the actual link number you want to target. And PRIM_POS_LOCAL must be followed by the vector of the new position you wish to apply. And all elements in the list are comma separated.
  15. Fenix Eldritch
    Ok, I see what happened now. It wasn't clear that you were suggesting the OP switch to using a single prim instead of four. My response was under the assumption that the OP wanted to keep using the four prim design. In which case, llSetLinkPrimitiveParamsFast would be a viable option to move all four prims at once. Edit: and if you don't want to stretch/shrink the scale, you can alter the prims' offsets instead using the same function.
  16. Fenix Eldritch
    I don't understand what you are saying, Steph. The server has to make calculations in either case. llSetScale(<1.0,1.0,1.0>) and llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_SCALE, <1.0,1.0,1.0>]) are functionally the same, are they not?
  17. Fenix Eldritch
    llSetScale() by itself only affects the single prim in which the script resides - which means if you were to use that, you'd need a script for each prim of the door, plus additional logic to synchronize everything. Instead of that, I would suggest you look at llSetLinkPrimitiveParamsFast(). This single command can be used to target each child prim at the same time with just one command using the LINK_TARGET for each child. And using its other constant PRIM_SIZE which is equivalent to llSetScale.
  18. Fenix Eldritch
    If I understand you correctly, then yes: it is possible to write a script that governs where an object will attach to when worn. Take a look at llAttachToAvatar() and the variant llAttachToAvatarTemp(). They take an input parameter which identifies the target attachment point it will use. There are constants for each valid attachment point, including HUDs. See the wiki pages for the details. Be aware there is a bit of a caveat with this... This will only work if you allow the script itself to do the attach. If you attempt to attach the object by using the viewer's menu and select an explicit point (like your left hand), then I believe that will override the script and forcibly attach the object to your left hand. In order to achieve your goal, you must let the script do the actual act of attaching. Additionally, objects maintain data about where they were last attached to. So once the object has been successfully attached, it will "remember" that location. Form then on, that instance of the object will always attach to that same point if you use the generic "wear" action from the viewer (without specifying an attachment point).
  19. Fenix Eldritch
    Oh man... I just remembered this one gesture I saw when I was hanging out with people in the beta grid while SL Voice was being first tested. The gesture contained a deformer animation that would elongate the neck - and only the neck. As it was spooling up, the gesture would play the sound effect of a raspy electronic voice which said "Neck.... Extend!" and the avatar's neck would shoot upwards and stay that way. It was hilarious and I tried so hard to find it on the main grid afterwards... but to no avail.
  20. Fenix Eldritch
    Well... rotation doesn't even come into play here, so it would be even simpler. We already have the previous position saved in the "pos" variable, so just check that against the current position returned by querying llGetPos(). if (llGetPos() != pos) { pos = llGetPos(); } Putting that test right before you start the timer (when the avatar first sits on the object) should ensure the start position is refreshed. Edit: Heck, we could even go simpler... You could skip the test part entirely and just issue pos = llGetPos(); by itself when the avatar first sits down. That forces the script to update the start position before it vibrates the outhouse wherever it may be. Technically wouldn't even need to reset the script then...
  21. Fenix Eldritch
    I believe the intent was to make the outhouse "rumble" when in use for comedic effect.
  22. Fenix Eldritch
    The reason it's doing this in the first place is because you only get the object's position once - at the very beginning of the script in its state_entry event. You're storing the position in the "pos" variable, so the script will remember it for as long as the script is running. As originally written, your script will only update the pos variable if the script gets rest, which in turn forces the state_entry event to be run anew. As Steph suggests, you can work around this by forcing the script to reset itself every time the object is rezzed. Adding a new event, on_rez, and putting in it the command to reset the script should do what you want. The on_rez event is automatically called when the script detects that its host object has just been rezzed in-world. However, in regards to your second question, this alone will not update the position if you manually reposition the object without resetting the script afterward. You would need to write additional code to keep track of the last known position and check if it is equal or not to the current position and update accordingly.
  23. Fenix Eldritch
    I have in my possession a copy of the "James Linden Nickel". Original creation date is 02/11/2002. Legend has it that this was made as a proof of concept for applying textures to prims. I think it's among the oldest objects still within SL. I also have a copy of a musket which contains a texture that has one of its dimensions as 2048. There was a (thankfully) brief time in SL's history where it was possible to upload textures at that size. There's also a Banshee Rezzer bracelet, which was given out during a promotional period in which SL was stress testing their servers to try and get to 5000 players online concurrently. The bracelet rezzes an simplistic orb pet which follows you around and can interact with other instances of it.
  24. Fenix Eldritch
    Yeah, did you mean to put a llSleep(1.0); command there instead of llSetTimerEvent(1.0); ? In either case, they wouoldn't be necessary there... Recall that as per my suggestion, you would be starting the animation at the beginning of myFunction(). That way the avatar animation and ball movement code is all contained within an easy to access package any time you want (such as via a timer). So the proposed sequence would be Request permission to trigger animations when you get permission, call myFunction() start your 10 second timer in your myFunction(), you have the code to animate and move the ball for one throw-catch cycle in your timer event, simply call myFunction() That should be it! Also, because the avatar animation doesn't loop, it will end by itself - so you don't need to manually call llStopAnimation() for it. And definitely check out the thread Rolig linked - some good stuff in there.
  25. Fenix Eldritch
    That would require altering the loop logic you employ. Currently, you use a while loop, which can do what you want, but you must add additional commands to control the variables. I would suggest you consider using a for-loop instead, as I personally think it's a little easier to read in this situation. Basically: integer x = 0; for(x=0; x <= 10; x++) //this loop moves the ball up { //put command to increment prim's local position here //put command for 0.1 sleep here } for(x=0; x <= 10; x++) //this loop moves the ball down { //put command to decrement prim's local position here //put command for 0.1 sleep here }
×
×
  • Create New...