My personal suggestion:<br><br>For getting apprearance data:<br>remove the 2nd "if" condition in "TryGetAvatarAppearance".<br>>>> if ((profile != null) && (profile.RootFolder != null))  --> if (profile != null)<br>
remove "SetAppearanceAssets" in "TryGetAvatarAppearance".<br>>>> // SetAppearanceAssets(profile, ref appearance);<br><br>For storing would be almost the same.<br><br>>This was added to deal with the "Can't find your clothes" issue.<br>
It seems that this is the reason why "RootFolder" information is needed.<br>I think it is not necessary (or should not) to check assetID's avaliability by using C# code.<br>It is a tired, buggy way to go, even you can make "getinventory" synchronous.<br>
Both of the MySQL, MSSQL have the native support of "FOREGIN KEY constaints".<br>RDBMS should handle such task for us.<br><br>THEN,<br>in that case, ... Table "inventoryfolders", "inventoryitems", "avatarappearance" should be always in the save DB. ...<br>
THEN,<br>probably, getapearance should be moved to inventoryservice :><br><br>It is very strange that you get appearance from use server and then check them by using the information from inventory server. these things can(should) be done in one request.<br>
<br><br><div class="gmail_quote">2008/6/10 Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Jun 06, 2008 at 04:07:18PM +0900, Johan Berntsson wrote:<br>
> Hi,<br>
><br>
> We have discussed #1370 and looked at the code and we are a bit<br>
> confused. Currently these events seems to occur when a client logs onto<br>
> a region:<br>
><br>
> Region receives UseCircuitCode packet, and calls GetAppearance().<br>
> GetAppearance needs InventoryFolder which has not yet been created, and<br>
> fails every time.<br>
><br>
> A bit later the region receives a CompletedAgentMovement packet, and<br>
> calls GetInventory(). It then calls GetAppearance() once again. If<br>
> GetInventory succeeded, then GetAppearance() also succeeds, and avatar<br>
> persistence works.<br>
><br>
> Here are some ideas/questions:<br>
><br>
> 1. GetInventory() is asynchronous but GetAppearance() doesn't check if<br>
> it has been completed or not. This probably explains why some people<br>
> experience #1370 while it works for others (the unlucky guys have slow<br>
> computers/networks).<br>
<br>
</div>Ok, that's a good catch.  There was a random sleep in the code before,<br>
which might have been trying to alleviate this (which is the bad<br>
approach).  It would be good to come up with a good way of delaying the<br>
response here.<br>
<div class="Ih2E3d"><br>
> 2. GetAppearance() is using InventoryFolder to get asset IDs even though<br>
> the inventory asset IDs are available in 'avatarappearance' in the DB.<br>
> The information seems to be duplicated. Can't we use the DB IDs<br>
> directly? In that case we don't need to synchronize GetInventory() and<br>
> GetAppearance().<br>
<br>
</div>This was added to deal with the "Can't find your clothes" issue.  It<br>
turns out that we were missing an update on appearance editing that<br>
meant the asset ids were out of date.  It seemed more logical to look it<br>
up via inventory.  If we can track down where we were loosing that<br>
update, we could rely on the asset fields again.<br>
<div class="Ih2E3d"><br>
> 3. One of the GetAppearance() calls seem redundant, but which? Should we<br>
> call GetApperance after UseCircuitCode or CompletedAgentMovement?<br>
><br>
> We think it would work if we removed the GetInventory() dependency in<br>
> GetAppearance() and the second call to GetApperance(), but we are<br>
> reluctant to commit the change since we don't understand the design<br>
> completely. Hope you can enlighten us.<br>
<br>
</div>Honestly, I don't understand the design completely either. :)  And worse<br>
than that, confirming that it works on Standalone + Grid / accross<br>
multiple dbs tends to show that one approach doesn't work in one of<br>
those environments.  At this point, any help in getting this pulled<br>
together would be appreciated.<br>
<br>
    -Sean<br>
<br>
--<br>
__________________________________________________________________<br>
<br>
Sean Dague                                       Mid-Hudson Valley<br>
sean at dague dot net                            Linux Users Group<br>
<a href="http://dague.net" target="_blank">http://dague.net</a>                                 <a href="http://mhvlug.org" target="_blank">http://mhvlug.org</a><br>
<br>
There is no silver bullet.  Plus, werewolves make better neighbors<br>
than zombies, and they tend to keep the vampire population down.<br>
__________________________________________________________________<br>
<br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.6 (GNU/Linux)<br>
<br>
iD8DBQFITVKuSamXem9TdyYRAitjAKCIpuwIj6rq/fDNnpqSb+wDi7pW4ACdGTj0<br>
nIcCQxwyrbmV48JpNHhJpDM=<br>
=HEnD<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Liu Xiaolu