MQO prps fail to open correctly

[Hazado]

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

[sinkillerj]

I will say good luck to anyone attempting to tackle this. There are ways to get into these files with a mix of tools, but the MQO PRPs got messier and messier as they were updated.

[Deledrius]

the MQO PRPs got messier and messier as they were updated.

Messier in what way(s)?

[sinkillerj]

Their formatting got a bit, atypical to say the least. From my perspective Cyan did not have the core URU team at that point, and thus the talent who knew how to work Plasma. For this reason quick hacks were employed in some places.

Mind you this is not insider knowledge or anything, just speculation on how we got to this point, and my own experience from working with these files in the past.

The Portal Well tends to be the easiest to work with, it saw far less updates from the beta versions, Courtyard and Forest are far more fun.

In regards to file versions that are still out there to refrence, in the community we have the retail disk, as well as the final live update. Sadly I did not keep the beta versions with the exception of a drizzle converted Forest. Regardless happy to share what I have, and happy to obtain other versions that may be floating around.

[Deledrius]

I wasn't aware they distributed a retail disc version!

[Hazado]

Examples of the issues with the data

ATC Anims Drizzle converted version Non converted version opened in PRPShop

Responders Drizzle version Non Converted

[sinkillerj]

It was a DVD we distributed at some MQ locations, I know we had it at our flagship in Myrtle Beach, but not sure what all franchise locations we sent it to. It was a way to promote the game to those who just finished playing at the physical location, we had them right at the exit into the gift shop of the game area at Myrtle.

The whole concept of a game was a bit of a feedback loop, get the physical players online with the digital version, then get them, as well as whoever happened to find the game exclusively online, back to a physical location since they unlock the physical Silver Dragon fight at the end.

Now that the game is gone, physical legacy locations that still remain have just patched the requirements for Silver Dragon to not require the rune from MQO. It can make the intro more than a bit confusing due to the characters that a player with no concept of MQO would know, but at least its still playable.

[dpogue]

Essentially, some of the MQO classes and data diverged from MOUL. I believe they changed the "class versions" in the PRP file headers when that happened, but those might overlap with subsequent changes to MOUL/MOULa and the data format is otherwise identical and has no disambiguating features.

Partly, there hasn't been as much interest in figuring out what all those data changes are (same with Hex Isle, support for that is very spotty), and partly it's not clear how easy is it to tell whether it's an MQO file or a MOUL file.

[sinkillerj]

It has been awhile since I worked with this, but I believe when adding an instance in PlasmaShop you select what game it is? There could be a parameter to pass a game ID to libhsplasma applications if theres not already.

[Hazado]

Partly, there hasn't been as much interest in figuring out what all those data changes are (same with Hex Isle, support for that is very spotty), and partly it's not clear how easy is it to tell whether it's an MQO file or a MOUL file.

How would one go about finding the data changes? Im willing to try, but need a push in the right direction.

[dpogue]

How would one go about finding the data changes? Im willing to try, but need a push in the right direction.

Determine which classes have data changes (either by the "class version" in the PRP header, or by seeing what fails to open properly), then disassemble the MQO executable and track down the Read/Write functions for that plCreatable class and sort out what was added/removed as compared to MOUL.

Then figure out how to decide if it's an MQO file or a MOUL file (or ABM or UU or PotS or MV or Hex Isle) and make it conditionally read/write the extra data.

It's not exactly a quick or easy process 😞

[sinkillerj]

"It's not exactly a quick or easy process 😞"

And this is why I never finished my revival, the tedium of this game is real and I super do not have that kinda time right now lol.

[Hazado]

If drizzle is already decoding these somehow, can we use the drizzle source to find these?

[dpogue]

Maybe! It looks like you'd want to search for realreadversion==8 in https://github.com/Jrius/Drizzle

[Hazado]

Started a branch https://github.com/hazado/libhsplasma/tree/MQOSupport

So far ive gotten AGAnim and oneshots reading/writing correctly.

Still need help with the following plCloneSpawnModifier - Stub currently plResponderModifier - `Responder Message' not implemented - Its looking for kAvatarMgr - https://github.com/H-uru/libhsplasma/blob/7bdcc17b973b4cdeb666fa5d5b84e46c74164e82/core/ResManager/plFactory.cpp#L448 plCameraMsg - has extra 12 bytes, Drizzle thinks its vertex data

[dpogue]

The changes to plCameraMsg are going to be problematic. There's literally no indicator when opening a file whether it has those extra 12 bytes or not, and because the messages are inlined creatables in the plResponderModifier, we can't do anything like checking for EOF to know if more data is available. The class version of plResponderModifier is still 0, and there are no class versions for messages in the PRP header.

Unfortunately, if we don't read those 12 bytes, the rest of the plResponderModifier reading is off and we can easily get into loops trying to read garbage data as creatables and crashing horribly. 😕

FWIW, I wouldn't call it "vertex data" but 12 bytes is the right size for an hsScalarTriple (hsPoint3 or hsVector3), so maybe it's some sort of X,Y,Z coordinate that the camera should be facing or something like that.