Fomenting Mutiny

[Legacy_Zarathustra217]

               I'm really excited that something like this finally seems to be happening. The mutiny is not now but was back then, and it's high time the community takes back what rightfully belongs to us all.

Using the CEP already on our PW, I'm of course hoping for full backward compatibility, but I'm sure that no matter what we'll figure it out somehow. What's best for the overall community should hold priority.

In that regard, I think Bannor Bloodfist has an excellent point in keeping it simple - if there's one thing we already have plenty of, it's projects that never got materialised. But I want to add to this call to simplicity by emphasizing that this should also cover making it simple for the entire community to contribute. Not by very long-winded discussions, but with all the small things we each are able to all do. I remember that one of our team members once send in some fixes she had made to certain CEP carpet models, and she was told that no one else outside the team had ever done that before. It's too easy to assume that that meant people weren't interested in helping, but to me, it is much more likely a witness that the way the old CEP team worked didn't do a very good job in getting people to help.

I wonder if we could perhaps set up some form of content repository that certain central community members moderated? In that way, we could make it easier for all to get into the process when we find a spare moment to contribute. I know I've already done a good handful of tiny fixes here and there to CEP content that I'd love to share - but you become hesitant when you don't know what is already being worked on within the CEP and what has already been fixed.
               
               

               
            

[Legacy_henesua]

               that sounds like a great idea, zarathustra.
               
               

               
            

[Legacy_Pstemarie]

               More I think about this, the more CEP might be better off mirroring the way the CC Challenges operate, sans the monthly theme of course. I'll second Zarathustra's idea about a repository where people can submit fixes, new content, etc. If you can implement a system like CVS, anyone coming in will know what's being worked on and by whom.
               
               

               
            

[Legacy_meaglyn]

               

Pstemarie wrote...

More I think about this, the more CEP might be better off mirroring the way the CC Challenges operate, sans the monthly theme of course. I'll second Zarathustra's idea about a repository where people can submit fixes, new content, etc. If you can implement a system like CVS, anyone coming in will know what's being worked on and by whom.

CVS would be a mistake I think. Git or mercurial are probably the best bets for this kind of distributed development.
Some people like SVN, but it's not really that good at distrbuted development either. Git would be my choice...
               
               

               
            

[Legacy_henesua]

               Git or Mercurial sound good to me. Who can set it up?
               
               

               
            

[Legacy_Tarot Redhand]

               For anyone interested here is a link to what I think is a reasonably balanced article on the merits and otherwise of various version control systems. From what I can see from that article, I think there is possibly a fundemental problem for using either git or mercurial for maintaining the CEP and that is there is no central repository with these systems. I personally would lean towards a subversion system myself such as tortoiseSVN.

TR 
               
               

               
            

[Legacy_Zarathustra217]

               To avoid us ending in the same situation as the old CEP team, I also think it's important that we set up some clear standards of how the democratic process should work before moving too far. To maximize the sense of community, I'd really recommend focusing on doing the things that has the broadest consensus possible, and which satisfies the most general needs. But a large part of that can be achieved if we already by now settle on being as versatile as possible. Nothing good will come out of disputing over how the ideal CEP works and what it represents. It should represent the community in it's diversity.

I like the modular approach that AD proposed in terms of adding new stuff. It wouldn't be hard to write a simple program that allowed for compiling 2das based on what haks you then decide to use.

And I don't think it would be much work to offer this new CEP3 (or whatever we call it) in a version that's both fully backward compatible (legacy) as well as a version that only contains whatever new stuff we decide to add. We could also offer haks in versions that directly overrides existing content, both Bioware and CEP, since that seems to have become a popular choice.

Concerning the existing CEP packages, one could easily argue that any fixes we make to the CEP2 should also be a hak of it's own that sits on top of them, since that assures that we don't run into a situation where the old CEP team starts to complain over ruffled feathers. On the other hand, if we simply update the CEP packages, we can in that way assure that existing modules (many whose authors are no longer around) can still benefit from whatever fixes we do. I actually think that's a really appealing argument considering the massive amount of high quality modules already available, which aren't likely to be updated.

But here, we also need to establish some broad consensuses on what constitute a "fix" and what is an "addon". Principally, I think the best solution is (for much the same reason) to distinct fixes from addons, so that fixes are exclusively things that would not require the module-maker to do any form of modification to their current module. A fix could in this way entail correcting stretched textures or even increasing or otherwise refining model detail - but it's essential that the confines of the model should remain the same so that any existing area setup wouldn't be impaired by it. Then, we could incorporate the fixes directly into the existing haks, and in that way make them not only backward compatible, but even backward improving.

Anyway, that's my 2 cents here.
               
               

               

                     Modifié par Zarathustra217, 22 janvier 2014 - 12:20 .
                     
                  

            

[Legacy_Tarot Redhand]

                Going back to the version control aspect. When it comes to texture images then we are into a different type of version control that would seem to require what is called Digital Asset Management. While it is true that subversion can store binary files, it would seem (from what I can discover elsewhere on the web) that something like Resource is necessary in order to be able to track changes to images.

TR
               
               

               
            

[Legacy_meaglyn]

               

Tarot Redhand wrote...

For anyone interested here is a link to what I think is a reasonably balanced article on the merits and otherwise of various version control systems. From what I can see from that article, I think there is possibly a fundemental problem for using either git or mercurial for maintaining the CEP and that is there is no central repository with these systems. I personally would lean towards a subversion system myself such as tortoiseSVN.

TR 

A central repository is not ideal. That's part of the point if a distributed VCS. What happens when that central repository goes away?

You'd still have an official master with git wihout having to have a single central repository.  But everyone who clones it has a full copy of repositiory(ies)  and tools as needed.  Then have an incoming branch which allows people to push changes to it.    A central team would then have rights to merge parts as needed from the incoming branch to the master.  That would in effect be the central repo, but is easily replaced when needed.  Plus you can share changes with each other without having to commit them to the official tree first.
               
               

               
            

[Legacy_Tarot Redhand]

               @meaglyn Doesn't the sharing with friends without committing to the official tree lead to possible multiple versions when only one was supposed to be produced?

TR
               
               

               
            

[Legacy_meaglyn]

               From that "reasonably balanced article":

"As there is no centralized server, Git does not lend itself to single developer projects or small teams as the code may not necessarily be available when using a non-repository computer".

This sentence is completely bogus.

The same can be said for any VCS (distributed or otherwise). If the code is not on your computer and you cannot reach a repository then the code is not available. The difference with a DVCS is that once you have the code you can make commits locally and move on to the next changes
(check out whole new trees, make branches and tags and so on too). Then you sync up, pull changes from the master, push your changes as needed when you are back in contact.  Every system that checks out the code _is_ a repository. So you also don't need to reach the "central" repo to get a copy, you just need to reach some repo.

But that's probably enough of that, don't want to turn this into a debate about version control. I just did not want to let that FUD sway opinions.
               
               

               
            

[Legacy_leo_x]

               Tarot raises a good point, I think.  It is worth keeping in mind that binary files are not going to merge, I'm not sure how much of cep resources that might include -- edit: even decompiled mdls might not be mergable -- , so if you use a DVCS like git or mercurial and have multiple people working on the same binary files at the same time, someone is going to have a bad time.

This is why most game studios seem to use Perforce for binary stuff, it lets you lock assets (so only one person can check them out at a time), among other things.
               
               

               

                     Modifié par pope_leo, 22 janvier 2014 - 03:40 .
                     
                  

            

[Legacy_meaglyn]

               

Tarot Redhand wrote...

@meaglyn Doesn't the sharing with friends without committing to the official tree lead to possible multiple versions when only one was supposed to be produced?
TR

No. I meant more for testing and shared development. Or experimental changes.  You can do all that with the others too but you'd end up checking them in (probably to a dev branch) to the central repo.  Eventually any changes that
wanted to be in CEP would need to find their way to the official release repo.

Every one who clones the repo has a fully functional repo. But we'd still want an official master with some gatekeepers for the actual releases. No one would be releasing official CEP HAKs from his/her personal
repo.
               
               

               
            

[Legacy_Zarathustra217]

               I think it's relatively rare that multiple people would be working on the same binary file at a time. Except for images, there's no reason to compile the files before leaving the repository and being published.

Ideally, people wouldn't even be working at the same time ASCII files either. Perforce sounds interesting in that regard, though again, I really encourage that we keep it as simple as possible for people to work with. And NWN resources are easy to work with in most repositories as more or less anything is separated into each own file, making it exceptionally rare that two people would be working on the same file at once.

The exception would of be things like 2da and set files, but we could set up special things for that, like a forum topic or wiki entrance for each where people proposed changes and a moderator would then incorporate it into the file.
               
               

               
            

[Legacy_henesua]

               I have wondered about how tracking changes in a decompiled mdl works as well. I figured that since they are text they'd work fine.