RAWA is our new community manager

[BAD]

I believe once the main code and prp structures are released we will be able to *hurm* acquire the meshes at least of the figures. The rest will have to be rebuilt if Cyan doesn't give out the originals. I understand that would be really difficult to do, but not impossible.

Perhaps if we made this clear to RAWA, he could speak to the rest of Cyan about it.

[GPNMilano]

At the moment I think it's best that Cyan focus on the two things, at this point, that are needed to get OpenSource up and running. Ripping out of proprietary code that is not theirs, so that they can release the source code for the client/servers and toolset. The second thing being is setting up a data server where we can download the compiled versions of the source to the servers we set up. (hopefully uneditted, as the compiled versions really won't give the community any more information than what we've already had for years) This is the quickest and fastest way to get Uru up and running. With the compiled versions the community will be able to meet once more in the cavern, meanwhile with the edited source code we can than start patching in the code we need to compile our own versions of the client.

Here's my issue with this whole mess though. Even if Cyan allows us to download the compiled versions of the client, and the game data (prps sound files etc). Won't there come a time when the client will be toyed with and reconfigured in such a way that the original age files for MOUL are no longer compatible with the newly compiled client (IE like what happened between AMB, CC and MOUL) Especially if we will be rewriting missing parts of the source code that very well could be tied with things like bink, and the physics engine itself?

[Trylon]

*cough* Drizzle *cough*

[J'Kla]

I stand corrected on the maintainer suit thing. However in the original game the only point of access to the wall meant wearing a maintainer suit and that would surely have lowered data overhead. Therefore not having legs to code for in a kayak paddling situation and making upper body wetsuit as standard has to make it simpler to code.

In the same way that avatars don't collide if the collision mesh was tied to the boat. My current thought is an age as a white water course and at some point an option of whitewater rafting. This all has to be way in the future anyway.

[ddb174]

Yeah, once it gets to the point were we actually have a working client (presumably, we'll want a single client that works both online and offline), I'll just make Drizzle convert Pots->Moul, so that we can have all the Fan Ages on the new client. And if the prp format has to change a little, then a Pots->Newformat and Moul->Newformat conversion. Hopefully ODE will suffice for all the physics things we want...

[GPNMilano]

Yeah, once it gets to the point were we actually have a working client (presumably, we'll want a single client that works both online and offline), I'll just make Drizzle convert Pots->Moul, so that we can have all the Fan Ages on the new client. And if the prp format has to change a little, then a Pots->Newformat and Moul->Newformat conversion. Hopefully ODE will suffice for all the physics things we want...

Here's the thing though, with multiple people working on multiple, possibly different clients, in the end there may be some "shards" that use a client incompatible with others. Perhaps it's best to develop drizzle into a tool that can convert between the varying formats. So that pyprp can simply export to the one starting format that the client becomes (if we develop a client that works both online and offline). In essence we take pyprp and make it so that it exports into a single format (say the new format that works offline and online) and then, when people develop the client to varying degrees that make it incompatible with the prps of the new format. Rather than develop multiple options for pyprp we develop drizzle to convert between them all. Pots-Moul, Moul-New Format. NewFormatA-NewformatB etc.

So in essence, PyPRP sticks with it's single format export, while Drizzle(Or a new program) converts between all various formats.

Which leads to an even more interesting idea, a multi-use tool, that encompasses them all (UruFun, PlasmaShop,PrpShop,Drizzle,Vaultshop) One tool that rules them all rather, all locked into one program you launch rather than multiple ones. You make it in similar format to PlasmaShop, where you have everything centrally located, with the ability to alter the vault, download ages, covert ages, and edit them manually all from one source before launching Uru and exploring your changes. Just a thought.

[Chacal]

Having different clients and servers is one thing, having different prp formats is an entirely different thing.
There should be a standard for the prp format, and for the communication format and protocol, and they should be used by all client/server versions.
There should be groups working on standards independently of developers.

[BAD]

Hmmm... Well if RAWA can't help us out with that than maybe someone should start a whole new thread about it, since it seems to be an important issue to discuss.

[J'Kla]

A lot of this has to remain in flux till we get the code for all we know the format for the open source shard data may not be that far from a common standard. I must concede however this has to be a case of wishful thinking on my part.

Admittedly it's been possible to port existing MO:UL ages to CC so conceivably it has to be possible for this to be a two way street. We have to wait and see for all we know to get ages into the new open source server we may need to re-engineer them via a 3DMax format it comes back to all those pesky development ideas that have to sit on the back burner till we get the tools from Cyan.

One simple question it may be worth asking RAWA might be

"Will the tools allow a Blender file and Python code to port to the open source environment via the tools they are considering for release?"

[Chacal]

The tools they are considering for release is the custom plug-in they have built for 3DSMax.
If 3DSMax can import a .blend file then it will be possible to at least load geometry and textures.