Chat log from the meeting on 2016-05-17

[11:02] George Equus: it is 11 AM..
[11:03] George Equus: 11 grid time is constant, never change
[11:03] Kayaker Magic: And heeeere's Andrew!
[11:03] Kayaker Magic: We must be in the right place/time!
[11:03] Andrew Hellershanks: Afternoon, everyone.
[11:04] Jeff.Kelley @88.161.20.136:9000: we need a MTC, Metaverse Time
[11:04] Kayaker Magic: Following the LL lead, MTC is PDT which is stupid 'cause it keeps changing.
[11:05] Andrew Hellershanks wonders if Gavin will be here today.
[11:05] Kayaker Magic: (can you tell I think the whole idea of daylight savings time is stupid?)
[11:05] George Equus: Stick to UTC. is universal and unchangeable. Or Zulu time for US military  :)...
[11:05] James.Atlloud @grid.kitely.com:8002: time - lol. ever heard me go on about metric time? It's ok. I'll spare you.
[11:06] Andrew Hellershanks: I thought we had already deal with the time change.
[11:07] George Equus: Time issues.. might be something to bring to the table on the General Meet on 22nd maybe.
[11:08] James.Atlloud @grid.kitely.com:8002: General Meet?
[11:08] George Equus: Svizz invention that, Metric time. never took hold
[11:08] George Equus: Well Membership Meeting then is more correct.
[11:08] James.Atlloud @grid.kitely.com:8002: I think Napoleon had a metric time proposal.
[11:09] George Equus: could be...
[11:10] Andrew Hellershanks: I have answers to some of the issues from last weeks meeting.
[11:10] Andrew Hellershanks: The patch to mantis #7900 that was a thread related issue has been applied to master.
[11:11] Jeff.Kelley @88.161.20.136:9000: Do you know why 7903 have not been reviewed ?
[11:11] Andrew Hellershanks: Mantis #7903 is about sit position. It is one of those "can of worms" issues.
[11:11] Jeff.Kelley @88.161.20.136:9000: it's a coding typo
[11:13] Gavin.Hird @grid.xmir.org:8002: this was not my lucky day teleporting here
[11:13] Andrew Hellershanks: Sit position is now calculated in master the same as it is in SL. It uses the bone information and an avatars height in to consideration when calculating the sit position.
[11:13] Jeff.Kelley @88.161.20.136:9000: a minus sign have accidentally flipped to plus
[11:14] Andrew Hellershanks: That report was about more than just a sign.
[11:14] Jeff.Kelley @88.161.20.136:9000: nope
[11:14] Jeff.Kelley @88.161.20.136:9000: http://opensimulator.org/mantis/view.php?id=7903, comment #4
[11:14] Andrew Hellershanks: Why does it take two patches to correct a claimed typo in the sign in a calculatoin?
[11:15] Jeff.Kelley @88.161.20.136:9000: because there are two different mistakes
[11:15] Jeff.Kelley @88.161.20.136:9000: one is sign flip, see by yourself:
[11:15] Jeff.Kelley @88.161.20.136:9000: git diff a11edce^! OpenSim/Region/Framework/Scenes/ScenePresence.cs
[11:15] Jeff.Kelley @88.161.20.136:9000: - // sitOffset is in Avatar Center coordinates: from origin to 'sitTargetPos + SIT_TARGET_ADJUSTMENT
[11:15] Jeff.Kelley @88.161.20.136:9000: - // So, we need to _substract_ it to get to the origin of the Avatar Center.
[11:16] Jeff.Kelley @88.161.20.136:9000: - Vector3 newPos = sitTargetPos + SIT_TARGET_ADJUSTMENT - sitOffset;
[11:16] Jeff.Kelley @88.161.20.136:9000: - Vector3 newPos = sitTargetPos + SIT_TARGET_ADJUSTMENT - sitOffset;
[11:16] Jeff.Kelley @88.161.20.136:9000: + Vector3 newPos = sitTargetPos + sitOffset + SIT_TARGET_ADJUSTMENT;
[11:16] Andrew Hellershanks: I woldn't trust the comments. Someone who knows the code needs to check the calculation or else applying the change will change the sit position yet again.
[11:17] Jeff.Kelley @88.161.20.136:9000: when you flip the sign again, you get exactly the sit position of .8.*
[11:17] Jeff.Kelley @88.161.20.136:9000: second patch is LegacySitOffsets in inis spelled "LegacyOpenSimSitOffsets" in code
[11:18] Jeff.Kelley @88.161.20.136:9000: that's why the ini has no effect
[11:21] Andrew Hellershanks: If the second patch just fixes a disconnect between code and the ini re: the name of a setting that patch could be applied.
[11:21] Jeff.Kelley @88.161.20.136:9000: also
[11:21] Jeff.Kelley @88.161.20.136:9000: either patch code either patch ini
[11:22] Andrew Hellershanks nods
[11:23] Jeff.Kelley @88.161.20.136:9000: but usually, variable names matches paramater names
[11:24] Andrew Hellershanks: It might be one of those things that got changed in code during the avination code merge.
[11:24] Jeff.Kelley @88.161.20.136:9000: commit a11edce was huge
[11:24] Billy.Bradshaw @hg.viewtwo.net:8600: makes sense to me Jeff, this is to correct functionality of LegacyOpenSimSitOffsets?
[11:25] Billy.Bradshaw @hg.viewtwo.net:8600: or fix
[11:25] Jeff.Kelley @88.161.20.136:9000: it is to give effect to the parameter LegacySitOffsets in OpenSimDefault.ini
[11:26] Billy.Bradshaw @hg.viewtwo.net:8600: worrying that a number of behavior changes introduced with the merge are only coming to light when people test.
[11:27] Kayaker Magic: Yes, that is a worry
[11:27] Jeff.Kelley @88.161.20.136:9000: how could they come before ?
[11:27] Kayaker Magic: The worry is that 1000's of little changes were made that have not been adequately tested.
[11:27] Jeff.Kelley @88.161.20.136:9000: agreed
[11:28] Gavin.Hird @grid.xmir.org:8002: Yep
[11:28] Jeff.Kelley @88.161.20.136:9000: we didn't test enough
[11:28] Billy.Bradshaw @hg.viewtwo.net:8600: Normally with patches the patch documents any possible change, with a large merge that far less obvious
[11:29] Billy.Bradshaw @hg.viewtwo.net:8600: Also noted looking through the merge commits (many) some have a note 'not tested'
[11:30] Andrew Hellershanks: There have been thousands of code changes in master. Some issues arising from applying all the changes have been dealt with but there could still be some others that haven't. Some issues may not come to light until the code is being put to use.
[11:31] Andrew Hellershanks: It is hard to catch all the use cases when trying to test code changes.
[11:31] Jeff.Kelley @88.161.20.136:9000: hg lm has just been fixed yesterday, i never would have offered a 0.9 to my users without this fix
[11:32] Gavin.Hird @grid.xmir.org:8002: One issue I think I have observed over time (not 100% sure) is that if multiple simulators start up concurrently, they don't notify each other properly about their online status and the grid becomes unstable,
[11:32] Andrew Hellershanks: Gavin, you said you were seeing a 50% increase in CPU usage with Bullet or ubODE. Is that in all region types or in vars?
[11:33] Gavin.Hird @grid.xmir.org:8002: I only have standard regions
[11:33] Andrew Hellershanks: How many prims in the regions?
[11:34] Gavin.Hird @grid.xmir.org:8002: But I made an observation that the increase only occurs when two simulators have adjacent regions
[11:34] Gavin.Hird @grid.xmir.org:8002: if you only start one simulator with multiple regions the CPU use is the same
[11:34] Gavin.Hird @grid.xmir.org:8002: the moment the next simulator comes up, the CPU use goes up
[11:35] Gavin.Hird @grid.xmir.org:8002: so there is some strange interaction there but we already know this from region crossings that don't work properly between simulators
[11:36] Andrew Hellershanks: If you use 0.8.2 you don't get the same jump in CPU usage?
[11:36] Gavin.Hird @grid.xmir.org:8002: no
[11:36] Andrew Hellershanks: ok
[11:38] Simulator Version v0.5 shouts: OpenSim 0.9.0.0 Dev 97a471c: 2016-05-12 17:42:42 -0700 (Unix/Mono)
[11:39] Andrew Hellershanks: Gavin, I'll pass that info on to the other devs. Is there a mantis I can point them to?
[11:39] Gavin.Hird @grid.xmir.org:8002: no
[11:40] Gavin.Hird @grid.xmir.org:8002: some of this is observations I made this week
[11:40] James.Atlloud @grid.kitely.com:8002: .. had the same question :)
[11:41] Andrew Hellershanks: Gavin, it would help if you file a mantis. If more questions get asked about the setup I will just have to route them to you once a week.
[11:41] Gavin.Hird @grid.xmir.org:8002: the code seems to work pretty good when you have multiple regions running on one simulator, but the interaction with adjacent simulators seems flaky compared to 0.8.2
[11:41] Andrew Hellershanks: James, you are also seeing higher CPU usage with physics in master?
[11:42] Gavin.Hird @grid.xmir.org:8002: May is the month of endless public holidays, and all kinds of obligations here, but I'll get around to it :-)
[11:43] James.Atlloud @grid.kitely.com:8002: No sorry, not expert at admin. Was wondering if there was a Mantis for the cpu issue.
[11:43] Andrew Hellershanks: Gavin, ok. It would just make it easier to gather the information that may be required to duplicate the issue and see about fixing it.
[11:44] Andrew Hellershanks: James, there isn't one yet.
[11:45] James.Atlloud @grid.kitely.com:8002: yup - got that. ty
[11:45] Andrew Hellershanks: :)
[11:46] Andrew Hellershanks: Kayaker, You raised issues with llCastRay. Are those problems in all region types?
[11:46] Gavin.Hird @grid.xmir.org:8002: both adjacent standard and var regions running on different simulators would probably reveal if there are issues and differences between 0.8.2 and 0.9 that needs to be fixed
[11:46] Andrew Hellershanks: Melanie said the cast ray problems may only be in vars.
[11:47] Kayaker Magic: The biggest problem with llCastRay is that is runs exponentially slower in var regions
[11:47] Kayaker Magic: even empty var regions.
[11:47] Andrew Hellershanks: Gavin, one var per instance is a common set up. I would have thought that problem would have been sooner.
[11:48] Gavin.Hird @grid.xmir.org:8002: right, but are they usually stacked border to border?
[11:48] Andrew Hellershanks: Kayaker, ok. The avination code was optimized for standard sized regions, not vars, as avination grid doesn't offer vars.
[11:49] Gavin.Hird @grid.xmir.org:8002: I have a feeling most vars are standalone islands and not used to make larger connected areas?
[11:49] Andrew Hellershanks: Gavin, I have many regions in a grid where regions are up against each other with one region per instance of OpenSim.
[11:50] Andrew Hellershanks: Var regions are usually not up against each other.
[11:50] Gavin.Hird @grid.xmir.org:8002: running on different IPs or same?
[11:50] Andrew Hellershanks: Gavin, I have it both ways.
[11:50] Kayaker Magic: On same IPs in the cases where I had trouble
[11:50] Gavin.Hird @grid.xmir.org:8002: same for me Kayaker
[11:50] Gavin.Hird @grid.xmir.org:8002: so there might be something there…
[11:51] vegaslon plutonian: seen trouble with two of them right next to one another on diffrent IP, can not fly between them
[11:51] Andrew Hellershanks: Gavin, ok. I thought you were asking about regions being side by side on same IP or different ones.
[11:52] Gavin.Hird @grid.xmir.org:8002: If you take SL as an example, they usually run 4-16 simulators on the same IP (they only have a one to one relationship between region and simulator)
[11:52] Andrew Hellershanks: We have two different issues. Let's take them one at a time.
[11:52] Andrew Hellershanks: Gavin, are you saying higher CPU load depends on whether adjacent regions are running on same or different IP?
[11:53] Gavin.Hird @grid.xmir.org:8002: so it seems, but I can't be 100% sure
[11:53] Gavin.Hird @grid.xmir.org:8002: because I have not broken them out to separate IPs to see what happens
[11:53] Andrew Hellershanks: Gavin, adjacent regions with different IPs do not present the higher CPU load?
[11:54] Gavin.Hird @grid.xmir.org:8002: that is the hypothesis
[11:55] Andrew Hellershanks: ok. That would be worth noting in a mantis.
[11:55] Andrew Hellershanks: Any other observations before we get back to llCastRay?
[11:56] Andrew Hellershanks can't tell if that is a no, or someone is still typing.
[11:57] George Equus: Got a question... when saving an OAR I get Could not find asset UUID# around 40 of them (probably invalid items). Is there any way to find the asset NAME for an UUID? Would like to remove the source of those invalids if possible.
[11:58] Andrew Hellershanks: George, you would have to do a search of the assets table for the name but if the oar saving says the asset isn't found you won't get the name that way.
[11:58] Gavin.Hird @grid.xmir.org:8002: You'd have to decode the XML
[11:58] Andrew Hellershanks: You could extract the contents of the oar and search the contents to track down the reference to the asset UUID.
[11:58] Jeff.Kelley @88.161.20.136:9000: and the Texture LONGBLOB in primshaped
[11:58] Kayaker Magic: Or paw through your MySql database
[11:59] George Equus: OK... in short not worth the effort I suppose  :)
[11:59] Andrew Hellershanks: Might be easier to check the OAR contents as there would be less stuff to search through.
[11:59] Gavin.Hird @grid.xmir.org:8002: For MySQL you have to install some plugin to decode the XML so you can search it. For Postgres you can do the decode and regex search in a query
[12:00] George Equus: Might go for the plugin approach..
[12:00] George Equus: Thanks. Got answer i needed I think
[12:00] Andrew Hellershanks: I don't know what causes these "lost assets". I have often seen those message.
[12:00] George Equus: We all have them I assume
[12:00] Gavin.Hird @grid.xmir.org:8002: there are two causes:
[12:00] Kayaker Magic: I get lost asset errors from importing scripts that reference textures by UUID for example.
[12:00] George Equus: And still find stuff in Iventory that is ghosts..
[12:01] Gavin.Hird @grid.xmir.org:8002: once an OAR is uploaded to a grid without the asset missing in your inventory or even in the asset table
[12:01] George Equus: probably after the Great Crash..
[12:01] Gavin.Hird @grid.xmir.org:8002: the second is database corruption that happens on MySQL
[12:01] Gavin.Hird @grid.xmir.org:8002: with the asset missing*
[12:02] George Equus: Mine is pretty fresh, besides had same issue with plain vanilla setup
[12:02] Gavin.Hird @grid.xmir.org:8002: to minimize it when setting up a new grid, all IARs must be loaded first and only then the OARs
[12:03] Andrew Hellershanks: You should not have that issue with a fresh install of OpenSim.
[12:03] Billy.Bradshaw @hg.viewtwo.net:8600: duty calls.. toodle pip
[12:03] Andrew Hellershanks: Kayaker, the information I got this week says that both issues you mentioned last week are var related.
[12:04] George Equus: No, is brought over when uploading OAR after switch of db
[12:04] Andrew Hellershanks: The message worth noting in the TP crossing issue report is where it said "Fround region using legacy size".
[12:04] Kayaker Magic: Yes, if the var issues were fixed I would be very happy with the ubODE version of llCastRay.
[12:04] Gavin.Hird @grid.xmir.org:8002: did all the content on the oars get created on the old grid?
[12:05] Andrew Hellershanks: George, ok. So its something about the OAR file. It is missing the assets then some of the objects in the OAR will trigger the missing asset references when you try to use the objects.
[12:05] George Equus: Yes. uploade several diff. OARs some very old, all contain some missing stuff when making new oar directly
[12:06] George Equus: always been around so to speak
[12:06] Andrew Hellershanks: Kayaker, the llCastRay issue is considered a low priority at this time so it will be a while before it gets looked at.
[12:06] Gavin.Hird @grid.xmir.org:8002: if you upload oars from different sources chances are you will have missing assets
[12:06] Gavin.Hird @grid.xmir.org:8002: usually textures
[12:06] George Equus: So far I visually don't miss anything
[12:07] George Equus: all is properly textured
[12:07] James.Atlloud @grid.kitely.com:8002: I was wondering about ownership of the assets or even if assets are from HG accounts.
[12:07] Andrew Hellershanks: Kayaker, I haven't seen/heard from Ubit in a while so I can't even raise issue with him.
[12:08] George Equus: some assets I find don't carry over from HG, item is in Inv but can't be rezzed
[12:08] Gavin.Hird @grid.xmir.org:8002: if you identify one object with missing assets, typically if you click on the texture you will not see it in your inventory
[12:08] George Equus: Right Gavin
[12:09] Gavin.Hird @grid.xmir.org:8002: so you can fix it manually by replacing the texture of the object
[12:09] George Equus: Yes,
[12:09] Gavin.Hird @grid.xmir.org:8002: or run queries in the database to fix it globally
[12:09] Andrew Hellershanks: You won't see the texture in your inventory if it is owned by someone else and you never had a copy in your inventory.
[12:09] Gavin.Hird @grid.xmir.org:8002: that too Andrew
[12:10] George Equus: well, there are a few plants around.. might be those
[12:10] Andrew Hellershanks: Could be one of them. More likely so if they came from an OAR.
[12:11] James.Atlloud @grid.kitely.com:8002: Maybe viewers could filter inventory by some aspect that would help.
[12:12] George Equus: Don't think anything in the viewer can help on this
[12:12] James.Atlloud @grid.kitely.com:8002: yes - was just thinking users could find problem assets before exporting.
[12:12] George Equus: One of those pesky errors we all have but noone seems to bring up lol
[12:13] Andrew Hellershanks: If its from bad OARs, then fix the OAR. :)
[12:13] Gavin.Hird @grid.xmir.org:8002: I think the assets are encoded in the XML file in the asset table
[12:13] George Equus: suppose is a pipe dream having a perfect console and error free OAR / IAR files
[12:13] Gavin.Hird @grid.xmir.org:8002: which is why the viewer is able to display it
[12:14] Andrew Hellershanks: George, it would be nice.
[12:14] George Equus: sure would
[12:14] George Equus: I know to little to start digging in the db anyway
[12:14] Gavin.Hird @grid.xmir.org:8002: so to fix it you need to rip it out of the xml file, and load it as a distinct asset in the asset table
[12:15] Gavin.Hird @grid.xmir.org:8002: but that could amount to content theft
[12:15] George Equus: def, beyond my capabilities atm
[12:15] Andrew Hellershanks: Gavin, to fix a missing asset you would need to create an asset the same type with the same UUID as the missing one.
[12:16] Gavin.Hird @grid.xmir.org:8002: exactly
[12:16] Andrew Hellershanks: The error message doesn't tell you what type of asset is missing.
[12:16] George Equus: No
[12:16] George Equus: tell very little
[12:16] Andrew Hellershanks nods
[12:16] Gavin.Hird @grid.xmir.org:8002: no, but you could find out by decodning the xml and search
[12:17] Andrew Hellershanks: Right.
[12:18] Andrew Hellershanks: Almost 20 past. Anything else before we wrap up todays meeting?
[12:18] George Equus: As long as things LOOK right I can live with it , seem to create no serious problems
[12:18] Andrew Hellershanks: I've seen the messages a lot but never really noticed anything in a region that appeared to be broken or not rezzed properly.
[12:18] George Equus: Nothing more from me. Thanks for discuss
[12:19] James.Atlloud @grid.kitely.com:8002: Fascinating discussions today.
[12:19] George Equus: Right Andrew
[12:19] George Equus: Look OK = Is OK
[12:20] Andrew Hellershanks: All right then. Thank you all for coming. See you all next week.