Jump to content

Fenix Eldritch

Resident
  • Posts

    766
  • Joined

Reputation

733 Excellent

1 Follower

Retained

  • Member Title
    Professional Novice

Recent Profile Visitors

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

  1. Without seeing the script in question, we can only make guesses. But it sounds like the animation script has been written with the expectation that the rabbit will be its own linkset not linked to anything else. A quick search for the mentioned product on the marketplace pulls up two entries by the creator, and one of them explicitly says as such: So I'd wager that is what's happening here. The warning about conflicts may not necessarily relate solely to interactions with other animations, but quite possibly also with the very linkset architecture. It likely uses functions that affect the entire linkset instead of just the rabbit object itself. Changing that is only possible if you can modify the script, otherwise you'll have to rip it out and replace it with a more compatible one. The fact that you are able to successfully link other similar products in the way you intend only indicates that those items were scripted differently from this one. It is worth pointing out that the other marketplace entry from the creator mentions they value customer service and encourage people to contact them if they have problems with their products. It may be worthwhile to reach out to them and see if something can be done from that end, as they would know their product and its limitations the best.
  2. As far as I'm aware, it is not possible for an LSL script to send group invitations such as the standard join popup directly to avatars. Rather, any time you do get that invitation, it's coming from another avatar. This includes automated scripted agents (avatars piloted by bots). So if you want a mechanism for sending the viewer's join-group popup to an avatar, you'll need to use a bot.
  3. In isolation, given the choice between your two options I imagine that option B might be a little bit more efficient. If you're going to store these in a list anyway, you could double dip by formatting said list as the input for llSetLinkPrimitiveParamsFast. That way, you don't have to do any processing on the timer part. Instead, just append the [PRIM_LINK_TARGET, x, PRIM_COLOR, face, color, alpha] to the list for each changed link as it is changed and then blindly call llSLPPF with the constructed list. And if the color of each link is the same, you could hardcode that part of the PRIM_COLOR parameter and not even bother looking up the link's color. Doing the above eliminates the need to iterate over a list and also unnecessary updates, as the list would only be populated with the links that needed to be changed.
  4. Sure, that's not terribly hard to do. The basic premise is that you need to somehow store the key of each person who takes an item during the day. Whenever someone tries to take an item, the script first checks if the person's key is in the database. If it is, we assume they've already taken today's item and disallow further attempts. Otherwise if the key isn't in the database, then assume they haven't taken today's item and allow it (but then add them to the database to block future attempts). Finally, run a 24-hour timer that clears the database so people can get items the following day. For storing keys, I'd recommend the LinksetData feature. You can use the associated functions to store, lookup, and clear entries that way.
  5. Just to add one last bit of info to fully answer the OP's original question... Larger than 64x "mesh" objects are not actually mesh, but rather megaprims that have been set as sculpted prims. Sculpted prims have the unique ability to change their geometry based on whatever sculpt map texture is currently applied, unlike mesh objects which are static after upload. So by taking an already huge megaprim and applying a custom sculpt map, people can create arbitrary* mesh-like shapes at larger than normal sizes. *arbitrary within the limitations of sculpties' capabilities.
  6. Unfortunately there isn't a setting that dictates by how much a particle stream is affected by the region wind. All we have is the flag which is either on or off - nothing in between. Though it might make for a good feature suggestion on the JIRA. I'm not in-world to experiment, but you might be able to fake it to some degree by reducing the particle's lifetime. The thought process being that a particle has a set amount of time to get from the emitter to the target and if it has less time to do so, that could equate to less deflection from the wind. Again, I haven't tested it, this is just me spitballing. Another approach could be to not use the wind mask at all, and instead simulate the swaying by gently rocking the emitter (using a looping KFM would be a low impact method - and can technically be done without a running script) in conjunction with the follow_src mask. Again, not in-world to test at the moment, but I think that might be possible.
  7. Additionally, emitter size also plays a factor. If the emitter prim is so small that it gets culled, so too will the particles it produces. But the solution here is as Frionil suggests: increase the particle size. Since you're using a ribbon, you can ramp of the Y size without visually affecting the ribbon. A value of 5.0 will make it visible out to a considerable distance (from my very quick test). In cases where you aren't using ribbons, the other option would be to use a particle texture that has its edges padded with empty/transparent space. That would create the illusion of a smaller particle. Amusing tangent: when I opened this thread the original post appeared with a forum timestamp of "7 minutes ago" while Frionil's response appeared with a timestamp of "2 hours ago". Thanks daylight savings!
  8. You can use the special constant PRIM_LINK_TARGET in the parameters rules list to (as the name implies) target other links with llSetPrimitiveParams function call. This allows you to make a more complex rules list that can simultaneously affect multiple prims at the same time in the linkset. //Demo - link 3 prims together and place this in the root. default { touch_start(integer total_number) { llSetPrimitiveParams([ PRIM_LINK_TARGET, 2, PRIM_COLOR, ALL_SIDES, <1.0, 0.0, 0.0>, 1.0, PRIM_LINK_TARGET, 3, PRIM_COLOR, ALL_SIDES, <0.0, 1.0, 0.0>, 1.0 ]); } } Normally, llSetPrimitiveParams can only target the same prim the script is in. But with the addition of PRIM_LINK_TARGET, you can make it instead target different links. See also llSetLinkPrimitiveParamsFast. In the example above, the script would be in the root, but you can observe how it only changes the color of links 2 and 3 and doesn't alter the root at all. You will need to discover the link numbers for the doors you wish to move, and should probably use llDetectedLinkNumber in the touch_start event as a filter to only try opening/closing the door when those specific links are clicked. As for automatic closing, see llSetTimerEvent. It's fairly straightforward: Start the timer when the door(s) are opened. In the accompanying timer event, stop the timer (so it doesn't keep running forever) and close the doors similar to how they were opened. It might be a good idea to add a global variable to keep track of the door's state and check/update that accordingly as well.
  9. From what I understand, a viewer's environment settings are purely local and can not be read by the server. At best, the server can override a target agent's environment via script (or parcel entry), but there is no guarantee those settings will be honored and/or won't be changed locally at any given moment. The viewer does not communicate such changes back to the server. Also, llGetSunDirection returns the parcel's env setting if a custom one is defined - otherwise it returns the region's setting. So you could configure your parcel to use a custom env and then script your lights to follow that.
  10. Regarding this point specifically, I would recommend to try making use of the various "linked" functions before resorting to llMessagedLinked between two scripts. LlMessagedLinked does have its uses, but these days it's quite possible for a single script to manipulate any other prim in the linkset via functions like llSetLinkPrimitiveParamsFast. The benefits to doing this are that you don't have to spread your logic across multiple scripts, and you avoid the extra setup/overhead of having to communicate between the scripts (and you avoid the 2nd script entirely). So it's potentially easier to code, maintain, and expand your script. Also, it's more resource efficient on the server to run fewer scripts.
  11. Yes, a large majority of the time, writing a custom script tailored for the specific task at hand will usually be more effective than using an off the shelf generic one. Knowing how to write one's own scripts is a very valuable and rewarding skill to have to SL - and fortunately there are many resources available for anyone wanting to learn. A good place to start would be the LSL 101 wikibook. It guides newcomers through the basics of scripting and assumes little to no prior programming experience. After that, exploring the LSL wiki in general, reading the functions' documentation, and trying the examples there will be a great way to practice. If you have specific questions/problems, feel fee to ask here on the forums (though soliciting for people to give you lessons may be more appropriate for the inworld employment forum). For your current windmill issue, a lot of it will depend on how the object is constructed. llTargetOmega is typically used to create a smooth and continuously rotating effect on objects. The function's specification tells us that if the host script is placed in a child link, then only that link will rotate around its local axis. If the script is placed in the root of the object, then the entire object will spin around the global axis. Regarding axes in Second Life, positive X is considered "forward" locally (or East globally), positive Y is considered "left" locally (or North globally) and positive Z is considered "up". Judging from your video, the windmill fanblades seem to be their own object. I can't say for sure without seeing the object in edit mode or the script you used, but it appears as though your current script is rotating the fanblades around the global Z axis. If that's the case, then I suspect the fix for you would be as simple as zeroing out the Z component of the vector supplied to llTargetOmega and instead putting some positive number in the X component of the same vector. Something like this: default { state_entry() { llTargetOmega(<1,0,0>,1,1); //spin about X axis } } If that doesn't work, try switching around which part of the vector is 1 (either the X, Y or Z parts) and observe how it changes the spin.
  12. I personally would not try to toggle the click action of the same prim like that... I think it would be safer to have dedicated prim buttons whose click action is set from the beginning and does not change. Less room for wonkyness, especially when dealing with payments. Because what happens if the dispenser is set to "click-to-pay-me" mode, but the user backs out at the last moment? You'd need a way to reset the device either on command or after a timeout.
  13. It is possible to make different prims in the linkset have different click actions. So you could have your dispenser setup with prim buttons using the default "touch" action that allow the user to select the desired item, and then have another prim set to "Pay Object" to serve as the checkout button which when clicked would bring up the pay resident GUI.
  14. LSL scripts are event based and single threaded - in the sense that one event can't interrupt another. Your script is in an infinite loop: it never finishes processing the while loop in the state_entry event. Because of that, it will never be able to process any queued up touch_start events, which is where you attempt to alter the loop variable. Instead of that while loop, consider using a timer. Timer events trigger automatically every x seconds, leaving time for other events to be queued up and executed in between. Alternatively, you could forgo any loop/timer and instead make a custom texture animation that has the same color changes for each frame. The benefit here is that texture animations are prim properties which do not need a script to sustain them. It's largely a local viewer effect: the script just starts the animation and that's it. The viewer will blindly animate the target face until another animation call is made with different parameters.
×
×
  • Create New...