Chat log from the meeting on 2020-05-19

[11:13] Ubit Umarov: strange.. commit issue should be not starting
[11:14] Ubit Umarov: well can't tell, Bill lost on RL
[11:14] Gavin.Hird @grid.xmir.org:8002: it was impossible to move there
[11:14] Kayaker Magic: Anyone contacted Andrew? I saw him logging out at one point.
[11:14] Kayaker Magic: Speak of the devil!
[11:14] Ubit Umarov: you cna tell him now :)
[11:14] Gavin.Hird @grid.xmir.org:8002: here he is looking at ssomething in the sky
[11:14] Andrew Hellershanks: Finally got logged in. What an ordeal it was today.
[11:14] Gavin.Hird @grid.xmir.org:8002: Hi Andrew and MB
[11:14] Misterblue Waves: hello all
[11:14] Kayaker Magic: Um, Ubit, you have something stuck on your hand.....
[11:14] Ubit Umarov: normal opensim life :p
[11:15] Andrew Hellershanks: hehe, yea that's right, Ubit.
[11:15] Ubit Umarov: yeah a llmovetotarget test
[11:15] Kayaker Magic: The prroblem seems to be Dev Outreach. I can log in and TP to other places.
[11:15] Ubit Umarov: im breaking that again
[11:16] Ubit Umarov: well thats ugly at sl
[11:16] Ubit Umarov: if the avatar is already flying it does nothing there
[11:16] Gavin.Hird @grid.xmir.org:8002: makes sense
[11:16] Ubit Umarov: well for some odd reason our code is not doing well also
[11:16] Ubit Umarov: no it does not make sense
[11:17] Ubit Umarov: :p
[11:17] Ubit Umarov: nothing on wiki speaks about that
[11:17] Gavin.Hird @grid.xmir.org:8002: if you fly, you fly and don't want to bounce around
[11:17] Ubit Umarov: more chances on bouncing if on ground
[11:18] Ubit Umarov: and if we are standing it does make the avatar fly depending on target location
[11:19] Ubit Umarov: guess their issue is similar to the one we actually have
[11:19] Ubit Umarov: avatar special motor locking the avatar on air
[11:19] Ubit Umarov: wc selby.Evans
[11:19] Andrew Hellershanks: Welcome, Selby.
[11:19] Gavin.Hird @grid.xmir.org:8002: Hi Selby
[11:21] Misterblue Waves: a lot of the avatar logic is it guessing what to do based on movement and selections... and what action to guess is not always clear
[11:21] Ubit Umarov: well i only debug that on ubOde :p
[11:21] Kayaker Magic: Gavin: Is there a 64bit OS for the Raspberry Pi yet?
[11:21] Ubit Umarov: get lost on bullet
[11:21] Gavin.Hird @grid.xmir.org:8002: There is Ubuntu
[11:22] Gavin.Hird @grid.xmir.org:8002: but I have not tested it
[11:22] Andrew Hellershanks: The standard OS for the Pi isn't 64-bit?
[11:22] Gavin.Hird @grid.xmir.org:8002: they are working on a full 64-bit version of Raspbian, so far you can run with a 64-bit kernel
[11:22] Andrew Hellershanks hasn't booted any of his Pi's in a while.
[11:22] Selby.Evans @grid.kitely.com:8002: Thanks Andrew -- Hi everyone
[11:23] Gavin.Hird @grid.xmir.org:8002: not it is 32-bit for backward compatibility with all kinds of boards and addons
[11:23] Kayaker Magic: I want to restart my small OpenSim server project. Set them all aside for a while.
[11:24] Ubit Umarov: ms did all the pains of making windows 64 run 32bit as fine
[11:24] Ubit Umarov: linux people just decided to go 64b only
[11:24] Kayaker Magic: If I run Ubuntu on it, I assume I'll be on my own trying to get OpenSim to run under that?
[11:24] Gavin.Hird @grid.xmir.org:8002: Raspbian is running the saem on all machines made the last 7 years, so there is a bit of history there
[11:24] Ubit Umarov: 32b is still a lot better on many cases
[11:25] Gavin.Hird @grid.xmir.org:8002: also they currently don't have any machines with more then 4GB memory, so no real issue there either
[11:26] Ubit Umarov: physical ram has no direct relation
[11:27] Ubit Umarov: there is a thing called swap
[11:27] Andrew Hellershanks: Perhaps the next version of Pi will have a version with 8GB of RAM.
[11:27] Gavin.Hird @grid.xmir.org:8002: swapping to an SD card is not optimal...
[11:27] Ubit Umarov: it may not even swap
[11:27] Andrew Hellershanks: Gavin, I was going to say it is painful. :)
[11:27] Ubit Umarov: larger virtual memory space, can matter
[11:28] Gavin.Hird @grid.xmir.org:8002: most likely a 16GB version as 8 GB memory chips in the form factor they use are not available
[11:28] Ubit Umarov: so actual physical ram and "word size" don't relate
[11:29] Ubit Umarov: even on machines with more ram, there is no relation
[11:29] Ubit Umarov: and diferente cpus have diferent max physical ram suport
[11:30] Gavin.Hird @grid.xmir.org:8002: the IBM 1401 had 16k memory and 48 bit word size
[11:30] Ubit Umarov: still giving 64b virtual adress space
[11:30] Ubit Umarov: to use swap space was norm
[11:30] Ubit Umarov: when ram was smaller and expensive
[11:31] Ubit Umarov: sure, not on sd cards :)
[11:33] Kayaker Magic: Ubit: If I make a call to llGetNoteCardLine just before a script crosses a region border, Will I still get the dataserver event in the new region?
[11:34] Ubit Umarov: no idea
[11:34] Ubit Umarov: guess that does "die" on crossing
[11:34] Ubit Umarov: hmm or not
[11:35] Ubit Umarov: that request almost sure will die
[11:35] Kayaker Magic: Then you wouldn't know if an llHTTPRequest done just before a crossing would still do the request event on the other side.
[11:35] Kayaker Magic: *response
[11:37] Kayaker Magic: <crickets> anyone still here?
[11:38] Ubit Umarov: there is a event about crossings
[11:38] Ubit Umarov: not sure how those things survive or not at sl either
[11:38] Kayaker Magic: Yeah, I just wondered if I had to keep track and restart them myself.
[11:38] Ubit Umarov: guess i never tested that
[11:40] Kayaker Magic: While on the subject of crossings, I noticed that every time I cross a region border, llGetTime() gets reset to 0.0. There's no mention of that in the SL Wiki.
[11:41] Andrew Hellershanks: The LSL wiki says the event queue is cleared on a state change. Is a region crossing treated (in part) as a state change?
[11:42] Andrew Hellershanks: Kayaker, that sounds like a bug.
[11:42] Ubit Umarov: guess that depends also on engine
[11:43] Kayaker Magic: I'll submit the llGetTime as a Mantis. I was seeing that on XEngine, I'll try on Y also.
[11:43] Andrew Hellershanks: Probably buried in what happens during a region crossing.
[11:44] Ubit Umarov: thats a issue.. main clock is machine dependent
[11:46] Kayaker Magic: On busy regions with lots of scripts running, reading notecards, calling llSetKeyframedMotion, etc. Under these conditions I'm seeing llGetNoteCardLine fail a lot. It just never calls the dataserver event.
[11:47] Kayaker Magic: I'm having to set a timer and re-submit the get line. Worries me I might request the same line twice.
[11:47] Andrew Hellershanks: Could it be an overflow of the event queue?
[11:47] Kayaker Magic: Is there an INI setting to make that queue larger?
[11:49] Ubit Umarov: and our gettime seems relative to script engine start
[11:49] Ubit Umarov: not script time
[11:49] Andrew Hellershanks: There is MaxScriptEventQueue but, IIRC, that is per script. It would take a lot to exhaust it.
[11:50] Gavin.Hird @grid.xmir.org:8002: Open Mic, Andrew
[11:50] Andrew Hellershanks: You got to hear me typing. :)
[11:50] Gavin.Hird @grid.xmir.org:8002: yup :-)
[11:51] Kayaker Magic: Hmm, I usually call llResetTime when I use llGetTime, never noticed time was not reset at script reset.
[11:51] Andrew Hellershanks: If it had happened earlier you would have heard my cat. :)
[11:51] Gavin.Hird @grid.xmir.org:8002: :-))
[11:51] Andrew Hellershanks: Kayaker, llGetTime() is based on the runtime of the script.
[11:52] Andrew Hellershanks: The LSL wiki says -> Returns a float that is script time in seconds with subsecond precision since the script started, was last reset, or call to either llResetTime or llGetAndResetTime.
[11:52] Ubit Umarov: sorry it is relative to script start
[11:52] Kayaker Magic: and apparently border crossing, at lease on XEngine
[11:53] Ubit Umarov: yengine does not reset it on script reset
[11:53] Ubit Umarov: guess neither does X
[11:54] Andrew Hellershanks: That's a change in expected behaviour. The function is documented in the wiki as resetting the time when the script is reset or if either of llResetTime or llGetAndResetTime is called.
[11:54] Object: Touch to start
[11:54] Object: 0.001000
[11:54] Object: Touch to start
[11:54] Object: 5.709000
[11:54] Object: Touch to start
[11:54] Object: 7.896000
[11:54] Object: Touch to start
[11:54] Object: 9.242000
[11:54] Object: Touch to start
[11:54] Object: 13.220000
[11:55] Ubit Umarov: nopes.. no clear on reset on X either
[11:55] Ubit Umarov: you told u to touch my thing?
[11:56] Andrew Hellershanks: Another mantis to file?
[11:56] Ubit Umarov: sounds like it :)
[11:57] Kayaker Magic: I'll test in X and Y and submit a mantis about the region crossing reset of llGetTime
[11:57] Ubit Umarov: crossing or tp are other story :)
[11:57] Andrew Hellershanks: Hm... it resets on region crossing when it probably shouldn't but it doesn't reset when it should?  :)
[11:58] Ubit Umarov: it is not serielized
[11:58] Ubit Umarov: so does not cross
[11:58] Andrew Hellershanks: I have used the GetTime and ResetTime functions in a script. I don't remember which of my scripts used it.
[11:58] Kayaker Magic: It does reset when I call llResetTime. I never tested script start.
[11:59] Ubit Umarov: reset time is about it
[11:59] Ubit Umarov: bigger bug if it did not reset
[12:00] Ubit Umarov: the on reset guess its a easy fix
[12:00] Ubit Umarov: well kinda
[12:01] Andrew Hellershanks: It may be something in the Stopwatch object handling.
[12:03] Misterblue Waves: I haven't been very talkative and it's time for me to bug out...
[12:03] Misterblue Waves: see ya all later
[12:03] Kayaker Magic: One last question for me today: Does anyone have experience with the INI setting ObjectsCullingByDistance?
[12:03] Andrew Hellershanks: Oh, I see what it is doing. LSL_Api.cs has a variable m_timer which it sets to Util.GetTimeStampMS() as the base time used by llGetTime.
[12:04] Andrew Hellershanks: ok, Bye, Misterblue.
[12:04] Kayaker Magic: Does OjectsCulling have the same effect as setting your viewer draw distance?
[12:05] Ubit Umarov: keep that off for now
[12:06] Ubit Umarov: "work for future" :)
[12:06] Ubit Umarov: well it kinda works
[12:07] Kayaker Magic: OK, good to know
[12:09] Andrew Hellershanks: Any other items for todays meeting?
[12:10] Kayaker Magic: Nope, I'm good!
[12:10] Andrew Hellershanks: That will do it for another week. Thank you all coming. See you again next week.