Onward: OpenUru Repository Reorganization
Re: Onward: OpenUru Repository Reorganization
We have a lot of minor improvements in the H-uru fork that make playing the game a much more enjoyable experience. It would be very nice if there were a path to get some of these back to Cyan.
Re: Onward: OpenUru Repository Reorganization
Thanks for the reminder, semperfi, but finding the time to answer has been on my mind. A bump was foremost on my mind, though yours seems to have worked, eh?
"The path to MOULa," as I like to call it, or the path to Cyan is more clear now since we've followed some suggestions/requests from Adam and Branan. Basically, if Bitbucket is easier for you than Foundry, clone to Bitbucket, make your changes, and send a pull request. A fundamental problem right now is the utter lack of mutually trusted reviewers and gatekeepers. We need a bigger community. We need to attract more new people and kindly help them along to eventual positions of merit, trust and responsibility. We had a willing, temporary reviewer and gatekeeper with a long, long history of trust and competence, but now we don't. Progress halted and the path was broken at that time. Having just one person in such a position is not a good way to do things anyway, and I had no wish for such a dependency or to put pressure on it. It just exposes the greater need to solve such a fundamentally important problem and I'd rather wait for naturally attracted people than continue to ask for favors. It cannot be sustained that way. But it would be helpful when we do find someone else, if we were to treat them well so work can proceed.
Until then, rarified and I can commit changes to CWE-ou if we have a reasonable consensus from a collection of people we trust that a changeset is okay. From there, it would be up to Mark (Cyan) to decide whether to use it and commit it to MOULa. Once on MOULa, he or I, with his okay, would commit it back to the CWE, the Cyan-compatible main trunk. Even then, there's the question of how to get GPL code into MOULa without requiring Cyan to publish their internal code. That's a dilemma. It's hard enough for any of us to make time in these days of economic hardships. I can't see Mark/Cyan making precedent to take on a program of private and individual code submissions from a multitude of developers wanting to circumvent that problem any time in even the long-term future.
So that's the path: Clone CWE-ou or MOULSCRIPT-ou from Foundry or Bitbucket --> do work and send pull request --> we see or are informed of successful reviewing and testing --> we commit and push, then we or the developer informs Cyan --> Cyan likes and implements it on MOULa --> Cyan pushes to the CWE repo on Foundry to complete the cycle.
The rock is hard.
My next step, which, yes, I have not gotten to yet but am still trying to get to soon if not this week, is to work on suggesting a licensing solution to Cyan to get us all past binary distribution, plus some form of content licensing. Don't expect significant change, but just enough - it will still be GPLv3 for the code, and maybe a Creative Commons license for the content. The criticisms about releasing the avatar content without licensing were really unnecessary. We were fully aware it would be a problem and that folks would still be frustrated. But it's all we could handle at the time. It's certainly not useless because folks can still privately learn and practice on the content, and maybe release such things as tutorials, to ramp up and prepare for when it is licensed. Just like open source, If we had waited for everything to be done perfectly up front, it wouldn't have happened at all because it would then be that much harder, if not impossible due to intervening events, down the road. We and Cyan are just taking one step at a time whenever we possibly can manage it. As I said, our next step is trying to do something about the licensing. But I hope you'll understand that just using the time to write this post has used up at least a day or three of time I can allocate to anything.
In the meantime, rarified would like to get an informal okay from GoW leadership to clone the h'uru repo onto Foundry and set up an analysis on Hudson (Jenkins) to find the true extent of actual changes. Despite the more recent fix of the h'uru fork incompatibility, two primary problems remain: wholesale whitespace and structure changes. Rarified says he'd like to "do the comparison to the current OU repo, and give an LOE (Level of Effort) on teasing out the improvements sans structural changes." We're not sure when it will be done or how long it will take, but one step at a time, right?
"The path to MOULa," as I like to call it, or the path to Cyan is more clear now since we've followed some suggestions/requests from Adam and Branan. Basically, if Bitbucket is easier for you than Foundry, clone to Bitbucket, make your changes, and send a pull request. A fundamental problem right now is the utter lack of mutually trusted reviewers and gatekeepers. We need a bigger community. We need to attract more new people and kindly help them along to eventual positions of merit, trust and responsibility. We had a willing, temporary reviewer and gatekeeper with a long, long history of trust and competence, but now we don't. Progress halted and the path was broken at that time. Having just one person in such a position is not a good way to do things anyway, and I had no wish for such a dependency or to put pressure on it. It just exposes the greater need to solve such a fundamentally important problem and I'd rather wait for naturally attracted people than continue to ask for favors. It cannot be sustained that way. But it would be helpful when we do find someone else, if we were to treat them well so work can proceed.
Until then, rarified and I can commit changes to CWE-ou if we have a reasonable consensus from a collection of people we trust that a changeset is okay. From there, it would be up to Mark (Cyan) to decide whether to use it and commit it to MOULa. Once on MOULa, he or I, with his okay, would commit it back to the CWE, the Cyan-compatible main trunk. Even then, there's the question of how to get GPL code into MOULa without requiring Cyan to publish their internal code. That's a dilemma. It's hard enough for any of us to make time in these days of economic hardships. I can't see Mark/Cyan making precedent to take on a program of private and individual code submissions from a multitude of developers wanting to circumvent that problem any time in even the long-term future.
So that's the path: Clone CWE-ou or MOULSCRIPT-ou from Foundry or Bitbucket --> do work and send pull request --> we see or are informed of successful reviewing and testing --> we commit and push, then we or the developer informs Cyan --> Cyan likes and implements it on MOULa --> Cyan pushes to the CWE repo on Foundry to complete the cycle.
The rock is hard.
My next step, which, yes, I have not gotten to yet but am still trying to get to soon if not this week, is to work on suggesting a licensing solution to Cyan to get us all past binary distribution, plus some form of content licensing. Don't expect significant change, but just enough - it will still be GPLv3 for the code, and maybe a Creative Commons license for the content. The criticisms about releasing the avatar content without licensing were really unnecessary. We were fully aware it would be a problem and that folks would still be frustrated. But it's all we could handle at the time. It's certainly not useless because folks can still privately learn and practice on the content, and maybe release such things as tutorials, to ramp up and prepare for when it is licensed. Just like open source, If we had waited for everything to be done perfectly up front, it wouldn't have happened at all because it would then be that much harder, if not impossible due to intervening events, down the road. We and Cyan are just taking one step at a time whenever we possibly can manage it. As I said, our next step is trying to do something about the licensing. But I hope you'll understand that just using the time to write this post has used up at least a day or three of time I can allocate to anything.
In the meantime, rarified would like to get an informal okay from GoW leadership to clone the h'uru repo onto Foundry and set up an analysis on Hudson (Jenkins) to find the true extent of actual changes. Despite the more recent fix of the h'uru fork incompatibility, two primary problems remain: wholesale whitespace and structure changes. Rarified says he'd like to "do the comparison to the current OU repo, and give an LOE (Level of Effort) on teasing out the improvements sans structural changes." We're not sure when it will be done or how long it will take, but one step at a time, right?
Perfect speed is being there.
Re: Onward: OpenUru Repository Reorganization
HI Guys
With a restructuring in the works here is a couple of ideas and solutions to add to the mix.
Flavours
The code variants of the CWE engine have proven to be counter productive in some ways. With the number of branches, tools and compilers and the lack of version numbers it can get very confusing, so I support the idea of official version numbers and separate versions of CWE instead of branches. The main reason is that there is a cross spectrum of developers with varying skills who might not want to delve into code contributions but do want to easily download, compile and test the code. This is where Jira, Fisheye, Mercurial and Github can play havoc. What about Sourceforge or similar for the release builds. That way the developers can go crazy on doing what they do best with their preferred versioning tools, and when you have a release for the fans who don't want to spend hours trying to puzzle the pieces together, you could drop a release on Sourceforge for easy uncomplicated downloading.
This raises the issue of the user friendliness of mercurial, which is generally quite sane compared to github, but github does make up for it with tarball downloads. Some folk just want a download, and don't want all the extra software to manage a project.
GoW White Space Cleanup
As to point 6, the solution has already been provided. This last month I have been doing a GoW CWE white space cleanup. I recently finished the white space correction to the client code base and have compiled and tested a working version running on dirtsand. This was a line by line comparison of the original MOUL code on OpenUru using Winmerge. Path correction has not yet been done to the GoW code base.
Here is the link to the cleaned code: http://dl.dropbox.com/u/23390003/GoW%20 ... espace.zip
(cmake files are intact and should compile nicely on VS2008)
This gives the fans a look under the hood of the GoW changes and allows them to use the best of the GoW code snippets but to also keep compatability with the Cyan engine and any other versions of the engine that spring up.
I can accept that this section of the forum is aimed at developers, but it makes sense to aim for user friendliness for the sake of the folk with two feet stradling the fence, aka "the builder who is a developer but mostly a builder" or the shard owner like myself. At the end of the day I think there needs to be a bridge between what the developers are doing versus the most important changes needed to the engine versus the realistic needs of the writers and builders. I think its worthwhile for the developer to keep in mind the end user, or more accurately the various types of end users:
* Player
* Writer/Builder
* Shard Owner
* Developer
Your roadmap is a vital contribution to bringing about the changes that will make CWE a truly awesome engine. This is where the roadmap comes into its own;
Some Suggestions for Roadmap (in no specific order)
* Fix the broken sound issue
* Fix the screen freeze issue (Ryzom handles this very cleverly by stopping the player in his tracks but he can still look around inside a scene.)
* Fix the lag and rubber banding with a better positioning system. (the server handles this already by forwarding and dropping data packets from the client) I had a lengthy discussion with Zrax and others some time ago, and I proposed "bending" the code so that the client sends it positioning data to the server, and the server then tracks only the bare essential positioning data and broadcasts to the clients. Zrax mentioned that it was indeed possible and since dirtsand needed a timer function, this feature could be incorporated into the timer function. With server in control of positioning, someone else mentioned that it would also prevent flymode that causes such havoc on the server.
Packaging
The other area that may need some clarity is how you intend to package the CWE engine. Some folk just want to play, but others want to run their own shards. A while ago I proposed a devpack that you could download according to your needs with all the tools and goodies the fan would need to get the job done. This is where licensing issues do arise, but even a comprehensive list of links on one page to every thing needed would solve the numerous searches needed to find the goods.
However if you had to look at the number of devpacks and dedicated wikis you would need, you would be looking at the following examples:
Pack 1: New players simply want to download and play. No configuration hassles. Probably CWE based.
Devpack 2: New age writers and builders would start with the TPOTS/ABM Devpack: ABM/TPOTS, Drizzle, Blender, URU Tools, etc (No programming needed) A newbies path to learning how to build ages in preparation for their jump to CWE compatible ages.
Devpack 3: More seasoned age writers and builders might focus on a CWE build: CWE precompiled, 3dsmax, Tiny Sandbox Shard to help them test their creations.
Devpack 4: Shard Owners would want to build their own client and server so they are able to make changes to the clients resources for the sake of branding (icons and images) and might need: CWE, VS2008 and dependancies, 3dsmax/Blender, Dual-Mode Sandbox.
As a result the developers would have to create the various end products to make all this tie together in an uncomplicated way. When a new user comes to OpenUru for the first time, how is he guided to choosing the right solution for this need? Would he be able to find the link easily if all he wanted to do was download and play? Would he be guided to a writer and builder section with one click if that tickled his fancy? Would he be able to follow a link to the resources needed to teach him how to host his own shard? And would he be able to find that link to the developers section?
With a restructuring in the works here is a couple of ideas and solutions to add to the mix.
Flavours
The code variants of the CWE engine have proven to be counter productive in some ways. With the number of branches, tools and compilers and the lack of version numbers it can get very confusing, so I support the idea of official version numbers and separate versions of CWE instead of branches. The main reason is that there is a cross spectrum of developers with varying skills who might not want to delve into code contributions but do want to easily download, compile and test the code. This is where Jira, Fisheye, Mercurial and Github can play havoc. What about Sourceforge or similar for the release builds. That way the developers can go crazy on doing what they do best with their preferred versioning tools, and when you have a release for the fans who don't want to spend hours trying to puzzle the pieces together, you could drop a release on Sourceforge for easy uncomplicated downloading.
This raises the issue of the user friendliness of mercurial, which is generally quite sane compared to github, but github does make up for it with tarball downloads. Some folk just want a download, and don't want all the extra software to manage a project.
GoW White Space Cleanup
As to point 6, the solution has already been provided. This last month I have been doing a GoW CWE white space cleanup. I recently finished the white space correction to the client code base and have compiled and tested a working version running on dirtsand. This was a line by line comparison of the original MOUL code on OpenUru using Winmerge. Path correction has not yet been done to the GoW code base.
Here is the link to the cleaned code: http://dl.dropbox.com/u/23390003/GoW%20 ... espace.zip
(cmake files are intact and should compile nicely on VS2008)
This gives the fans a look under the hood of the GoW changes and allows them to use the best of the GoW code snippets but to also keep compatability with the Cyan engine and any other versions of the engine that spring up.
I can accept that this section of the forum is aimed at developers, but it makes sense to aim for user friendliness for the sake of the folk with two feet stradling the fence, aka "the builder who is a developer but mostly a builder" or the shard owner like myself. At the end of the day I think there needs to be a bridge between what the developers are doing versus the most important changes needed to the engine versus the realistic needs of the writers and builders. I think its worthwhile for the developer to keep in mind the end user, or more accurately the various types of end users:
* Player
* Writer/Builder
* Shard Owner
* Developer
Your roadmap is a vital contribution to bringing about the changes that will make CWE a truly awesome engine. This is where the roadmap comes into its own;
Some Suggestions for Roadmap (in no specific order)
* Fix the broken sound issue
* Fix the screen freeze issue (Ryzom handles this very cleverly by stopping the player in his tracks but he can still look around inside a scene.)
* Fix the lag and rubber banding with a better positioning system. (the server handles this already by forwarding and dropping data packets from the client) I had a lengthy discussion with Zrax and others some time ago, and I proposed "bending" the code so that the client sends it positioning data to the server, and the server then tracks only the bare essential positioning data and broadcasts to the clients. Zrax mentioned that it was indeed possible and since dirtsand needed a timer function, this feature could be incorporated into the timer function. With server in control of positioning, someone else mentioned that it would also prevent flymode that causes such havoc on the server.
Packaging
The other area that may need some clarity is how you intend to package the CWE engine. Some folk just want to play, but others want to run their own shards. A while ago I proposed a devpack that you could download according to your needs with all the tools and goodies the fan would need to get the job done. This is where licensing issues do arise, but even a comprehensive list of links on one page to every thing needed would solve the numerous searches needed to find the goods.
However if you had to look at the number of devpacks and dedicated wikis you would need, you would be looking at the following examples:
Pack 1: New players simply want to download and play. No configuration hassles. Probably CWE based.
Devpack 2: New age writers and builders would start with the TPOTS/ABM Devpack: ABM/TPOTS, Drizzle, Blender, URU Tools, etc (No programming needed) A newbies path to learning how to build ages in preparation for their jump to CWE compatible ages.
Devpack 3: More seasoned age writers and builders might focus on a CWE build: CWE precompiled, 3dsmax, Tiny Sandbox Shard to help them test their creations.
Devpack 4: Shard Owners would want to build their own client and server so they are able to make changes to the clients resources for the sake of branding (icons and images) and might need: CWE, VS2008 and dependancies, 3dsmax/Blender, Dual-Mode Sandbox.
As a result the developers would have to create the various end products to make all this tie together in an uncomplicated way. When a new user comes to OpenUru for the first time, how is he guided to choosing the right solution for this need? Would he be able to find the link easily if all he wanted to do was download and play? Would he be guided to a writer and builder section with one click if that tickled his fancy? Would he be able to follow a link to the resources needed to teach him how to host his own shard? And would he be able to find that link to the developers section?
-
Christian Walther
- Member
- Posts: 317
- Joined: Sat Dec 13, 2008 10:54 am
Re: Onward: OpenUru Repository Reorganization
Bitbucket has tarball downloads too. Look for “get source” at the top right of the Overview tab on https://bitbucket.org/OpenUru_org/cwe-ou/overview. (GitHub is teh awesome and beats Bitbucket and everyone else in many ways, but I think this is not one of them.)Phoenix wrote:github does make up for it with tarball downloads. Some folk just want a download, and don't want all the extra software to manage a project.
-
Christian Walther
- Member
- Posts: 317
- Joined: Sat Dec 13, 2008 10:54 am
Re: Onward: OpenUru Repository Reorganization
It appears that the Foundry repository moves have now been completed. Nice!
There was one commit in the decommissioned MOULSCRIPT-dev that I don’t see anywhere anymore in the new structure:
Fix for loading and saving column files by D'Lanor, 2011-06-29 00:44 (probably +0200)
(fix for MOULSCRIPT-2). Probably rightly so, but I hope it hasn’t disappeared entirely?
I suppose the correct place for this would now be either in a fork of MOULSCRIPT-ou on Bitbucket or in a patch submitted somewhere (JIRA?). I hope you're working with D'Lanor on this and either of you still has a copy around somewhere (I don’t).
There was one commit in the decommissioned MOULSCRIPT-dev that I don’t see anywhere anymore in the new structure:
Fix for loading and saving column files by D'Lanor, 2011-06-29 00:44 (probably +0200)
(fix for MOULSCRIPT-2). Probably rightly so, but I hope it hasn’t disappeared entirely?
I suppose the correct place for this would now be either in a fork of MOULSCRIPT-ou on Bitbucket or in a patch submitted somewhere (JIRA?). I hope you're working with D'Lanor on this and either of you still has a copy around somewhere (I don’t).
Re: Onward: OpenUru Repository Reorganization
I still have a copy. However Branan intended to write a better alternative, but if he did it has not appeared in the H-uru / moul-scripts master branch at GitHub yet.
Re: Onward: OpenUru Repository Reorganization
Ah, you discovered my cobwebs 
Yes, I have the -dev change, I need to extract it as a patch and apply it. I deferred that when the JIRA upgrade went south, so it still is on the list for today. Should have amended the post, but was a little tired after wrestling for 6 hours.
_R
Yes, I have the -dev change, I need to extract it as a patch and apply it. I deferred that when the JIRA upgrade went south, so it still is on the list for today. Should have amended the post, but was a little tired after wrestling for 6 hours.
_R
One of the OpenUru toolsmiths... a bookbinder.
Re: Onward: OpenUru Repository Reorganization
I believe there's still one remaining issue with pulling changes back and forth between the repositories. We can pull changes from bitbucket into github with no problems, but I don't think a path exists to pull changes from github back to bitbucket. I will double check with CWalther if this is the case, but my understanding is that you would also need to apply the same changes we made so that both repositories are compatible.JWPlatt wrote:In the meantime, rarified would like to get an informal okay from GoW leadership to clone the h'uru repo onto Foundry and set up an analysis on Hudson (Jenkins) to find the true extent of actual changes. Despite the more recent fix of the h'uru fork incompatibility, two primary problems remain: wholesale whitespace and structure changes. Rarified says he'd like to "do the comparison to the current OU repo, and give an LOE (Level of Effort) on teasing out the improvements sans structural changes." We're not sure when it will be done or how long it will take, but one step at a time, right?
In terms of structural changes, the bad news is that they are probably going to keep happening. Branan has started to look at replacing PhysX with Bullet, and at some point we're going to need to rip out and replace all of the network code with something that isn't Win32-dependent. We've also been removing old unused code files from the repository, and removing modules that aren't used by the client. Obviously those removals can't be merged back to Cyan, since it's quite likely that the server code depends on those modules. At this point our focus is on a working cross-platform client, with DirtSand or MOSS as a server; rather than waiting to see whether Cyan will be able to release their (Windows-only) server code at some point in the future.
That said, I'd be interested in seeing what sort of analysis Jenkins provides. I don't think there would be any problems with cloning into Foundry as long as there's some sort of appropriate link back to the source on github.
Re: Onward: OpenUru Repository Reorganization
I don't think he's written it--he's got his hands full with plBullet and plGLPipeline, so that comparatively trivial fix probably just slipped his mind. I'll take a look at it now--I certainly understand the value of having features like this work. Besides, I really don't want to read my Genetics book right nowD'Lanor wrote:I still have a copy. However Branan intended to write a better alternative, but if he did it has not appeared in the H-uru / moul-scripts master branch at GitHub yet.
EDIT: And pushed. I have no idea what your fix looked like, D'Lanor, but it probably wasn't much different from what I came up with. It wasn't overly difficult.