PrpShop: Deleting an object crashes

[diafero]

When I try to delete object with PrpShop, the application often crashes with a segfault. It doesn't happen always though - I was editing the DescentMystV_District_dsntFootRgns.prp file from Race's Myst V additions, and while deleting the "Audio Interface" or the "Win32 Streaming Sound" worked, removing the "Win Audible" or the "Sound Buffer" crashed. Even the object which was removed obviously still had some traces though, as PrpShop would (after saving and opening the file again) still show "Audio Interface", but without any object in it.

EDIT: I removed the objects using PrpPack, and it seems to work (at least the game doesn't crash ). However, PrpShop still shows an "Audio Interface" category without any object in it (the other categories of which the only object got removed do no longer appear). Any idea what that could be caused by? I can upload the prp file somewhere if that helps.

[Zrax]

First off, deleting an object in both PrpShop and PrpPack will NOT delete any dangling references to it... You will still need to find and remove any keys in other objects that still reference the deleted object. Causing PrpShop to crash, however, is a different story . If you could send me a sample file (or note which file in an existing game) and note what is needed to cause it to crash, I can debug and fix the problem... Thanks!

[diafero]

Yes, I know about the reference - the prp file I edit is fairly simple and I want to completely remove a sound region, so all the objects which have references to it should also be removed.
Which would by the way be a cool feature: The ability to export or to remove the selected objects as well as all those it references and it is referenced by (directly and indirectly).

[Zrax]

a cool feature: The ability to export or to remove the selected objects as well as all those it references and it is referenced by (directly and indirectly).

That's a good idea... Well, the "referenced by" is -- keys that an object references might not go out of scope (or might be referenced by a PRP that isn't currently loaded), so should be left alone until you delete them. Actually, PRPs that aren't loaded will also still have to deal with not having their version of the key deleted, but I can at least flag the key for removal in any PRPs that *are* loaded.

EDIT: Actually, when I think about it, that's a much bigger task than I realized... It would work well to just mark an object for deletion when only a single key is referenced, but anywhere an array of keys is used, I'd have to add additional checks (which would slow down writing and cause a lot of new code to be required). So, it *is* a good idea, but I think it'd be better to just require you to manage reference cleaning manually for now. Perhaps at some point I'll add a way to find references to a key to PrpShop, which will at least help with that.

[Chacal]

Perhaps at some point I'll add a way to find references to a key to PrpShop, which will at least help with that.

Recursivity is a bitch. The only worse thing is recursivity.

[Zrax]

The file you sent me still has two references to the missing AudioInterface (located in the Responder Region.004_SndRgn)... What's happening is that while loading the PRP, the ResManager is seeing references to an AudioInterface key that it expects to be located in that PRP. However, PrpShop, while loading the keys, ignores that key because no object is loaded for it, so it gets to the point of adding the folder, but skips over the invalid key. I can easily tell PrpShop to not create that folder if it finds that there aren't any valid keys, or I can even go ahead and show the invalid key (which will cause a message about the object not being loaded to appear if you were to try to open it). However, in either case, you'll still have to deal with the fact that there are still keys to this non-existant object in the PRP.

[diafero]

show the invalid key (which will cause a message about the object not being loaded to appear if you were to try to open it)

Having such a kind of message which also says where the references to the non-existing object are would definitely be great, it would save a lot of hassle when removing stuff.

After removing the responder, the "Audio Interface" category remains, so obviously there are other references there, too. It really seem to be a bad idea removing objects this way, at least as long as there is no way to detect which keys I break.

[Lontahv]

Maybe Drizzle could fix some of its bugs. Of course more detailed info about invalid stuff in libPlasma is great, but the main issue I see here is Drizzle.

EDIT: I thought this was a different topic. It doesn't really address an existent issue. Keeping it because I don't believe in changing history.

[ddb174]

Maybe Drizzle could fix some of its bugs. Of course more detailed info about invalid stuff in libPlasma is great, but the main issue I see here is Drizzle.

Watch out, your bias is showing...

While I'm sure Drizzle does have bugs, the thing is that such a problem wouldn't be a bug. libPlasma reads Uru files fine, so no bugs there. Drizzle's files are read by Uru fine, so no bugs there. It would be an incompatibility between libPlasma and Drizzle, which could be rectified on either end, but it isn't a problem with either of them, per se.

Oh, and if you actually read the thread, you'll see that Drizzle wasn't even used here.

Edit: I apologise, I think this post sounds too harsh.

[Zrax]

After removing the responder, the "Audio Interface" category remains, so obviously there are other references there, too. It really seem to be a bad idea removing objects this way, at least as long as there is no way to detect which keys I break.

Actually, this time it *is* a libPlasma issue... When you load the PRP, even though the missing AudioInterface isn't in the saved file's keyring, it gets referenced by the Responder and libPlasma writes the key back to the keyring >.>. That's an easy fix though.