Quake3World

Does anyone know if difference software for the Q3 .map file format has been made before?

My (perhaps feeble) google searches didnt find any results, so I thought I'd check with the knowledgeable folks here. I think I remember it being talked about a few times in the past, but I'm not sure if anything came from it.

Ive been thinking about it and have started to write a program to do it. So far I've got a parser and classes to hold and compare all the data, from individual vertexes up to whole entitys.

If this works it'll allow multiple people to work on different parts of the same map at the same time. By sharing .diff files with other mappers that started with the same base .map all the mappers could be kept upto date with each other.

Bert Peers' LEET was supposed to do something like that...

LEET is an experimental tool, which some day wants to be a sort-of level editor At the moment, it is mostly a .map viewer and exporter, with the following features :

* Network enabled -- connect to a server and make your changes online
* Multi-user, realtime cooperative editing, with Password protection
* No tokens, no turn-based; full Undo/Redo support. Only data integrity is the limit.
* Full unicode support -- read anything typed by anyone (requires appropriate fonts)
* Various viewing modes -- Wireframe, Hidden line, Textured
* View the map with animating shaders, without the need to compile first
* Animating texture browsers, with prefix or regex filtering
* Export the .map file to DXF, ASE or 3DS
* View using parallel or perspective camera. Freelook camera, panning, zooming
* Various filters -- show or hide sky, nodraw, portals, noclip, .. brushes
* Custom filters
* Arbitrary, user-defined window layout
* Automation enabled (limited functionality)

... but I don't think he ever got around to finishing it, he doesn't have it listed on his site anymore. I have an old alpha version.

According to hints and rumors, id Studio for idTech 5 should support multiuser editing.

$NulL wrote:I think I remember it being talked about a few times in the past, but I'm not sure if anything came from it.

Me, perhaps? I wrote a prototype of gtkradiant + versioning about a year (or maybe two) ago. Nothing much really came out of it, it was just a showcase to see if it was possible.

As an aside: you can scavenge code from `rcs`, the tool CVS uses to create and maintain diffs. I did, anyway. =)

The problem I have with standard diff/merge software is that radiant has the habit of changing the order of things everytime it saves. Well not so much entitys/brushes, but entity keys get shuffled around a lot so you end up with every entity having an entry in the diff, which isnt desirable.

What im trying to build is a system that recognizes brushes and entitys, no matter what order there component parts are arranged.

Easy fix: have gtkradiant sort the entity keys before writing them to disk.

Well I made it anyway. So it can work for any version of radiant. Another problem with standard text diff software is that different versions of radiant (namely 1.5.0) output floating point number different ways.

Compare these lines: Which would cause a diff entry for nearly every line in the map.


Here's my map diff/merge tool, it creates custom format diffs when comparing two maps and can merge them with other maps.

It operates on map components (brushes/patches/entitys), instead of single lines. It works correctly even when map components have been shifted around within the .map file.

Feel free to give it a try: Download

This is how I see it being used:

1. Two mappers start with the same base file.

2. Both make modifications to the areas that they are working on.

3. Both create diffs from their working copies against the base map.

4. They share their diffs, and merge each others modifications into there own maps.

5. This merged combination is backed up as the base map, and they repeat from #2.


On the incident of both mappers editing the same brush (/patch/ent), when they come to merge an error will occur which will lead to duplicate brushes being in the merged .map. The merge algorithm will detect this and will output and error.map which reports all the incidents of brushes(/patches/ents) that could not be found/removed from the map getting merged. To fix the duplicate problem the mapper must look at the location of the brush in the error.map, this should give the location of the duplicated brush in the merged output file.
Note: if you use -diff with -v you will get two additional .map files, one shows all the brushes that the .diff removes and the other shows all the brushes that the .diff adds. Kind of pointless but i think its nice to see.

this sounds like a great tool. who wants to make a map with me?