Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-5955] Restore to Last Position (used only by TPVs) causes content loss #13859

Open
1 task
sl-service-account opened this issue May 6, 2014 · 23 comments
Open
1 task

Comments

@sl-service-account
Copy link

sl-service-account commented May 6, 2014

Steps to Reproduce

Fielding customer support inquiries from hundreds of customers who are losing their tables.

Actual Behavior

This was too long to concisely explain in the summary:

I make games, a lot of games. I currently have 14 different games that all share some common prim components, namely the table and chairs. They are sold as transfer-only. No-modify, no-copy. They all have the same problem. Anytime someone tries to do "restore to last position" on them, they get the error message "Cannot restore object. No world position found." The weird part is, this even happens to me. The super annoying part is that since they are transfer-only, for anyone but me this results in the object disappearing and NEVER coming back. Even months later it doesn't show up in inventory again, it's just gone forever.

I am in my own private simulator, which I own completely. There's nothing else at 0,0,0. There's no permissions issue with rezzing at 0,0,0 in my sim. I can rez out, for example, an old 30 prim vehicle I made years ago, pick it up, restore it, works just fine. I can create a new cube, pick it up, restore it, works totally fine.

If I rez out any of my games, pick it up, then try to restore it. It fails. Every single time. 100% failure rate. Not just for me, but also for all of my customers, in every sim in SL.

I tried deleting every script from the game, still fails.

Ultimately, I discovered that if I unlink the root prim from my games, then I can pick up the table minus the root prim, and it will restore fine. Even weirder, I can then pick up the root prim by itself (separate from the rest of the table) and it will also restore just fine, but as soon as I link them back together, they fail to restore again.

This happens on games that are partially mesh as well as games that have no mesh at all. They are a combination of sculpt and regular prims. The root prim in this case is sculpted. When the root prim is removed, the next prim in line that takes over for the root prim is also a sculpt, with the exact same sculpt map as the root prim, in the exact same position as the old root prim.

I can reproduce this any time, anywhere. It only happens to my games. Help?

Expected Behavior

To not have to replace hundreds of games to an inventory bug.

Other information

Attachments

Links

Related

Original Jira Fields
Field Value
Issue BUG-5955
Summary Restore to Last Position (used only by TPVs) causes content loss
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Karsten Rutledge (karsten.rutledge)
Created at 2014-05-06T16:47:51Z
Updated at 2022-10-17T17:17:29Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-05-06T12:29:59.726-0500',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'This was too long to concisely explain in the summary:\r\n\r\nI make games, a lot of games. I currently have 14 different games that all share some common prim components, namely the table and chairs. They are sold as transfer-only. No-modify, no-copy. They all have the same problem. Anytime someone tries to do "restore to last position" on them, they get the error message "Cannot restore object. No world position found." The weird part is, this even happens to me. The super annoying part is that since they are transfer-only, for anyone but me this results in the object disappearing and NEVER coming back. Even months later it doesn\'t show up in inventory again, it\'s just gone forever.\r\n\r\nI am in my own private simulator, which I own completely. There\'s nothing else at 0,0,0. There\'s no permissions issue with rezzing at 0,0,0 in my sim. I can rez out, for example, an old 30 prim vehicle I made years ago, pick it up, restore it, works just fine. I can create a new cube, pick it up, restore it, works totally fine.\r\n\r\nIf I rez out any of my games, pick it up, then try to restore it. It fails. Every single time. 100% failure rate. Not just for me, but also for all of my customers, in every sim in SL.\r\n\r\nI tried deleting every script from the game, still fails.\r\n\r\nUltimately, I discovered that if I unlink the root prim from my games, then I can pick up the table minus the root prim, and it will restore fine. Even weirder, I can then pick up the root prim by itself (separate from the rest of the table) and it will also restore just fine, but as soon as I link them back together, they fail to restore again.\r\n\r\nThis happens on games that are partially mesh as well as games that have no mesh at all. They are a combination of sculpt and regular prims. The root prim in this case is sculpted. When the root prim is removed, the next prim in line that takes over for the root prim is also a sculpt, with the exact same sculpt map as the root prim, in the exact same position as the old root prim.\r\n\r\nI can reproduce this any time, anywhere. It only happens to my games. Help?',
  'What were you doing when it happened?': 'Fielding customer support inquiries from hundreds of customers who are losing their tables.',
  'What were you expecting to happen instead?': 'To not have to replace hundreds of games to an inventory bug.',
  'Where': 'Everywhere',
}
@sl-service-account
Copy link
Author

alexios.donardson commented at 2014-05-06T17:30:00Z

this is the official Jira for the linden viewer, the firestorm bug system can be found here.
http://jira.phoenixviewer.com/secure/Dashboard.jspa

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-05-06T17:33:05Z

I already talked to Firestorm, this isn't an issue with Firestorm or any specific viewer, it's a problem with something on the server side.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-05-06T21:42:57Z, updated at 2014-05-06T22:09:12Z

Repro objects can be found here: http://maps.secondlife.com/secondlife/Karoastoff/139/188/402

Testing with the "K.R. Engineering Greedy Greedy" table which can be bought at the above location.

Region tested on: http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/113/105/22
I have ability to rez at 0,0,0 on this region.

  • First to test I rezzed a cube at http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/113/105/22 and took this cube back to inventory - time is 2.33PM SLT 6th May.
  • Then right click cube in inventory -> Restore to last position at 2.34PM.
    Log entry... "2014-05-06T21:34:08Z WARNING: llmessage/lltemplatemessagebuilder.cpp(84) : LLTemplateMessageBuilder::newMessage: Sending deprecated message RezRestoreToWorld"
  • Cube correctly rezzed inworld at its last position.
  • I rezzed "Greedy Greedy Table v2.47" from inventory at http://maps.secondlife.com/secondlife/Testylvania%20Sandbox/113/105/22 at 2.35PM SLT.
  • I took the Greedy table back to inventory.
  • Within invntory I right clicked "Greedy Greedy Table v2.47" -> Restore to last position at 2.37PM SLT.
    Log entry... "2014-05-06T21:37:30Z WARNING: llmessage/lltemplatemessagebuilder.cpp(84) : LLTemplateMessageBuilder::newMessage: Sending deprecated message RezRestoreToWorld"

Observed: I received a notification saying "Cannot restore object. No world position found."
http://i.imgur.com/NEfnlBv.png

Greedy table does not return to my inventory - even after a cache clear and relog.
Attaching log from the session above - see Log1_whirly.log

Maestro, I know that the official viewer removed the restore to last position feature a long time ago but if you can please have a look at why these tables are failing to restore to last position at the server end that would be very helpful.

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-05-06T21:49:15Z

I can also make a copyable reproduction object available to anyone who needs it for diagnostics. I took Greedy, removed all the chairs and game elements so that it is just a wooden table and nothing else, no scripts or anything else, and it fails every time.

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-05-06T21:54:59Z

I have sent a copyable reproduction object to Maestro Linden for evaluation.

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-05-06T22:09:46Z

Okay, upon further testing, this is what I discovered:

Back in 2011, I needed an extra prim in my game tables. It appears what I did at the time was unlink the root prim, make a copy of the root prim, and then link both the original root prim and the copy back into the table. The copy of the root prim contains no scripts or any other functionality, it's just a prim after being copied. This happened on Greedy Greedy v2.12. Before this, on Greedy v2.11 and earlier, the tables restore just fine, even now. v2.12 and later all fail to restore. If you delete either the original root prim, or the copy of the root prim created in 2011, the table will begin restoring correctly again. It will only restore if it has 1 or the other, but not both of these prims present in the linkset. Both of these prims will also restore just fine on their own as single unlinked prims, but not together.

Unfortunately, after Greedy v2.12, this table was copied to every other game I make, so every game I make has this problem.

It appears from my customer service log that this began to be a problem in late 2012.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-05-06T22:11:11Z

A build of the official viewer can be used to test this.. please refer to comments on SVC-7907, namely...

Kitty Barnett added a comment - 10/May/12 11:57 AM

Short history: when the Zindra continent was announced many residents pointed out that it would be a lot of work and hassle (to sheer impossible) to pick up their (adult) build from its then-current location and move it to the new adult continent.

LL's response was "Restore to World" which was released in the official viewer and then removed again shortly after due to some shortcomings (LL should have more details on what exactly they worried about).

The code however is still all there:
http://hg.secondlife.com/viewer-release/src/3142ebd0bc5a/indra/newview/llinventorybridge.cpp#cl-1351

The feature should still be able to be enabled by anyone in the official viewer download simply by removing the comment markers:
http://hg.secondlife.com/viewer-release/src/3142ebd0bc5a/indra/newview/skins/default/xui/en/menu_inventory.xml#cl-626

@sl-service-account
Copy link
Author

ObviousAltIsObvious commented at 2014-05-06T22:38:31Z

Note that "Restore to Last Position" is also commented out from llinventorybridge.cpp

To make this work on an already compiled LL viewer, the function needs to be stuck on some menu item that is already displayed.

@sl-service-account
Copy link
Author

Zi Ree commented at 2014-05-07T18:01:28Z

Karsten,

I tried the reproduction and found one peculiar thing. If you unlink the test object, then deselect (important!) all pieces, then select them again and re-link, the retore works flawlessly. Maybe that can be a workaround for you to get a properly restoring table out to your customers.

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-05-07T22:11:51Z

Hi Zi, when you relinked all the pieces together, did you get all four of them, including the tiny invisible prim in the center of the table? If you missed that prim, then you just got the same results I did where removing either that tiny invisible prim or the root prim fixes it, but it won't work with both.

@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-05-08T18:35:35Z

'Restore to last position' has a long history of issues; it was 'disabled' in the Linden viewer in 2009 due to VWR-13105, though the simulator apparently still supports that message. We recommend that third party viewers should also remove this feature until it is fixed.

We think this feature should be blocked in the simulator as well, until it is properly fixed. There are some basic design problems with 'restore to last position', so a 'fixed' version may use an entirely different message from the viewer.

@sl-service-account
Copy link
Author

Jessica Lyon commented at 2014-05-08T21:35:31Z

Why don't we then invest a little bit of time fixing this very popular and extremely beneficial feature instead of killing it. It is a very worthwhile investment as it carries much more value towards the user experience than some of the other projects LL has invested in recently,(Pathfinding).

Lets face it, once it is removed from TPV's and/or blocked server side by LL, it will never get fixed. And by that time TPV's wont be able to do anything about it either.

I feel I can speak for all Third party viewers when I say we are ALL more than happy and willing to help out in any way possible to get this feature working properly and reliably again.

Let us know how we can help and we will get started on it right now!

Jessica Lyon
Project Manager
Phoenix Firestorm Project.

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-05-08T21:55:31Z

I for one am getting sick and tired of people telling me "I clicked Restore to Last Position and my game disappeared, I filed a ticket about it but Linden Lab said they can't help me and I should talk to you about it." Can't tell you how many times I've heard that over the last couple of years, and I'm sure I can't be the only one. If the feature is that broken and no-one is willing to fix it, you need to just turn it off at the server level already and be done with it. I agree with Jessica that it would be a very good feature to keep if it were working properly, and would certainly be worthwhile to fix, but until then all it is doing is eroding trust in Second Life. Every bug (especially a bug that is ongoing over 5 years) that is an immediate threat to inventory makes people less inclined to spend money on things that they could lose at any second. The fact that there is a known gaping maw devouring inventory year after year erodes consumer confidence, and that's bad for content creators, it's bad for Linden Lab, it's bad for virtual worlds as a whole. Please, either turn it off or fix it, but don't wait another 5 years to pick one.

@sl-service-account
Copy link
Author

MartinRJ Fayray commented at 2014-05-08T23:37:00Z, updated at 2014-05-08T23:37:33Z

My suggestion is that you (LL) ban the feature, so that there will be no more content-loss, and if TPV-projects still feel the need to implement a 'restore to last position' feature, they should easily be able to do that viewer-side (e.g. by adding a tiny database with inventory-uuids and last position to the sl-cache directory). TPVs can do that in no time, that's very easy to implement, and could be done by a clever programmer in a matter of minutes or maybe hours.

I don't believe that this is the right place to discuss which investment of LL carries more or less value than another.

@sl-service-account
Copy link
Author

Zi Ree commented at 2014-05-09T00:00:15Z

Martin, you're speaking like a true Linden! No clue anout how SL is used, and no intent to fix things people are actually using.

  1. a database like that would quickly get out of hand with all those objects being created, taken into inventory, and forgotten about, maybe even deleted.

  2. a database like that would not carry over in case of a clean reinstall, computer hardware fauilure, using multiple computers etc.

  3. what you believe to be the right palce or not doesn't have to be what everyone else believes.

@sl-service-account
Copy link
Author

MartinRJ Fayray commented at 2014-05-09T00:10:11Z

Martin, you're speaking like a true Linden! No clue anout how SL is used
No need to start offending each other.
Please keep all these things off the Jira (like defamation, or personal opinions, or rants about LL).

Martin - 'like a true Linden' - RJ

@sl-service-account
Copy link
Author

Zi Ree commented at 2014-05-09T00:19:36Z

I don't believe that this is the right place to discuss which investment of LL carries more or less value than another.

Practice what you preach, keep personal opinions off the Jira.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-05-09T00:33:03Z

For those interested, this issue was discussed at the server beta usergroup earlier. Transcript is here: http://wiki.secondlife.com/wiki/Beta_Server_Office_Hours/Minutes/2014-05-08

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-05-09T01:02:32Z

Firestorm viewer will block the ability to use the restore to last position feature with no copy objects. This has been set as a blocker for the next release: http://jira.phoenixviewer.com/browse/FIRE-13672

Jess is going to contact other TPVs and ask them to do the same.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-05-09T12:23:48Z, updated at 2014-05-09T13:36:16Z

Fix has been committed and is in QA: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/d4e8245c7257
http://i.imgur.com/M0TmPpQ.jpg

@sl-service-account
Copy link
Author

Jessica Lyon commented at 2014-05-09T23:03:39Z

Spoke to Sianna of Singularity today and they will put a check in their viewer to prevent use of "restore to last position" on no copy items as well. Spoke to Kitty Barnett of Catznip viewer and they have also agreed to add the check.

This takes care of the major active Third Party Viewers at the moment and will bring content loss under control which result from this bug.

It is my hope that this will buy some time for the feature to live long enough that we can convince LL to help us fix it once and for all.

Linden Lab, please work with us to fix this feature properly so that it functions safely and reliably again.

@sl-service-account
Copy link
Author

Karsten Rutledge commented at 2014-08-14T15:47:33Z

I hate to be a harpy, but as near as I can tell, this functionality still hasn't been disabled in the Firestorm viewer. This is still a huge problem.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2014-08-14T15:57:24Z

Oh good timing!
The Firestorm 4.6.7.42398 release just went out to the preview group a couple of hours ago. Barring any blockers found by the preview group, this will go out as a full release on Sunday :)
Restore to last position is disabled for no copy objects on this release.

If you would like to test that build with your Greedy table, then you can join "Phoenix-Firestorm Preview Group" (secondlife:///app/group/7ba4569c-9dd9-fed2-aaa7-36065d18a13c/about) and the download links are in the group notice.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant