Should a future MOULa client be H-uru-based?

Discussions About CyanWorlds.com Engine Client & Plugin
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Should a future MOULa client be H-uru-based?

Post by Christian Walther »

With MOULa clients now being built by the OpenUru.org Foundry rather than by Cyan, the primary reason for the separate existence of the CWE-ou fork, maintaining compatibility with Cyan’s antiquated build environment, has fallen away (with one caveat, see bottom). As already mentioned elsewhere, I therefore think that now would be a good time to discuss whether to base future MOULa clients on the H-uru fork instead. It seems I don’t need to go into much detail anymore about the advantages of that (in short, it makes things much easier for future contributors, and it gets us a lot of accumulated contributions at once), but I can expand if requested. However, there are some challenges as well that need research and discussion, and that’s what I would like to do here. I have tried to collect everything that comes to my mind or has been mentioned earlier, along with what information I have and what questions are still open.

First off, there would still be a fork, because there are some aspects where we want MOULa to be different from H-uru/Plasma – most obviously compatibility with MOUL servers. But the hope is that it could be one that can take regular merges from H-uru/Plasma master for the foreseeable future, rather than the tedious work that is currently required to port contributions from H-uru/Plasma to CWE-ou. This will inevitably get harder over time again as H-uru/Plasma accumulates changes that are deemed unsuitable for MOULa (e.g. protocol updates or system requirements), but no more so than if we continue with CWE-ou.

Also, maybe we need to consider what the alternative would be? It seems to me that it would essentially be a stagnant MOULa in terms of engine contributions. Very few people have put in the effort to contribute to CWE-ou in recent years, and I don’t see that changing much, even with activity on processing the backlog picking up again right now.

1. Mismatching developer attitudes
Issue
a) H-uru has a bit of a “shoot first, fix later” attitude (they can afford that because the fixing can be fast too), while OU+Cyan has been moving in a more DRC-like cautious (and accordingly glacial) manner. The consequence being that what’s in the H-uru/Plasma repository at any point in time may be a bit more unstable that what we would like on MOULa.
b) H-uru is quick to take advantage of the latest and greatest and relatively unafraid of leaving behind people unable or unwilling to keep up with that, compared to other developers (specifically me) and the MOULa player community at large.
State of research / CW’s opinion
a) With another layer of testing on Minkata in between (as well as Gehn, even though it is not intended as a testing shard, and TOC) I think this should be manageable.
b) This will occasionally lead to divergences between MOULa and H-uru/Plasma, but that is still a preferable condition to the CWE-ou status quo, and working together in an atmosphere of mutual respect should minimize them. I don’t think we need to ask for compromises from the H-uru team, but willingness to advise (as commendably shown by Hoikas) would be helpful.
Open questions
Everyone willing to work together in these circumstances? If not, yell.

2. MOUL server compatibility
Issue
H-uru/Plasma has recently broken compatibility with MOUL (and compatible, such as MOSS) servers, and there could certainly be further updates to the protocol in the future. These will have to be backed out of the MOUL fork, contributing to its divergence and increasing the effort required to keep up.
State of research
The only incompatible change so far has been the removal of the game manager (source).
Open questions
Can the game manager removal be backed out without affecting future mergeability too much?
How often are further incompatible changes expected? Are any in the pipeline already?
If all else fails, can we get MOULa on an open-source server?

3. Code removal
Issue
H-uru has thrown out a lot of code that was not used in the client, Max plugin, and some tools. Ever again building a server or a full set of tools from that code base is probably out of the question. Maybe CCR client too.
State of research
This is no loss for the open-source community who can’t build these closed-source parts anyway, and Cyan seems to be fine with it (source: e-mail conversation with Mark).
Open questions


4. Windows XP compatibility
Issue
Default H-uru/Plasma builds do not run on Windows XP anymore. This is intended. It is however conjectured that there is still a sizable number of MOULa players with Windows XP that we may not want to alienate.
State of research
Visual Studio 2013 and 2015 come with an alternative XP-compatible compiler toolchain. H-uru/Plasma does not currently use any XP-incompatible APIs (source).
Open questions
Try to build an XP-compatible H-uru client.
Failing that, can we gather some numbers on how many players are still on XP? (I don’t think the client presently reports that to the server, but it does report whether it’s on Mac or Windows, so that could probably be extended.)
If it’s a significant number, can we somehow provide a “legacy client” for them?

5. Mac compatibility
Issue
H-uru/Plasma no longer runs in the Cider wrapper from MOUL. We need to provide an alternative way of playing MOULa to Mac users. (This affects me, so I’m not going to accept any compromises on this. :))
State of research
Up until version 20, the Gehn client worked excellently in Wineskin. Version 21 no longer ran in my (Ainia’s) Wineskin, but I never tried whether updating to a different version of Wine or some other tweakery fixes that. Nobody has gotten a VS-2015-built client to work in Wine(skin) yet, but we’re getting closer (source).
Open questions
Try to build a client that runs in Wineskin with Visual Studio 2015. Failing that, try with Visual Studio 2013.
If VS 2013 is the only solution, how easily can we keep the code compatible with it as long as required?
Pie-in-the-sky: Distribute a Wineskin wrapper to users using the standard game update process (same as it worked with Cider in MOUL times).

Any additions to this list? Any contributions to resolving the open questions? Any other opinions?

There is one more issue that speaks against ditching CWE-ou just yet: Cyan’s exporter producing the jerky female backward-walk and jump-landing animations. There is a proposed fix for that by Hoikas (I forgot where, possibly this: https://github.com/Hoikas/Plasma/compare/p20-v71), but it will need to be tested by someone at Cyan. This requires that the Cyan builders can build an updated Max plugin (which we have not checked yet), or possibly that the Cyan asset build can run with a community-built plugin, although I currently don’t know of anyone in the community who would be capable of building such a plugin. (I have talked to Chloe, she has the Max 7/8 SDK but not Visual Studio 2003. I believe Hoikas has Max 7/8, but IIRC is reluctant to put in the work to set up the VS 2003 environment unless he gets a guarantee that someone at Cyan is going to test the result. Paul has Max 7, but efforts to install it on the Foundry builder have stalled as far as I’m aware.) Can we do anything to get the ball rolling on this?

Possibly related is the question of how to handle community-provided modifications of Cyan content such as the KI fixes (provided Cyan wants them in MOULa). If these go to Cyan as Max files, that too requires them to still have a working export pipeline.
User avatar
rarified
Member
Posts: 1061
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

Re: Should a future MOULa client be H-uru-based?

Post by rarified »

Not ignoring this thread, just need some time to digest it in between RL. Comments in progress...
Thanks for starting this discussion, it's important!

_R
One of the OpenUru toolsmiths... a bookbinder.
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Should a future MOULa client be H-uru-based?

Post by Christian Walther »

That’s okay, considering that it took me about two weeks to get this far… :)
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: Should a future MOULa client be H-uru-based?

Post by Hoikas »

Clearly I'm in support of a MOULa built based on the H-uru client. I'll do my best to respond to some points here--feel free to direct me toward specific concerns. I'll be painting broad strokes here.
First off, there would still be a fork, because there are some aspects where we want MOULa to be different from H-uru/Plasma – most obviously compatibility with MOUL servers. But the hope is that it could be one that can take regular merges from H-uru/Plasma master for the foreseeable future, rather than the tedious work that is currently required to port contributions from H-uru/Plasma to CWE-ou.
This is perhaps the most important point. Right now, moving between H-uru and OU is impossibly difficult because of the huge delta. And it's not just changes for the sake of changes; there are real benefits to working in the H-uru codebase. For example, we have introduced a plString class that removes the need for working with C strings entirely. A ton of the old divergent and redundant char*/wchar_t* code is simply gone from H-uru. If you follow the progress of the Gehn Shard, you'll notice that it actually has its own fork of Plasma and moul-scripts based on H-uru. And yes there are some small changes.
Mismatching developer attitudes
Our process isn't well documented anywhere, so it probably seems very "seat-of-the-pants" if you're not plugged in. I think there is no secret we all stay in the #writers IRC channel on irc.guildofwriters.org 24/7, so a lot of communication happens there. As with the rest of the community, we are very strapped for time, manpower, and interest. Our general rule of thumb for pull requests is that we need to get two thumbs up for any one pull request, of course, the thumbs up of someone like Zrax carries a bit more weight than the thumbs up of Bozo the Clown, so that rule isn't exactly the end-all-be-all. Also, because we're low on manpower, I often step up into what Paradox has referred to as "defacto owner(ship)" and do a lot of the vetting myself, especially when interest seems very low. This is another exception to the thumbs-up rule. Sometimes I miss things, but you are correct in noting that the fixing is fast. That tends to happen when someone shows interest in your code. Any time I or someone else can start something small happening in the code, other folks throw in a few things as well :) Naturally, all of this gets discussed in IRC at some point.

We also do discuss upgrading requirements quite a bit. The minimum required compiler is still VC++2013 (4 years old), and I believe gcc 4.6 compiles the linux-compatible projects (debian testing is currently on gcc-5.0). We stayed with VC++2010 for quite awhile before bumping the requirement. Once you go C++11, you can't go back. ;)
2. MOUL server compatibility [...]
Can the game manager removal be backed out without affecting future mergeability too much?
How often are further incompatible changes expected?
Are any in the pipeline already?
If all else fails, can we get MOULa on an open-source server
1) For now, I forsee no issues. But, keep in mind, we'll be building upon a codebase with no game manager from henceforth. Removed code is always a pain.
2) We don't make incompatible changes lightly. Even now, you can take the H-uru client onto MOULa and use it for something like the AGM. You shouldn't try actually playing the game in a multiplayer situation though.
3) That would be nice. As I've said before, I believe MOSS and DirtSand are both inappropriate for this goal. MOSS is too inflexible and DirtSand will likely not scale up well enough. We've not expended much effort onto writing a new server to address the scaling issues of DS because DS has done its job well, especially after we applied some bandages to the obvious problems. If there is interest in a scalable server, I have actually designed one, it's just not coded yet.
There is one more issue that speaks against ditching CWE-ou just yet: Cyan’s exporter producing the jerky female backward-walk and jump-landing animations.
With the recent client-code-only fix that makes all but two of the game's animations smooth again, I am less inclined to blame the exporter. Rather, I think there might be a problem with the max files themselves for these animations. This is not a totally unprecedented situation. There have been several max data issues introduced from PotS to MOUL, such as broken lighting in Ahnonay. Also, the Great Zero activation sequence was broken (I had to rewrite the responders by hand for our upcoming Gehn GZ activation). I would rather get ahold of those max files for a closer look before we revisit the changed exporter code.
Image
User avatar
Mac_Fife
Member
Posts: 1239
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Should a future MOULa client be H-uru-based?

Post by Mac_Fife »

There is another aspect that I'm inclined to raise, more as a note of caution than anything: I could summarise it as "we don't know what we don't know". There may be tools that Cyan re-builds and uses internally that re-use parts of the client code, perhaps "Customer Care" tools or the like, so there could be adverse knock-on effects on those that maybe give Cyan more work to do rather than less work. Maybe there's no issue at all, I'm just suggesting that we need to be sure that Cyan is on-board with whatever gets proposed and has a chance, if necessary, to evaluate the implications for them.
Mac_Fife
OpenUru.org wiki wrangler
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Should a future MOULa client be H-uru-based?

Post by Christian Walther »

Thanks for the details, Hoikas!
Hoikas wrote:Clearly I'm in support of a MOULa built based on the H-uru client.
I’m glad you are, even though it reduces the competitive advantage of Gehn. :)
Hoikas wrote:I would rather get ahold of those max files for a closer look before we revisit the changed exporter code.
That sounds like something worth doing, if you can. Would you be able to fix them as well? I wonder if Cyan would be willing to agree to that under an appropriate FCAL.
Mac_Fife wrote:There may be tools that Cyan re-builds and uses internally that re-use parts of the client code, perhaps "Customer Care" tools or the like, so there could be adverse knock-on effects on those that maybe give Cyan more work to do rather than less work. Maybe there's no issue at all, I'm just suggesting that we need to be sure that Cyan is on-board with whatever gets proposed and has a chance, if necessary, to evaluate the implications for them.
Agreed, I think that falls under what I meant with point 3. Of course we need Cyan’s final approval after we figure out things for ourselves. In that regard it’s not “no open questions”.
User avatar
Hoikas
Member
Posts: 344
Joined: Fri Jun 03, 2011 8:38 pm

Re: Should a future MOULa client be H-uru-based?

Post by Hoikas »

Between Deledrius and myself, most things can be fixed ;)
Image
Marein
Member
Posts: 5
Joined: Sat Feb 13, 2016 9:28 pm

Re: Should a future MOULa client be H-uru-based?

Post by Marein »

I've been trying to get GehnShard/Plasma to work on Windows XP but with no luck so far. I'm trying this inside a VM because I couldn't get XP installed on my machine. MOUL is running just fine in the VM, but Gehn (compiled for XP in VS 2013) is stuck at the launcher. This is after installing the C++ 2013 runtime.

Image

Specifically, if I run plUruLauncher, it keeps on "Connecting..." for a while before the loading bar freezes and the program becomes unresponsive. Killing the program yields an error report containing these files. Clicking 'Cancel' before the program freezes shuts down the launcher.

Image

If I run plClient, the login window appears. Shortly after this, a large black square appears and disappears towards the top left of the screen, in a split second. This seems a bit like the game window starting and closing immediately. Upon clicking the login button, the login window freezes (regardless of whether the login info is correct). Killing the program produces these files, in addition to a 70mb file called plClient.exe.hdmp. The 'Quit' button works.

As can be seen in the screenshots, there is an error in the launcher about SSL certificates, but I read that this is apparently not related.

I wasn't able to gain any more insight into why it's not working, but maybe someone else can use this information.

edit: I just realized that Gehn is offline, so I'll try this again when it's up.
User avatar
janaba
Member
Posts: 197
Joined: Tue Jan 10, 2012 4:48 pm
Location: Berlin, Germany

Re: Should a future MOULa client be H-uru-based?

Post by janaba »

Marein wrote:I've been trying to get GehnShard/Plasma to work on Windows XP but with no luck so far. I'm trying this inside a VM because I couldn't get XP installed on my machine. MOUL is running just fine in the VM, but Gehn (compiled for XP in VS 2013) is stuck at the launcher. This is after installing the C++ 2013 runtime.
Hello, Marein, I might be wrong, because I don't know if this applies to everything XP, but maybe it has to do with this (intention to completely drop Win XP support), and here's Deledrius saying it's done ... :)
Marein
Member
Posts: 5
Joined: Sat Feb 13, 2016 9:28 pm

Re: Should a future MOULa client be H-uru-based?

Post by Marein »

janaba wrote:Hello, Marein, I might be wrong, because I don't know if this applies to everything XP, but maybe it has to do with this (intention to completely drop Win XP support), and here's Deledrius saying it's done ... :)
Hey janaba, thanks for the links. I'm aware of the situation - I'm trying to get Gehn working on XP in response to the original post in this thread :) (issue 4: Windows XP compatibility)
Post Reply

Return to “CyanWorlds.com Engine - Client & Plugin”