Doing some admin...

Basically, what we need is somebody who is prepared to combine source code for different mod, as well as maintain the current versions of the source-code and mod files both on SourceForge and on CFC. They'll probably also have to do the announcing new for versions of the mod as well as any beta/alpha releases we do.

Anybody up for it?

I would be willing to handel this project since I do have a spare Server2003 with a secure FTP and Broadband connection. I can also build the sourcecode b/c I have VS 2003.

You'll probably want to set up a CVS or subversion server, as well, for source control, versioning and team management. Alternatively, we could try to set up something on Source Forge (which I've only personally worked with in passing :/ ).

You'll probably want to set up a CVS or subversion server, as well, for source control, versioning and team management. Alternatively, we could try to set up something on Source Forge (which I've only personally worked with in passing :/ ).What are they? Never come accross the tems before.

Okies - SpoiledFruit, do you want to make a post with the current source code & dll (ie. nothing at the moment) in this forum and I'll talk to TF about stickying it.

Which terms? CVS and Subversion are both source control utilities. As is Source Forge, and to a lesser extent Source Safe.

The primary purpose of a source control utility is to allow programmers working on the same project to track and adjudicate who is working on which files at any given time. All the ones I've mentioned above also allow for the tracking of versions (called versioning), and allow you to "roll-back" to previous versions of each file as necessary. Beyond that, the features of the above diverge. Source Forge is a GNU-like open source kinda project management website where folks can gather and use their services to coordinate non-profit projects. They use CVS, as I recall, but also add ftp service for distributing releases, forums, membership tracking and the like.

I was going to use a Server 2003 Enterprise edition to handel the FTP and it can also do source control via VS. We could also use SourceForge.net (http://sourceforge.net/projects/civ4ccp/) but it is up to the group. I don't care either way.

In any case I might want to get a user account at SourceForge so I can mannage Files if we go that route.

We alread have a SF project here (http://sourceforge.net/projects/civ4ccp). There's nothing on it at the moment though.

I had a glimps on the SF CVS. Although I did some management functions on SF in the past, I never touched the CVS. My impression is that it is a bit bulky. Does anybody else has some experiences with it?

Anyway, I would like to do a proposal to start a discussion about how we can manage our sources and releases :

1.) Source managment:
a.) we use SF for release versions only. So everybody can DL the officially released version there.

b.) we use SpoliedFruits 2k3 Server for the versions in-work. Only project members have access there. Because each check-out locks the file for others, the check-out times should be reduced to a minimum.

c.) each programmer of the team will have his local copy of the SDK (of course). There we do our changes. After we finished our package, we synchronize the results with the version at SpoiledFruits server, file by file.


2.) Release management:
a.) if possible, everybody should annouce the changes he would like to do and what time he "thinks" he need for it. A very rough estimation is more than enough. Then he synchronizes his local SDk with the one from SpoiledFruits server and start wotking on it. When he finished his implementation and testing (!!!) he looks for the files he changed, checks them out from Spoiledfruits server, merges the versions and checks them in again. As already mentioned, this should be quick operation.

b.) from time to time we should decide to make a release. That means, the current version will be closed for implementation and will go into a test phase. We need that test phase, because there may be conflicts between some packages.

c.) After internal test phase is fnished, we do an official release (beta or alpha) which is put on Source Forge for public download.

d.) The new release is then base for the next loop starting again at point a.


In general this is more or less the typical release cycle of a software :
- specification phase,
- implementation phase,
- test phase,
- release


Because I don't think that we need a big specifcation phase at the moment we should reduce to the a simple anouncement of what somebody wants to do. But this information is of use to get a feeling about the next release date.
The test phase could also be split into a internal test and an public test (beta relaese), but this is something to be discussed.

As stated above, this is something to start a discussion, so let me hear your comments please.

I had a glimps on the SF CVS. Although I did some management functions on SF in the past, I never touched the CVS. My impression is that it is a bit bulky. Does anybody else has some experiences with it?


I've used SVN in the past:

http://subversion.tigris.org/

http://en.wikipedia.org/wiki/Subversion_(software)

Once I got the hang of it, I thought it was really rather good. But then again, since it's the only versioning system I've used, I don't have anything to compare it with.

All sounds good!

2.) Release management:
a.) if possible, everybody should annouce the changes he would like to do and what time he "thinks" he need for it. A very rough estimation is more than enough. Then he synchronizes his local SDk with the one from SpoiledFruits server and start wotking on it. When he finished his implementation and testing (!!!) he looks for the files he changed, checks them out from Spoiledfruits server, merges the versions and checks them in again. As already mentioned, this should be quick operation.
Can I suggest that the announcements be made in the forum, with specific threads for each specific set of changes, and that people remember to update the "Mods in Progress" with whatever they happen to be doing at the time, along with the ETA.

I dont realy see why we should be keeping source in 2 different places, I am not familiar with running a project off SF but I see projects their all the time that have stable releases and unstable development version coexisting. Whats the advantage to using Spoiled Fruits server for development rather then SF?

May we have some contact point or proxy/agent for Firaxis?
We have lots of question and some request to ask to Firaxis developer.
It would be best if at least one Firaxis developer with source code access periodically visit here and answer our question and relay our opinions to Firaxis. Or alternatively as second best, one person here in our group who did beta-test SDK, act as such proxy for us and do similar work by contacting Firaxis people.
We need documentaion other than source code. Especially for API's documentaion for part of code that was not included in this SDK release. Python API doc string is far from enough and very uninformative. I am not asking full formal/internal documents but at least quick cheat-sheet level of under-documented un-explained API calls without source code. There must be at least minimal documentaion, however rough and informal it may be.

My opnion on SVN/CVS:
I prefer SVN. I had some more experince with it. But CVS will be OK to me, too.
SVN has more features but it is less widely used and has less variety of user-level tools are avilable than CVS.

May we have some contact point or proxy/agent for Firaxis?I very much doubt many of them will have much time to spare given Warlords is only a few months away. It's also not the sort of thing that they do in general.

']I dont realy see why we should be keeping source in 2 different places, I am not familiar with running a project off SF but I see projects their all the time that have stable releases and unstable development version coexisting. Whats the advantage to using Spoiled Fruits server for development rather then SF?

The main reasons to have two locations is, that we should reduce SF downloads/uploads to a minimum, because the performance and stability is very poor (at least from here). I expect it to be better at SpoliedFruits server, but this is just a guess (or wish ;)). Also; I'm not sure about the CVS at sourceforge, but this is just a feeling.
On the other hand I don't want to save everything on SpoiledFruits server, because if the "tree" factor (this is the factor which plays a role, when SpoiledFruit has a car accident and hits a tree). Then everything is lost for us. Having the major releases at SF, would safe at least the major releases for everybody.

As I said, everything is just a suggestions. I do only know Visual Source Safe, so I don't have anything to compare. I'm quite sure we could live with SVN and CVS, so its nothing critical.

Just for your info:

Server 2003 Computer -
Pentium 4 3.60GHz
2GB RAM
Primary 10GB HD (For OS Only)
Secondary 80GB (Data Backup) and 200GB HD (Program and File Storage Drive)
DVD Burner (for hard copies in case of computer virus or bad HD)

Network:
1.5Mbps Upload
200Mbps Download
2 Firewalls (External Firmware and Internal Software)
Static IP

I was thinking of making the source code lockable so that someone can reserve that file like a library book. This way no one can suddenly add changes to the source file while someone may still be in the process of adding new code. You could still download files, but new uploads would only be allowed by the person who reserved the file. Once the file is free, another developer could upload the new file version, add the new code he/she was working on, test it and upload it with a new file version.

I would make sure that the submitted files use the latest version (excluding changes, obviously) and I would make sure that no one has a file reserved for an excessively long amount of time (24-48hrs). If longer time is needed, users would just PM me before reserving the file.

Every person involved in the project will have a username and password assigned to them, all you would need to do is PM me.

Right now I am just reformating and reinstalling Server 2003 (had a buch of test crud - Clusters, POP3, AD, Etc) so it should be back up this weekend when I get time.

Just for your info:

Server 2003 Computer -
Pentium 4 3.60GHz
2GB RAM
Primary 10GB HD (For OS Only)
Secondary 80GB (Data Backup) and 200GB HD (Program and File Storage Drive)
DVD Burner (for hard copies in case of computer virus or bad HD)

Network:
1.5Mbps Upload
200Mbps Download
2 Firewalls (External Firmware and Internal Software)
Static IP

I was thinking of making the source code lockable so that someone can reserve that file like a library book. This way no one can suddenly add changes to the source file while someone may still be in the process of adding new code. You could still download files, but new uploads would only be allowed by the person who reserved the file. Once the file is free, another developer could upload the new file version, add the new code he/she was working on, test it and upload it with a new file version.

I would make sure that the submitted files use the latest version (excluding changes, obviously) and I would make sure that no one has a file reserved for an excessively long amount of time (24-48hrs). If longer time is needed, users would just PM me before reserving the file.

Every person involved in the project will have a username and password assigned to them, all you would need to do is PM me.

Right now I am just reformating and reinstalling Server 2003 (had a buch of test crud - Clusters, POP3, AD, Etc) so it should be back up this weekend when I get time.

What software version tool do you plan to use?

I very much doubt many of them will have much time to spare given Warlords is only a few months away. It's also not the sort of thing that they do in general.
Firaxis invested much time and effort to make the Civ4 user modable game, If it was not designed to be user-moddable from the beginning, they would have saved quite a much time and effort ( and money too) in developing it.
So success of modding community is important to them, too, to justify the investment already put to it.
To let a developer visit here regularly like once a week and answer some question in forum or having technical chatting for a while from time to time (once a month ?), or having some e-mail or mailing list discussion for techical Q/A would not take too much time and effort for them.
But its benefit would be enormous. A problem which will take a few hour or even few days for us to solve can be answered and solved in few minutes with their help. We can do Civ4 modding much better even with their minimal help.
For them, it will be their oppotunity to express their opinion and have influence on this project.
Most of all, psychological feeling that we have some "last resort" and being supported by Firaxis will encourge whole modding community very much.

Why not try to establish such a precious oppotunity? It would not cost us a penny even if we are refused. I think that it is at least worth a try.
I am not English native speaker as you may see from my writing. So I would be last person fit for this job.
But if anybody here does not volunteer to try it, I will. Any one interested in it?

EDIT: Damn, I deleted the last version of this post. Now to try and remember what was in it...

You're right - we have nothing to lost by asking.

On a different note, when do people think we should aim for for a first release date? It would seem that pretty much everything has been set up, or is about to be set up, and personally I'd quite like to see something released which will help us to gain momentum. Can I suggest May 17th (3 weeks time) as this date? It seems this will be long enough so that we will have time to make some fairly large changes, while near enough to prevent us losing momentum. I also like Wednesdays.

Also, I was wondering what people thought about making this forum public after the first release. It seems to me it would bring more publicity, and more people, to the mod. Neither of these things can be bad can they?

:bump:

Any thoughts on the above?

Shouldn't be a problem for me. My server will be up by then and my options tab addition should be done as well.

Everyone who adds a new function call should put this in there code:

if (bCppEnabled == true)
{new function}
else
{old function}


This way the new options tab will work.

Public read maybe, but only registered Moders creating new threads, I dont want to be drowned in requests by noobs for requests that are either far beyond our scope "Please make the game an RTS" or easily performed in XML/Python "Can you make Archers stronger?". I like keeping this forum as a place of serious debate of code practice, integration and other nut&bolt stuff by individuals who know C++, the SDK and actualy DO the moding. I am all for expanding membership provided people meet these requirements.

Shouldn't be a problem for me. My server will be up by then and my options tab addition should be done as well.

Everyone who adds a new function call should put this in there code:

if (bCppEnabled == true)
{new function}
else
{old function}


This way the new options tab will work.Hmmm. I wonder if it would be possible to have it so that an alternate .dll file (without the CPP files in) was used instead if this variable was disabled. Would save an awful lot of hassle when writing the code.

If not, I'll stick this in the contributions guide.

EDIT: On further consideration I don't think a .dll switchin method would work - it would be far too fidley to incorperate with other mods also altering the SDK.

@SpoiledFruit : any news about your Server? What software version system do you plan to use there?

@all : what about Source Forge? Should we use two servers as I suggested? If so, should we use CVS or Subversion at SF?

Anybody who wants to enrole the CCP Project at SF should send me his Source Forge Account as a PM. I will add him as Developer.

12m

IMO we should just update sourceForge with the new source code and .dll whenever we release a new version. Otherwise it might be a bit complicated.

The good thing about sourceForge is that we always use it as a backup if there are any emergencies.

Just reformated the HD and put in new ram to upgrade it to the 2GB (it was 256MB) and come to find out the RAM is bad, so I need to replace it today or tomorrow, then it will be up and running.

On the software I am not sure as I was thinking of just writing a simple source control macro myself for my FTP software. If you have any suggestions though i would appreciate it. The one I currently have is not good at all for internet source control.

Oh, and I will send you my username for SourceForge ASAP.

2.) Release management:
a.) if possible, everybody should annouce the changes he would like to do and what time he "thinks" he need for it. A very rough estimation is more than enough. Then he synchronizes his local SDk with the one from SpoiledFruits server and start wotking on it. When he finished his implementation and testing (!!!) he looks for the files he changed, checks them out from Spoiledfruits server, merges the versions and checks them in again. As already mentioned, this should be quick operation.

b.) from time to time we should decide to make a release. That means, the current version will be closed for implementation and will go into a test phase. We need that test phase, because there may be conflicts between some packages.

c.) After internal test phase is fnished, we do an official release (beta or alpha) which is put on Source Forge for public download.

d.) The new release is then base for the next loop starting again at point a.


In general this is more or less the typical release cycle of a software :
- specification phase,
- implementation phase,
- test phase,
- release
Just going to bring this back up. Firstly, is everybody still good for a release date of 17th May for the first release? Do we have enough to show, or should we push it back a bit? It seems to me that we really need something to show regular civ players, as well as modders. It feels a bit rich of me to ask this, as I haven't been/won't be able to contribute any code yet, but maybe if somebody could work on the list of bug fixes that I proposed then we might get a slightly wider audience from the outset.

Once we've got the first version up I'll make a new thread asking for ETA's of the next set of mods, so we can see about sorting out a general target for the next release.

Secondly, we need to decide how long we want for the test phase, where the code will be locked to editting. Personally, I think 3 days should do it - that should catch most of the obvious bugs, and if everybody tests as they go along then we should be fine. If we find a bug obvously we'll have to unlock and fix it, and then begin testing all over (though maybe only over 2 days). I'll make a couple of posts in the original thread asking for testers a few days before we're due to lock down the code, so hopefully we won't have to do it all ourselves.

Finally there is the issue of backward compatability. It seems to me that as many releases as possible should be backwards compatable, and that we should shove all the stuff that would make the release not backward compatable together in one batch until we have enough to justify breaking all the save games.

Am I right in thinking that the first release will be backwardly compatable? I wasn't quite sure after reading SimCutie's thread.

Don't expect too much from first release. Now, only 3 weeks have passed from SDK release. And we are not doing this as a job, it is our hobby. It is just "dip our toe in the water" stage.
I think that first release should be focused on team-building and process improvement and gaining experince on this kind of cooperative development, not features to show to general public. So how many fancy features it has doesn't matter now.
The planned first release should not aimed for general public usage, but for experimentation and to get grip on where we should head to and how far.
I suggest that we start to check in CVS/SVN as soon as possible and as frequent as possible for the time being to reveal and expose any initial hurddle or problems. The sooner they are found, the eaiser to fix them.
On backward compatibility:
In current stage of project, it is too early to consider backward compatibility from first release. We have no experice on SDK modding for setting standard for it. We don't have format specifiaction or general framework to maintain compatibility with old save format. Let's experiement freely for the time being.. As the project matures, we should be able to do it later.

Don't expect too much from first release. Now, only 3 weeks have passed from SDK release. And we are not doing this as a job, it is our hobby. It is just "dip our toe in the water" stage.
I think that first release should be focused on team-building and process improvement and gaining experince on this kind of cooperative development, not features to show to general public. So how many fancy features it has doesn't matter now.
The planned first release should not aimed for general public usage, but for experimentation and to get grip on where we should head to and how far.
I suggest that we start to check in CVS/SVN as soon as possible and as frequent as possible for the time being to reveal and expose any initial hurddle or problems. The sooner they are found, the eaiser to fix them.
On backward compatibility:
In current stage of project, it is too early to consider backward compatibility from first release. We have no experice on SDK modding for setting standard for it. We don't have format specifiaction or general framework to maintain compatibility with old save format. Let's experiement freely for the time being.. As the project matures, we should be able to do it later.
I don't fully agree. Of course the first release will be not the "big throw" and it'll be also an exercise for us. All that is true.
But we should make this release public, at least to tell the people that there is a group who takes care of a general improvement of the API/SDK. We have to convince them about the advantages of a common SDK/API. If we do that, they will support us with their ides and changes and they will start to use it.
You can see in the forum, that quite a lot of people do changes in the SDK. Modders who are not able to program in C++ already have problems to merge them (OK, and there are still some people who are simply not aware of that problem ;) ). However, the earlier we release something the better the support will be.
So, in my opinion we definitly should make this relaease public.

Also, we should check compatibility of all our releases. We should do that in two ways :
- can we load and handle old save games
- can our own save games be handled by standard.
THe first one will be more important, the second one is more an infromation. If we have an incompatibility each release, we may get no acceptance and support.

However, the earlier we release something the better the support will be.
I agree with this. I also agree that we shouldn't try too much, too soon. However, I do think we need something that we can show and say "look, we have done this".

IMO the biggest, and probably easiest big-hit features I can think of are bug fixes. Many people will download the mod just for them... just like people download patches even if they don't have a problem with the current game. Once we have people following us, the whole project should begin to take off.

Very few people will notice a small tweak in the AI, or an enhancement to modding ability. If we go and say "the bug when upgraded caravels continue to transport missionaries has been fixed" then it's something people can latch on to. It's also probably quite an easy fix (as I said, I would do it myself, but can't due to circumstances out of my control).

About save-game compatability - if old save games are not compatable people aren't going to install the mod instantly, and by the time they've finished their current game they may well forget, and never install it at all. This would be bad for them, and bad for us. This is the reason I feel we should start of making sure that it all merges seamlessly with the original game.
If we have an incompatibility each release, we may get no acceptance and support.

This is a reson why we should label first release as "experimental". We don't have working and agreed and tested backward compatibility scheme. And it is very unlikely that we will have good one before May 17. Even if we make one in hurry, it is higly like that it will be revised in next release and fail to maintain compatibility. If we call this as "alpha" or "beta" release, then no one will expect save file compatibility.
Being ambitious is good one. But we should not promise what we can not do in reasonable time or give false expectation to general public.
One solution is that, for first release, we maintain compatibility with original save file. (i.e. no savefile extension) by holding off modification that requires change of save file until we have well designed and tested savefile solution. Bug fix will be good objective for that matter.
Or we stop our current on-going mod work and start talking and working on save file solution first and not issue first release until we have satisfactory and well-tested save file scheme. Then it would be inevitable to push further the first release date off. (at least to next month?)
In any case, we should start working on save file scheme, sooner or later. Does any one have good idea? I have some very crude scheme in my snapshot release, but it is far from satisfactory solution.

Any news on the server fruity?

About save game scheme - surely we can just adopt/adapt the methods already set by Firaxis, much like you have.

Server is up and running, Just have to set the proxy to target the server and open the FTP port in my firewall. Should be ready this week. The only thing is that I am reluctant to give out the server IP over unsecured communications so if I do release the IP here, please dont share it outside our group. This is on my work network and I don't want to be hacked.

I also found a good (to me) CSV program from Component Software. It's free, workes over the internet, is compatable with SourceForge, suports multiple platforms, and integrates nicely into VS 2003 for compiling easier (I also think its what Firaxis used - another bonus if I'm right).

I have added all the usernames I have seen in this forum so I will PM you your passwords when it is fully functional. If you want it changed, PM me back your old one and the new one you want.

Just in case this forum does ever become public, I would suggest you PM the IP address along with the passwords.