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: 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.