Jump to content

Rider Linden

Lindens
  • Posts

    221
  • Joined

Everything posted by Rider Linden

  1. There is a feature request for this and I would like very much to get it into an upcoming simulator. I don't have any sort of ETA for you however. Nor do I have an explanation about why it was left off in the first place. BUG-6961
  2. The short answer is that sleep time is the mean amount of time in ms per simulator frame that the simulator has spent idling over the last minute. The long answer is that the simulators attempt to keep a constant number of processing frames (one cycle through the main loop) per second. This number is displayed in the statistics window as Sim FPS. This value is not the same as the Viewer's FPS. When the Sim FPS starts to fall below 45 you will begin to see lag events like delayed movement and rubber banding, among other symptoms. A single frame should take about 21ms. (21ms * 45) = ~1 second (less about 50ms overhead). If a single simulator frame takes less than that 21ms we need to add a few extra ms in order to maintain the constant rate. This extra time is reported as "Sleep Time" and tracks closely to "Spare Time". Every frame on the simulator is divided into a number of phases. The big ones are network message processing, advancing the state of the physics simulation, processing agents in the region and updating their interest lists, and executing scripts. The amount of time allowed per frame to execute scripts is capped. The simulator will attempt to execute all the scripts in the region in that allotted time slice, if it can not make it all the way through the list it will stop and pick up where it left off on the next frame (this gives you the "Scripts Run %" statistic.) Since the time for script execution is capped you can see situations where the % of scripts executed per frame begins to fall even though there is idle time reported on the simulator.
  3. Yes, All of the sun and moon functions (direction, rotation) and the day length day offset functions are EEP aware. The llGetRegion* (Sun/Moon)(Rotation/Direction) functions will always return the value for the region even if there is an environment set on the parcel. This family of functions are also altitude aware. This means that if the object containing the script is at 1100 meters and the region or parcel owner has set a custom environment at 1000 meters they will recognized the sun position from the custom environment.
  4. We had to reverse the RC and Main Channel rolls this week. That is likely what you encountered. https://community.secondlife.com/forums/topic/455707-deploy-plan-for-the-week-of-2020-06-01/
  5. The dates on the group notices is a known bug (BUG-228696 and others). A fix rolled to two of the Release Candidate channels yesterday (server version 2020-05-15T18:31:37.542403). Our plan is to roll that to the rest of the grid next Tuesday.
  6. He could send the object in question a message on a predetermined channel (llRegionSayTo) and add a script to your discovered object that would respond with a "yes, I'm your object". If you don't get the response back you know it isn't one of yours.
  7. Comments will never affect script performance. LSL is compiled into byte code and that is what is actually executed, comments are not included in the byte code.
  8. The sun and moon actually follow what is called a great circle path across the sky dome, which is the shortest distance between two points on the surface of a sphere. When projected to an observer on the ground this path can appear to be a curve. (This is actually the same reason that a plane traveling from SFO to London will go through the Arctic.)
  9. Conversation logs are stored on your local computer. The file with your past chat transcripts will contain the old name after a name change.
  10. In a nutshell, parts of the server were not expiring old names correctly. Rather than being time based it would keep a name cached until the entire server was either restarted or the server had collected more than 20,000 names and decided it was time to cull some of them (whichever event came first...) This has been corrected and names will be marked as stale after some period if time and then culled (or refreshed) a little while later. The entire process can take as long as 24 hours.
  11. It can take up to 24 hours for old names to clear out of the name caches on the simulators. There is also a bug that is fixed in 2020-04-10T18:39:41.540037 (currently deployed on the RC channels, but not SLS yet) involving names in the HTTP headers (SL-12900).
  12. It would appear that I did not correctly link the function up in the wiki (I will do so today.) llTargetEmail() is a convenience function that will send an email to certain "well known" agents if they have a verified email address associated with their profile. The two targets defined at this time are: TARGETED_EMAIL_ROOT_CREATOR Sends the email message to the creator of the root object in the linkset. TARGETED_EMAIL_OBJECT_OWNER Sends the email message to the owner of the object or linkset. More information can be found on the wiki: http://wiki.secondlife.com/wiki/LlTargetedEmail
  13. Environment Settings should not change at all going forward. All remaining changes are in the shaders to get the settings to display correctly.
  14. With EEP you can set your own environmental settings on any parcel that you own. You can do this now using the EEP RC Viewer (https://releasenotes.secondlife.com/viewer/6.4.0.536347.html) and any other EEP enabled viewer will be able to identify and display the parcel specific settings.
  15. In general, lines of code and comments have no impact on stack usage in the program. Although, larger programs (with more instructions) will produce more bytecode and reduce the amount of memory available to the stack and the heap. Comments are not compiled into the bytecode at all.
  16. @ItHadToComeToThis, You might be on to something actually. An LSL Programming blog of some sort. I might want to start out with just some basic "Programming 101/Basics" stuff but I could get into some of the deeper aspects too. Let me see what I can get organized.
  17. I believe that: integer i; i++; Will not increase stack size (the compiler is smart enough to do the right thing in this case.) foo(++i); bar(i++); For both of the calls above an integer is pushed onto the stack (LSL is a pass by value language.) for foo i would be increased by one and that value is pushed. for bar the value of i would be pushed and then increased by one.
  18. I would need to check, but I believe that the stack and the heap share the same memory address. Mukashi Mukashi, in langues like C, the heap would grow from up from the bottom of available memory and the stack would grow down from top, when the two overlapped you would get a stack/heap collision. I don't think it would be easy to change stack size without also changing the heap size. Heap usage shouldn't be permanent. If I have a list and I put 20 items into that list, each of those items is using some heap. If I then clear that list the memory used on the heap should be returned to the program and be available for other uses. (If this is not happening that would be a bug.) As to the problem with large bits of data coming in from outside the program (HTTP results, llGetStaticPath, etc) I wonder if there would be a way to let the program access those results as they are stored outside its own memory space. I will have to thing very hard about that since it could very easily have security implications.
  19. A minor correction. The Heap is used for run-time memory and global variables. So in your example list j; // Lives in the heap and j += message; // Will increase heap usage. i, is a "local variable" and does live in the stack. integer i; // Does live in the stack, modifying it (++i) changes the value in the stack but does not alter stack usage. If however you have a local variable of say type list: list local_list; // Lives in the stack, but its memory usage there is fixed local_list = local_list + [ "foobar" ]; // This actually grows the Heap The list itself lives on the stack, but the items contained in the list actually live in the heap. Once a function has set up its local variables on the stack their usage is fixed, any additional memory required needs to be allocated from the heap.
  20. Let's talk about what a stack and a queue are and then I'll discuss what they mean in the context of a running program. Stacks and Queues are both very similar data structures that are used extensively in software engineering. At a very basic level stacks and queues are just a list of "things". What those things are varies from use case to use case. You can add things on to the end("top") of one of these lists and take things off the end. In both stacks and queues things are always added to the end of list. The difference arises in how you take things off. In the case of a stack items are taken from the end of the list (Another name for a Stack is a "Last In, First Out" or LIFO List). A common image would be a stack of plates... You put a plate on the top of the stack after you've washed it, then when you need a plate you take the one on the top (Trying to take the bottom plate in this example usually leads to a very loud crash 😉) For a queue items are added to the end of the list and removed from the front. Queues are also called FIFO Lists for "First In, First Out". A common example would be a line of people waiting at the grocery checkout. The common terms for adding a thing to one of these lists is called "pushing" and taking a thing off is called "popping". Now, In the context of a running program. When a program calls a function it needs to know where it was called from so that it can return there when the function has finished. Most programming langues, including LSL, use a stack for this purpose. When the program encounters a function call it will push the address that should execute after the function is done onto the stack, along with all of the parameters that should be passed to the function. It then jumps to the function and begins running it. The first thing that function does is pop the parameters from the top of the stack. When it is finished it will pop the address that it should return too, push the return value (if any), and then jump to the address it was given. When the original code gets control back after the jump it pops the return value and continues on its merry way. LSL programs also process events. Events are things that happen at arbitrary times within the environment that the program is running, and the program must respond to these events. We can not arbitrarily interrupt the program in real time when an event occurs so instead we push that event and any data about it (who touched the prim, what was the chat message, etc) into a queue. Every frame the program looks at the queue to see if there are any events waiting. If there are we pop the next event and its data and call the event handler in the program to do whatever processing is needed by the program (at this point the stack takes over.) Since events are in a queue we know that they will always be processed in the order that they were pushed(FIFO). You, also asked for some clarification about how these interact with for instance a while statement. while is one of a family of instructions that are called "flow control statements" (others common examples would be for, if/else, and goto.) Flow control statements do not interact with the stack, they simply execute a jump to the next instruction. Here are some short videos on Stacks and Queues (and watermelons!) that I found.
  21. Correct. You can apply your planet texture using either the sun (SKY_SUN_TEXTURE) or to the moon (SKY_MOON_TEXTURE) depending on which of the satellites you would like to use as your planet.
  22. I can't go back 10 years but: Rider 2015. vs Rider 2020
  23. The sun and the moon are flat images on the sky dome. The only planet textures that I included in the library were one of Jupiter and "Blue Marble". But any that you make yourself should work.
  24. llRezObject and llRezAtRoot can produce that message. The '' at the end of the message seems to indicated that an empty string was passed as the first parameter to the function call.
×
×
  • Create New...