I tried to use VisRegions with objects on other pages than the default mainRoom 0; I exported with PyPRP1. It did not work in the game, the object keeps appearing invisible.

So I thought it would be a good idea to use PlasmaShop (3.0 beta, build 229) to have a look what's wrong.Unfortunately, when I try to view what's in the [0088] Soft Volume Simple on that second page (its "District_Hedges" in the example below) which belongs to the VisRegion "VisReg_Hedges1" in [0116] Vis Region, PrpShop (build 210) just crashes. Even selecting "Edit PRC" instead of "Edit" does not help.

It opens well the Soft Volume Simple entires on the first page (District_mainRoom), and it also opens any Soft Volume in any page in Cyan's Worlds.

(In PlasmaShop 2 / PrpTool, that mentionend Soft Volume data looks much shorter than normally - like some data is missing. But I don't understand those HEX values. I can't even read them. Do I miss a needed Font, by the way?)

Hmm, I do remember that PRPTool bug, but sadly I don't remember what caused it or how to fix it...

On the other hand, I looked at the PRPs, and I see two issues with it: - The owner key is null. This is odd, but it shouldn't crash PrpShop- The plVolumeIsect creatable embedded in the soft volume is null. This will definitely crash PrpShop when trying to write the PRC out. I'll make a change to libhsplasma to not attempt to write dereference a null volume

While I fix that, I would suggest that one or both of the above might be the cause of your Plasma issue as well.

EDIT: The latest version (r233) contains a fix for the null volume (as well as several other things that have been fixed/added since the last time I built a release).

Now I was able to track it down, and you were right with the two issues you mentioned.For some reason, PyPRP1 did export a correct version of the said soft volume in District_mainRoom. So I copied that version over to that in District_Hedges - I had to adapt the 0's to 1's where it says ' Location="9872;0" ', because it's in page 1 now instead of 0 - and it worked pretty well in the Age.

(I'm a bit unsure what I should do with ObjID="1" though. Are ObjIDs usually numbered per page or per age?)

Now I'm wondering where I should start in PyPRP1 code to find where the part of the code is that causes the softvolume to export in the wrong page...

ObjIDs are used in MOUL/Myst V. You can safely ignore them on CC.IIRC, later versions of Plasma identify each object by a number. Complete Chronicles' version of Plasma identifies each object... by its name. Which explains why loading times are 20x longer on Uru.

As for the error...It seems PyPRP creates the visreg "VisReg_Hedges1" in the wrong PRP. It should be in mainRoom (since the corresponding softvolume is there), but the plVisRegion is in the Hedges PRP.

vr = root.find(0x0116, volume.Key.name, 1) looks for a visregion in the same PRP as the object. Since it doesn't find one, the last argument with value 1 means "create it if it isn't found". So the visregion is created in the second PRP, although the SoftVolumeSimple is located in the first.Then, eithervolume = softVolParser.parseProperty(str(reg),str(self.Key.name))orvolume = refparser.MixedRef_FindCreateRef(reg)does the same thing: look for the soft volume with the name you gave in the same PRP as the object, and since it cannot find it, it creates one... probably empty, which crashes Uru.

VisReg_Hedges1 has taken it into the correct PRP, because the objects that belong to it are put in that page.Only the belonging softvolume keeps stuck in the first PRP, while a copy of it with zero content makes it into the second PRP.(It seems the VisReg made it automatically to the second PRP.)I'm sure I already tried to force putting that VisRegion into page 1 by assigning page_num=1 to it, which did not work. All belonging objects disappeared.I tried again, which seems to work now. Don't ask why, I don't know.

Let's assume this as solved for now - until I come up with issues again. (oh, and by the way: URU did not crash. I just behaved strange in showing objects.)

Your prcdc wants to use jpeg-8 but finds jpeg-9. This *should* not be a problem, but it looks like it is and should be fixed. Where did you get your copy from? If it is using some libjpeg or jpeg DLL you can try to replace it with a DLL of version 8.

If all you want is to extract a texture image, you can use the latest version of PlasmaShop. I added a "Save As..." link to the texture preview that allows you to export to formats like JPG, PNG, TIFF and BMP. I'm not sure whether Zrax released that version yet, but you can use my download here. The prcdc in there might also work.