Jump to content

Kelly Linden

  • Content Count

  • Joined

  • Last visited

Community Reputation

10 Good

1 Follower

About Kelly Linden

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. C# in sansar will be a little more complicated to write, but also a bit easier to use. For example instead of configuration notecards, public variables are shown in the object's properties - right next to the rest of the object properties. The current API is pretty limited, and of note for your example there is no interface yet to the visual components of an object. So these examples are somewhat theoretical at this time. However except for VisualObject and its methods the below is how your script could look in Sansar. First is probably the closest to how LSL lays things out: // You
  2. Qie Niangao wrote: Kelly Linden wrote: Qie Niangao wrote: Unless there are much deeper changes than just a shift to C#, scripting in Sansar will have much the same limitations. Heya Qie, long time no chat. What specifically would you like to see addressed, in terms of deeper changes and limitations in SL and LSL? Hi Kelly, good to hear from you. I was referring to limitations inherent to any platform supporting user-generated scripts: the need to apportion resources among competing consumers by some quota system or another. In the context of C# for SL, some scripters had unrealistic exp
  3. Qie Niangao wrote: Unless there are much deeper changes than just a shift to C#, scripting in Sansar will have much the same limitations. Heya Qie, long time no chat. What specifically would you like to see addressed, in terms of deeper changes and limitations in SL and LSL?
  4. Lucia Nightfire wrote: So glad the scripted prim return functions are finally coming. I do have quite a few concerns about exploits and limitations. I'll bring them up at the next OH. Here are some general guidelines and thoughts regarding exploits and limitations: There are no cases where one of these new LSL calls would return an object that you could not manually return yourself. There are some cases where these new LSL calls will not return objects that you could manually return yourself:To prevent severely damaging accidents the mass returns by owner (llReturnObjectsByOwner) will no
  5. Adonis Adamski wrote: Hello Oskar Issues wearing attachment crossing from Frumatay to Thorklin. Happens every time but last occasion Friday 4 May around 02.50 hours (2.50am). Regards, Adonis I just had a look at both Frumatay and Thorklin. I am unable to reproduce the issue there. My attachments work if I log directly into either region and after TPing between the regions both ways. The last restart of Frumatay was 10 days ago, and Thorklin was 2 days ago. The regions appear healthy at this time, though thorklin is a tad on the script heavy side it is well within normal ranges. I also
  6. Levio Serenity wrote: I found another instance of a non backwards compatible change to llDeleteSubString() https://jira.secondlife.com/browse/SCR-306 -Tiger Right now llDeleteSubString uses the exact same code whether compiled to mono or not. As such the current behavior is the expected behavior, and the change is most likely a result of the relatively brief time when their implementations differed. If you can demonstrate a difference when compiled to Mono or not on the same region I would be interested.
  7. I believe Oz was hoping to stem the tide of armchair development on how we should fix it. It is far more valuable to us to hear how it is used. Hence why in what you bolded: "it's too soon for us to be talking about possible approaches". That said, using the existing flag for 'can everyone see my presence' is a very popular suggestion that I would like to briefly touch upon. I want to assure everyone that I have *absolutely* investigated that possibility. I think it has some significant downsides in the aspects of code complexity, expectations and usability. Code complexity: It is unfortuna
  8. Ansariel Hiller wrote: Kelly Linden wrote: Viewers do not produce bytecode. More specifically the Second Life servers will not accept bytecode from viewers: all compilation is done on the server from the source provided by the viewer. In the case of code compiled to mono the IDs aren't even relevant or used. The IDs are not needed for syntax highlighting. There is no reason for any viewer to need accurate function IDs. If the source code requires an ID for each keyword in its syntax table just make them up. They are generally monotonically increasing, but it really doesn't matter what a view
  9. Cincia Singh wrote: This rolling restart also broke thousands of mailing list products in SL; SVC-7631. Nice. Unfortunately some mailing list and product updaters may break or need to be updated. To stop a griefing mode that has effects on the entire grid's back end infrastructure a throttle was added to llGiveInventory. This throttle matches (but is separate from) the existing throttle on llInstantMessage and exists for nearly identical reasons. That throttle is 5k per hour per owner per region; the maximum burst is 2.5k. It is impossible to hit this limit with a single script, but syste
  10. Ansariel Hiller wrote: Oskar Linden wrote: I agree and the viewer team is aware of the issue. Since they operate on a different release schedule from the server team there can sometimes be a disconnect. We've been investigating other options for keeping the function list up to date. As for TPV's we have no control over syntax highlighting in their code. __Oskar But I have control over syntax highlighting code in Firestorm, but cannot add them without the risk of messing up the produced script bytecode without knowing the function ID so I can add them in the correct order. Question: Who a
  11. Lyle Maeterlinck wrote: I just wanted to say thanks for implementing this function. I think the ability to confirm a successful transaction before delivering a product is critical. We will be building this into the newest version of our affiliate vendors to replace the much more complicated system we currently have in place to confirm transactions. Glad you are finding it useful.
  12. Cold Spitteler wrote: SERVICE_ERROR is returned in some situations where the transaction was succesfull. https://jira.secondlife.com/browse/SVC-7623 This was determined to be an error in the lsl scripts and not a bug in llTransferLindenDollars. Specifically the scripter had added his own timeout which was shorter than the time a successful transaction could take and was not verifying the ID in the transaction_result message matched the one given by llTransferLindenDollars. This meant the script would associate the results with the wrong transactions. Always verify the transaction_res
  13. Imnotgoing Sideways wrote: To see if I'm reading this right... () "Returns 0 and does not move the object if position is more than 10m off region or above 4096m." Does this mean that there is a potential to position an object up to 10m into a neighboring sim, triggering a sim crossing? ( ) Correct. This function can be used to cross region borders.
  14. Lucinda Bulloch wrote: As Mr. linden said it will still take up 64k, once upon a time they were going to have script limits, they did a lot of work for it, created new instructions, then they found out that if they implemented them things like DCS would not work with all its magic and web sites, so they stopped, now in the very start of this I warned you of the macho game, seems within a few post you got caught in that trap. Don't worry to much, when it all came out in the first place I made detectors adjusted all my script then found out it wasn't going to happen. lol, but the script s
  • Create New...