Jump to content

Fenix Eldritch

Resident
 View Profile  See their activity

  • Posts

    778

  • Joined

 Content Type 

Everything posted by Fenix Eldritch

  1. Fenix Eldritch
    Look at it this way: it could very well be a user error, but we don't yet have that information definitively. We don't know the exact conditions under which ItHadToComeToThis experienced their unexpected results. Again, it could have resulted from user error, but we don't know just yet. Rather than dismiss them out of hand and assume they tripped over the repeats/rotation caveat, I'd like to verify a little deeper. You may believe it's a waste of time, which is fine. I'm the one asking for the extra info, so it's my time to waste. Even if it ultimately turns out to be user error, it nothing else, it may help ItHadToComeToThis come away with a better understanding of the function and let them feel comfortable using it again. I'd say that's worth the time spent investigating.
  2. Fenix Eldritch
    Hence why I asked them to clarify. I wanted to see if it was a misunderstanding or an actual issue. There is no harm in performing a sanity check.
  3. Fenix Eldritch
    That does sound peculiar... I also wonuldn't expect screen resolution should have an effect on the results of llDetectedTouchUV. What issues did you see? Is this something you can still reproduce? If so, list the steps - I want to see if I can hit the problem too. If either of us can reliably reproduce the problem, it would be worth creating a jira bug report. The wiki page for llDetectedTouchUV does mention that the returned results will be different if the face's repeats and/or rotation settings are not at the default values, but I'm assuming you had already taken that into account, correct?
  4. Fenix Eldritch
    As a sidenote regarding the understanding of quaternions, there is a thread in the LSL Library forum which links to a video about them. I've been meaning to watch it, and I hear it's pretty good at explaining how they work.
  5. Fenix Eldritch
    I agree with Wulfie, if your intent is to use the texture animation functions to smoothly scroll an image across a prim face, you must use a texture which has been created/edited to not have a visible seam at its edges. This must be done outside of SL prior to uploading the image. Having said that, there are other approaches you could try to make a faux scrolling backdrop even if you don't have access to perfectly seamless textures. But they require some more work to hide the seams. As an example, instead of a single prim canvas, you could construct a diorama for your backdrop with props like telephone poles at regular intervals - especially at the edges of the canvas where the texture edges would fall. Using multiple copies of this diorama, you could script them to use key framed movement to non-physically slide themselves past the train car windows. Once one section has moved out of view, the KFM would put it back at the front, ready to slide past the windows again in a forever looping motion, similar to how the segments of an escalator move. The key here is that the edges of the backdrop texture would be obscured by linked props and thus help hide the obvious edge from casual observation.
  6. Fenix Eldritch
    Yep, a combo of custom gestures that speak commands on a hidden channel for another object to listen for and act on is one work around. Not as responsive as a true control event, but it's at least something. Regarding the actual controls, they use bitfields, meaning you could theoretically have up to 31 unique controls to capture. Currently 10 are implemented. So there is probably (at least as I understand it) room to expand.
  7. Fenix Eldritch
    Alas, it has been an often requested feature for a long time to have additional key inputs that LSL can detect. But as Rolig states, what you see in llTakeControls is all we have at the moment. However.... there is jira request to add in an "X action key", which apparently was implemented for the Oculus Viewer. I don't know much about how it worked, but I presume /hope if expanded it might extend to getting a proper LSL constant assigned to it for use in scripts.That jira appears to be in an accepted state, so it may actually happen... some day. And I've also made my own jira request for a few more control inputs as well. That jira has been in a "been triaged" state for a while. I don't know if that's good or bad, but I'm afraid to poke it, lest it get knocked into a rejected state.
  8. 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.
  9. 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?
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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
  15. 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.
  16. 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?
  17. 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.
  18. 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.
  19. 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.
  20. 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>]);
  21. 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.
  22. 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.
  23. 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?
  24. 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.
  25. 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).
×
×
  • Create New...