423 réponses à ce sujet

[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.

[henesua]

that sounds like a great idea, zarathustra.

[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.

[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...

[henesua]

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

[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 

[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 .

[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

[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.

[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

[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.

[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 .

[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.

[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.

[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.

[meaglyn]

pope_leo wrote...

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.

He does, and I'm not trying to dismiss them out of hand. I jus think that using a centralized version control system
for this nascent distributed development effort does not make sense.

Binaries are an issue anywhere.  I suspect these game studios are mostly local or VPN accessible
and have an IT staff to make sure everyone can always reach the repo.  you'd also have to deal with
people who lock things and never unlock them. 

Text files also fail to merge at times. And someone has to fix that too.

In these cases the onus should be on the people who both editted the file, not the gatekeepers. git complains if you try to push and there is a conflict.  You then have to  pull changes down and merge locally before pushing to the incoming branch of the master.  It would effectively be on the person who pushes second to do the merge in this case.

[Shadooow]

henesua wrote...

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.

i dont think you could merge/view changes in mdls. Unless they are edited by someone with notepad, Max totally rebuilds the file usually.

[Zarathustra217]

I honestly believe you might be overthinking it a bit here. This isn't about merging a large amount of code. Most of the CEP is made up of model files, and for most fixes it would entail no more than changing a few details in a model. It's a lot of little things. Unless two people within some brief moment of time decide to fix the same thing, there wouldn't be any issues (except the .set and .2da files as I mentioned above).

Personally, I feel TortoiseSVN might be a good choice since it's so simple to use.

Modifié par Zarathustra217, 22 janvier 2014 - 04:38 .

[henesua]

While i like version control, something as simple as possible - like dropbox simple - is probably the way to go so that ancillary systems don't get in the way. Most artists just want to play with models. All the other technical things become barriers to entry as they have no patience for them.

[The Amethyst Dragon]

Is the CEP really such a complicated thing that it requires tools designed for multiple software developers to manage?

It's just a (big) set of haks, a .tlk file, and a starter module.

Why not do something simpler?

Made a fix?  Added something via 2da?  Submitting something brand new?  Just zip/rar/7z it up, attach it to an email, and send it to nwncep@gmail.com.  I download it into my "CEP Pending" folder, do an online backup (I've got like 198 extra GB on my website account I already pay for), get things merged in, and backup the merged haks.  Every once in a while post an update on the new Vault.

I looked at Dropbox, but a free account is only 2 GB and I don't feel like spending money for a "premium" account.  While the 7z-compressed CEP (currently) comes in at under 800 MB, I could see multiple people putting stuff in the dropbox account quickly swelling it beyond the limit.

[Zarathustra217]

My main reservation with that is that unless you want to keep everyone constantly posted on what's been updated, fixed and whatnot, people will feel alienated to the process and thus not participate as easily. It's basically how the old CEP team worked.

TortoiseSVN is very much like dropbox (it even use the same icons!), and anyone able to use dropbox should have no issue with that.

Modifié par Zarathustra217, 22 janvier 2014 - 06:19 .

[meaglyn]

Zarathustra217 wrote...

My main reservation with that is that unless you want to keep everyone constantly posted on what's been updated, fixed and whatnot, people will feel alienated to the process and thus not participate as easily. It's basically how the old CEP team worked.

TortoiseSVN is very much like dropbox (it even use the same icons!), and anyone able to use dropbox should have no issue with that.

I agree that people doing the work should have access to the latest state of things, not the last released state. This could be mitigated by AD posting very regular (daily, weekly?) snapshots, but that's a lot of bandwidth for people if only a little bit changes each time.

TortoiseSVN is a windows only interface to SVN. It's not what the project would be in (that'd be SVN itself). TortoiseSVN would just be the client you may choose to access it with.

Those of us who do most everything on Linux probably won't bother with that one

[Zarathustra217]

Right, of course, but there's still some considerations to be made if it's made the "standard solution" (rather than the other proposals). I'm sure the linux folks will know how to navigate the SVN in their own way, but the point is to focus on what methods we can adapt to make it easily accessible for all (i.e. not just those more used to work with SVN).

As for hosting, wouldn't it be possible to use sourceforge?

[Tarot Redhand]

Sorry about this but I think I just realised another (but at least in part, easier to solve) problem. It has to do with textures and other images within the CEP. The thing is that a number of models use the same texture or to put it another way one texture may be used by 2 or more models. Not only that but some outside projects (I'm thinking of the CCP here as an example) use textures from within the CEP and will not work properly without them.

So before any models and associated textures are stored, in whatever manner, I think someone will need to write some sort of program to go through all of the models to find out which textures they use and to produce a report on it so that fixing something in one place doesn't break something else that appeared to be working before. Not only that but it might be well mannered to include the CCP in this process. And that doesn't even cover the icons and portraits...

TR

Modifié par Tarot Redhand, 22 janvier 2014 - 11:27 .

[Builder__Anthony]

i dont see how anyone can complain.