Chat log from the meeting on 2021-12-07

From OpenSimulator

Jump to: navigation, search
[11:02] Ubit Umarov: hi
[11:03] Selby.Evans Hu Jamie
[11:04] Gavin.Hird Hi Jamie
[11:04] Jamie.Jordan Hi everybody
[11:04] Selby.Evans hi jamie
[11:07] Ubit Umarov: well andrew seems a bit late
[11:08] Vincent.Sylvester Gonna throw peanuts at him
[11:08] Ubit Umarov: as you sure know, last sunday 5th, we did release version
[11:08] Gavin.Hird /clap
[11:09] Gavin.Hird when is the release party?
[11:09] Vincent.Sylvester Ubit Umarov are looking at it lol
[11:09] Ubit Umarov: yeah lol
[11:09] Ubit Umarov:
[11:10] Ubit Umarov: devel version is now Dev
[11:10] Vincent.Sylvester Changelog is quite extensive compared to previous, so long that even after going through git history I still haven't found everything worth mentioning
[11:10] Ubit Umarov: like already on this regions
[11:10] Gavin.Hird as festive as the covid booster
[11:10] Ubit Umarov: ops
[11:10] Ubit Umarov: devel version is now Yeti Dev
[11:10] Ubit Umarov: :)
[11:10] Vincent.Sylvester Squashed quite a few bugs that have been sitting around for years
[11:11] Vincent.Sylvester One of the more productive releases I'd say
[11:11] Ubit Umarov: well almost two years since
[11:11] Gavin.Hird He's been on it night and day (with some help of course)
[11:12] Vincent.Sylvester Also a lot of future proofing going on behind the scenes as things move toward newer standards which is always useful in reducing overheads and prevent some things from just not working anymore
[11:13] Vincent.Sylvester YEngine becoming the default now providing a much nicer baseline for scripting overall
[11:13] Ubit Umarov: :)
[11:13] Ubit Umarov: ofc all of you already know it
[11:13] Ubit Umarov: you are using it or a derivative
[11:14] Ubit Umarov: like zeta and kitely
[11:14] Ubit Umarov: or xmir :)
[11:14] Gavin.Hird xmir is fully in Y
[11:14] Gavin.Hird no changes there, only a few eep omissions
[11:14] Vincent.Sylvester I have flooded Ubits inbox with patches lately that should hopefully bring some useful changes for the next release once he gets around reading them
[11:15] Ubit Umarov: oh i was talking about version
[11:15] Gavin.Hird mius EEP
[11:15] Gavin.Hird minus*
[11:15] Ubit Umarov: :)
[11:16] Gavin.Hird so if anyone wants a de-eep-ed version...
[11:16] Ubit Umarov: zeta usually follows Dev
[11:16] Ubit Umarov: kitely usually waits for a release, but this time did incorporate some time ago
[11:16] Ubit Umarov: because it is needed for new viewers
[11:17] Vincent.Sylvester I build patches on top of core directly so I don't have to deal with merging each change, that drove me nuts
[11:17] Ubit Umarov: so thanks you all for your help :)
[11:18] Vincent.Sylvester From the changes to release notes it sounds like the plan is to more regularly do releases now?
[11:18] Gavin.Hird hehe - wasn't that the plan the last time around also?
[11:19] Ubit Umarov: well i had plan to release  last year
[11:19] Ubit Umarov: so.. well lets see :)
[11:19] Ubit Umarov: like happened with, may be released soon
[11:20] Ubit Umarov: depending on number of issues ppl may report now
[11:20] Ubit Umarov: i already made a change on it :)
[11:21] Ubit Umarov: on even simple standalones need do set a region with flags Default
[11:21] Ubit Umarov: that info is only on the release notes
[11:21] Vincent.Sylvester Plenty of issues also still on mantis, but quite a few are the works to attempt to reproduce so they have been sitting there for years, really needs more status types to sort things as stale, needing testing etc
[11:21] Ubit Umarov: so on that will not be necessary again, depending on a new option i added
[11:23] Ubit Umarov: thing is that if at login no "oficial " region is found to send the user 2,  code just sends to any region it finds online
[11:23] Ubit Umarov: as you can imagine that can be a big privacy violation, etc..
[11:23] Vincent.Sylvester It can also fail if the region is misconfigured
[11:23] Ubit Umarov: so will not do that..
[11:24] Gavin.Hird or big embarrasment depending...
[11:24] Ubit Umarov: may do it acording to that new option
[11:24] Ubit Umarov: yeah
[11:24] Ubit Umarov: a old opensim issue
[11:24] Ubit Umarov: but to totally block the option as i did on
[11:25] Ubit Umarov: so..  added the option, with recomendation to only let it set true where that does not matter
[11:26] Ubit Umarov: so this was first code added to :)
[11:26] Ubit Umarov: one day and bits after the release ;)
[11:26] Vincent.Sylvester post fixes all over
[11:26] Gavin.Hird I thought incrementing the version number was the first
[11:27] Ubit Umarov: well i stop suing the name postfixes on versions
[11:27] Ubit Umarov: minor number on version, means small changes of bug fixes
[11:27] Ubit Umarov: i never understud how we could only have a xxx-postfixes version
[11:27] Ubit Umarov: kinda over optimistic :p
[11:28] Ubit Umarov: as oyu noticed also stopped the release candidates stage
[11:28] Ubit Umarov: they where not getting any extra feedback
[11:28] Ubit Umarov: so just waste of time
[11:29] Gavin.Hird how can you have a release candidate to something that is in beta?
[11:29] Gavin.Hird :-)
[11:29] Gavin.Hird or is it alpha?
[11:29] Ubit Umarov:
[11:29] Ubit Umarov: well we had those
[11:29] Ubit Umarov: even RC1, RC2..  etc
[11:30] Vincent.Sylvester At this point if you still want to call it an alpha then I wonder what the heck Win11 is, cause that works far less reliably
[11:30] Ubit Umarov: just normal simple version numbers do it all
[11:30] Gavin.Hird Win11 is a boot sector virus
[11:30] Ubit Umarov: as i said the minor digits mean minor changes etc
[11:30] Ubit Umarov: like most software does
[11:31] Vincent.Sylvester I consider a beta something you can run that won't randomly decide to explode if you leave it alone
[11:32] Ubit Umarov: as you see on the old release cycle the version to release was even placed
[12] Ubit Umarov:  on a branch called..  xxx.postfixes
[11:32] Ubit Umarov: well now i place a release on a branch with its version number
[11:33] Ubit Umarov: like brack 0.9,.2.0 on git has the code released
[11:33] Ubit Umarov: branck
[11:33] Gavin.Hird I call it a beta when it still does not realize it runs in  a virtual machine, and comes with all kinds of weired recommendations based on  when it has seen it running - such as when best to apply updates
[11:33] Ubit Umarov: yeah i can't type...  branch :)
[11:34] Ubit Umarov: and on similar point o master there is the tag0.9.2.1Dev to mark start of work
[11:34] Ubit Umarov: well i think this is more "clean" do you?
[11:35] Ubit Umarov:
[11:35] Ubit Umarov: shows the braching and tag :)
[11:35] Vincent.Sylvester I'm waiting for the influx of mantis issues other folks blowing the irc channel up, release was so quiet in a way it seems no one noticed thus far
[11:36] Ubit Umarov: well a lot of ppl only looks to a release
[11:36] Ubit Umarov: and is ppl with other use cases etc
[11:36] Vincent.Sylvester Mantis needs a bit of love I feel, some more status tags and updating the version numbers
[11:36] Ubit Umarov: so normal to get more bug reports
[11:37] Vincent.Sylvester What's left on open issues needs a better structure to see what's what
[11:37] Ubit Umarov: lets see how it goes and if we do need to release even this month lol
[11:37] Ubit Umarov: if a major issue is found ( and we can fix )
[11:38] Vincent.Sylvester I would love just a "needs testing" tag to flag issues for review either after getting fixed or what reproduction is a ton of work
[11:38] Ubit Umarov: on mantis?
[11:38] Vincent.Sylvester Yes
[11:38] Gavin.Hird user feedback required
[11:38] Ubit Umarov: well a lot of ppl ignores all that
[11:39] Ubit Umarov: fun sameone told me he only sees version up to 0.9,1,1 to set
[11:39] Ubit Umarov: i did add and and i do see them
[11:39] Vincent.Sylvester I just want to bring more structure to it so it gets easier to see what still is an issue now and to make it clear to people looking to help what they can do to help
[11:40] Vincent.Sylvester There are probably a few dozen issues buried in it that should be looked at, but finding them and confirming them is a lot of work
[11:40] Vincent.Sylvester Like all the freeswitch issues, reproducing that is near impossible now that freeswitch becomes ever harder to setup it seems
[11:40] Ubit Umarov: oh hope all is ok with Andrew
[11:40] Ubit Umarov: or his cat
[11:41] Vincent.Sylvester Probably fell asleep somewhere
[11:41] Vincent.Sylvester winter does that to you
[11:43] Vincent.Sylvester With the cleanup I been doing I buried a few important issues that were submitted, need to find and bump those back to the top I think
[11:44] Gavin.Hird such as?
[11:44] Vincent.Sylvester Especially that weird behavior with the object caching is something that gets annoying when it happens
[11:44] Vincent.Sylvester I need to get back to testing, I disabled that cap for the region it was happening the worst on to see if that yields better results
[11:45] Vincent.Sylvester Disabling it viewer side seemed to help, but that's not ideal
[11:45] Gavin.Hird I never see weird object caching
[11:45] Gavin.Hird are you sure it is not a viewer issue?
[11:45] Ubit Umarov: some viewer side options on that are broken
[11:45] Ubit Umarov: never used at SL, so ignored
[11:45] Vincent.Sylvester I think it's viewer not understanding data it gets sent
[11:46] Gavin.Hird ok, does it log anything?
[11:46] Ubit Umarov: here is sleepy Andrew
[11:46] Ubit Umarov: :)
[11:46] Vincent.Sylvester I have some debug log I have to put in and see what it does, but I suspect that will say everything is fine as is
[11:46] Gavin.Hird Hi Andrew
[11:47] Andrew Hellershanks: Hello, everyone.
[11:47] Vincent.Sylvester Either the call gets malformed on the way to the viewer or the viewer fails to understand it
[11:47] Andrew Hellershanks: I was doing some work using my laptop and forgot about what day it was.
[11:47] Gavin.Hird but what happens?
[11:47] Ubit Umarov: opps
[11:47] Ubit Umarov: i forgot about the region log :)
[11:48] Vincent.Sylvester Well basically what happens is older prims that are in cache in the viewer can be edited just fine from the perspective of the region
[11:48] Gavin.Hird now we have to start over again
[11:48] Ubit Umarov: ok andrew can make a summary of what we said :)
[11:48] Vincent.Sylvester But when you force the viewer to redraw the prim it uses the cached version which still shows the previous state of the prim
[11:48] Gavin.Hird force the viewer to redraw the rpim?
[11:49] Vincent.Sylvester Zoom out real far and back in
[11:49] Vincent.Sylvester I posted a video on how to reproduce it to the mantis which shows what happens
[11:49] Gavin.Hird how often do you flush changes to persistent storage?
[11:50] Vincent.Sylvester On the region it's fine, you edit, that change takes when you nuke the viewer cache it all looks fine, it's definitely local viewer cache messing up
[11:50] Andrew Hellershanks: ty, Ubit.
[11:50] Vincent.Sylvester What's odd is that there seems to be code to tell the viewer to purge the object from cache
[11:50] Vincent.Sylvester Let alone the viewer itself is editing the prim so it should know to purge it from cache and retrieve a new copy instead
[11:50] Gavin.Hird why is that odd
[11:51] Gavin.Hird cache is ment to be purged or invalidated at any time
[11:52] Vincent.Sylvester It's probably there to make sure things are purged, but in regards to testing this issue it is strange the viewer doesn't do this itself as well, knowing which prim is being edited so knowing that it shouldn't used the local cache version afterwards yet it still does
[11:52] Gavin.Hird if your change has not been written to persistent storage and you do something that force the viewer to invalidate the caceh and retrieve it from persistent storage, you will lose cahnges
[11:52] Gavin.Hird so you need to set your region to write your changes back to the db more often
[11:53] Vincent.Sylvester The edit on the region works properly that's not the issue, you can verify this using physics
[11:53] Gavin.Hird so where does it not work?
[11:53] Vincent.Sylvester I scaled a prim down to reveal terrain underneath and when I had the viewer redraw the prim showing the original size the part I scaled back became phantom
[11:55] Vincent.Sylvester
[11:56] Vincent.Sylvester Ubit been telling me to leave object cache enabled for performance reasons, though outside of particularly slow regions I don't really see much difference in that, perhaps I am more patient than others when it comes to waiting for a region to load
[11:57] Vincent.Sylvester It's just driving me mad when you make changes to something, turn around to have them all undone and you gotta nuke cache and relog each time
[11:57] Ubit Umarov: i see caching working fine most the time
[11:57] Gavin.Hird I don't think ti was undone in your example, because wjhen you walked around there after the zoom, you came to the point where you stepped up to the resized prim
[11:58] Gavin.Hird it is a drawing problem in the viewer
[11:58] Vincent.Sylvester Yep like I said on the region itself the edit sticks just fine, the viewer just doesn't follow because it grabs the cached version
[11:58] Ubit Umarov: yeah that clip is irritating ofc
[11:58] Gavin.Hird but I don't see the point of those zooms?
[11:59] Vincent.Sylvester Forces redrawing
[11:59] Gavin.Hird for what purpose?
[11:59] Vincent.Sylvester So it triggers cache fetch
[11:59] Ubit Umarov: and that is not even viewer cache
[11:59] Gavin.Hird why?
[11:59] Ubit Umarov: that is in memory things
[11:59] Gavin.Hird exactly Ubit
[12:00] Vincent.Sylvester That's the thing, disabling viewer object cache in the viewer directly entirely removes this behavior
[12:00] Gavin.Hird why do you want to trigger cache fetch?
[12:00] Vincent.Sylvester After doing that I couldn't get a single prim to "misbehave" in that manner
[12:00] Gavin.Hird did you only test this in FS?
[12:01] Gavin.Hird or does other viewers behave the same
[12:01] Vincent.Sylvester I have not tested with other viewers so far
[12:01] Gavin.Hird ok, but FS has a very particular cache implementation
[12:01] Gavin.Hird so it could be an issue there
[12:02] Gavin.Hird also I still don't get the need to trigger a cache feetch
[12:02] Gavin.Hird fetch
[12:02] Vincent.Sylvester Because when you work on something it randomly does that while you aren't looking and then you turn around to see all the changes you made half an hour ago seemingly undone when they actually aren't
[12:03] Vincent.Sylvester Made me question my sanity first few times I saw that
[12:03] Gavin.Hird never, ever experienced that
[12:03] Vincent.Sylvester The mantis ticket exists simply to track this on OpenSim end and to get verification that OpenSim does send proper information
[12:03] Gavin.Hird what is the size of the region you work on?
[12:03] Vincent.Sylvester var or normal doesn't matter happens on both
[12:04] Gavin.Hird ok
[12:04] Gavin.Hird have you tweaked the occlusion settings in your viewer?
[12:04] Andrew Hellershanks: Allow me to interject a quick reminder. The Open Simulator Community Conference is this weekend. Check out the web site at for the schedule of events.
[12:04] Vincent.Sylvester Did tell FS devs about this, but haven't heard back, guess I will open a ticket on their end in this regard to get the ball rolling
[12:05] Vincent.Sylvester I have ambient occlusion turned off
[12:05] Gavin.Hird that was not what I meant
[12:06] Gavin.Hird objects off camera can be occluded to speed up rendering
[12:06] Gavin.Hird typically things behind you
[12:06] Gavin.Hird but also objects hidden by others
[12:07] Vincent.Sylvester Outside of disabling object cache I haven't changed viewer debug settings yet
[12:07] Gavin.Hird ok
[12:08] Gavin.Hird how much GPU memory have you allocated for the viewer?
[12:08] Vincent.Sylvester There is a setting for that?
[12:08] Gavin.Hird there is for texture memory
[12:09] Vincent.Sylvester That's set to 512 mb
[12:09] Gavin.Hird ok
[12:09] Gavin.Hird how much GPU memory do you ahve?
[12:09] Vincent.Sylvester Not sure if that has bearing on it, but worth a try I guess
[12:10] Vincent.Sylvester Regular Nvidia 1080 so not all that much and it has to drive 4 screens so probably got 2-4gb left ot play with
[12:11] Vincent.Sylvester Like I said merely opened the mantis so we can rule out OpenSim as the cause of this if it does indeed send proper notice to invalidate an object that's been edited
[12:11] Gavin.Hird I think I have heard LL say the viewer code is not particularly happy with GPU memory over 4 Gb, but I might be wrong
[12:12] Ubit Umarov: well opensim did sent right information, you seen prim change size
[12:12] Ubit Umarov: and the zoom is 100% viewer side
[12:12] Gavin.Hird yes it is
[12:12] Vincent.Sylvester Yep from going through the support code for object cache I didn't find anything that stuck out to being a potential cause for this if it wasn't working right
[12:13] Ubit Umarov: so..  vodoo
[12:13] Vincent.Sylvester I will make a note to poke FS via a ticket as I haven't gotten a return on my email yet
[12:13] Ubit Umarov: guess not easy to try repo similar circunstances at sl
[12:13] Gavin.Hird I think it might be the viewer does not invalidate the cached item when it is persisted to the region,
[12:14] Vincent.Sylvester That would be my guess too
[12:14] Ubit Umarov: if you relog the prim is as it was edited
[12:14] Ubit Umarov: no ?
[12:14] Vincent.Sylvester Not always, but more likely, if I nuke cache it definitely is as it fetches it from region
[12:15] Gavin.Hird but there is caching in the viewer, but also in flotsam, yeah?
[12:15] Ubit Umarov: so region just did its thing..
[12:15] Vincent.Sylvester I made some experiments leaving cache and just disabling caching system, mixed results there and I don't know the internals of what causes it to invalidate it either
[12:15] Ubit Umarov: nothing to so with flotsam
[12:15] Ubit Umarov: prims are not even on it
[12:15] Gavin.Hird ok
[12:16] Vincent.Sylvester This issue has been around for years now, I have seen that first time all the way back in 2017 even
[12:16] Ubit Umarov: ( unless if rez from inventory possible )
[12:16] Vincent.Sylvester It must be something small just a missing line somewhere in the viewer code, but chances of me finding that within the decade are slim
[12:17] Gavin.Hird but in any case it should be invalidated in the viewer cache when persisted to the region
[12:17] Ubit Umarov: i remember there was a viewer cache option that did show prims, if we did move away and back.. boing all gone till relog :)
[12:18] Ubit Umarov: i show a fs dev..  answer was " why did you set that option.. it is not used.."
[12:18] Ubit Umarov: done :)
[12:18] Andrew Hellershanks: As you are talking about viewer behaviour and caching I'll add in a comment/question in case it might be related.
[12:19] Andrew Hellershanks: I was noticing the other day that after I logged in to a region some of the textures were blurry (because they had not fully loaded yet?). I forced a texture refresh and they fully loaded and looked good. A few moments later they went blurry again then eventually fully loaded once again and looked ok.
[12:20] Andrew Hellershanks: It seems a bit odd that a fully texture would "unload" and need to be loaded a second time.
[12:20] Gavin.Hird texture trashing
[12:20] Gavin.Hird too little texture meory most likely
[12:21] Vincent.Sylvester Dayturn used to do that for me quite a bit, few releases ago it stopped though
[12:21] Andrew Hellershanks: I hadn't moved. It was like a given texture wasn't loaded fully, then loaded and showed properly then reverted to a partially loaded state, then settled down to a fully loaded state.
[12:22] Andrew Hellershanks: The only thing I was doing during that time was using Tex Refresh in the viewer to help it load a partially loaded texture.
[12:22] Vincent.Sylvester Viewer loads close things first then everything farther away so it might eventually load a prim the next region over causing it to fill texture memory
[12:22] Gavin.Hird There has a been a lot of fixes to texture memory allocation, so that basically got rid of it
[12:23] Andrew Hellershanks: Vincent, ok. Sounds like it viewer side. I'm running the latest version of FS.
[12:23] Gavin.Hird plus if you have oversize textures, meaning larger than 1024x1024 it goes nuts about it
[12:23] Ubit Umarov: just see it happen
[12:23] Ubit Umarov: if a prim is a old to be cachable..
[12:23] Andrew Hellershanks: Wasn't my region or my objects so I have no idea of the size of the texture(s).
[12:24] Ubit Umarov: ( simple box)
[12:24] Ubit Umarov: we log in..  resize it..  zoom out completly that in.. the size change is gone
[12:24] Gavin.Hird older objects might have 2048x2048 textures applied to them
[12:24] Ubit Umarov: fs shoes the prim as it was at login even on edit tab
[12:25] Ubit Umarov: we relog, and go get the changed prim
[12:25] Ubit Umarov: so.. fs is doing some mess
[12:25] Ubit Umarov: i can't test at sl
[12:25] Gavin.Hird it is still possible to do that, but you have to sneak the texture that size in via direct upload to db
[12:25] Ubit Umarov: bc can't rez a box for 30 mins or to
[12:25] Ubit Umarov: or so..
[12:26] Ubit Umarov whispers: test at sl  rez a box and leave there for some time ( 30min) ?
[12:26] Ubit Umarov: so it is flagged as cachable
[12:27] Ubit Umarov: then login and repeat change size  zoom out, zoom in..
[12:29] Andrew Hellershanks: We are at about the hour and a half mark. Does anyone have any other questions before this meetings is wrapped up?
[12:30] Andrew Hellershanks: I don't see any one typing so I will take that as that is all for today.
[12:30] Selby.Evans
[12:30] Andrew Hellershanks: I hope to see some of you at the OSCC event this weekend.
[12:30] Jamie.Jordan great meeting
[12:31] Andrew Hellershanks: Enjoy the OSCC events. We can talk about it this coming Tuesday.
[12:31] Andrew Hellershanks: Thank you all for coming. See you again next week.
Personal tools
About This Wiki