h-uru / libhsplasma Goto Github PK

Currently PRCs containing a plAgeLinkStruct (such as the plLinkToAgeMsg in a linking book's responder) simply show an integer value, but it would be useful for human readers to use the proper enum names.

It looks like JPEG compression always uses the top mip level, even if there
are multiple mipmaps. The following code will cause a crash if a JPEG
mipmap has more than 1 mip level:

for(int level = 0; level < mip->getNumLevels(); level++) {
char *data = new char[mip->GetUncompressedSize(level)];
mip->DecompressImage(level, data, mip->GetUncompressedSize(level));
glTexImage2D(GL_TEXTURE_2D, level, GL_RGBA, mip->getLevelWidth(level),
mip->getLevelHeight(level), 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
delete data;
}

A plMipmap that will cause the crash is xkingadeshmtkcvrd_eng*1#0.hsm in
City.age

(by branan, from https://code.google.com/p/libhsplasma/issues/detail?id=45)

Comment 1 (Zrax):

JPEG-compressed plMipmap objects only store the top-level mipmap, regardless of how
many mipmaps the PRP says are available. HSPlasma currently does not scale JPEG
mipmaps for you...

Changing to FeatureRequest because of this.

Comment 2 (Paradox):

It should be safe to use gluBuild2DMipmaps for JPEG images?

Storing the POTS physics flags in the generic flags is not entirely lossless, which triggers a bunch of warnings when reading some POTS files. Worse, editing such a file using libhsplasma will write it back in a changed state.

Examples:
BahroCave_District_YeeshaCave.prp: [003F]Wedge-TeledahnExclude colGroup changed: 0x00020000 => 0x00000000
BaronCityOffice_District_BaronCityOffice.prp: [003F]OuterSphere colGroup changed: 0x00000000 => 0x00020000
city_District_canyon.prp: [003F]OuterSphere03 colGroup changed: 0x00000000 => 0x00020000
city_District_courtyard.prp: [003F]ALYOrangeCone10 colGroup changed: 0x03820000 => 0x03800000
CustomAvatars_District_YeeshaNoGlow.prp: [003F]YeeshaNoGlow memGroup changed: 0x00020000 => 0x01000000

It is possible to export data that will not function due to race conditions in all versions of Uru. Specifically, plAGMasterMod assumes that all other modifiers are loaded on the targeted plSceneObject and expects to be able to access the plAGModifier immediately. Given that the plSceneObject modifier list is often what causes these objects to load, there is a mandatory order for modifiers in the plSceneObject modifier list.

(arbitrary mods)
plAGModifier
(arbitrary mods)
plAGMasterMod, plCameraModifier

libHSPlasma should probably correct this at write-time.

When compiling with Visual C++ 2012 (v110 toolchain), I see many compile warnings (almost ten thousand) of the same type. They seem to all occur when using a libhsplasma DLL_[CLASS|STRUCT] in an STL container.

C:\Development\Plasma\libhsplasma\core\Util/hsBitVector.h(77): warning C4251: 'hsBitVector::fBitNames' : class 'std::map<_Kty,_Ty>' needs to have dll-interface to be used by clients of class 'hsBitVector'

I have no idea what these warnings mean (they weren't present with v100). I do know that they seem to be increasing the compile time, which is somewhat frustrating.

EDIT: According to MSDN (http://msdn.microsoft.com/en-us/library/esew7y1w.aspx), they're garbage in this case. Can we disable these?

These would be nice to have for korman

Making any changes to Particles will cause the Yaw and Pitch to become zero for any particle emitters

Before

After

I was working on the Great Tree Pub, when I noticed that if libhsplasma touches the ATC Anim files, the hsQuats changed "-nan(ind)" into a number.
This cause the below issue.

With the improvements in Python IDEs and Python language servers, such as VS Code, in both interpreting python type hints and displaying this information, we should consider writing PEP 484 Type Stubs for PyHSPlasma to improve the experience.

Essentially, PyInit_PyHSPlasma isn't marked as visible, so the module initialization fails.

This is fixed in Python >= 3.9 because they added visibility attributes to the PyMODINIT_FUNC macro, however some of us are still building with Python 3.7 to run korman on Linux with Blender 2.79 (which depends on Python 3.7).

Based on how libHSPlasma and libHSPlasmaNet are doing things, I imagine there's some sort of PYHSPLASMA_EXPORT thing that could be added here to make it visible, but I don't know enough about where and how CMake is defining these macros to be sure of that...

Some characters must be escaped when used in data or attributes in an XML file, such as the ampersand character. Otherwise, XML parsers will reject the file.

LibhPlasma methods that output prc files or views should change "&" to "&", and methods that input prc files should change "&" back to "&", and do the same for the other illegal characters.

(from https://code.google.com/p/libhsplasma/issues/detail?id=75)

Comment 1:

Only place I can think of where an & might occur is inside the raw hex data blocks for mipmaps or unsupported classes.

Could we avoid needing to escape by wrapping those in a <[CDATA[ ... ]]> block?

Comment 2:

<plDrawableSpans>
<plKey Name="Personal_District_psnlMYSTII_00000000_0Spans" Type="plDrawableSpans" Location="13;1" LocFlag="0x0000" ObjID="1" />
<Properties Flags="0x00000000" Criteria="0x00000000" RenderLevel="0x00000000" />
<Materials>
    <plKey Name="Top&Bottom" Type="hsGMaterial" Location="13;1" LocFlag="0x0000" ObjID="165" />

Basically, anywhere the age builder can enter a name, such as materials, textures, etc. But also technically, any manual change in the prp could do that.
CDATA blocks are a possibility, but not as simple or safe as escaping when exporting, and de-escaping when importing.

The current Python/CMakeLists.txt is responsible for setting the destination directory of the shared python library PyHSPlasma.so. It currently does so by executing a Python code snippet obtaining the value of distutils.sysconfig.get_python_lib().

Unfortunately it does so with a call to that routine with no arguments, which sets PYTHON_LIB_DIR to the installation directory of the currently running Python interpreter.

While that may be appropriate for building/installing as a manner of installing HSPlasma for the machine performing the build, it becomes inappropriate when HSPlasma is being built in a build environment such as Jenkins, where the Jenkins build process attempts to do a make install with CMAKE_INSTALL_PREFIX set to a non-live destination. If the build is performed (as it should be) in Jenkins under a non-privileged user, the make install operation will attempt to install PyHSPlasma.so into the working Python library directories, and fail because of privileges. As it should. If for no other reason than that make install ignored CMAKE_INSTALL_PREFIX.

I am suggesting for the NOT WIN32 situation to alter your snippet to use

get_python_lib(prefix='${CMAKE_INSTALL_PREFIX}')

instead of the base get_python_lib() call. This will properly pick up the destination for the Python library in an isolated build environment.

-rarified

Opening magiquest prps in prpshop will fail to load some of the data correctly.

plMipmap::CompressImage (squish) appears to overrun the image data buffer when compressing a DXT5 mip level of 1x1. In most cases, this does not appear to crash on Windows x64. However, I have observed a few scenarios where the MSVCRT detects this overrun on deleting the image data, crashing the application. Specifically, using a 160x160 JPEG that was resized to 128x128 in Blender (the image buffer I provide is RGBA). This behavior can be debugged by using the Windows Debug Toolkit's gflags.exe /p /enable <appname.exe>.

AFAICT our level size calculation is only allocating enough buffer for the alpha block in, so when squish tries to write the color block, it corrupts the heap.

A potentially related issue: when exporting a DDS from PRPShop and attempting to import the same DDS yields a read-past-eof error. PRPShop consistently requests 12 more bytes than is available in the stream.

I have been trying to add some permalights to a drawable span and it keeps stripping them out when I hit compile and save.

		<Span>
			<PermaLights>
				<plKey Name="RTOmniLight15" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="15" />
			</PermaLights>
		</Span>
		<Span>
			<PermaLights>
				<plKey Name="RTOmniLight16" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="16" />
			</PermaLights>
		</Span>
		<Span>
			<PermaLights>
				<plKey Name="RTOmniLight09" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="9" />
				<plKey Name="RTOmniLight08" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="8" />
				<plKey Name="RTOmniLight10" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="10" />
				<plKey Name="RTOmniLight06" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="6" />
				<plKey Name="RTOmniLight05" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="5" />
				<plKey Name="RTOmniLight11" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="11" />
				<plKey Name="RTOmniLight07" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="7" />
				<plKey Name="RTOmniLight12" Type="plOmniLightInfo" Location="21;10" LocFlag="0x0000" ObjID="12" />
			</PermaLights>
		</Span>
	</PermaLightInfo>

The last span there is stripped out every time I hit compile and save.

when I try to make changes to Drawable Span - Ahnonay_EngineerHut_00000000_0Spans and then save it, it causes prpshop to insta-crash.

Im using the latest prpshop and libhsplamsa. im on windows 10 22h2.

When I try to build this on my Debian testing system, I get a build error:

mkdir build
cd build
cmake ..
make -j8

shows

uru/libhsplasma/core/PRP/Animation/plWindBoneMod.cpp: In member function ‘virtual void plWindBoneMod::removeTarget(const plKey&)’:
uru/libhsplasma/core/PRP/Animation/plWindBoneMod.cpp:107:65: error: no matching function for call to ‘find(std::vector<plKey>::iterator, std::vector<plKey>::iterator, const plKey&)’
  107 |     auto it = std::find(fTargets.begin(), fTargets.end(), target);
      |                                                                 ^
In file included from /usr/include/c++/10/iterator:66,
                 from /usr/include/string_theory/st_charbuffer.h:29,
                 from /usr/include/string_theory/st_string.h:26,
                 from /usr/include/string_theory/string:1,
                 from uru/libhsplasma/core/Stream/hsStream.h:23,
                 from uru/libhsplasma/core/Stream/pfPrcHelper.h:20,
                 from uru/libhsplasma/core/PRP/plCreatable.h:20,
                 from uru/libhsplasma/core/PRP/KeyedObject/hsKeyedObject.h:20,
                 from uru/libhsplasma/core/PRP/Object/plSynchedObject.h:20,
                 from uru/libhsplasma/core/PRP/Modifier/plModifier.h:20,
                 from uru/libhsplasma/core/PRP/Animation/plWindBoneMod.h:20,
                 from uru/libhsplasma/core/PRP/Animation/plWindBoneMod.cpp:17:
/usr/include/c++/10/bits/streambuf_iterator.h:422:5: note: candidate: ‘template<class _CharT2> typename __gnu_cxx::__enable_if<std::__is_char<_CharT2>::__value, std::istreambuf_iterator<_CharT> >::__type std::find(std::istreambuf_iterator<_CharT>, std::istreambuf_iterator<_CharT>, const _CharT2&)’
  422 |     find(istreambuf_iterator<_CharT> __first,
      |     ^~~~
/usr/include/c++/10/bits/streambuf_iterator.h:422:5: note:   template argument deduction/substitution failed:
uru/libhsplasma/core/PRP/Animation/plWindBoneMod.cpp:107:65: note:   ‘__gnu_cxx::__normal_iterator<plKey*, std::vector<plKey> >’ is not derived from ‘std::istreambuf_iterator<_CharT>’
  107 |     auto it = std::find(fTargets.begin(), fTargets.end(), target);
      |                                                                 ^
make[2]: *** [core/CMakeFiles/HSPlasma.dir/build.make:368: core/CMakeFiles/HSPlasma.dir/PRP/Animation/plWindBoneMod.cpp.o] Error 1

Version information:

$ g++ --version
g++ (Debian 10.2.0-15) 10.2.0

Compiling on macOS for Apple Silicon (Arm64) yields the following warning:

clang: warning: argument unused during compilation: '-msse2' [-Wunused-command-line-argument]

Also libsquish tries to pull in the SSE headers and fails to compile.

Files: core/PRP/Geometry/plGBufferGroup.h and plGBufferGroup.cpp

Issue originally posted at the Guild of Writers: http://forum.guildofwriters.org/viewtopic.php?f=114&t=5872

It seems using getVertices() function of plGBufferGroup doesn't work as expected.
Calling this function with start != 0 crashes the program using HSPlasma.
When setting start to 0 and count to any number, the function returns every plGBufferVertex from (start) to (last index - count), instead of from (start) to (start+count).

I had this issue using the Windows 64-bits r848 Python interface.

If passed a mesh with no verts, the NXCook*Mesh functions in plGenericPhysical::IWritePXPhysical fail, and the GenericPhysical object is not fully written to the PRP. However, any SimulationInterfaces which reference it still continue to do so, resulting in a crash in Plasma when loading the PRP.

For example, reading and writing back Gira_District_giraCanyon.prp with my check-script (scripts/prp-checkfiles.py -cp) complains (amongst others) about

Type [0015]plCoordinateInterface, object CapBase06 changed but stay same size
Type [0015]plCoordinateInterface, object Fumerols29 changed changed size (337 => 333)
Type [0015]plCoordinateInterface, object Fumerols29 changed but stay same size
Type [0015]plCoordinateInterface, object Fumerols27 changed changed size (337 => 333)
Type [0015]plCoordinateInterface, object Fumerols27 changed but stay same size
Type [00D5]plPointShadowMaster, object ShadowLight-LampPost_2 changed but stay same size
Type [00D5]plPointShadowMaster, object ShadowLight-LampPost_3 changed changed size (97 => 93)
Type [00D5]plPointShadowMaster, object ShadowLight-LampPost_3 changed but stay same size
Type [00D5]plPointShadowMaster, object ShadowLight-LampPost_0 changed changed size (97 => 93)
Type [00D6]plDirectShadowMaster, object ShadowLightCaveOpening_3 changed but stay same size
Type [00D6]plDirectShadowMaster, object ShadowLightSun changed changed size (86 => 82)
Type [00FF]plStereizer, object cSfxStereize-LavaR changed changed size (73 => 69)
Type [00FF]plStereizer, object cSfxStereize-LavaR changed but stay same size

I'm pretty sure this is a regression, TPOTS files used to read and write back fine (except for physics). I'm currently doing a bisect.

What steps will reproduce the problem?

1. Open any MOUL file containing a physical object

What is the expected output? What do you see instead?
I would expect a valid, well-formed file to open without a warning. Instead, I get an error like
this for many (if not all) plGenericPhysical objects:
"Size-Read difference: n bytes"
I think this is caused by the contained PhysX data which libHSPlasma can not parse - but
this error message is useful to find possible problems in prp files, so a well-formed file
should not show them.
Is the length of the cooked data known? If yes, I would suggest to just skip over it so that
the error is not shown if the length value is correct. If not, I suggest to skip over all bytes
which are left for the object at the end of the function reading a PhysX physical. Since the
message is then silenced only for this type, it can again be used to find actual problems.

(From https://code.google.com/p/libhsplasma/issues/detail?id=15. There are some comments on there, which can be summed up by: We do not want to just silence the warning since it is an actual issue. Instead, someone will have to implementing reading the PhysX data)

21c5f67

This commit causes objects in the file to not be removed correctly.
If you remove everything in a prp with PRPShop, the file size will stay the same after you save it.

The physics flags from POTS are not always properly preserved, which makes edit POTS age files with PrpShop a problem: You will loose information, even if you change an object totally unrelated to physicals.

Some examples:
Reading TPOTS/dat/Myst_District_Fireplace.prp...
<28|1>[003F]d_sw colGroup changed: 0x00000000 => 0x00020000
<28|1>[003F]FireplaceDoorExclRegMesh colGroup changed: 0x01020000 => 0x01000000
<28|1>[003F]fireplaceExcludeRegionMesh repGroup changed: 0x00020000 => 0x00000000

Reading TPOTS/dat/Kadish_District_opt-kdshCourtyardPhysLeaves.prp...
<22|19>[003F]RedLeaf00b colGroup changed: 0x03800000 => 0x03000000
<22|19>[003F]RedLeaf01b colGroup changed: 0x03800000 => 0x03000000
<22|19>[003F]RedLeaf02b colGroup changed: 0x03800000 => 0x03000000
<22|19>[003F]RedLeaf03 colGroup changed: 0x03800000 => 0x03000000
<22|19>[003F]RedLeaf04 colGroup changed: 0x03800000 => 0x03000000

Reading TPOTS/dat/GreatZero_District_LinkInRoom.prp...
<39|3>[003F]OuterSphere colGroup changed: 0x00000000 => 0x00020000

Wrap all libhsplasma calls in PyHSPlasma to raise python exceptions. As it is now, C++ exceptions can bubble up through python and crash everything. A good macro would make this easy.

Shared mesh for clothing when modified with PRPShop will disappear if you get too close to the clothing in game.
I found when doing a binary compare of before and after that the initial section of the binary was very different.
Replacing the initial section with the original changes would fix the disappearing clothes.

I think that the maxbones and penbones are not being saved correctly, or the structure of the file is somehow important to MOULA in displaying the clothing correctly.
This only affects the visibility of the clothing when you get close to them.

The recent change to install PyHSPlasma to ${_PYTHON_PREFIX}/lib/python${PYTHON_VERSION_STRING}/site-packages broke it (again). For two reasons, actually:

• ${PYTHON_VERSION_STRING} expands to 2.7.6, but the Python folder for that version is python2.7 (the patch version is not relevant)
• At least on my system (Debian testing), /usr/lib/python2.7/sites-packages is not searched for libraries to import. However, /usr/lib/python2.7/dist-packages and /usr/lib/python2.7 are searched.

Building and installing libhsplasma on 64bit linux distros will always put the modules in the prefix/lib directory regardless of the conventions of the distribution, which may want 64bit libraries installed in prefix/lib64. To fix this, some cmake files need to be manually adapted, a better option would be to use ${LIB_INSTALL_DIR} and make it configurable. Find two patches attached to fix this problem. This way, libhsplasma can be built with
cmake -DCMAKE_INSTALL_PREFIX:PATH= -DLIB_INSTALL_DIR=< libdir > .
to respect the filesystem conventions.

(from https://code.google.com/p/libhsplasma/issues/detail?id=73)

Comment 1:

I will point out that if your distro is 64-bit and using /usr/lib for 32-bit files, it's breaking the linux Filesystem Heirarchy Standard which while non-normative (like most linux standards) is followed by most distros.

That aside, I really have no idea why this was hardcoded to lib instead of ${LIB_INSTALL_DIR}. I don't see why we can't fix it.

Comment 2:

From what I know all Red Hat based systems, and also Fedora, use lib for 32bit libraries and lib64 for 64bit ones, while Debian based distros use lib32 for 32bit ones and lib with a lib64 symlink pointing to lib for 64bit ones.

Comment 3:

LIB_INSTALL_DIR isn't predefined by CMake (although on Fedora, you probably wouldn't notice that since Fedora hacks their CMake to include it).

On Ubuntu this causes errors when running cmake.

There's a SetPaths.cmake file in the Google result for "LIB_INSTALL_DIR" that we might be able to pull in, but it seems a bit overkill IMO.

A lighting regression has appeared in Chiso Preniv, introduced by commit 63ffd78.

Any ideas @Jrius?

It seems that the Python module is compiled against Python 3, but installed to the Python 2 path:

$ nm /usr/lib/python2.7/dist-packages/PyHSPlasma.so -D|fgrep PyHSPlasma
00000000000cde00 T PyInit_PyHSPlasma

If I understand the source properly, this symbol should only exist for Python 3 modules. Loading it in Python 2 gives the following error:

ImportError: dynamic module does not define init function (initPyHSPlasma)

I'm not sure what changed to break this. It's certainly not in libhsplasma, as the breakage was introduced after a re-build yesterday. But probably the Python stuff in cmake is should somehow make sure that the versions match. (And Python 2 is, for now, the version I'd want, but it would be okay if I would have to configure that explicitly.)

Attached is an example of a prp file that used to open fine with older versions of libhsplasma, that works fine with Uru, but that does not work with current master. The error shown by PrpShop says something about invalid UTF-8, so I assume this is related to the recent move to a different string processing library.

Elodea_District_beach.prp.tar.gz

hsArraySize uses features not available in VC++2013. There also seem to be lots of errors around the union in the ENDSWAP functions. Visual C++2013 is required by Korman due to Blender 2.79b's dependency on the same. It is presently not feasible to upgrade Korman to Blender 2.80.

PyHSPlasma functions that accept an str for a filename or path should also accept an object implementing os.PathLike by calling the object's __fspath__ method. os.PathLike was added in Python 3.6.

• Take an array of plGBufferVertexs
• Take an array of plGBufferIndices
• Do Magic!
• Add them to the DSpans object
• Return a plIcicle* (so that flags can be set)

This should handle adding the BufferCell, calculating the Icicle bounds, and
possibly matrices (if passed as an argument?).

Ideas? Feedback? This would greatly simplify the work done by AgeCreator and
PyPRP.

(by Paradox, from https://code.google.com/p/libhsplasma/issues/detail?id=32. Below are the comments copied from over there)

Comment 1 (Paradox):

Looking at Cyan's PlasmaMax plugin, it's interesting to see how they build up their geometry.

They create a plGeometrySpan for each material on each object (usually only 1, but if an object has 2 material == 2 spans).
They add all the vertices, UV coords, faces, paint, etc. to the GeometrySpan.
They do some magic to determine the renderlevel and rendering flags at a per-object level and store those in the GeometrySpan instance data.

At some point when all of the objects are converted, they start building DrawableSpans.
Grab all the GeometrySpans with the same RenderLevel and blend flags, consolidate the data into DrawableSpans data.
Once the data is in the DrawableSpans, they run an optimize function to build up the spacetree and clear any references to the GeometrySpan data.

[I'll finish my thoughts on this in a bit... >.>]

Comment 2 (Paradox):

[continued from above]

I don't think we need anything quite that complicated, since we can probably imitate the GeometrySpan stuff in PyPRP without needing a full implementation. However, other projects will need a GeometrySpan -> DrawableSpan converter soon.
The majority of the code for this was documented by Tahgtahv not too long ago...

Comment 3 (Paradox):

Branan's been working on this for AgeCreator.

(I do not know the current status, and since the original bug is still open, I assume branan got interrupted somewhere)

What steps will reproduce the problem?

1. plasmasum -c newsumfile.sum
2. plasmasum -c existingsumfile.sum

What is the expected output? What do you see instead?

1. plasmasum -c newsumfile.sum should create a new, empty file. It does not, and the only output is:
   newsumfile.sum:
2. plasmasum -c existingsumfile.sum should empty the already existing sum file. It does not, and the only output is:
   exisitingsumfile:

There is no error message.

What version of the product are you using? On what operating system?
Last Windows build for 64 bits. On Windows 7 64 bits.

Please provide any additional information below.
libHPlasma and Uru are installed on drive I:, and UAC is turned off.

(from https://code.google.com/p/libhsplasma/issues/detail?id=77)

pyLocation_Hash can return -1, Python's magical "hey there was an exception" value in cases when there is no error (there should never be an error for hashing locations). This value (and the exception) has been observed on default-inited plLocation objects.

I know this is one of those problems where there's no perfect solution. Previously we tried not to touch Object IDs and that turned into problems when re-saving files and breaking references between objects, now we always recalculate Object IDs when saving pages.

We've had a few bugs lately around PRC parsing, and I wanted to to try comparing before and after PRC output to make sure it was the same, using a process like this:

prcdc -o before.prc somefile.prp
prcc before.prc -o temp.prp -v moul
prcdc -o after.prc temp.prp
diff before.prc after.prc

Except the prcc step recalculates all the Object IDs and reorders all the objects and makes the diff completely unusable. In theory it doesn't need to do that, since it's already parsing the Object IDs from the PRC file (but it's unknowable if there have been changes to the PRC file that would require recalculating IDs).

Maybe this is something that we could set as a flag on plResManager for whether to recalculate Object IDs at write time, and default it to true, but provide a prcc flag that tells it to keep the existing IDs?

Running PrpPack with either the -c or -r options results in a Segmentation Fault.

Tested multiple PRPs from TPotS, MOULa, and MystV with the same result.

The following small script triggers a segfault when run in the Uru:CC directory:

import PyHSPlasma
plResMgr = PyHSPlasma.plResManager()

for file in ("Minkata_District_minkCameras.prp",
             "Minkata_District_minkExteriorDay.prp"):
    print "loading",file
    page = plResMgr.ReadPage("dat/"+file)
    print "unloading",file
    plResMgr.UnloadPage(page.location)

The program prints the following output:

loading Minkata_District_minkCameras.prp
unloading Minkata_District_minkCameras.prp
loading Minkata_District_minkExteriorDay.prp
Segmentation fault

The crash does not happen if I just load minkExteriorDay.prp.

The backtrace is

#0  0x00007ffff642a10c in plSceneObject::addTarget (this=0x1d4df80, obj=<optimized out>) at /home/r/src/uru/libhsplasma/core/PRP/Object/plSceneObject.cpp:28
#1  0x00007ffff63efbe4 in plKeyData::setObj (this=0x1f6f920, obj=obj@entry=0x157f7c0) at /home/r/src/uru/libhsplasma/core/PRP/KeyedObject/plKey.cpp:83
#2  0x00007ffff63ef1b4 in hsKeyedObject::read (this=0x157f7c0, S=S@entry=0x1533300, mgr=mgr@entry=0xa12580) at /home/r/src/uru/libhsplasma/core/PRP/KeyedObject/hsKeyedObject.cpp:36
#3  0x00007ffff642cc60 in plSynchedObject::read (this=0x157f780, S=S@entry=0x1533300, mgr=mgr@entry=0xa12580) at /home/r/src/uru/libhsplasma/core/PRP/Object/plSynchedObject.cpp:21
#4  0x00007ffff63fea58 in plMultiModifier::read (this=0x157f720, S=S@entry=0x1533300, mgr=mgr@entry=0xa12580) at /home/r/src/uru/libhsplasma/core/PRP/Modifier/plModifier.cpp:51
#5  0x00007ffff6401aad in plPythonFileMod::read (this=0x157f6d0, S=0x1533300, mgr=0xa12580) at /home/r/src/uru/libhsplasma/core/PRP/Modifier/plPythonFileMod.cpp:229
#6  0x00007ffff649acbc in plResManager::ReadCreatable (this=this@entry=0xa12580, S=S@entry=0x1533300, canStub=canStub@entry=true, stubLen=stubLen@entry=417) at /home/r/src/uru/libhsplasma/core/ResManager/plResManager.cpp:619
#7  0x00007ffff649bb27 in plResManager::ReadObjects (this=this@entry=0xa12580, S=S@entry=0x20c6b40, loc=...) at /home/r/src/uru/libhsplasma/core/ResManager/plResManager.cpp:514
#8  0x00007ffff649d990 in plResManager::ReadPage (this=0xa12580, filename=<optimized out>, stub=<optimized out>) at /home/r/src/uru/libhsplasma/core/ResManager/plResManager.cpp:168
#9  0x00007ffff68fbe78 in pyResManager_ReadPage (self=0x7ffff7f5c228, args=<optimized out>) at /home/r/src/uru/libhsplasma/Python/ResManager/pyResManager.cpp:159

I am pretty sure this used to work in earlier versions - I am still trying to figure out when it broke.

Was making some changes to Cluster groups in PRPShop and I noticed that it completely zero'd the vertex colors of the template section. Tested just doing a save and compile with the same data and only the vertex colors were incorrectly changed. Everything else was the same.