Jump to content

JoyofRLC Acker

Resident
 View Profile  See their activity

  • Posts

    176

  • Joined

  • Last visited

 Content Type 

Posts posted by JoyofRLC Acker

    llGetNotecardLineSync()

    in LSL Scripting

    Posted

    15 hours ago, Love Zhaoying said:

    I know someone posted awhile back that they had a 6502(?)/6510(?) emulator in LSL.. I think they wrote that they could run assembly code from game ROMs or something like that. I was a little jealous until I realized, yeah and they did that WITHOUT LinksetData... (I like where I am now better).  Like you said, not that much of a masochist.

    For real masochism there was always the Iverson APL formal description of IBM 360 in just  a few pages.

    • Like 1

    llGetNotecardLineSync()

    in LSL Scripting

    Posted

    Ok, Ill bite 😀

    What do people use NC (in scripted objects for)?

    In my case its

    1.  Settings (rarely > 10 lines)
    2.  Help - size varies but never read into memory just a llGiveInventory

    So what are these mammoth NC used for?

    llGetNotecardLineSync()

    in LSL Scripting

    Posted

    Another question about cacheing - and apologies if this is a silly question.

    The cache is server specific?  Even for an attached HUD?  So if an agent moves to another sim then the NC has to be cahced all over again?

    llGetNotecardLineSync()

    in LSL Scripting

    Posted · Edited by JoyofRLC Acker

    For me, the issue is more about simplicity (or lack of) in code structure as much as speed of reading NC lines.  This is rarely a time critical task (and if it is perhaps its the wrong tool).  We seem to have half a loaf in that a DS event of some sort has to be raised in order to ensure the NC is cached, or we need some exception handling etc. 
    In coding remember  SSSS - Simple Structure Saves Sanity   😀 

    I have an alternative suggestion, but I fear this ship has sailed as it were.

    string llGetNotecardLineAmbiguous(string name, integer index, integer wait)

    If the NC is cached the result (data or EOF) is returned right away;
    if it is NOT cached then,
    - if wait == TRUE the server pulls the NC into cache and then returns the requested line (or EOF; or NAK if the NC does not exist)
      so yes there may be a delay (as there would be for the DS event to be raised)
    - if wait == FALSE the server returns NAK immediately

    (yes NAK is overloaded, better to have different constants for "NC doesnt exist" and "NC not cached")

    What do people think?

    PS:  small prize for coming up with a better name!!  My first try was using Ambivalent but i realised that is literally inappropriate!

     

     

    Deploy Plan for the Week of 2021-10-18

    in Second Life Server

    Posted

    Ok Im really not getting the joke in the "release note".  Is this just 'maintenance' or something more?

    Especially i the context of :

    "

    Update - Scheduled maintenance is still in progress. We are aware some regions are taking longer than normal to come back online. Thank you for your patience!
    Oct 19, 07:50 PDT
    "
    (emphasis added)

    Deploy Plan for the Week of 2021-03-15

    in Second Life Server

    Posted

    One big question, which Ill try to get Simon to answer is ... what is the relative impact of the new code for each case of a border crossing

    Old > New
    New > Old
    New > New

    Right now Id say its all looking pretty good so maybe the better question is when will this to to Main Channel.

    Also, is there any expected benefit to agent detaching and other sorts of collateral damage?  (ie Im not sure if thats just a possible comsquence of a slow crossing or if it can occur for other reasons.

    • Like 1

    Deploy Plan for the Week of 2021-03-15

    in Second Life Server

    Posted

    Im confused.   ("What else is new, I hear you ask).

    I think my first question should be, as Ive been a bit out of touch, is - how can I tell if a region is RC or Main channel.   I dont see it on the window nav bar and The server_channel argument to llGetEnv seems to return "Second Life Sever" everywhere.  Alternatively is ther ea list of which sims are in each channel?

    As I understand it - RC channel should have 556847 and main channel should have 556255,

    The reason Im looking into it is that I had thought that 556847 was only on beta grid and it had some sim crossing improvement code.  But Im actually seeing 556847 on a lot of main grid sims ( Blake Sea etc ).

    Yesterday I observed dramatically improved sim crossings compared to the previous few weeks.  Looks like the improvements made it to RC channel.

     

    Deploy Plan for the Week of 2020-11-09

    in Second Life Server

    Posted

    We have filed tickets, with this response "We have escalated the regions with the trouble you have noticed and hope they will resolve the issue soon. Is there anything else that Support could help with today, as we are not able to alter anything in development?"

    i wasnt aware that the updates to the main grid are "in development" LOL

    my basic question is - how is this update going?   does not seem like "This update has a couple of cloud configuration changes; these may improve some of the performance metrics, but otherwise should not be anything user visible"

    Deploy plans for the week of 2020-09-28

    in Second Life Server

    Posted

    The 10 day thing is normally Tuesday I believe.  I am still not clear what maintenance was scheduled for today.

    I do have an explanation for what was happening in Blake this afternoon (EDT) ... we had requested that a couple of down sims in Blake be restarted (at about 11:30 SLT or thereabouts.  I gather that the CSR noticed a number of sims had not been restarted for 10 days and decided to do unscheduled restarts on all of them two, thus causing us to abandon our racing.

    However this has nothing to do with whatever was started at 9 am SLT.

     

    Blake Sea is now up on Aditi!

    in Second Life Server

    Posted

    6 hours ago, animats said:

    The "fix" that affected the main grid has to do with objects, not avatars, crossing. So it looks like the big winners there are people with large vehicles. I'm not seeing any improvement on the main grid for motorcycles and a small helicopter. Still getting random fails just driving around.

    The faster crossings on the beta grid AWS areas work fine.

    If you're a vehicle scripter, please take a look at BUG-229231 and see if this would affect you. Thanks.

    The improved performance seems to be persisting.   I'm measuring the "freeze time" at the border (as opposed to the agent detach / attach time), and that is regularly under 0.4 seconds now, usually under 0.2, versus 4 - 7 seconds before (on a Trudeau 12m yacht - 92 LI, 992KB script memory plus 400KB for HUDS).

    The other thing that seems to have changed is that when the agent fails to re-attach, I'm finding that I can TP back on to the boat with about 90% success rate (cam is a little messed up and you're stuck in mouselook mode, but the boat is responsive to gestures etc) - previously the success  rate of getting back on was < 20% for me.

    The bottom line is that we now have a very much higher % of boats finishing a race, and many more without falling off.

×
×
  • Create New...