Should a future MOULa client be H-uru-based?
Posted: Sun Jan 17, 2016 7:57 pm
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.
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.