Spring RTS Engine

Keep firing at it.

I think you are updating ca too much (some times per day) and your team is not sycnronised. One member makes changes, other reverts it etc. A little order could help

yeah quanty, sounds like you need a fresh dose of GIT source code management - the style of developing and testing that you guys do is precisely what git was meant for.

I'll agree with the newb on this one. 1 update per day, and some kind of communication between your members could greatly improve it.

as a side note, i think 7 out of every 5 posts i've made in the past two months have been about git.

I think dragon is onto something. Commit/revert wars are fun for 100 revisions or so, get a little boring after that

Most of the CA developers use Windows. Git has very poor Windows support. It is written as several different C programs and glued together with bash and perl scripts. This requires you to install either a Cygwin or Msys development enviroment. The closest thing to a GUI is Git-Cheetah, but it looks like to be an abondoned project before reaching a useful state. Git also has a steep learning curve.

Mercurial would be a much nicer fit. It has most of the advantages of Git. It is written in Python and works very well on Windows. Mercurial should be easy to pick up on for anyone who has used SVN. It has a GUI for windows called TortoiseHG, but while it appears to be actively developed, it doesn't appear mature enough for serious use.

Even if CA moved to distributed RCS, commit wars wouldn't be solved. The AutoBuilder and by extention CAUpsater require a central repository.

Personally git gui + gitk works ok for me on win (for normal staging & committing), and shell for complex stuff.

A TortoiseGit interface would be nice though

Commit wars are a process problem, not a VCS problem. Just a matter of discussing changes before committing them to the central repo
(Though I admit the fact that branching & distributing personal branches is easier in git may help against commit wars, and if you do truely DVCS then commit wars == forks I guess)

Imho, the problem is that our version control is also our distribution system: every single revision is sent to players.

I think we need a "don't distribute" tag.

Or "DISTRIBUTE" -- this was discussed in #ca,
it's probably better to make it a positive tag such
that distributions or not created if you forget the
tag.

example commit message:

reminds me of BUGFIX a bit but much better than pushing every single release out.

Maybe I should make that in Spring repo too so I don't have to bother with releases anymore

trepan wrote:Or "DISTRIBUTE" -- this was discussed in #ca,
it's probably better to make it a positive tag such
that distributions or not created if you forget the
tag.

example commit message:

Code: Select all

DISTRIBUTE
* Nerfed core units
* OPed arm units

The next version of CAUpdater (by Licho) will probably only down new snapshots that are tagged in this manner. Snapshots will still be built for every commit.

trepan wrote:Or "DISTRIBUTE" -- this was discussed in #ca,
it's probably better to make it a positive tag such
that distributions or not created if you forget the
tag.

example commit message:

Code: Select all

DISTRIBUTE
* Nerfed core units
* OPed arm units

what the hell? someone actually listened to me!?!?!

There doesn't appear to be an experience requirement for morphing HLTs to tachyon/Doomsday like there is between most of the other military building morphs. Is this intended?

Yes, you must have lvl2. and thats all.

That seems a bit cheap, since it pretty much eliminates the need for the core combat engineer or t2 cons in general to be able to build military stuff, morphing at this point makes t1 cons able to make just about everything already.

Edit: And for those that start with kbots, t2 constructors don't come in amphibious or all terrain.

well, you have to tech up and it still takes time and resorces to morph. and if you dont build tier2 con/ engineers you doin it wrong.

overkill wrote:well, you have to tech up and it still takes time and resorces to morph. and if you dont build tier2 con/ engineers you doin it wrong.

Could you guys make some sort of crude documentation about things like this in CA? I still don't know off-hand what can morph to what and if you want to morph you'll need a t2 con or a t2 fac etc. I like your unit guide on caspring.org but it would be great if you added these sorts of things to it.

Another example: what the difference is between a ditch and a trench. New people could read a few quick sentences and not have to experiment nearly as much.

A trench is shallower, but has straight up-and-down sides.

A ditch has, admittedly highly-sloped sides, and sinks deeper.

I prefer to use ditches, as they allow communications trenches, 'Ambush' cells, etc.