Brilliant Idea: A revision control system for individual maps

Here’s my 25 cents:

Imagine a revision control system that operates on a single map or multiple maps. Actually no, scrap that, existing RCS’s like SVN or Perforce will work for this purpose. All that’s needed is the ability to take the difference between two maps in a relevant way (i.e. be able to fly through the map and see highlighted regions that are different, the same, or conflict.) This way multiple people could check out/check in from an SVN, and merge their changes into a map without having to do it manually in an editor. Think how Perforce requires you to update to latest, and merge changes made after your base revision into your checked-out version.

tl;dr: “diff” command for VMF’s and BSP’s + SVN = really easy collaborative efforts.


I see what you’re getting at, sort of like the ability to merge maps. I think it would still be better to do it in the editor, because then you wouldn’t get minges merging downtown with evocity and trying to pass it off as their own downscity.

So you mean if you and your friend each take a copy of a vmf and change it and want to combine the separate work you’ve done without using an editor?

How would you merge 2 maps (bsp or vmf) together? How would the program decide what to keep or what to change?

I’m still kind of confused about that third sentence. What do you mean by fly around the level to see changes? Is it the editor that does that or do you and your friend fly though?

As it stands right now, your friend will just have to tell you what he’s changed and you work those changes into your map in hammer.

I am completely utterly lost. Lost of big words hurt my dumbox of a head.

Simplify, or expand?

I kinda get it.

I suppose it’s a neat idea, but it’d have to be limited to private servers or the whole thing would be a complete mess.

There would be huge gaps in the map where the brushes dont meet up. Nice idea, but I might have read wrong.

It is very simple to do this without any program.

Just always work on an area relitive to the world location. then copy and paste it with a brush at 0,0,0 then you can always posistion it perfectly.

Yeah, and us coders like to merge our code files manually too (THIS IS MY SARCASTIC VOICE.) Honestly, being able to merge parts of a collaborative map using a very simple tool like “diff” would be amazing.

If you don’t understand how diff works with revision control, look at how Perforce works, or JFGI.

First off, that’s not how merging works. Merging evocity with downtown would look like a huge mess of differences. But before I explain that, let me say that I don’t think that new ideas like this should be supressed just because Sgt.Sgt’s pissed that minges keep trying to steal his map. The benefits of the tool outweigh the potential for abuse. Also, this community has its rules for plajarism, and if they’re broken FOOLS GET BANNED. End of story.

Ok, so merging (hoo boy…) First go look up what “check in” and “check out” mean in SVN speak, then come back and read the rest. I’ll wait.

Ok, ready? Let’s say that you and a friend check out the same map from an SVN repository. You both then make changes to that map, based off of the revision you originally checked out. That checked-out revision is called the “base revision” which you both started out with.

Now, let’s say your friend checks in his file and adds his changes. Now let’s say that SVN has a rule that says you have to make sure you don’t overwrite your friend’s changes in your check-in. You have to “merge” your version with the version that is now in the SVN, by using a tool which lets you add your changes to the base revision AND add his changes to the base revision, making a “merged” version which contains both your changes.

Ok, an example. Let’s say you’re collaborating on a new flatgrass. Your base revision is, well, a plane of flat grass. You both check out and start editing. Your friend adds a concrete platform on the ground, and checks it in. You add a skybox to your version. Now you have to check in, but SVN complains that you have to merge. The “merge tool” I’m proposing automatically takes the differences between your map, your friend’s map, and the base revision, and asks you which changes you want to add. You keep both your skybox AND his platform, and check it in.

Now, let’s say you both check out and simultaneously start adding a tower in a certain region. He checks in, you try to check in but have to merge, and you find out that both your towers are in the same location overlapping. That’s called a “conflict.” You have to use the editor to figure out if you want to somehow combine your towers, go with his tower, or go with yours. A good merge tool would automate most of this process for you, so you could pick and choose different changes with a single click or keystroke.

Make sense anybody? Or did this wall of text just confuse people more?

What method should determine what is different?


Brush data in a vmf isn’t located by position, it’s based on time of creation, and not in actual time, just in brush numbers. So if one person wanted to work on the left side, and another the right, then merge it with a center map, both of them would have brush #s that are the same. If you diff the files, it will find the same faces with different plane values and textures.

If you wanted to do this, you would have to have a program read the vmf and make sense of it, determine which brushes don’t exist, then write that all into a new vmf, making sure not to duplicate side/brush ids.

It’s complicated and I’d personally just take someone else’s map and copy/paste it into the “master” version of the map.

Just use dropbox and both work on a seperate file?
Then when you’re both done, merge the maps together with the hammer merge feature…

Kind of like coding, guys. If I add a bit of code to one area, my friend adds code to another area, and we both submit the code to a SVN server, both codes add but the base still stays there.

If you both add code to the same area it doesn’t override the area of the other coder unless he already sent it in. You have to work on separate areas at the same time.

So it’s like merging documents on Microsoft Word?

Maybe the tool could sort the brushes/ents by origin, then take a text diff? Each brush/ent that is different gets highlighted one color or the other, or bright red if theyre a conflct.

This man speaks the truth.

You must be clairvoyant, because Valve just added that to the SDK. True they broke it at the same time, but now with manifest

on another note…