|
|
|
I know the 2 second delay llInstantMessage is supposed to have is now gone. Thats the only one i've noticed. Perhaps they just haven't reached the point of putting in these artificial delays in yet.
I really hope they don't put the delays back in at all, particularly llSetRot. There are several scripting projects I had to abandon due to the artificial delays that I'd love to finish.
Yes, please "fix" this with care. Not all of these are necessary, and any script that breaks from a delay being missing technically has a bug in it anyway.
Aha, I was wondering when this kind of thing would happen. I'm expecting that we're going to see a fair number of scripts across the grid fail simply because they're running faster. If delays are removed (and I really hope they are!) then I think we'll also see a lot of scripts that depended on them start to behave badly.
It's a really tough tradeoff. I, for one, would love to see the end of script delays, but it's sure to break some content. I thought some delays were due to the time it took for that call to execute and weren't really a programmed delay.
Either way, I would prefer them to not exist as well (as long as operation remains consistent). If you really believe you need the delay you can always llSleep(). @lex
why would this break content? only new scripts will run on mono. old scripts will continue to run fine on LSL, and there are no plans to remove the LSL but instead allow for an option to migrate scripts into mono..... If it breaks, just don't check the box that says mono and it will continue to run as planned. Hopefully between the natural delays no longer exist due to LSL acting more efficiently and faster and except for maybe the grey goo fence on llRezObject and the delay on llInstantMessage for preventing object spam and IM spam respectively the artificial delays can be removed since they aren't needed either because script lag is almost non existent in mono even when doing very complex and long operations.
llSetPos() is also missing its 0.2 second delay.
llRemoteLoadScriptPin() doesn't have its 3.0 second delay. I can't say I miss the delays, as long as Mono is efficient enough that such delays aren't needed. I wonder.. because I AM seeing a time dilation (and Sim FPS, etc.) drop while using llRemoteLoadScriptPin() upon 12 prims. I will test it some more and probably open a new issue for that. It isn't as bad if I add a llSleep(1.0) after each llRemoteLoadScriptPin. It seems much better with 3.0 delay.. but there are some other things involved in my script, initialization of variables and such. I'll have to make a basic skeleton script and try it again. Some of the delays are due to server/client communications issues - I believe the .2 second delay on llSetRot, llSetPos, and llSetPrimitiveParams was of that nature. The basic point of it was that it was way too easy to flood the client with updates to primitive parameters. Of course, people started parallelizing them to smooth them out - but then again broadband got more ubiquitous.
Perhaps the delays need to be reconsidered - but not necessarily removed completely. At some of the reported rates of Mono code running - the Rot/Pos/PrimParams commands could easily brutalize the physics engine and the client rendering engine. Maybe the question would be, can we come up with a list of things that should be left as is, no delay, and things that need the delay re-applied? Also a linden dropping in and giving a response on if this is expected behavior because of mono or just something that was missed would be good.
I just did some testing with llRemoteLoadScriptPin, and I see a 3 second delay in using that function. Is this issue fixed already?
Now I am seeing a 3 second delay in llRemoteLoadScriptPin as well.
I can understand why you'd like these sleeps to be removed. However the aim of this project is to have compatibility with scripts that run under LSL2.
New API will be considered alongside any changes to the scheduler or languages. Scouse, when you say "new API" I hope you mean adding functions (like a new llSetRot) that take advantage of the new capabilities made possible with more efficient Mono-compiled scripts? I hope this is what you mean. I can see how it would be essential to maintain backwards compatibility by maintaining legacy interpretation of the artificial delays in these functions. I'm hoping you mean there will be replacement functions that people can use moving forward to allow, for instance, for reasonably fast motion control that is usually only possible to simulate in a limited subset of instances by using llTargetOmega for seemingly smooth motion?
I do hope a good compromise will be found. One question: the change, at least in llSetRot is only apparent when one compiles a script under mono. If one chooses to run it as is, at this point, without Mono, the legacy behavior appears to be preserved, consistent with how it runs on the main (gamma?) grid. I would be inclined to hope that whatever decision is reached, the speed advantages enjoyed under Mono would not be TOO artificially crippled. I really think the delays on llRemoteLoadScriptPin and llLoadURL are gratuitously huge. llLoadURL has a 10 second delay for some reason, that's really frustrating, to the point it requires a slave script to use in most cases.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Mono Beta: Functions Missing Delay
See the videos linked here for examples: http://www.youtube.com/watch?v=Oj7k2soTa6w