Chat log from the meeting on 2018-02-27

[11:09] James.atLLOUD @hg.osgrid.org: Ferd Frederix (SP) was on Mal's show sunday and he seemed mighty respectful of the core devs. Good things to say. [11:09] Andrew.Hellershanks @hg.osgrid.org: This past week there were some messages in the IRC channel that indicated the new script engine is getting some testing. [11:10] Andrew.Hellershanks @hg.osgrid.org: James, that's good. [11:10] George Equus: Heard something about MySQL crashed the other day... didn't notice anything myself [11:11] Andrew.Hellershanks @hg.osgrid.org: An issue was mentioned regarding the new engine. Not unexpected that there would be some problem. At least the code is being tested to problems can be found and fixed. [11:11] James.atLLOUD @hg.osgrid.org: Andrew, can you describe the script engine again? I get confused with LSL, OSSL but I think that's not it. [11:12] Andrew.Hellershanks @hg.osgrid.org: The scripting engine used to run LSL and OSSL is XEngine. The new one is called MMREngine (IIRC). I don't currently have the httptests branch checked out. [11:12] James.atLLOUD @hg.osgrid.org: OH! it is then. OK, many thanks. [11:12] Andrew.Hellershanks @hg.osgrid.org: yw. [11:13] Andrew.Hellershanks @hg.osgrid.org: That new scripting engine is considered experimental. Scripts will need to be recompiled if you use it. [11:14] TG.Lucan @hg.viewtwo.net:8600: httptest suggests that other developments are included any details of those? [11:14] Kayaker Magic: What are the advantages of it? Has llSleep been fixed? [11:15] Andrew.Hellershanks @hg.osgrid.org: TG.Lucan, that branch was created by Ubit to allow him to test out some HTTP related changes. Since then, it is the branch where he has been doing most of his current work. [11:16] TG.Lucan @hg.viewtwo.net:8600: Would you know if it will work with the current robust as an attached region? [11:16] Andrew.Hellershanks @hg.osgrid.org: Kayaker, It has changed the way threading is done and a function like llSleep won't have the problem it has in XEngine. [11:16] Kayaker Magic: Yay! [11:17] Andrew.Hellershanks @hg.osgrid.org: TG.Lucan, I'm not aware of any changes that would prevent it from being used as an attached region. Best way to find out is to try it. :) [11:18] TG.Lucan @hg.viewtwo.net:8600: true, just trying not to screw the existing setup, without loading a completely new grid [11:20] Andrew.Hellershanks @hg.osgrid.org: TG.Lucan, backups are your friend. :) [11:20] TG.Lucan @hg.viewtwo.net:8600: ha [11:21] Leighton.Marjoram @grid.opensim.life:8002: I think it can be enabled on a region basis so it should not effect your robust. As far as I know. [11:21] Andrew.Hellershanks @hg.osgrid.org: I just checked out a copy of the httptests branch. It appears that Ubit is renaming (or at least referring to) the new scripting engine as YEngine. [11:21] Leighton.Marjoram @grid.opensim.life:8002: X and Y Engine [11:22] Andrew.Hellershanks @hg.osgrid.org: Yes, he did rename it on the 23rd. [11:22] Kayaker Magic: LOL [11:22] James.atLLOUD @hg.osgrid.org: very nice [11:24] Leighton.Marjoram @grid.opensim.life:8002: If I enable the new Engine do I need to do the "delete scripts at startup" in the OpenSim.ini? [11:25] Leighton.Marjoram @grid.opensim.life:8002: for the first startup of the region. [11:25] Andrew.Hellershanks @hg.osgrid.org: The log of the httptests branch indicate some changes regarding face counts for tortured prims. That would be changes arising from what we talked about last week. [11:25] Andrew.Hellershanks @hg.osgrid.org: Leighton, yes. As I mentioned earlier you will need to recompile all scripts. That would be a good way of ensuring it happens. [11:25] TG.Lucan @hg.viewtwo.net:8600: That is also in master, if I recall correctly [11:25] Leighton.Marjoram @grid.opensim.life:8002: Ah ok thanks Andrew [11:26] Andrew.Hellershanks @hg.osgrid.org: I don't see a reference to the new engine in the master branch. [11:26] Andrew.Hellershanks @hg.osgrid.org: My cat is wanting attention from me. :P [11:26] TG.Lucan @hg.viewtwo.net:8600: face counts [11:27] Andrew.Hellershanks @hg.osgrid.org: oh, face counts. Let me check... [11:27] TG.Lucan @hg.viewtwo.net:8600: a few more changes on tortured prims number of sides/faces [11:27] Andrew.Hellershanks @hg.osgrid.org: yes. There are changes for face counts in master. [11:27] James.atLLOUD @hg.osgrid.org: I wonder if cats count faces [11:28] Leighton.Marjoram @grid.opensim.life:8002: only if they want something from that face :) [11:28] James.atLLOUD @hg.osgrid.org: more likely tails [11:28] James.atLLOUD @hg.osgrid.org: true [11:28] Andrew.Hellershanks @hg.osgrid.org: Not sure. Mine was watching some of the olympics on a couple of occasions when she was on the table sitting in front of my monitor. [11:29] James.atLLOUD @hg.osgrid.org: oh, smart cat. [11:29] Leighton.Marjoram @grid.opensim.life:8002: I could have as many faces as I wanted as long as one of them fed my cat she's happy. [11:29] TG.Lucan @hg.viewtwo.net:8600: I share my desk with a cat, she has her own patch :) [11:31] Andrew.Hellershanks @hg.osgrid.org: Mine likes to park herself in front of the monitor. Not too bad if she lies down but makes it hard for me to see when she is sitting up. [11:32] Andrew.Hellershanks @hg.osgrid.org: I'm not sure when the code here will be updated to include the changes affecting face counting. [11:33] Andrew.Hellershanks @hg.osgrid.org: It will be interesting to see whether the changes have fixed the texturing issues shown here last week. [11:34] James.atLLOUD @hg.osgrid.org: it will - it seems such an odd thing to have changed, though I've not done much texturing of late [11:35] Andrew.Hellershanks @hg.osgrid.org: I haven't done a lot of prim torturing of late. Just the basic type of changes. [11:37] James.atLLOUD @hg.osgrid.org: Andrew, are there other commands likely to be improved by the threading of the new script engine? [11:38] Andrew.Hellershanks @hg.osgrid.org: I didn't know such a thing existed until about a week or so back when it was mentioned in an email. [11:38] Bill.Blight @grid.opensim.life:8002: If we are talking about XMR/Yengine, I can tell you that state changes in scripts are much faster [11:38] Andrew.Hellershanks @hg.osgrid.org: Yes, we were just talking about YEngine. Ubit renamed it a couple of days ago. [11:38] Leighton.Marjoram @grid.opensim.life:8002: its great fun, there are two days left one party tonight and the HG Safari are going all out Cornflakes tomorrow. [11:39] Andrew.Hellershanks @hg.osgrid.org: Kayaker had asked about how it handles llSleep. [11:39] Bill.Blight @grid.opensim.life:8002: Load up the llsleeps it just doesn't seem to care [11:39] Andrew.Hellershanks @hg.osgrid.org nods [11:40] James.atLLOUD @hg.osgrid.org: cool [11:40] Andrew.Hellershanks @hg.osgrid.org: With XEngine the way to show the problem with llSleep was to use one in a handler for a timer event. [11:40] Bill.Blight @grid.opensim.life:8002: I ran a test with a box that slept talked and slept and talked then counted, then talked, then looped, left it running for 4 days [11:41] Andrew.Hellershanks @hg.osgrid.org: No problems with script runtime and no region crash? [11:41] Bill.Blight @grid.opensim.life:8002: no region crash [11:41] Andrew.Hellershanks @hg.osgrid.org: I wonder how long the region would have lasted under XEngine. Perhaps it would have stayed running but the script runtime would have been high. [11:41] Kayaker Magic: I had a friend that set up 1000 Xmas lights, each one llSlept(1), blinked on llSlep(2) blinked off and repeat. [11:42] Bill.Blight @grid.opensim.life:8002: script times look funky to the viewer because of the way it reports, but NO they were not out of control [11:42] Kayaker Magic: Locked up all the scripting threads, releasing them for a narrow window every once in a while. [11:42] Andrew.Hellershanks @hg.osgrid.org: Kayaker, that type of script is best handled by a timer where you have 1 or 2 second event times and a flag to say whether to turn lights on or off. [11:43] Bill.Blight @grid.opensim.life:8002: yeah I use timers and llGetWallclock and some math for things like that [11:43] Leighton.Marjoram @grid.opensim.life:8002: shudders lol [11:44] Andrew.Hellershanks @hg.osgrid.org: No math would be needed for a simple light flash script. Just a flag to say whether lights are to be turned on or off in the timer handler and to say whether the next timer event should be 1 or 2 seconds in duration. [11:44] Kayaker Magic: Oh, I know how to blink lights, had to educate my friend. Of course it was a free script from SL. And worth at least what she paid for it! [11:44] James.atLLOUD @hg.osgrid.org: lol [11:44] Andrew.Hellershanks @hg.osgrid.org: Yeah, it sounds like the type of script someone would get from SL. [11:45] Andrew.Hellershanks @hg.osgrid.org: Just the sort of script that some of us get paid to fix. :) [11:46] Andrew.Hellershanks @hg.osgrid.org: Another point on the topic of scripting... I received a report today that there could be a problem with some of the LSL calls that manipulate prims in a linkset. [11:47] Andrew.Hellershanks @hg.osgrid.org: The calls may not be checking for out of range prim number references. I haven't had a chance to investigate. [11:47] Kayaker Magic: llCreateLink and llBreakLink? [11:47] Andrew Hellershanks: llSetPrimitiveParamsFast [11:48] Andrew Hellershanks: All functions that manipulate prims will need to be checked. [11:48] Bill.Blight @grid.opensim.life:8002: that should not even know about linksets [11:48] Bill.Blight @grid.opensim.life:8002: llSetLinkPrimitiveParamsFast should know about linksets [11:49] Andrew Hellershanks: The person who reported the problem had a script where a bug caused them to pass a prim number of 0 when dealing with a linkset. In a linkset the root prim is 1 and not 0. [11:49] Bill.Blight @grid.opensim.life:8002: that may be a viewer bug, it used to happen with FS all the time [11:49] Kayaker Magic: 0 and 1 both refer to the root prim. [11:49] Bill.Blight @grid.opensim.life:8002: They fixed that a few versions back [11:49] Andrew Hellershanks: The case reported to me was a bug in the persons LSL script. [11:50] Bill.Blight @grid.opensim.life:8002: I have not seen that in a long time .. [11:50] Andrew Hellershanks: Kayaker, that is something I'd have to see written down in some doc. A single prim has a number of 0 for the "root" prim. Once the prim is linked to other prims, the root prim has a number of 1. [11:51] Bill.Blight @grid.opensim.life:8002: if it was a common thing my vehicles would blow up a lot [11:51] Bill.Blight @grid.opensim.life:8002: LOL [11:51] Andrew Hellershanks: I don't know whether using 0 would be valid in a linkset. [11:52] Andrew Hellershanks: Bill, your vehicle scripts are changing prim parameters for the root prim in a linkset where you refer to it as prim 0? [11:53] Bill.Blight @grid.opensim.life:8002: I never call it zero, I usually just call the LINK_THIS constant [11:53] Andrew Hellershanks: That is for message passing. That's a different situation. [11:53] Bill.Blight @grid.opensim.life:8002: umm [11:53] Bill.Blight @grid.opensim.life:8002: also for params [11:54] Bill.Blight @grid.opensim.life:8002: it is in the spec for llSetPrimitive params [11:54] Bill.Blight @grid.opensim.life:8002: *link [11:54] Andrew Hellershanks: I don't recall seeing use of things like LINK_THIS or LINK_OTHERS in the calls to set params. It might work based on the defined values for those constants. [11:55] Bill.Blight @grid.opensim.life:8002: http://wiki.secondlife.com/wiki/LlSetPrimitiveParams [11:55] Bill.Blight @grid.opensim.life:8002: scroll down [11:55] Andrew Hellershanks: I've always referred to prims by number. [11:55] Bill.Blight @grid.opensim.life:8002: but you are right the root should be 1 [11:55] Bill.Blight @grid.opensim.life:8002: not disputing that fact [11:56] Andrew Hellershanks: ok. That list doesn't show a LINK_* with a value of 0. [11:56] Andrew Hellershanks: Use of the value 0 is the possible problem. [11:56] Bill.Blight @grid.opensim.life:8002: integer   link    –    Link number (0: unlinked, 1: root prim, >1: child prims and seated avatars) or a LINK_* flag [11:56] Bill.Blight @grid.opensim.life:8002: root prim should always be one, in a link set as stated, so yes this is a problem if it is not being reported that way [11:57] Andrew Hellershanks: The problem was one of trying to set the properties of prim 0 in a linkset. [11:58] Bill.Blight @grid.opensim.life:8002: yeah that is not going to work [11:58] Bill.Blight @grid.opensim.life:8002: never has [11:58] Bill.Blight @grid.opensim.life:8002: not supposed to work [11:58] Andrew Hellershanks: I'll be running some tests later today or tomorrow to see if I can reproduce the problem. [11:58] Andrew Hellershanks: No, the code should just ignore the invalid prim number. [11:58] Bill.Blight @grid.opensim.life:8002: just as that says in a link set there is NO zero [11:58] Bill.Blight @grid.opensim.life:8002: right [11:58] Bill.Blight @grid.opensim.life:8002: I agree Andrew [11:59] Bill.Blight @grid.opensim.life:8002: but if you script right, you will not be passing an invalid parameter anyway [12:00] Bill.Blight @grid.opensim.life:8002: Personal opinion this is an education problem not a code problem [12:00] Andrew Hellershanks: Right. The person who had the problem has very complex scripts. That is why they wound up with a bug in it that had the wrong prim number reference. [12:01] Kayaker Magic: No, you have to make the system respond in a meaningful way to idiots. At the least, it should display a debug message on an invalid link number. [12:01] Andrew Hellershanks: Kayaker, Right about that second part. No comment on the first part. :) [12:02] Bill.Blight @grid.opensim.life:8002: I agree and disagree Kayaker, if we spend too much time "idiot proofing" the code, then that is less time spent on fixing meaningful bugs .. Sorry to put it so bluntly [12:02] Andrew Hellershanks: We have hit the top of the hour. Any last minute thoughts before we wrap it up for this week? [12:03] Andrew Hellershanks: Bill, that is true. If the bad values don't cause any major problems then protecting against bad values can be put off for later.