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.
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?
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.