What do you want from the developers moving forward?

[diafero]

Wow, a whole lot of great ideas and much more two years than ever in the last one or two years

What I consider very important is a working way of centrally managing resources that need to be centrally assigned: Sequence Numbers have been mentioned. Relto Pages, clothing, animations would be other examples.

Regarding format changes: I know prp is currently neither forward nor backwards compatible, but can't that be changed? MOUL has a concept of version numbers for classes, so maybe could the format be changed in a way that the original MOUL files can still be read?

And third, what are your plans for the server? I know we have MOSS working and DirtSand in early development, but wouldn't it make sense to implement a server based on CWE code? Having too many different implementations of Uru format and classes will just make things more complicated (especially format changes), and we currently have CWE, libHSPlasma (necessary for PyPRP), and MOSS.
Cyan announced to also open-source the server, right? Did they give a timeframe?

[GPNMilano]

Cyan announced to also open-source the server, right? Did they give a timeframe?

Yes. "Not Soon" i believe was the timeframe.

[Robert The Rebuilder]

Add my votes to PyPRP 2 and a standalone CWE client.

[Aloys]

I still stand by my idea that compiling the debug client would be a productive project. And hopefully it wouldn't be too time consuming to do.

[Branan]

We can build any combination of Internal/External Debug/Release we want at this point. It's just a matter of actually packaging one for general consumption. This won't happen until we're ready to start setting up a server for general public use. Anyone who can build their own server should be able to build the client for it as well

[Aloys]

How does being able to put together a server package influence the release of the client binaries? IIRC you could simply install an internal debug client on a regular release Uru/MOUL client, all that is needed is the binary itself plus the specific SP.dll and simly overwrites existing files, no other setup needed.

[Branan]

I don't want to be help responsible for any mayhem that might ensue if I release an internal build that can connect to Cyan's servers. I'd rather play it safe and hold off on releaseing a build until there's a more experimentation-friendly server available.

[Aloys]

Good point.
Although that could be fun, some people would probably disagree. (the nerve of some people.. )
I guess I could find some valid arguments to further my cause (like: it'd be easy to make sure the client can't connect anywhere; or: it's open source so anyone could compile it and connect to Cyan's servers anyway etc), but I'll let you guys sort out the priorities since you're doing the work and I'm not.

[N. Sigismund]

anyone could compile it and connect to Cyan's servers anyway etc

Which is a critical problem, I fear. I shudder to think about how much work would need to be done to server code to make it so that a lot of the hidden fun stuff that can be done with an ID build can't actually be done on normal servers. :\

EDIT: Might as well point out that I mean when we get the server code.

[Chacal]

I don't want to be help responsible for any mayhem that might ensue if I release an internal build that can connect to Cyan's servers. I'd rather play it safe and hold off on releaseing a build until there's a more experimentation-friendly server available.

I'm confused. You released an experimental MOUL client some time ago (sorry I forget the name).
To which server did you connect for testing it?