Ok, in preparation for the stuff on the bundler application - here's a link to the tutorial I used to figure it out:
https://www.ghostrecon.net/forums/index.php?showtopic=36760 The key items I took from the tutorial are to put my project maps in a folder structure down on the c: drive that looks like this:
c:\mymap
and inside that folder it's the same structure as in the BUNDLE files, not the structure you find in the editor temp files inside the custom levels folder. The easiest way to get your map into that structure is to simply unbundle it to the C: drive and rename what becomes a mymap.bundle folder to just \mymap. In it it's all going to be perfect.
the next thing that's important is to know your bundler command line with all the right switches. I saw many incorrect posts about this. Here's what works, given your files are in c:\mymap in the right structure:
C:\path_to_your_bundler_exe\bundler -vvb quick-bundle -r C:\MyMap -D mymap.bundle On my system the command is somewhat more complex, as there are space in file names and everything needs to be wrapped in quotes to work. Here's the exact command I used to rebundle the thinning_the_herd map (and because it is such a mess, I keep a text file on my desktop that has this line of code in it. For new maps I edit the name of the map and save it for the next few days of use. I just copy/paste it from the text file into the dos box to do the below):
When things work out alright, you will see a screen like this scroll by:
The bundler also creates a text log that gets dumped next to the bundle file into c:\ when using the above synax - check in there for any possible errors.
I also have a screen of the directory structure of the unbundled raw files I keep editing and replacing before rebundling with the above command. In the picture below I am selecting the Left_Behind map minimap tga file to open and edit it in Photoshop:
The structure of the directories in these folders must always be the same
The minimap is in the /gui dir, while most of the stuff that needs frequent replacing while debugging a map are the world and script files in
C:\thinning_the_herd\data\levels\custom_levels\thinning_the_herd
and
C:\thinning_the_herd\data\levels\custom_levels\thinning_the_herd \xml
respectively.
Knowing this structure is also very important for recycling those light maps from the maps supplied with the game as single player missions, since this is where you exchange your low quality light maps with what you unbundle from the original mission file. You have to replace 3 files usuall to do that - two are in the same directory with the world.xml file and are called ambient_cubes.bin and massunit.bin, plus you may need to replace the texture_scope.xml with the one from the original mission if you have the old yellow-blue object issues. In the above example, that file sits here
C:\thinning_the_herd\data\levels\custom_levels\thinning_the_herd\texture_scope.xml
Note that I do a lot of editing in the GUI editor to move objects, etc that need updates from the last version. All I do after that is take the latest numbered world_nn.xml from the work directory inside /custom_levels of the game, copy it into the above extracted map structure where the world.xml sits, delete that file, rename the new one to world.xml and bingo, the map can be rebundled.
You can always remove map items that way, but when you move them or add them, you will have to do a complete lightmap render job, so make sure your map has everything on it before you render light maps. If you are using maps from the original games, you can always remove stuff. Adding is limited to a very small number of props that don't generate light maps of their own. I could post those props, but that would go off topic here.