(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
[11:11 AM] Ubit Umarov: well welcome :)
[11:12 AM] Ubit Umarov: about last week code changes
[11:12 AM] orbert tatham: The row boat I just rezzed matches correctly
[11:12 AM] Ubit Umarov: yeah somethign sttrage on that previus owner transmission on HG
[11:13 AM] Ubit Umarov: well on new code i did add a few lsl things
[11:13 AM] Ubit Umarov: llmapbeacon
[11:14 AM] Ubit Umarov: llGetRenderMaterial
[11:14 AM] Ubit Umarov: llIsLinkGLTFMaterial
[11:14 AM] Ubit Umarov: and llWorldPosToHUD
[11:15 AM] Ubit Umarov: also some fix for mantis 9212
[11:16 AM] Ubit Umarov: ofter tp was not working between 2 regions on diferent instances if target was in view range
[11:16 AM] Vincent.Sylvester @hg.zetaworlds.com: 9213 also fixed when some code came back from vacation
[11:17 AM] Ubit Umarov: ald made ubODE teh default physics engine on the ini files
[11:17 AM] Vincent.Sylvester @hg.zetaworlds.com: hurray
[11:17 AM] Ubit Umarov: ahh yes.. also a fix for 9213
[11:19 AM] Ubit Umarov: for the record before the start of log, Obert was reporting some issue with pims last ower on HG
[11:19 AM] Ubit Umarov: it somehow guests changed...
[11:19 AM] Ubit Umarov: err gets!
[11:20 AM] Ubit Umarov: wel mb regions are as good as me typing..
[11:20 AM] Vincent.Sylvester @hg.zetaworlds.com: Only thing that really stores last owner is prims on region, inventory doesn't and neither does asset data, so that part is mostly down to the transfer
[11:23 AM] Ubit Umarov: lastowner is stored on all the above
[11:24 AM] Ubit Umarov: hmm at most see a option to store uuid zero on oars
[11:24 AM] orbert tatham: It the prim has one set of data in OSGrid's Asset database and a different set of data in the other grid's database, would the OSGrid set override the on where it came from when I rez it here?
[11:25 AM] Ubit Umarov: no idea need to look
[11:25 AM] orbert tatham: What I am wondering is if the asset/uuid is in the OSGrid database and the same uuid is in AMV database, I got the item in AMV but rezzed it here
[11:26 AM] Ubit Umarov: wel all code assumes uuids are unique across the universe
[11:26 AM] orbert tatham: That wouold make sense of things
[11:27 AM] Ubit Umarov: that is a hg limitation
[11:27 AM] orbert tatham: Agreed
[11:27 AM] Ubit Umarov: but you said that on original grid that example uuid was 8... and not it is 7...
[11:28 AM] orbert tatham: yes - e8... originally, and 75... now
[11:35 AM] orbert tatham: When you rez something out of inventory, it hanges the group on it to math where you are rezzing it. ould the rezz ode also be pulling the "previous owner" field out of the OSGrid database instead of the one in inventory?
[11:35 AM] orbert tatham: Sorry keyboard issues
[11:35 AM] orbert tatham: .
[11:35 AM] orbert tatham: +
[11:38 AM] Vincent.Sylvester @hg.zetaworlds.com: Was the original group owned?
[11:38 AM] orbert tatham: Not deeded to the group that I know of
[11:38 AM] orbert tatham: Not certain, though
[11:39 AM] orbert tatham: I will have to look at the vendors and the scripts in them
[11:41 AM] orbert tatham: The UUID that shows up as Previous Owner" is that of someone who could very possibly be reselling the ideam in his shop in OSGrid
[11:45 AM] orbert tatham: The original item is "no transfer" but we all know how wasily that is bypassed
[11:45 AM] Ubit Umarov: uuid on my test prim is right
[11:46 AM] Vincent.Sylvester @hg.zetaworlds.com: When rezzing an item out it has to fetch additional data, because assets and inventory alone don't have all that is necessary to build the scene part, there are only a few paths in code that manipulate the last owner id, rest just takes what data they receive
[11:46 AM] Ubit Umarov: made by a alt on my grid.. and did bring it here with my main alt there that gave it to me
[11:46 AM] Ubit Umarov: what are you talkinng about__
[11:46 AM] Ubit Umarov: inve has all the data
[11:47 AM] Ubit Umarov: objects are serielized into inventory
[11:47 AM] Cuga.Rajal @rajal.org:9000: Could the issue be caused by someone taking ownership in God mode?
[11:47 AM] Ubit Umarov: same code as oars, basicly
[11:47 AM] orbert tatham: That was my thought as well, Cuga
[11:47 AM] Ubit Umarov: so all info is there
[11:47 AM] Vincent.Sylvester @hg.zetaworlds.com: The inventoryitems table has no lastownerID field, only owner and creator
[11:48 AM] Ubit Umarov: wel and worked fine on mu test
[11:50 AM] Vincent.Sylvester @hg.zetaworlds.com: rez code is complicated, it's somewhere in there fetching data from inventory and assets to build the sop, but hardly any code actually interfacing with last owner to set it to something else, that only appears in context of group id
[11:50 AM] Ubit Umarov: well i was told a bout things from user inventorynot prims inventory
[11:52 AM] Vincent.Sylvester @hg.zetaworlds.com: Maybe I remember it wrong but when doing hg doesn't the user retain its asset information from the region they came from, meaning transfer data is pulled via that region?
[11:52 AM] Vincent.Sylvester @hg.zetaworlds.com: Cause it must be pulling the last owner from something other than user inventory
[11:52 AM] Ubit Umarov: well i did text a hg tp and last owner was fine
[11:53 AM] Vincent.Sylvester @hg.zetaworlds.com: So either the origin region reporting wrong data, some interaction with group id or potentially an object where the rootpart last owner is somehow corrupted
[11:54 AM] Vincent.Sylvester @hg.zetaworlds.com: That's really the only places that interacts to build the sop that ends up as base for the viewer data request
[11:54 AM] orbert tatham: It came from AMV, and the other grid I tested it on that reported it correctly was (I think) running Diva code
[11:55 AM] Cuga.Rajal @rajal.org:9000: I think someone taking it in god mode, and then perhaps more ownership transfers, could also account for the change
[11:55 AM] Vincent.Sylvester @hg.zetaworlds.com: I have seen it a few times that last owner just displayed loading... cause the data was somehow missing or couldn't be turned into an actual name due to the remote endpoint being dead
[11:55 AM] Ubit Umarov: loading is viewers crap
[11:55 AM] orbert tatham: Seen that in the creator field, too - the limitations of just passing the UUID
[11:56 AM] Ubit Umarov: and guess worse with hg uuids
[11:56 AM] Ubit Umarov: well no idea
[11:56 AM] Ubit Umarov: lastonwer seems to be where it is needed
[11:56 AM] Ubit Umarov: how another uuid gets tehre.. no idea
[11:57 AM] Vincent.Sylvester @hg.zetaworlds.com: Creator data is fixed as uui or uuid to it so that will always display, if not the profile picture when the endpoint is dead, but last owner id only exists on the rezzed prim, not in inventory or assets. At least I can't see a field that would hold it and assets xml doesn't seem to have it either. The oar serializer pulls it from the sop, but where the transfer over hg to rez gets it from... it's somehow building the sop from somewhere
[11:58 AM] Ubit Umarov: is is on SERIELIZED DATA.. grrr
[11:58 AM] Ubit Umarov: like everything else on a asset
[11:58 AM] Ubit Umarov: object asset
[12:00 PM] Ubit Umarov: and that is informative info only... no real need to waste more than ncessary on it
[12:00 PM] Ubit Umarov: anyway.. no idea of the full history of those objects.. and some more debuf on those is needed
[12:01 PM] Ubit Umarov: to find how the 75 is injected there
[12:01 PM] Ubit Umarov: the uuid 75.. i mean
[12:03 PM] Ubit Umarov: withing same grid, on other regions it does show the right last owner?
[12:04 PM] Ubit Umarov: well guess we need to ask on next meeting :)
[12:04 PM] Ubit Umarov: any other issue?
[12:05 PM] Cuga.Rajal @rajal.org:9000: nothing here
[12:05 PM] Ubit Umarov: oh orbert...
[12:05 PM] Ubit Umarov: [12:03:10] (You): within same grid, on other regions it does show the right last owner
[12:05 PM] orbert tatham: Sorry, momentary crash
[12:06 PM] Ubit Umarov: ?
[12:06 PM] orbert tatham: yes, on the grid where it originated, it shows the same multiple places
[12:06 PM] Ubit Umarov: well some hg vodoo then
[12:06 PM] orbert tatham: the correct person
[12:06 PM] Ubit Umarov: correct person is other level.. i mean same uuid :)
[12:07 PM] orbert tatham: Right, sorry, sloppy terminology
[12:07 PM] Ubit Umarov: yeah typical HG :)
[12:07 PM] orbert tatham: :P
[12:07 PM] Cuga.Rajal @rajal.org:9000: what if someone on grid B deliberately used the same uuid as someone else on grid A?
[12:07 PM] orbert tatham: :P
[12:08 PM] Cuga.Rajal @rajal.org:9000: for their avi
[12:08 PM] Ubit Umarov: that is the other level i meant
[12:08 PM] Ubit Umarov: for on this case the uuid did change
[12:08 PM] orbert tatham: Yeah, I made sure the UUIDs were not the same before I brought you the problem
[12:08 PM] Cuga.Rajal @rajal.org:9000: ah ok
[12:08 PM] Ubit Umarov: uuid collision is another problem
[12:08 PM] Ubit Umarov: that is not taken in consideration on last owner i guess
[12:09 PM] Ubit Umarov: but obert does report a diferent uuid.. no.. well no idea...
[12:09 PM] Ubit Umarov: just ti worked fine on my test
[12:10 PM] Vincent.Sylvester @hg.zetaworlds.com: Well in other news. Spent last week taking out System.Drawing and dropping SkiaSharp in. Essentially re-implementing the functions used by current code. Just to see how much work that ultimately would be should System.Drawing completely disappear. Quite a few things will need adjusting in libomv due to the dependency, but actual code changes are fairly minimal. Most things can be added back in with relative ease. In fact I mostly copy pasted code and vibe coded the complicated math stuff. It compiles at least. Doesn't work quite right, but that's for later me to figure out. So in summary, System.Drawing can go bye bye and we'll be fine :) Of course currently no reason to replace it while System.Drawing still works fine.
[12:11 PM] Ubit Umarov: yeah
[12:11 PM] Cuga.Rajal @rajal.org:9000: is that something for resilience with future dotnet?
[12:11 PM] Ubit Umarov: bc system.draw has actually less dependencies that skia
[12:12 PM] Ubit Umarov: and they are very visble while skia are hidden by nuget etc
[12:12 PM] Vincent.Sylvester @hg.zetaworlds.com: SkiaSharp is what Microsoft recommends to use instead so that's part of why I looked at that. There is another option, but that seems less easy to implement
[12:12 PM] Ubit Umarov: skiashark is just a wrapper aroung google skia, compiled in native code
[12:12 PM] Vincent.Sylvester @hg.zetaworlds.com: Yep
[12:13 PM] Ubit Umarov: so we need all its dependencies for ALL platrforms
[12:13 PM] Ubit Umarov: and i even have no idea where they are lol
[12:13 PM] Ubit Umarov: well
[12:14 PM] Vincent.Sylvester @hg.zetaworlds.com: They are in the nuget packages
[12:14 PM] Vincent.Sylvester @hg.zetaworlds.com: Under the runtime folder
[12:14 PM] Vincent.Sylvester @hg.zetaworlds.com: If you look on nuget for skia you can find the platform specific stuff
[12:14 PM] Ubit Umarov: thei are listed on nuget
[12:14 PM] Ubit Umarov: https://www.nuget.org/packages/SkiaSharp/#dependencies-body-tab
[12:15 PM] Ubit Umarov: apparently there only win and macos are supported
[12:15 PM] Ubit Umarov: err and android..
[12:15 PM] Ubit Umarov: etc
[12:16 PM] orbert tatham: Interesting - Rust libraries have a port of a Skia subset called tiny-skia - I will have to look into it further
[12:16 PM] Ubit Umarov: don-t see linux there.. whatver
[12:16 PM] Vincent.Sylvester @hg.zetaworlds.com: The biggest issue it has is that the in-memory stuff changed so code using that will fail spectacularly
[12:16 PM] Ubit Umarov: move to skia is moving to even worse evel
[12:17 PM] Ubit Umarov: evil
[12:17 PM] Vincent.Sylvester @hg.zetaworlds.com: Eh, it's alright. I thought it would be worse, but most of it is essentially the same thing
[12:18 PM] Vincent.Sylvester @hg.zetaworlds.com: Honestly thought it would be near impossible to do
[12:18 PM] Ubit Umarov: well the worse we may need is to unglue system.drawing out of dotnet source tree
[12:18 PM] Ubit Umarov: making it i independent project
[12:19 PM] Ubit Umarov: thing some already di dthat for private things
[12:19 PM] Ubit Umarov: think
[12:19 PM] Ubit Umarov: ofc a pain. since it is inside the same source tree, calling things all over the place
[12:19 PM] orbert tatham: Have to be careful - Micro$haft could have snuck some copyrights into it since thye owned Mono
[12:19 PM] Ubit Umarov: some internal to dotnet, bc reasons
[12:19 PM] Vincent.Sylvester @hg.zetaworlds.com: There is actual upside to Skia though, some functions internally use memory operations that are much faster so I wonder if all the in-memory stuff is even necessary with it
[12:20 PM] Ubit Umarov: duhh it is all inmemory
[12:20 PM] Cuga.Rajal @rajal.org:9000: I need to go , have a great week everyone :)
[12:20 PM] Vincent.Sylvester @hg.zetaworlds.com: Certainly seems near impossible to implement LockBits properly without either not working right or doing a fun access violation
[12:20 PM] Vincent.Sylvester @hg.zetaworlds.com: Well as in pointers unsafe
[12:20 PM] Ubit Umarov: cpuis cant read thigns outside memory >P
[12:20 PM] orbert tatham: Later, Cuga
[12:21 PM] Ubit Umarov: that is a change ms did all over the place
[12:21 PM] Ubit Umarov: qitht the unsafe.as.. crap
[12:21 PM] Vincent.Sylvester @hg.zetaworlds.com: I don't like that either, hate pointers, but can't argue with how fast it is
[12:21 PM] Vincent.Sylvester @hg.zetaworlds.com: Deal with the devil basically
[12:22 PM] Ubit Umarov: well unless in debug, that unsafe tyhing is as fast
[12:22 PM] Ubit Umarov: ofc guess that made GC even worse...
[12:22 PM] Vincent.Sylvester @hg.zetaworlds.com: Not really worse, just insanely lazy
[12:23 PM] Ubit Umarov: but only reason to lock things in memory is to tell gc to not touch them
[12:23 PM] Ubit Umarov: guess gc really does not need that
[12:24 PM] Ubit Umarov: because on the rare ocasions compiler does things right the asm code is same as c compile would do
[12:25 PM] Ubit Umarov: oops
[12:25 PM] Ubit Umarov: rl calls
[12:25 PM] Ubit Umarov: any other issue ?
[12:26 PM] Vincent.Sylvester @hg.zetaworlds.com: Nope
[12:26 PM] Ubit Umarov: ok hope to see you all next week :)
