Need a release manager

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.

 

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.

 

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.

 

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.

 

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.

 

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.