Jump to content

Kelly Linden

Lindens
  • Posts

    123
  • Joined

Reputation

11 Good

1 Follower

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 have to include the libraries you want to use in C# using LindenLab.ServerScript; using System; // All scripts are a class that extends one of a selection of base classes. // The base classes decide what APIs are available and where the script could work. // This one works on an object. Some might be agent or scene(region) specific. public class AlphaChanger : ObjectScript { // Public fields in the base class get shown in the UI when editing public float HighAlpha = 1.0; public float LowAlpha = 0.4; public override void Init() { // Init is the place to set up callbacks and events. // There is a timer class, so here is one quick option. // Note that ChangeAlpha could be any method we create that takes a TimerData // Thus multiple timers are easy Timer.Create(TimeSpan.FromSeconds(2), ChangeAlpha); } public void ChangeAlpha(TimerData data) { // Hypothetical VisualObject is an interface to visual object APIs // This one has a hypothetical property to get and set the alpha if (VisualObject.Alpha == HighAlpha) { VisualObject.Alpha = LowAlpha; } else { VisualObject.Alpha = HighAlpha; } } } This is how I would probably actually write it in C#, but it is more dense and a little harder to read. // You have to include the libraries you want to use in C# using LindenLab.ServerScript; using System; // All scripts are a class that extends one of a selection of base classes. // The base classes decide what APIs are available and where the script could work. // This one works on an object. Some might be agent or scene(region) specific. public class AlphaChanger : ObjectScript { // Public fields in the base class get shown in the UI when editing public float HighAlpha = 1.0; public float LowAlpha = 0.4; public override void Init() { // Init is the place to set up callbacks and events. // This is a bit more dense, but C# supports anonymous methods inline so for simple actions on events this might be “easier”. Timer.Create(TimeSpan.FromSeconds(2), data => VisualObject.Alpha = (VisualObject.Alpha == HighAlpha) ? LowAlpha : HighAlpha); } } Lastly here is an overly fancy way to do it, that is overkill but some example of the power in Sansar's C#: // You have to include the libraries you want to use in C# using LindenLab.ServerScript; using System; // All scripts are a class that extends one of a selection of base classes. // The base classes decide what APIs are available and where the script could work. // This one works on an object. Some might be agent or scene(region) specific. public class AlphaChanger : ObjectScript { // Public fields in the base class get shown in the UI when editing public float HighAlpha = 1.0; public float LowAlpha = 0.4; public override void Init() { // Init is the place to set up callbacks and events. // We support coroutines, which are like mini scripts all themselves which can // be paused or wait for events independently of the rest of the script. // If you are doing something more complex than a toggle these can be a lot easier to read and write. StartCoroutine(ChangeAlpha); } public void ChangeAlpha() { // <side note here that this is overkill for this example, but is cool so I wanted to show it> while (true) { // Hypothetical VisualObject is an interface to visual object APIs // This one has a hypothetical property to get and set the alpha if (VisualObject.Alpha == HighAlpha) { VisualObject.Alpha = LowAlpha; } else { VisualObject.Alpha = HighAlpha; } // This will wait 2 seconds before continuing this loop. The rest of the script is not stopped. // For events there is also WaitFor(<event>) which would pause just this method until the event happens. Wait(TimeSpan.FromSeconds(2)); } } }
  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 expectations of using whole cushy libraries; imagine the "learning opportunity" about how memory- and compute-intensive are our usual application programs if they were to be squeezed into 64K chunks and given only their fair shares of sim frame time! In Sansar, though, there could be a somewhat different strategy for sharing resources, if I understand the business model correctly. That is, those who pay to deploy Sansar experiences just might have more flexibility in how they dedicate resources to one or another use. (Maybe.) If so, such deeper changes could materially enhance the programming environment in ways that SL and LSL couldn't reasonably achieve because in SL, the same quotas must apply uniformly to every script of every owner in every sim. Something similar may extend beyond the computing resources used for generating the Sansar experience to flexibility about how scripts are allowed to affect users, including permissions, expected graphics capacity, viewer features -- even viewer-side scripting. Finally, in an ideal world (for scripters), functionality would not be exposed to the viewer until it's also available to scripts. The idea of "bots" to perform rote functions should be obsolete; the risk of security or performance degradation should be handled the same whether triggered by script or viewer because ultimately they're the same threats. The resulting uniform API to the virtual world would enable fully scripted testing of all services at representative loads. Hmm. I didn't really set out to write a manifesto. Sorry if I made you sorry to have asked. I'm not sorry I asked at all. These thoughts closely align with my ideals. A "uniform API to the virtual world" is probably the toughest of them in practice, but it clearly has high value. More flexibility in resource management is also important, as well as better "permissions" models. Thanks for the reply. - Kelly
  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 not work for your own items, items owned by an estate owner or manager or items that are owned by the group the land is 'set' to. To protect some of our back end systems there are some fairly generous throttles in place. These functions should be able to return everything on your land within a region in one go, but not necessarily more than once an hour for such a large return. There is a required runtime permission. This is not a solution to griefing or 'grey goo' attacks. These calls can help with sandbox cleaning and automated rental property management. In some limited cases it may help with griefing cleanup, but the throttles mean it will only be effective after the cause is cleaned up or stopped. It is also not great for dynamic content (alife etc) because objects are returned to their owners inventory - there is no way to return to an object's contents or 'delete' an object with these methods.
  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 do not see anything unusual in the logs.
  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 unfortunate this this flag is really not in the right place to easily use and would require significant code refactoring - while probably a good thing to do it would require significant effort for development and testing beyond what you would naively expect. Expectations: It has never been expected that this flag would control online visibility to scripts and while it might be reasonable to extend it's features in this way changing the meaning of any long-standing feature should be undertaken with great care. Usability: it would be quite reasonable to only want scripts to have access, or only some scripts, or no scripts while still allowing profiles to show online status- none of which would be possible if re-using this flag. Even then it doesn't solve the very significant problem of item delivery and several other mentioned needs. In short: we are aware of that flag as an option and it is under consideration but is not as clearly an ideal solution as it may first appear to be.
  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 viewer uses internally. - Kelly Okay, then I assume those big warnings in lscript_library.cpp are for server-side code only? // When adding functions, they <b>MUST</b> be appended to the end of // the init() method. The init() associates the name with a number, // which is then serialized into the bytecode. Inserting a new // function in the middle will lead to many sim crashes. Phoenix 2006-04-10. // IF YOU ADD NEW SCRIPT CALLS, YOU MUST PUT THEM AT THE END OF THIS LIST. // Otherwise the bytecode numbers for each call will be wrong, and all // existing scripts will crash. Correct.
  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 systems designed to spam very large amounts very rapidly may hit it and need to be adjusted. We will be monitoring the effect of this throttle to adjust it as we can if needed. Security issues like this, especially of this grid wide severity, require that we act swiftly and without significant prior notice, for which we do apologize.
  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 actually defines those function IDs? It would really be helpful if the LSL Wiki would be updated more promptly. 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 viewer uses internally. - Kelly
  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_result id matches what you expect. If possible keep a list of IDs to handle the case of multiple transfers. A transaction can take up to a minute and still succeed.
  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 snobs still love to make an issue out of nothing. This is not a version of history that I remember. Some work was done towards memory limits, and it is still something we may possibly implement in the future. llSetMemoryLimit is indeed one piece along that road.
×
×
  • Create New...