observed diffrences between urucc and mystv

[jfmherokiller]

"Nice to see someone showing interest in picking up a lost craft " Its not at all a lost craft if you look at games like skyrim and the fallout series and a lot of other games which have unofficial modding support.

Also as far as I have rn in terms of disassembling uru and mystv I have the functions I named myself and some of the python internals mapped out.

[Sirius]

Maps and PDBs are extremely useful to people with actual reverse engineering skills. Which means neither me nor Maroonroon will have any use for those
Boy I sure am glad MOUL is now open source. I've relied on the Plasma/HSPlasma sources innumerable times. And the other day I even managed to compile the plClient for the first time and add a few tweaks (probably not impressive to some but for me it's a big achievement ! It shows how much work the community has put into improving the engine for less skilled users like me.)

Its not at all a lost craft if you look at games like skyrim and the fallout series and a lot of other games which have unofficial modding support.

What Paradox probably means is that in the context of Uru, reverse engineering hasn't been necessary for a while. It was more common during the early days of Uru modding.
The modders of games like Skyrim keep impressing me. Hacks that work on all engine versions due to an address library, complete overhauls of the movement and animation system, new physics engine for err, "stuff", and the like. And whenever the game updates, they fix mods in just a few days. These people are crazy good.
But let's not forget very few people actually have those skills. Those games have a massive fanbase...

[jfmherokiller]

true, also heres the latest version of the uru stuff I am also including a header file which contains the types I "reconstructed"

[Maroonroon]

I still don't don't understand what is a map file for? What's his purpose? Also for the pdb file?

.map and .pdb files provide information about where functions and data structures are located in the compiled .exe binary file, and are useful for debugging and reverse engineering.

Maps and PDBs are extremely useful to people with actual reverse engineering skills. Which means neither me nor Maroonroon will have any use for those

Thanks!

[Sirius]

true, also heres the latest version of the uru stuff I am also including a header file which contains the types I "reconstructed"

And here I thought reverse engineering was supposed to take time

Seriously though, I don't know how far you intend to go with this, but this is getting interesting. I wouldn't mind seeing if we could use this to fix a few issues (like the horrendous aspect ratio), or add a couple new features (such as external loading of textures, so we can create texture mods). Uru even supports adding new PRP types at runtime via the ModDLL folder, so if you go that way reimplementing the sketch feature sound feasible (although still quite difficult).

[jfmherokiller]

true, also heres the latest version of the uru stuff I am also including a header file which contains the types I "reconstructed"

And here I thought reverse engineering was supposed to take time

Seriously though, I don't know how far you intend to go with this, but this is getting interesting. I wouldn't mind seeing if we could use this to fix a few issues (like the horrendous aspect ratio), or add a couple new features (such as external loading of textures, so we can create texture mods). Uru even supports adding new PRP types at runtime via the ModDLL folder, so if you go that way reimplementing the sketch feature sound feasible (although still quite difficult).

well so far the only types I reconstructed are mainly stuff I copied from the python 2.2.2 headers. There are quite a few things not accounted for as of right now. I am tempted to see what I can pull from libhsplasma but since it has been significantly updated (that is my assumption at least) I am not sure how well it equates to the code in uru and mystv. Getting my hands on the pdb files of most of the libhsPlasma and other bits would probably help me map out types tho.

Btw one thing id love to implement is loading regular python files, eg uncompiled unpackaged python files. Basically throw a python file into the python folder and it will be loaded kind of thing.

[Sirius]

Correct me if I'm wrong, but wouldn't the current plClient code be closer to PotS and Myst V since they share the same codebase ? LibHSPlasma was made from scratch for reading/writing PRPs, so it's going to be fairly different from the engine itself, if I had to guess.

Btw one thing id love to implement is loading regular python files, eg uncompiled unpackaged python files. Basically throw a python file into the python folder and it will be loaded kind of thing.

Yes please. If it's not too complex to do, this can be a time saver !

Eventually I hope the open sourced plClient will be good enough for offline play. This will make adding such simple QoL improvements much easier...

[jfmherokiller]

Correct me if I'm wrong, but wouldn't the current plClient code be closer to PotS and Myst V since they share the same codebase ? LibHSPlasma was made from scratch for reading/writing PRPs, so it's going to be fairly different from the engine itself, if I had to guess.

Btw one thing id love to implement is loading regular python files, eg uncompiled unpackaged python files. Basically throw a python file into the python folder and it will be loaded kind of thing.

Yes please. If it's not too complex to do, this can be a time saver !

Eventually I hope the open sourced plClient will be good enough for offline play. This will make adding such simple QoL improvements much easier...

by plclient do you mean the code from here? http://wiki.openuru.org/index.php?title ... s#Download

also I just found the function that seems to deal with that moddll thing you were talking about in uru https://pastebin.com/Q01KzuS8

I do not know the entire format of these mod DLLs but they do seem to require an InitGlobals export.

[Sirius]

by plclient do you mean the code from here?

This appears to be it. Personally I always work with the H'uru fork since it's the one getting daily updates. The plClient part of the project is actually what compiles to UruExplorer.exe.
The MOUL client is obviously an evolution of the PotS one. The Myst V version of the engine was forked at some point between PotS and MOUL. That's why I suspect a recent plClient (for which we have the sources and can generate pdbs and maps) will have something like 80% in common with both the older PotS UruExplorer.exe and MV eoa.exe, for which we're lacking the sources. (Even though technically they weren't built by the same version of Visual Studio's compiler, but most of the underlying classes remain fairly similar.)

HSPlasma was written through reverse-engineering before we got the source code, with the sole purpose of being a PRP reader/writer. So I suspect it's going to compile to something quite different from the actual engine itself. Can still be used as a guide to understand the PRP format for older versions of the engine, of course.

I do not know the entire format of these mod DLLs but they do seem to require an InitGlobals export.

Oh, it's fairly straightforward. See the source to get an idea. That mechanism has been here since forever (even before the first release of Uru), and we have examples of it being used in the old Kahlo demo to load new PRP object types at runtime (I can dig up the download link if you want). I also used it a while ago to fix a mouse bug on PotS when playing Uru on Windows 10. Of course, if you intend to interact with the engine code itself, it only works for the version of the plClient it was intended for. That's why modding PotS through ModDLLs was never a huge deal - we don't have the offsets/structs for that version of the engine, and everyone is focused on improving the version of the client for which we have the actual sources.

[Tsar Hoikas]

by plclient do you mean the code from here?

This appears to be it. Personally I always work with the H'uru fork since it's the one getting daily updates. The plClient part of the project is actually what compiles to UruExplorer.exe.
The MOUL client is obviously an evolution of the PotS one. The Myst V version of the engine was forked at some point between PotS and MOUL.

MOUL and Myst V both diverged from TPotS. Cyan backported quite a few things from Myst 5 to MOUL, but only those they needed to build the game.

I do not know the entire format of these mod DLLs but they do seem to require an InitGlobals export.

That's why modding PotS through ModDLLs was never a huge deal - we don't have the offsets/structs for that version of the engine

ORLY?