C2C SVN Changelog

Just found a HUGE bug in AI city founding position evaluation that has been there since at least BBAI was introduced (it's in the AND base revision and K-mod for instance). The net effect is that the AI will tend to choose 'ok' positions for cities but not notice the best ones!

Fix pushed to SVN (rev 823)
 
Just found a HUGE bug in AI city founding position evaluation that has been there since at least BBAI was introduced (it's in the AND base revision and K-mod for instance). The net effect is that the AI will tend to choose 'ok' positions for cities but not notice the best ones!

Fix pushed to SVN (rev 823)

That is great to hear. Will the AI move his initial settler to a better spot if one is visible? Or do they always build on the tile they are placed at?
 
Updates
Two new XML files added: CIV4CulturalAgesInfos.xml and CIV4PropertyInfos.xml.
They are both read into info classes but the info is not yet used.
 
Just pushed a few speed ups to SVN:
  • Upgrade cost calculation (5 secs per turn -> 0.6 for my game, early ancient on gigantic)
  • Max compat save time (6.5 seconds -> 3.5 seconds on the same game). This one was bugging me due to using it on my auto saves
 
I think we need to change the way we're handling releases now we have so many more users, and more active modders. Basically we need to get a lot more professional about it, or we're going to have stability problems (as we've been seeing) in released versions more than is desirable.

What is needed is a release freeze of some sort. Some period before a release (a few weeks) we freeze all activity on new features etc. and ONLY bug fixes go in. Ideally we all spend our time playing/testing in that period.

This doesn't PRECLUDE ongoing development (we can create a branch for each release in the SVN), but if we want to allow ongoing developemnt during release freezes apart from pure bug fixes then we'll need to setup branches in the SVN and SVN usage will get a fair bit more complex (it's designed to do that, but most of you are not professional software developers so it would increase complexity in areas you're likely to be unfamiliar with SVN-wise).

I would propose that we keep it simple, and just straight forwardly freeze for two weeks prior to each release, and all spend that time in testing/play testing. The only SVN changes to be allowed in such a period would be (ideally agreed - no sense fixing low impact bugs that have their own risks when we make changes to address them, if they won't greatly hurt the release anyway) bug fixes.

Edit - this isn't aimed at anyone or any specific change BTW - it's just that we're seeing a lot of hard-to-pin-down CTD reports recently. Most likely they will turn out to be my fault, but the point is that chnages all have risks and we're pouring a lot of changes in currently.
 
What is needed is a release freeze of some sort. Some period before a release (a few weeks) we freeze all activity on new features etc. and ONLY bug fixes go in. Ideally we all spend our time playing/testing in that period.

Well a few weeks seems like a long time to go without new stuff, especially when we are releasing a new version once a month. I could understand maybe a buffer week. But only having 1 week to submit stuff a month seems a bit too extreme. Especially if you working on a big project or are busy with real life during that week.

Personally I think we should take it on a case by case basis where all the team are asked if they need more time or not. And we are given a goal date, which in this case was October 15th right?

Personally I am in between projects where I could hold off until after the 15th. However there are a couple of things I would like to see get in before then from others.

However on this issue of testing I would assume that people like JosEPh_II who do not update on the SVN but report back errors frequently do test for us. Other players who do use the SVN are constantly giving feedback and then of course we the modders play too and will self adjust the game based on our games.

In short a small freeing window would be nice but not so much that it keeps us from adding stuff at our own rate. Its hard enough to get us motivated enough to do stuff on our own. Putting limits would only harm the relaxed creative atmosphere we have here.

EDIT: One case in point are DH's and my side projects that we have a bunch of and have sitting around unfinished. I fear that more of these will build up if we have a freeze period that lasts too long.
 
I agree we need a freeze on new stuff before a release,even if it is only so we get a chance to check that all our work fits together well.

EDIT: One case in point are DH's and my side projects that we have a bunch of and have sitting around unfinished. I fear that more of these will build up if we have a freeze period that lasts too long.

I disagree with this bit. Having the freeze will free me up to set to on those components.
 
I agree we need a freeze on new stuff before a release,even if it is only so we get a chance to check that all our work fits together well.

I do agree here, a ONE week of NO adding will be scheduled per month for playing and making SURE that the stuff "we" added/subtracted does actually work.

So a propose this time it be from 7 October to 12 October, because of this new proposal, so short. Then add/delete etc from the 13th and the early morning of the 14th to get stuff in that we need to, that way i can get everything all tied together for an FPK update and start that darn 6 hours UPload to the server on the early morning of the 15th.

Then 6 - 13 Nov for the next time freeze. and the 18th of Nov, for the next update. How does this sound?
 
I completely agree with you here;)

I agree as well. There is no rush to constantly make changes and the more that are made w/o GOOD playtesting the harder it is to backtrack and rebalance, debug, etc.

Although just a small contributor, I would like to continue helping where I can, but between being a home owner, married, full time job, etc. my Civ modding time is somewhat limited.

@Hydro

I don't think Koshling was saying you can't work on your projects and refine them, he just means-- and correct me if I'm wrong Koshling-- that we won't be making SVN commits during that 2 week period. Take time to play the game, dude. Enjoy the fruits of your labor. :)
 
I agree as well. There is no rush to constantly make changes and the more that are made w/o GOOD playtesting the harder it is to backtrack and rebalance, debug, etc.

Although just a small contributor, I would like to continue helping where I can, but between being a home owner, married, full time job, etc. my Civ modding time is somewhat limited.
Take time to play the game, dude. Enjoy the fruits of your labor. :)

What ever happened to that guy that was an Audio Specialist?
 
I do agree here, a ONE week of NO adding will be scheduled per month for playing and making SURE that the stuff "we" added/subtracted does actually work.

So a propose this time it be from 7 October to 12 October, because of this new proposal, so short. Then add/delete etc from the 13th and the early morning of the 14th to get stuff in that we need to, that way i can get everything all tied together for an FPK update and start that darn 6 hours UPload to the server on the early morning of the 15th.

Then 6 - 13 Nov for the next time freeze. and the 18th of Nov, for the next update. How does this sound?

That sounds reasonable. The way it sounded was 3 weeks of testing and only 1 week of submitting stuff.

I agree as well. There is no rush to constantly make changes and the more that are made w/o GOOD playtesting the harder it is to backtrack and rebalance, debug, etc.

Although just a small contributor, I would like to continue helping where I can, but between being a home owner, married, full time job, etc. my Civ modding time is somewhat limited.

@Hydro

I don't think Koshling was saying you can't work on your projects and refine them, he just means-- and correct me if I'm wrong Koshling-- that we won't be making SVN commits during that 2 week period. Take time to play the game, dude. Enjoy the fruits of your labor. :)

I personally think more than a week of freezing is too much. One thing I like about the SVN is I can play, tweak, add and test all in real time with everyone else. Before we had the SVN it was basically work, work, work then barf out what you worked on for all the weeks you worked and tested it and then see if they merge ok. Now we can have them all co-exist and test at the same time.

At any rate all I request is no more than a week for the freeze period. What strategyonly just proposed sound perfect to me.

EDIT: Note that if specific projects like the terrain project did need to push the release date back. We should allow for that kind of thing if needed. I doubt we will have many of those but it should still be an option.
 
Back
Top Bottom