Jump to content

Rider Linden

  • Content Count

  • Joined

Community Reputation

484 Excellent

About Rider Linden

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. 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/
  2. 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.
  3. 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.
  4. 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.
  5. 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.)
  6. Conversation logs are stored on your local computer. The file with your past chat transcripts will contain the old name after a name change.
  7. 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.
  8. 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).
  9. 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
  10. Environment Settings should not change at all going forward. All remaining changes are in the shaders to get the settings to display correctly.
  11. 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/ and any other EEP enabled viewer will be able to identify and display the parcel specific settings.
  12. 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.
  13. @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.
  14. 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.
  15. 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.
  • Create New...