Hey everyone,

I've got a newbie mod question for you.

When you guys have finished or made substantial progress on a mod and a patch for the game comes out, and subsequently the new version of the source comes out, how do you handle that? I'm assuming you have to take all your mod code from the old source and put it into the new source...is there some easy way to do that?

I thought about it today and realized I have no idea how that works.

We use our version control software to help do a lot of that work for us.  For example, if we license an engine, we will put that code into source control.  We will then branch that source.  One branch represents the licensed code, the other branch represents our changes.  We'll make changes on our side of the branch to reflect the game we are making.  When we get a new update of the engine, we'll update the licensed code branch with that.  We can then have the version control software "merge in" those changes into our branch.  Most of those changes will come over fine.  One problem you'll run into is when you have changed the same section of code that the new update has changed.  Another problem is if the new update has changed variables or structures for which you are using in your code.

Hopefully that makes some sense...

Rick, mind if I ask what version control software you are using?

For the previous SOF2 patches (1.01, 1.02,...we haven't gotten 1.03 yet ;) ), I just used WinDiff to run through the changes and see whether I wanted to make the new change or not. This worked fine because the changes were rather small and many of them weren't relevant to our mod anyway since its a TC.

WinDiff is just a file comparison tool that comes with MS Visual Studio. There are others out there just like it as well, some that also do the merging like the version control.

I like to be able to see the changes myself, but if its a lot of changes or the project is the size a engine would be, I would definetly use version control or the auto-merging ones.

We were solely using SourceSafe, but are now migrating to PerForce (which I really like).  2 of our 3 projects are now on PerForce.

We use a combination of CVS tagging the 'good' version, and a tool called beyond compare from scooter software (http://www.scootersoftware.com I think).

BC is like Windiff or Unix diff on steroids, it lets me open the old (my code) and the new SDK patches in a window side by site, and copy over lines or blocks of code from the new patch to our source code. It also will tell you what's different down to the character in two lines of code (which windiff does not do).

Because we tag/branch in CVS, we can easily back out the changes if we screw up (we've got on the order of a million lines of code to go through -- it gets kinda boring, and you can slip up easily).

It usually takes me somewhere between 3 hours to 3 days to diff in a new SDK version, depending on how much has changed, whether things require substial hand editing or not, etc.

Not sure what ravensoft uses, but I've used both Visual Source Safe (microsoft's offering) and CVS, CVS is my opinion the hands down better of the two, it operates better remotely (because it doesn't use microsoft's crappy slow share technology), and also is far more intelligent merging in multiple developer's changes.

VSS makes developers work in a fundamentally weird way to me - only one programmer can 'check out' a file at a time. While he/she has that file checked out, no one else can work on it.

CVS uses a line by line comparison (actually running *nix diff IIRC) and merges in multiple developer's changes most times rather smoothly. Now and again, you'll find that two people have changed the same line, that's where you go and 'fix it', putting the most recent change to that line in instead.

Since the SDK I'm dealing with requires that multiple programmers change the same file at the same time, I think CVS is the best solution.

CVS is the right price also (free as in beer), beyond compare was well worth the $30 USD I spent on it.