Charliedru Lannock

Perhaps an option to pay an additional fee (extra $2.50 USD for under $5000 USD cashout, and $5.00 USD for $5000 and higher cashouts) in order to have an instant transfer to paypal. Alternatively, LL could calculate correct amounts that would cover the interest they would lose by not holding the USD for an extra 7 days. Just a suggestion. Waiting 1-2 weeks is difficult for the ones who have their RL business in SL. CDru

Oh great to find this thread! I just posted a suggestion right here a little while ago thinking I was doing this wrong, haha. Good to know about this. I'll have to post that on the JIRA as well.

It's possible this is in the wrong forum / topic, since I'd like to suggest this idea to LL as a new function for LSL because I want to do very awesome things with this. It'd be nice to have a flag that is OBJECT_SIT_TARGETS with the following functionality: list object_targets = llGetObjectDetails( objUUID , [OBJECT_SIT_TARGETS] ); This function should return a list / array of vector sit targets for the object being scanned. The order of the list should be as such: Option 1) Strided List in format Link Number, Vector, Rot: object_targers = [linkNumber1, vector1, rot1, linkNumber2, vector2, rot2, linkNumber3, vector3, rot3..., linkNumberN, vectorN, rotN]; Where 1,2,3, ... , N represents the amount of Sit Targets for this object, with the limit of returns being N=5 (or 15 entries, to be conservative for script memory). Option 2) Normal List in format Vector1, Rot1, Vector2, Rot2, ... , VectorN, RotN, where the Index for each 2 entries is the Link Number. (Possible if sit target parameter is a prim property and cannot hold multiple values for the same prim, which is how I believe the system works...I think stuff like AVSitter retains the multiple sit targets only in LSL memory and just manually positions avatars based on how many are seated). However, Option 1) would allow you to return say, only link numbers 3, 6, and 20 for an object that only has for example 3 sit targets and 20 prims. A list of single entry ZERO_VECTOR should be returned for an object with no Sit Target. Purpose of this function: This function would allow prims or objects to scan for Avatar Sit Targets on other prims (not part of the same object / LSL script). Even prims owned by others. This would enable your object to know the Sit Target and adjust itself accordingly. For example, in the case of breedable pets, the pet could detect the sit target then "Sit" on the prim itself. Using a method to detect if an avatar is sitting on the prim currently, or simply using CastRay you could auto-adjust the "Pet" to properly sit on the lap of an avatar seated on a prim, according to the prim's properly Sit Target. Thanks for reading. I hope something like this gets made. CDru EDIT TO ADD: I noticed that I can post this now on the JIRA as a "New Feature" thanks to a post that was pretty much right below this one, lol. Will do this soon, good to know there's an official method to recommend this. Any feedback from others users is also welcome. After all, they probably won't implement it without the votes. xD

This is excellent information and exactly what I needed! Thank you very much, LepreKhaun!

Hmm, interesting. From what I understood, it was still in Beta with an opt-in program for private sim owners on the main grid to allow pathfinding in their region to assist with the testing prior to launch. As per Server Release Notes on RC BlueSteel, RC Magnum, and RC LeTigre, they are still performing updates on pathfinding and installing new features (Last was on 2013-06-19). http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_BlueSteel/13 My focus on pathfinding not being released was only regarding the restrictions of CastRay which were announced by Falcon Linden to be disabled when pathfinding is released. By released, I wasn't sure if it was meant Grid-Wide release, or this Opt-In Program for some region owners, which isn't actually an official launching from my understanding, or I'd be able to use it commercially, grid-wide. My main worry is the llCastRay limitations, but thanks for bringing this to my attention, Rolig. It is possible that the llCastRay limits were disabled when pathfinding was released in this Beta phase (as the post was dated back May, 2012). I'm still interested if anyone has any experience with limits on high volume of cast rays in short periods of time. Would be of great help and it'd save me a lot of trial and error time testing it out. Wouldn't want to have any scripts break down someday during an event with people present, lol. ^^

I am curious about CastRay limitations before venturing into a commercial project. I have researched the Jira SCR-199 (https://jira.secondlife.com/browse/SCR-199) regarding reduction/removal of llCastRay limitations. However, the last that was posted by Falcon Linden on 26/May/12 was the following: "The resource pool limits have been disabled on pathfinding regions and will be removed gridwide when pathfinding is released. The 'region performance too low' has not been change. Note that that you should still check for all error codes as the limits may be reapplied if we discover performance problems, though I no longer expect that to happen." Pathfinding has not yet been released grid-wide, so I believe the pool limits are currently active on the main grid. If they are disabled upon release of pathfinding, then it may be possible they are activated again in the future. Venturing into a major commercial project would be difficult without some further understanding of the current limitations and possibly long term limitations... So finally to my question: I plan on having anywhere between 50-200 objects on a private sim casting rays upon a user's click. On click, each object will cast anywhere from 1 to 5 rays. User might click multiple times, causing more rays to be casted by the object. Performance must be real-time, therefore I cannot sleep the script in any measure above a fraction of a second. Rays would be filtered to detect other prims whether scripted or non-scripted. Not agents, not land. On top of ray casting on click, objects will cast rays on their own in the same range of 1-5 casts, but not at regular intervals. It could take 3-7 seconds before auto rays are cast for each individual object. I am curious exactly as to how fast llCastRay replenished its pool. The wiki states a frame, but I am unfamiliar with a time value with respect to a frame. Would 200-1000 rays every 2-3 seconds be too much for the current and/or possible future limitations of llCastRay? Any help would be appreciated, thanks. CDru

llJsonGetValue and llJsonSetValue work, but they seem to be limited for what I needed. Funny thing though, a Json object is just a string. You can easily use a do loop to populate the string as necessary, or llSubStringIndex to find a particular field in the string and modify it to your liking. Format is something like: { Entry1:[Var1 for Entry1, Var2 for Entry1, ..., VarN for Entry1], Entry2:[Var1 for Entry2, ..., VarN for Entry2] } Can populate your list using llJsonSetValue or converting a list and then use llOwnerSay to report the Json string. Gives you an idea how the data is stored. I also found some good info here: http://wiki.secondlife.com/wiki/Json_usage_in_LSL