Jump to content

Fenix Eldritch

Resident
  • Content Count

    325
  • Joined

  • Last visited

Community Reputation

208 Excellent

About Fenix Eldritch

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. If you're new to scripting in general, it may be beneficial to go through some of the introductory tutorials on the wiki. But as for your latest code, do as Love Zhaoying suggest and remove that lone (integer) statement. It's not doing anything good there. I believe that should get the script to compile. Edit: oops, I missed the mismatched braces that KT Kingsley points out below. That'll definitely cause issues. Now consider what the goal of your script is. You had some code that originally was triggered when the owner clicked the object. Said code was contained inside a touch_start event. You wanted to make the trigger instead happen when the script "hears" a specific command spoken by the owner. You've already got the llListen and listen event setup, so all that remains is to move the code into the listen event. For reference, the state_entry is only triggered once, automatically when the script enters a given state. Your script only has one state (the default state) so that means its state_entry event will automatically trigger when the script starts up. That's why it's good to do your setup there, like setting the llListen handler. But after that, you want to just deal with the listen event. Does that make sense?
  2. Rather than using a touch_start event, you want to place your code within a listen event. And in order to make a script actually trigger listen events, you must set up a listen handler/filter with the command llListen. The llListen command requires several parameters which will act as a filter. This is important because you want to filter out as much chatter as possible so as to not accidentally trigger the event - similar to how your original code checks if the owner was the person who touched the object. The wiki pages I linked above can give you the full details on how to set this up, but for a quick example, the following code can set up a listen which will trigger when the object's owner speaks the word "command" in local chat and is within hearing range of the object. llListen( 0, "", llGetOwner(), "command" ); //sets up a listener filter for when the owner says "command" on channel 0
  3. Ah, yes it was the vehicle flag I was half remembering. I'm not very familiar with that, so others may be able to provide better advice. However if you intend to remove it completely, I believe you don't need to continually turn it off in the control event. Instead, you can set/remove the flag once at the beginning in something like the state_entry and then leave it be.
  4. Hard to tell what's going wrong without seeing the code, or getting a better picture of the expected behavior verses how it's misbehaving when you enter mouselook. Saying it's "just awful now" doesn't give us a lot of info to go on. But if I were to hazard a guess, I imagine you might be getting tripped up by the fact that the left/right arrow keys behave differently when you enter mouselook. Normally they trigger the CONTROL_ROT_LEFT and CONTROL_ROT_RIGHT respectively (these turn your avatar). But when you're in mouselook, they instead trigger CONTROL_LEFT and CONTROL_RIGHT (these strafe your avatar). So if your script doesn't account for that, that could be your problem... But again, I don't know how your script is expected to work in third person, so I can't say for sure without more info. In any case, yes, it's relatively simple to code your control event to behave differently when in mouselook or not. Use llGetAgentInfo to query the status of the target avatar and check the resulting bit field against the AGENT_MOUSELOOK constant. Separate your different control code with an IF ELSE statement. integer x = llGetAgentInfo(llGetOwner()); if(x & AGENT_MOUSELOOK) { //do mouselook control stuff } else { //do non-mouselook control stuff } Edit: Oh, wasn't there also some kind of mouse steering for vehicles? I vaguely remember something about that, but can't seem to locate it on the wiki...
  5. If you're looking to commission a scripter (or even get an estimate on what a potential job would cost) you really should be posting in either the Inworld Employment forum, or the Wanted forum. The LSL Scripting forum is geared more towards discussions of scripting tips/techniques/questions/etc between people writing their own scripts. If you were looking to write your own combat HUD and needed suggestions or guidance, then this would be the place to ask - but you'd need to be much more specific with what you where having problems with.
  6. Yeah, if your parcel is larger than that, that's another limitation
  7. So you basically want to avoid the overhead of a potentially lengthy list returned by llGetAgentList... I suppose you could circumvent that by using a sensor event, since the num_detected parameter can be used as an index to all targets sensed within the sensor sweep. You would need to iterate over num_detected and for each one, pull out the uuid with llDetectedKey and perform some operations on that single user to determine if they're over your land. If the target is over your land, increment a counter. As for how to determine if an individual avatar is over you land, one approach is to extract the target's position and check that position against llGetLandOwnerAt. Edit: I forgot that sensors only return the first 16 hits, so this may not be the most robust solution...
  8. llGetNumberOfPrims only returns the total number of prims in the linkset. That's not going to be very helpful here. For example, if you have ten prims in your linkset, that function will return the integer 10 every time. You were on the right track with using the KEY = llDetectedLinkNumber(0). Try taking your previous example and modifying the llSay to look like this: llSay(0, "linknumber " + (string) KEY + " pressed, and it's name is "+llGetLinkName(KEY)); The above code (when placed inside a touch event) will tell you the linknumber and the name of the prim touched. Now my previous suggestion depends upon placing copies of the sound assets directly into the piano's inventory. This is because we can rename them to match their associated piano key names. The LSL functions that actually emit sounds allow you to specify a sound either by UUID, or by the name of the sound file (as long as it exists in the object's personal inventory). So the idea here is to make a given key and its associated sound have the same name. For example, find the prim with linknumber 2 and in the build tool, rename the child prim to "KEY2". Then, get the sound asset you want for that key, place it in the piano (wherever the script will reside) and rename the sound file there to be "KEY2" as well. By doing this, we can eliminate the need for all those IF checks. Instead of checking "if key 2 is pressed, play this uuid" we can instead simply say: llPlaysound(llGetLinkName(KEY),1.0); The trick here is that since the specific key and associated sound have the exact same name, we don't need to do any tests. We just feed the prim's name into the sound function directly. Try adding that to your previous example.
  9. Now that I think more about it, you're probably going to want to have each key produce a unique sound, so it would become important to actually distinguish one key from another - whether by linknumber or name as you started to do earlier. (Apologies for leading you in circles) Building on your latest script, you could give each piano key a unique name and then make the associated sound file have a matching name. That way when you play it, you would supply the name of the currently clicked prim as the sound's name.
  10. Ah ha... whoops. Yes that would be rather important, wouldn't it? My mistake. There are a number of ways to approach this. You could use a compound IF statement that checks if KEY was equal to any of the desired linknumbers: if (KEY == 2 || KEY == 3 || etc...) Another way would be the give the piano keys a distinct name and check if the name of the currently pressed key was equal to that. See llGetLinkName. if (llGetLinkName(KEY) == "pianoKey")
  11. Firstly, you don't need to have all those IF statements. You already know what the currently touched key is, so use that KEY variable like this: llSay(0, "Key "+(string)KEY+" pressed"); llSetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL, llList2Vector(llGetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL]), 0) + <0.0, 0.0, 1.0>]); llSleep(1); llSetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL, llList2Vector(llGetLinkPrimitiveParams(KEY, [PRIM_POS_LOCAL]), 0) + <0.0, 0.0, -1.0>]); This will make the code flexible enough to apply the position movement to whatever key was currently pressed without needing to check through every possible key. Secondly, you could use llSetLinkPrimitiveParamsFast which is a variant of the function that doesn't have a built in delay on top of the explicit sleeps you have.
  12. Better than what? What have you tried first? Using llSetLinkPrimitiveParamsFast with the PRIM_POS_LOCAL constant and its associated parameters and targeting the clicked prim via llDetectedLinkNumber would be the typical approach.
  13. As far as I'm aware, there is only one function that can remove inventory items: llRemoveInventory() - but its scope is confined to the prim in which the host script resides. This means the function can't target other prims in the linkset. That is a considerable limitation, but if you reeaaallly want to force it, there may be a workaround. It's not pretty though. Hypothetically speaking, I suppose you could accomplish this by writing your script in such a way that it would initiate a "delete everything plus myself last" loop when it receives a specific message command. Then use llRemoteLoadScriptPin to inject copy of that script into each linkset of the object. Then send the aforementioned signal (like llMessageLinked or something similar). When all scripts hear the signal, they begin the deletion loop and should in theory, clean themselves up last. But that's a lot of effort compared to the viewer's menu command. Is there a particular reason why you're aiming for a scripted solution? Edit: Whoops, I completely misread how llRemoteLoadScriptPin works. See Wulfie's post below.
  14. llDetectedKey (and related functions) only work within a small subset of events - as per the wiki page specifications: So trying to use it in the run_time_permissions event won't work. If you want to reference the user's key that you detected in the touch_start event, you must store it in a global variable.
  15. The problem is in your run_time_permissions event. You are trying to start the nextDance animation, but that variable has not yet been populated. run_time_permissions(integer perm) { if (perm & PERMISSION_TRIGGER_ANIMATION) { if (lastDance != "") llStopAnimation(lastDance); llStartAnimation(nextDance); lastDance = nextDance; } } When you reset your script, your code immediately requests animation permission, which queues up the above event and the first IF statement passes. At this point in time, no variables have been updated, so lastDance and nextDance are still empty. So the second IF test fails. However, that only prevents "llStopAnimation(lastDance)" from being executed. The other two lines after that are not part of the IF statement, so they will still run and that's why your script complains - it's trying to start an animation called "" but that doesn't exist. Did you mean to group those two lines within the second IF statement?
×
×
  • Create New...