Dumping of compiled maps in the SVN

[fromhell]

Should I do this? I mean, deleting all the generated BSPs we have now in the /maps, and having .bat/.sh files that generate them (back into the svn, no i'm not changing the whole pak building process and most importantly i am not removing maps). I hope it would encourage that whole build script thing I wanted to do.

bat/shs would be placed in the maps source folder.

[bill-----]

on the plus side: 
You'd know that the .bsp was generated from the .map, Has there been
much problem with mismatched .map and .bsp files?  Knowing that everything can
be regenerated from source, and there's no hidden 'gotchas' in the tree would be a Good Thing.

on the challenge side: 
You'd have to pick the correct compile program and compile options. 
Don't know how long it would take to compile them all, but I'd guess it'll take a while, and
require non-trivial CPU and memory.  Comparison and verification of function and appearance
will also be non-trivial, and probably can't be done automatically.  A community effort.

on the negative side: 
In the unlikely event that a map won't compile or doesn't work like the
original, you'd have to decide whether or not to make an exception or take on the task of
correcting problems.

Knowing you can or knowing why you can't is better than not knowing.

[cosmo]

Not a good idea: high quality lightmaps require 10+ hours of compile time on Quadcore CPUs with 4GB RAM. You do not want to go through this, do you? Some q3map2 versions tend to segfault, others do not, regarding to compile options.

Think about this: Ban Quark from the mapping tool list because it generates mapfiles not being readable by radiant. I have not tried converting mapfiles with q3map2 so far.