hello do you plan to fix the 0.7.5-post-fixes version for this bug ?
2013/4/30 Nebadon Izumi <[email protected]> > OSgrid release has just been posted, feel free to download it and give a > test! http://www.osgrid.org/index.php/downloads > > > On Mon, Apr 29, 2013 at 7:16 PM, Dr Ramesh Ramloll <[email protected]>wrote: > >> Thanks so much Justin, that was fast. >> >> >> On Mon, Apr 29, 2013 at 5:22 PM, Justin Clark-Casey < >> [email protected]> wrote: >> >>> I was able to reproduce this bug and fix it in git master 12054aa. >>> >>> It looks like the bug may have been around for a very long time (perhaps >>> even since June 2010) though that would be quite surprising. >>> >>> It would probably have affected all viewers. >>> >>> >>> On 28/04/13 15:56, Dr Ramesh Ramloll wrote: >>> >>>> Thanks for pointing this critical bug out. It is surely a show stopper >>>> if one is using a lot of object dispensers for >>>> users ... on a sim. Looks like my obsession to keep all inventory as >>>> rezzed objects and saved as an oar file is going to >>>> continue for a while (might be irrational but the inventory system does >>>> not look safe yet). >>>> >>>> >>>> On Sun, Apr 28, 2013 at 12:34 AM, Chris <[email protected] <mailto: >>>> [email protected]>> wrote: >>>> >>>> Hmm... That is a bit strange. On the viewers I thought to be OK I >>>> was able to utilize the test object after the test >>>> (By attempting to rez the object and looking to see if it would >>>> appear or not and watching the console for errors). >>>> However, I based all my tests transferring an item from Phoenix >>>> viewer (which is currently my viewer of choice) to >>>> the viewers in my test results since it didn't seem to make a >>>> difference which viewer the item came from, just the >>>> viewers they were going to. I managed to lose a script I spent >>>> about 8 hours working on in the process due to the >>>> Lost and Found folder issue explained toward the end of my previous >>>> email (D'oh!)... but I was able to recover it by >>>> grepping a dump of my database and then dumping the most recent >>>> asset. >>>> >>>> I did a quick test as I was writing this with a transfer from >>>> Firestorm to Firestorm on seperate computers and with >>>> viewers on the same computer (Computer OS is running on) to be sure >>>> but I was not able to reproduce the issue in >>>> this way. I also tried with both HTTP Inventory on and off as well >>>> but it didn't seem to make a difference. The Lost >>>> and Found issue also does not show up on the viewers listed as OK >>>> in my previous tests with the exception of Phoenix >>>> viewer, it's OK when using silent discard, but the issue shows up >>>> when using regular discard. >>>> >>>> As an addendum to my previous test, I also noticed that if other >>>> avatars had a copy of the object you gave to >>>> another avatar, and the issue is triggered, then that particular >>>> object will missing from the other avatars >>>> inventories as well. Just to be clear, when I say missing, I mean >>>> that it seems to be missing from the database, but >>>> not visually from the inventory (at least not until a relog); can't >>>> do anything with the object in the way of using >>>> it such as rezzing, wearing, transferring, etc. >>>> >>>> >>>> On 4/27/2013 6:32 PM, InuYasha Meiji wrote: >>>> >>>> So you understand and know, I only used two viewers with two >>>> different accounts on the same machine, on the same >>>> machine running the grid. Both of these logged in using the >>>> latest Firestorm for Opensim. Having the same >>>> results as well and finding that although you see that >>>> Firestorm in your list appears to be ok... >>>> >>>> Item Transfer -> Singularity (1.8.0) = Missing inventory item >>>> Item Transfer -> Firestorm (4.4.0) = OK >>>> Item Transfer -> Hippo OpenSim (0.6.3) = Missing inventory item >>>> Item Transfer -> Imprudence (1.3.0) = Missing inventory item >>>> Item Transfer -> Phoenix (1.6.0.1600) = Missing inventory item >>>> when using normal Discard, OK when using >>>> (Discard) (Silent discard) >>>> Item Transfer -> Radegast (2.12.1354) = Missing inventory item >>>> Item Transfer -> Kokua (3.5.1.27984) = OK >>>> Item Transfer -> CoolVL (1.26.8.1) = Missing inventory item >>>> >>>> It really isn;t. It is only in your inventory in name, but not >>>> useable, so I would not give it an ok. Thanks >>>> for gonig through all the trouble of testing so many viewers to >>>> prove it isn't a >>>> Viewer issue. >>>> >>>> InuYasha >>>> >>>> >>>> >>>> >>>> On 4/27/2013 2:29 PM, Chris wrote: >>>> >>>> Last night I tested with 2 avatars on the same machine >>>> OpenSim is running on, one avatar on one machine and >>>> one avatar on a different machine, and both avatars on a >>>> machine other than the one OpenSim is running on. >>>> >>>> I repeated my tests today a bit more in depth and it would >>>> seem that the issue does not depend so much on >>>> the viewer the person transferring the item is using but >>>> more depends on what viewer the person on the >>>> receiving end of the inventory transfer is running. >>>> Steps to reproduce: >>>> >>>> 1. Offer an item transfer to another avatar that you aren't >>>> afraid to lose (Creating a new prim and taking >>>> it to inventory then offering that is sufficient) >>>> >>>> 2. Decline the transfer on the other avatar and it should >>>> go to that avatar's trash folder. >>>> >>>> 3. Empty that avatar's trash folder. >>>> >>>> 4. Go back to the first avatar and try to rez, wear, or >>>> otherwise utilize the item that was to be >>>> transferred (In my case I attempted to rez the object). >>>> a. Should notice that it won't have any effect >>>> b. Look in the console and there should be errors to >>>> the effect of "item not found" >>>> >>>> My error when attempting to rez the object: >>>> 16:11:48 - [INVENTORY ACCESS MODULE]: Could not find >>>> item 6d3689ee-5c06-478d-8c10-__**10870cc6e788 for >>>> >>>> Test User in RezObject() >>>> >>>> 5. Relog the avatar you attempted item transfer from. The >>>> item will be missing from their inventory upon relog. >>>> Test results: >>>> (Format: Item Transfer -> Viewer name of the person >>>> receiving item.) >>>> >>>> Item Transfer -> Singularity (1.8.0) = Missing inventory >>>> item >>>> Item Transfer -> Firestorm (4.4.0) = OK >>>> Item Transfer -> Hippo OpenSim (0.6.3) = Missing inventory >>>> item >>>> Item Transfer -> Imprudence (1.3.0) = Missing inventory item >>>> Item Transfer -> Phoenix (1.6.0.1600) = Missing inventory >>>> item when using normal Discard, OK when using >>>> (Discard) (Silent discard) >>>> Item Transfer -> Radegast (2.12.1354) = Missing inventory >>>> item >>>> Item Transfer -> Kokua (3.5.1.27984) = OK >>>> Item Transfer -> CoolVL (1.26.8.1) = Missing inventory item >>>> >>>> It seems like if the issue triggers, there will be two >>>> copies of the declined object that will show up in >>>> the receiver's trash folder. The tests also apply to >>>> offering entire folders of items. It also looks like on >>>> declining the transfer, If there are any other items >>>> directly under neath it in the person transferring the >>>> item, those items will some how wind up in the other >>>> person's lost and found folder. If the person deletes >>>> those items from lost and found it will remove those items >>>> also from the other persons inventory. >>>> >>>> As far as the viewer I use; I mainly swap between Phoenix, >>>> Imprudence, and Singularity. As for other users >>>> on my install it could be any of the ones listed in the >>>> tests (And possibly others, but these are the main >>>> ones I was able to come up with). >>>> >>>> >>>> On 4/27/2013 10:47 AM, drWhiet wrote: >>>> >>>> Chris, are you testing this with yourself e.g. With 2 >>>> Viewers running on the Same machine ? Or are you >>>> testing this behaviour with your avatar and a different >>>> users Avatar ? And by the way which Viewer do >>>> you (and the other user) use ?? >>>> >>>> Best regards, >>>> >>>> Am 27.04.2013 um 03:37 schrieb Chris< >>>> [email protected] <mailto:[email protected]>>**: >>>> >>>> >>>> -- >>>> OpenSim: 10 Region Standalone on 0.7.6 Dev >>>> Physics: Open Dynamics Engine >>>> OS: Windows 7 (x64) >>>> CPU: AMD Phenom II X4 840 3.2 GHz >>>> Memory: 11 GB DDR3 >>>> Database: MySQL 5.1.63 (x64) >>>> >>>> >>>> ______________________________**___________________ >>>> Opensim-users mailing list >>>> [email protected] <mailto:Opensim-users@lists. >>>> **berlios.de <[email protected]>> >>>> >>>> https://lists.berlios.de/__**mailman/listinfo/opensim-users<https://lists.berlios.de/__mailman/listinfo/opensim-users> >>>> >>>> >>>> <https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>>> **> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> OpenSim: 10 Region Standalone on 0.7.6 Dev >>>> Physics: Open Dynamics Engine >>>> OS: Windows 7 (x64) >>>> CPU: AMD Phenom II X4 840 3.2 GHz >>>> Memory: 11 GB DDR3 >>>> Database: MySQL 5.1.63 (x64) >>>> >>>> ______________________________**___________________ >>>> Opensim-users mailing list >>>> [email protected] <mailto:Opensim-users@lists.** >>>> berlios.de <[email protected]>> >>>> >>>> https://lists.berlios.de/__**mailman/listinfo/opensim-users<https://lists.berlios.de/__mailman/listinfo/opensim-users>< >>>> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>>> **> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 'Consider how the lilies grow. They do not labor or spin.' >>>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate >>>> /Research Associate Professor/, Idaho State University, >>>> >>>> Pocatello, ID 83209 Tel: 208-240-0040 >>>> Blog >>>> <http://deepsemaphore.**posterous.com/<http://deepsemaphore.posterous.com/>>, >>>> LinkedIn >>>> <http://www.linkedin.com/in/**rameshramloll<http://www.linkedin.com/in/rameshramloll>>, >>>> DeepSemaphore LLC >>>> <http://www.deepsemaphore.com>**, Google+ profile < >>>> https://plus.google.com/**103652369558830540272/about<https://plus.google.com/103652369558830540272/about> >>>> > >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> Opensim-users mailing list >>>> [email protected] >>>> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>>> >>>> >>> >>> -- >>> Justin Clark-Casey (justincc) >>> OSVW Consulting >>> http://justincc.org >>> http://twitter.com/justincc >>> >>> ______________________________**_________________ >>> Opensim-users mailing list >>> [email protected] >>> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>> >> >> >> >> -- >> 'Consider how the lilies grow. They do not labor or spin.' >> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research >> Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: >> 208-240-0040 >> Blog <http://deepsemaphore.posterous.com/>, >> LinkedIn<http://www.linkedin.com/in/rameshramloll> >> , DeepSemaphore LLC <http://www.deepsemaphore.com>, Google+ >> profile<https://plus.google.com/103652369558830540272/about> >> >> _______________________________________________ >> Opensim-users mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-users >> > > > > -- > Michael Emory Cerquoni > > _______________________________________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-users >
_______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
