|Anonymous | Login | Signup for a new account||2019-05-26 11:09 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008411||opensim||[GRID] Inventory Service||public||2018-11-22 05:03||2019-03-23 06:00|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0008411: Coalesced items in inventory are no longer shown with the coalesced item icon and other inventory weirdness|
|Description||As of commit eb5fe57a17ada01885fbc5bb5ea543d109dab7ec coalesced items in inventory no longer show with the proper icon (The icon that resembles the object icon but is broken up slightly to denote a coalesced item).|
Some of these items (Especially larger coalesced builds) won't rez at all; You'll hear the "build" sound when you try but nothing ever appears, not even after a sim restart.
This doesn't seem to be viewer dependant (Tested on several different viewers including Firestorm and Singularity)
Possibly related, but unsure, I have been randomly seeing a lot of XML parsing errors on master that don't seem to show up prior to commit eb5fe57a17ada01885fbc5bb5ea543d109dab7ec that look something like this:
2018-11-22 04:57:20,540 DEBUG [serverUtils.ParseXmlResponse]: failed error: Unexpected end of file while parsing Name has occurred. Line 1, position 204801.
(Then just an obscene amount of XML describing seemingly everything that agent owns in their inventory following this error)
|Steps To Reproduce||Have a coalesced item in inventory on OpenSim master revision and check what the icon for the object looks like in inventory.|
Note: The issue won't show up if you make a new coalesced item; It only affects existing items in inventory. I did notice that if I duplicate (Copy and paste elsewhere in inventory) the item that is supposed to have the coalesced icon does have the proper icon on the newly copied item, but the new item then has the wrong icon upon next relog (Possibly after clearing viewer cache).
So it may be possible to purposefully trigger the issue by making a new coalesced item, take to inventory, clear viewer cache, and then relog and check the icon.
|Additional Information||Git Bisect Results:|
$ git bisect good
eb5fe57a17ada01885fbc5bb5ea543d109dab7ec is the first bad commit
Author: UbitUmarov <firstname.lastname@example.org>
Date: Sat Oct 6 23:42:24 2018 +0100
more use of simpler xml encoder on inventory fetch, plus other cosmetics
:040000 040000 f2d5d8b89b00bac9c4eae724eb67ef79833a77ed 8879fcac9d6b1c22f1c28758cdec4072e01146fa M OpenSim
|Tags||No tags attached.|
|Git Revision or version number||master|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
|Viewer||Applies to all viewers|
|Attached Files|| mantis8411.png [^] (186,921 bytes) 2018-11-22 10:50
manstis 8411_singu.png [^] (463,619 bytes) 2018-11-22 10:54
mantis8411_win_net_xassets.png [^] (68,849 bytes) 2018-11-22 11:04
edited on: 2018-11-22 11:28
What version of firestorm are you using?? What type of asset server , Xassets or fsassets ..
Tried to replicate it, attached image.
EDIT: I am testing with very latest master.
edited on: 2018-11-22 17:10
@mewtwo0641 Ubit did find something wrong that just seemed to not affect me, so there is a new master with hopefully a fix ..
|yes I made a change on master|
@BillBlight - Sorry about that, I was a bit tired when I posted the mantis. But I was testing with the latest Firestorm (v18.104.22.168786). The asset server is standard MySQL storage (not FSAssets). Also I probably should have clarified that you won't see the issue if you make a new coalesced item; It only affects existing items in inventory. I did notice that if I duplicate (Copy and paste elsewhere in inventory) the item that is supposed to have the coalesced icon does have the proper icon on the newly copied item, but the new item then has the wrong icon upon next relog (Possibly after clearing viewer cache)
@Ubit - Thanks for looking into this Ubit, I am having a bit of trouble compiling master in order to test though.
"D:\ostest\opensim.sln" (default target) (1) ->
"D:\ostest\OpenSim\Region\ScriptEngine\YEngine\OpenSim.Region.ScriptEngine.YEngine.csproj" (default target) (64) ->
(CoreCompile target) ->
XMRInstCtor.cs(894,37): error CS0136: A local variable named 'eventCode' cannot be declared in this scope because it would give a different me
aning to 'eventCode', which is already used in a 'parent or current' scope to denote something else [D:\ostest\OpenSim\Region\ScriptEngine\YEngine\OpenSim.Region.ScriptEngine.YEngine.csproj]
|@mewtwo0641 hmm never seen that exact compile error, have you tried a completely clean download, into a fresh empty directory?|
that should be at most a warning (that I don't see on VS or mono)
but changed on master, also for clarity
|@BillBlight - I just tried on a fresh newly cloned opensim download with the same error|
edited on: 2018-11-22 18:10
@Ubit - The latest change on master does compile. I am a little confused by the change though
ScriptEventCode evtCode = (ScriptEventCode)Enum.Parse(typeof(ScriptEventCode),
The variable name was changed in its declaration but m_EventCounts[(int)eventCode]++; wasn't changed to reflect that name change. So ScriptEventCode evtCode = ... Would be essentially doing nothing?
changed also some code on take, take copy.. of more than 250 objects
note this may fail a lot
you need to wait for viewer to finish the select, and this can take a lot of time!!
MySQL config option max_allowed_packet needs to be large enough (also for other things)
@Ubit - No problem :)
I tested again and it appears the coalesced items in inventory are showing up with the correct icon now. Tested with Firestorm, Alchemy, and Singularity. All are latest release except Singularity which is a slightly-older-than-latest-build Alpha.
Although there are still some coalesced objects that refuse to rez for me (And rezzes just fine on older code i.e. 0.8.x series and most recent public release). This may be a seperate issue though; I will have to test some more and see if I can pinpoint a spot in time when that first started happening.
I have max_allowed_packet set to 1024M, which is probably waaaay overkill, but I am pretty sure the objects that are failing to rez don't come anywhere near approaching that.
|2018-11-22 05:03||mewtwo0641||New Issue|
|2018-11-22 05:03||mewtwo0641||Steps to Reproduce Updated||View Revisions|
|2018-11-22 10:50||BillBlight||File Added: mantis8411.png|
|2018-11-22 10:51||BillBlight||Note Added: 0033522|
|2018-11-22 10:54||BillBlight||File Added: manstis 8411_singu.png|
|2018-11-22 11:04||BillBlight||File Added: mantis8411_win_net_xassets.png|
|2018-11-22 11:28||BillBlight||Note Edited: 0033522||View Revisions|
|2018-11-22 17:10||BillBlight||Note Added: 0033523|
|2018-11-22 17:10||BillBlight||Note Edited: 0033523||View Revisions|
|2018-11-22 17:15||UbitUmarov||Note Added: 0033524|
|2018-11-22 17:42||mewtwo0641||Note Added: 0033525|
|2018-11-22 17:48||mewtwo0641||Steps to Reproduce Updated||View Revisions|
|2018-11-22 17:51||BillBlight||Note Added: 0033526|
|2018-11-22 17:55||UbitUmarov||Note Added: 0033527|
|2018-11-22 17:57||mewtwo0641||Note Added: 0033528|
|2018-11-22 18:04||mewtwo0641||Note Added: 0033529|
|2018-11-22 18:10||mewtwo0641||Note Edited: 0033529||View Revisions|
|2018-11-22 18:44||UbitUmarov||Note Added: 0033530|
|2018-11-22 18:47||UbitUmarov||Note Added: 0033531|
|2018-11-22 19:21||mewtwo0641||Note Added: 0033532|
|2019-03-23 06:00||mewtwo0641||Status||new => resolved|
|2019-03-23 06:00||mewtwo0641||Fixed in Version||=> master (dev code)|
|2019-03-23 06:00||mewtwo0641||Resolution||open => fixed|
|2019-03-23 06:00||mewtwo0641||Assigned To||=> mewtwo0641|
|Copyright © 2000 - 2012 MantisBT Group|