3DS Max

[Paradox]

"Identical" except that every object reference is different between PotS and MOUL, the format of the PRP files is different, the class IDs are sometimes different, animation keyframes are entirely rewritten and no longer use the same set of plControllers, MOUL uses PhysX which has packed "cooked" physical data whereas PotS uses Havok which does not, Any object with a matrix is different, because Cyan added 1 byte to the start of every matrix...

Small changes, yes. But they are enough to make the object entirely incompatible.

[GPNMilano]

a) similar does not equal compatible, quite the opposite.
b) they don't need to create new tools from the ground up each time, just change things and add features enough to make them incompatible

Yes, but this is where logic takes over in my mind.

Take PyPRP. When we create our ages in blender, we create a book, that book is just a text file in Blender. We create our objects. Those objects are just objects in Blender. We cannot take the blend file, put it in the dat folder, and run uru off the blend file. Its not an age file, and it doesn't have the prps it needs. Instead we need to export. Upon export is when those objects are converted into things that Plasma knows what to do with. To me, it makes more sense to simply create multiple export options, under one tool, that tells 3dsmax/Blender "Okay, this object is going to be a Myst V clickable region" it then goes to the necessary scripts, in the case of Blender, and takes that information of what export it is to find the appropriate information in the logic etc. scripts, and export the object. Thus instead of multiple plugins, what would make more sense is one plugin that does everything, and upon export it reads what needs to be done to make it an age. Why would you create multiple plugins, when to me its much less techincal to just add the additional code into the plugin as a separate export. Like with PyPRP, we currently have PRP_SndClasses.py, PRP-AnimClasses.py etc. Why not, when we need to create a MOUL plugin, just create new ones for the objects that need to be changed (like physics etc) rather than rework an entire new plugin. Just put in the additional scripts needed, add an export function to pyprp that reads these new scripts upon export, and bam, you have a MOUL age.

Obviously to me, in the case of Blender, that seems alot more simple. (I don't know how it would be done with 3dsmax, and maybe thats why i'm confused as to why they did it the way they did.
c) You seem to be operating under the assumption that Paradox's assertions are his "opinion", as yours are. Paradox has had direct contact with present and former Cyan employees, who have told him things about their history. Most of his statements are based on facts gleaned from these exchanges, as well as a great deal of time spent staring into the inner workings of various versions of Plasma.

[Nadnerb]

If what you say is true, then converting MOUL to POTS would thus change the hex of the files as well

Why? Just because some parts of a file were not changed does not mean the tools used to create those files were compatible.

What is your argument here anyway? You say you think Cyan uses a unified toolset that supports every version of their engine, when they only really need support for their latest, and your justification is that a fan made tool that translates one version into another doesn't change the entire file, only some of it?

I don't see why any of this means that Cyan's tools must be capable of performing conversions between versions, or even that they're capable of operating in reverse... somehow... for importing from a one-way output format.

You say you just don't find it plausible that a company would change their tools and not have infinite backwards compatibility. (how much pointless coding would it take to do that?) So let's lay out a little scenario and see if you find it plausible. If not, why?

Okay, so Cyan writes engine, builds some content in max files, and uses a plugin that shares code with the engine (the data types) to export it to a game format. They release a game. Then they make updates and changes to their engine. Now it's no longer capable of reading or dealing with the files the last version used because of changes to a number of object types, so then what? Then update the plugin and export the same max file again to the new version's format. They don't loose anything except compatibility with a version of their engine that they're not using anymore.

Once they've released a game, they don't need to support that version of the engine anymore. Why would they? They can keep updating it and simply use the latest version for whatever game they're working on next. There is no need whatsoever, after a release, to suddenly need to export a "Myst V clickable region". If they end up needing to use the same content again, then they just grab their max files and export to the newest version.

The real point: Cyan does not need multiple plugins OR multi-version plugins because they only use one version of the engine at a time. The latest.

[GPNMilano]

What is your argument here anyway? You say you think Cyan uses a unified toolset that supports every version of their engine, when they only really need support for their latest, and your justification is that a fan made tool that translates one version into another doesn't change the entire file, only some of it?

First, one of the reasons I hold the assumption that there is one plugin for 3dsmax, is that Cyan has stated they are going to release both the plugin, and the source for it. But here's the problem with that, if there are multiple plugins, then which are they releasing, considering we make content for Uru POTS and yet we're going to be making content for both Uru POTS and MORE (Which will be using the MOUL plasma) so, are we only getting the one plugin, and for which plasma? Or are we getting multiple plugins now? This is why I hold the belief that there is one 3dsmax plugin, with multiple export functions. It may be that there are multiple plugins, but there is one plugin that governs both MOUL and POTS, while Myst V has a different plugin entirely.

But the fact remains, Cyan says they want to release the plugin, yet if there are multiple plugins then which one is getting released?

See the conundrum. If there are separate ones for every plasma, and they only release the MORE one, then generally we're going to have to take the source for said plugin, and adapt it to PyPRP (since its unlikely the average player will want to plunk down the 3000 for whichever 3DMax program that the plugin is compatible with) When they can just as easily use the free one with Blender. So, we need to adapt the plugin for PYPRP. If Cyan created multiple plugins, as has been suggested, then I don't think we should do the same is all. I think we should simply rework PyPRP's export, so that it can export to both versions, rather than create a separate plugin for MORE. This would serve two purposes 1. It would prevent unnecessary confusion from people about which plugin to use. 2. It would clear up the Export function of PyPRP as it currently stands, as we really don't need all those options. The average user only ever uses the "generate release age" option when creating a new age, and the "Generate single PRP with PerPage Textures" option for ages like Ahra Pahts and for hacking/modding their own Uru.

I'm just looking at what was done, and considering what should be done with our own plugin when the time comes.

[Grogyan]

Any previous version i'd expect would be in their vault along with backups of Max scenes.

The only reason I can see why people like Dustin were able to bake a backwards decompiler is on the basis that they know that information will be lost, the opposite is entirely not possible such is the way of software

I know that when we receive the max plugin, that PyPrp will change in a way what we will make what we do now entirely different

[GPNMilano]

The only reason I can see why people like Dustin were able to bake a backwards decompiler is on the basis that they know that information will be lost, the opposite is entirely not possible such is the way of software

I know that when we receive the max plugin, that PyPrp will change in a way what we will make what we do now entirely different

Well, to be techincal, 95 percent of the information was intact. THe only thing that was really lost with converting the ages was the physical stuff. And that was only on the camera regions, and ladder regions. (for whatever reason) clickable regions remained intact, for the most part. Some linking books didn't work, yet the Myst linking book in Kveer did, as did the linking books for Eder Tsogal, Delin, Garrison, and the Great Zero in the hoods. Figure that one out, cause I'm still confused as why some clickables converted yet others didn't.

The rest of the stuff (the doors in the Eders) they don't work because they were coded with C++ like the other game APIs. And of course the GUIs and CustomAvatar and Clothing ages didn't convert properly. Which isn't a huge surprise, considering they're a mess to get working even with PyPRP, or so I've heard.

[D'Lanor]

Anyone who expects a MORE compatible PyPRP version immediately after the release of the Max plugin will most likely be disappointed. It is not as if you can simply throw it at Blender and press some kind of magical "convert" button.

If we want PyPRP MORE compatible around the same time Cyan releases their Max plugin the PyPRP developers should be working on it as we speak with the knowledge they already have at this time. The code of the Max plugin will only help them to tweak and add functionality afterwards.

I don't see a reason why MORE functionality would change PyPRP fundamentally. Of course there will be changes during the implementation but if it suddenly becomes a totally different tool I will eat my hat.


Edit: grammatical error

[Aloys]

One different approach to the "Various engines compatibility" exporter:
It wouldn't make sense from a production stand point that they keep a 'one for all' approach. In a software development environment one of your primary concerns when working on different projects which share 'some' code is to keep things clean and neatly separated wherever possible. So when you move from version 1 of your engine to version 1.1 or 2 you clean everything you can from the old version that you won't *need* anymore. Simply because you don't need it. If you don't do that your code base end up being a mess, which makes you lose heaps of time and money to maintain, debug, and evolve.
Then again they might do it for reasons we don't know, but for all we know that wouldn't seem like the logical thing to do.
So I vote for 'no'.

[Lontahv]

Anyone who expects a MORE compatible PyPRP version immediately after the release of the Max plugin will most likely be disappointed. It is not as if you can simply throw it at Blender and press some kind of magical "convert" button.

If we want PyPRP MORE compatible around the same time Cyan releases their Max plugin the PyPRP developers should be working on it as we speak with the knowledge they already have at this time. The code of the Max plugin will only help them to tweak and add functionality afterwards.

I don't see a reason why MORE functionality would change PyPRP fundamentally. Of course there will be changes during the implementation but if it suddenly becomes a totally different tool I will eat my hat.


Edit: grammatical error

Right. We are in the process of it.

[Justintime9]

eating your hat?