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

Discussions About CyanWorlds.com Engine Client & Plugin
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 » Sun Feb 14, 2016 2:49 pm

Ah, I see Marein, ok, I just glanced over it (I didn't before, because that's too much technical stuff for me lol) ... :D

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

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

Post by Hoikas » Sun Feb 14, 2016 10:51 pm

We figured out this is a DirtSand bug, not a client issue.
Image

DarK
Member
Posts: 49
Joined: Fri Dec 26, 2008 2:04 pm

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

Post by DarK » Wed Feb 24, 2016 9:58 pm

I'm largely parroting what's been said else where, but another voice of consent can only help.

I’d get behind building future clients from H-uru, just for the build being generally easier to deal with.

I’ve been hacking out PhysX for Bullet, and initially after several hours of attempting to do things with the CWE-OU client and not getting very far, I moved to H-uru.

I got a built client in a couple of hours, and after setting up a local DirtSand Shard, I was gleefully ripping out PhysX from the client not too long after.

The ease of getting setup came from the active development, it shows, and as the CWE-OU client is so far behind H-uru in terms of development. I think it makes sense to remove CWE-OU as the upstream and focus efforts on H-uru.

1. Mismatching developer Attitudes

a) I agree there needs to be some control, but OU seems overly committed for the actual scale of the development and with so few people involved this possibly has hindered development on this version of the client.

I think the “seat of the pants” development is helping development for H-uru, as when developers have limited time to code, they want to code.

The development process Hoikas has outlined looks good as there are only a good handful of developers involved at this time.

The +1 rule protects, but does not hinder and defacto owners can give veto on troubled commits when there is contention and reasoned discussion has taken place without a resolution being found.

It’s easy to fork/branch a stable build tree, debian style, and impose a rule to only commit to stable when a release goes out. This seems a quick and easy method to maintain stability, and a tried and tested method.

b) As new code/widgets come out with more efficient methods of doing things, we should move with those changes, especially if it frees up a developers time, provides advantages up-stream to people such as builders, and improves a player’s experience.

I think change is something people need to get used to, as maintaining legacy code for the sake of a few people is not productive development, particularly where available time is a large factor.

An example is maintaining an XP Build, if there is enough people with a need to warrant a developer’s time it will likely be a cause for concern for the main client. Otherwise anyone wanting to develop an XP client should be encouraged to fork.

Research Points

a) Testing Shards, I would consider how many we need, as fewer is better. You want to be able to have the largest amount of testers working on a single set of code to confirm suitability, with rotation of the code on test being high.

Developers do testing themselves on their local code, and with a +1 also confirming testing, this should be enough to move code to a mass testing shard and from there to release.

Personally I would say one is the max to officially run, with of course the ability for anyone else to set something up too if they wish to invest their time.

b) I would hope there will be divergences between MOUL and H-uru as this shows progress :)

There really should be no thought given to branching and moving down other routes, it should just be done, but with an aim to have it pulled to a stable build in the future.

As community builds are being used on MOUL, there is hopefully a case for consideration for the “official” MOUL client to look very different in the future, particularly if community server builds become part of the equation too.

2. MOUL server compatibility

See above 1b) – Most of this can be avoided by having the correct pull structure, and where MOUL breaking changes are occurring, don’t push them up-stream.

3. Code Removal

I don’t think this needs further discussion as getting rid of legacy code is only a good thing :)

4. Windows XP Compatibility

As a desktop specialist, I have very strong feelings on people who still use XP due to it causing me pain professionally :) so the following is very biased!

First, the OS is 14 years old and anyone who is still using it should have some form of expensive scientific instrument attached to their computer to warrant still having windows XP (I do still support some Windows 3.1 and DOS 6 systems for this reason). Please for the sake of technical people’s sanity, look at upgrading if you can!

I support expanding the client’s telemetries for OS version creeping to assist with number gathering to see if XP builds are still warranted.

On the other side of things, getting the engine as open and free as possible, to improve portability and compatibility should be a main aim.

As a stop gap, it looks as though the XP Build is something that we don’t immediately have to deal with thanks to Marein’s and Hoikas’s recent work :)

5. Mac compatibility

There are two ways to do this, wine, or a native client.

Wine is generally good when you are in a fix, but say the client starts to use something not available in wine it might stop implimentation of a feature or bug fix while wine catches up. Wine's priorities are also diffrent so we could be waiting for a long time for something to apear, if at all.

A native client has more scope as this brings in possibilities for a Linux client as well due to the similarities between the two OSes.

There is progress in H’uru to remove dependency on DirectX and replace it with an agnostic pipeline (and another reason to look at H’uru as a replacement for CWE-ou), and looking at Bullet as a replacement for PhysX should remove the need for anything windows specific.

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

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

Post by Christian Walther » Thu Feb 25, 2016 9:09 pm

Thanks for the comments! Just one note on your last point – judging from the latest report, a native non-Windows client is significantly farther away than a Wine solution, which is why I didn’t even mention it. There has in fact been recent progress on the latter front, although I haven’t been able to replicate it yet (which may have to do with being on 10.6.8, which I don’t insist on supporting).

Apart from that, unfortunately I haven’t gotten around to making any progress on the open questions myself.

Chogon
Cyantist
Posts: 7
Joined: Mon Dec 22, 2008 5:19 pm

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

Post by Chogon » Fri Feb 26, 2016 7:58 pm

Hi guys,

Sorry for the "Chogon time"

Good discussion here.
To me (not speaking for all of Cyan), now that y'all are building the client and Cyan no longer is, these kind of decisions are mostly on your side of the court. It is not quite as simple as this but pretty much all I need is a client build to start the update process. However, some decisions and/or changes will affect Cyan and that should be carefully considered.

The biggest thing that could be affected is Cyan Support (aka Cyan CS or Cyan Customer Care). After the last update from the OpenUru.org Foundry with no supposed changes, there was a lot trouble tickets and a lot of internal discussion about how to provide support for issues we (aka Cyan) don’t know about and can no longer address and resolutions are out of our hands. This can put Cyan customer service in a quandary and in a bind could decided they can no longer provide support. Hopefully it doesn't come to that and maybe there is a way to get tech help information to Cyan CS more directly. A liaison would be helpful.
Losing XP and Mac compatibility would be very troublesome and would put Cyan CS in a precarious place. I know that XP is extremely old and unsupported but those explorers that will be affected will see it as a step backwards and it is hard to justify "we care" to a customer by saying "Well, it was those guys over there that did it."

As far as the internal Customer Care client, once the building of the client became external to Cyan we knew that it would fall behind in updates. But it should be ok, as long as it can still run and connect to the server, which without server changes it should continue to do. It might mean the ResEngs will have to switch back an forth between clients. But I think they already do that.
And I think that moving to an open source MOULa server is highly unlikely unless the fans take over *all* of MOULa.

Even though I get into "Chogon time", please keep sending me email to say "hey look at this", even if I don't respond right away.

Thanks,
Mark

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

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

Post by Hoikas » Wed Jan 18, 2017 1:41 am

What's the status on this? I've been reading through some ancient history, and I uncovered a fully functional mutual ignore branch in my H-uru/Plasma fork and a series of emails from Vicki and Mark about their wanting to include this in MOULa to combat the griefer situation. I feel sort of bad about it languishing in my fork for the past 2.5 years--mind you in my defense that was right before my 1st year of teaching started. Anyway, it seems particularly relevant considering MOULa registration is closed.
Image

User avatar
rarified
Member
Posts: 786
Joined: Tue Dec 16, 2008 10:48 pm
Location: Colorado, US

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

Post by rarified » Thu Jan 19, 2017 11:26 pm

Just to let you know this discussion is not being ignored, I have not yet had time allocated to study how to build and compare H'uru in our environment.

There are still some "rebuild" and "upgrade" tasks for the Foundry build system as it has existed up to now, and creating a new build toolchain has been outside the scope of those tasks.

Nevertheless, I need to and will be working on at least replicating the build environment you use to create the H'uru client, so I can understand the moving parts. It just is too soon to set a date on completing that set of tasks.

_R

[Postscript: you brought up the ignore capability in your current client. Is that tied to other major changes we don't have in the existing OU client?]
One of the OpenUru toolsmiths... a bookbinder.

User avatar
Hoikas
Member
Posts: 284
Joined: Fri Jun 03, 2011 8:38 pm

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

Post by Hoikas » Fri Jan 20, 2017 3:34 am

rarified wrote:Just to let you know this discussion is not being ignored, I have not yet had time allocated to study how to build and compare H'uru in our environment.

There are still some "rebuild" and "upgrade" tasks for the Foundry build system as it has existed up to now, and creating a new build toolchain has been outside the scope of those tasks.

Nevertheless, I need to and will be working on at least replicating the build environment you use to create the H'uru client, so I can understand the moving parts. It just is too soon to set a date on completing that set of tasks.

_R
Understood. Let me know if there's anything I can do on that end. If you choose to use Visual C++2015, things get a little interesting when compiling Python 2.7. I plan on making available a set of VC++2015 libraries real soon(TM).
rarified wrote:[Postscript: you brought up the ignore capability in your current client. Is that tied to other major changes we don't have in the existing OU client?]
It looks like the only major functionality required is #281 for the ability to silence the linking SFX. There's some small usage of the hsRef H'uru-ism, but that's easy to pull out :)
Image

Post Reply

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

Who is online

Users browsing this forum: No registered users and 1 guest