In my last post I touched on some of the potential pitfalls when it comes to exporting a map from GE in order to reduce file size. As I now understand it the process strips out any files not being used by the map01.i3d. In most cases this is what we want and divesting the map of unused assets, duplicate textures and other debris can lead to some very significant savings in file size. I understood that there were files that sit in the directory above the maps directory that needed to be added back in for the map to function. If these files are not present the map won’t even load. Since my map loaded and everything seemed to work I concluded that I’d done a good job and promptly moved on, no need to check the log file here. If I’d bothered to check the log file I’d surely have seen that my skills as an exported of maps were not quite as robust as I thought.
I believe I mentioned in an earlier post that ShyWizard has an excellent YouTube tutorial on reducing map file size. What I didn’t mention is that last time is that I only watched enough of that tutorial to be dangerous. The first part of the vid covers exporting your map and adding the files you need to get in running back in. The second part of the video, which I had neglected to watch earlier, does a very though job of showing the viewer how to run through the error log and correct all the issues that had been uncovered. With this new found knowledge in hand I quickly set about restoring wayward shader.xmls and corralling in all those dds files that had mysteriously wandered off to parts on known. For every 4 errors I squashed (there were 87 at one point) another one or two new ones would pop up but I was quickly machining my way down the list and an error free mod was just around the corner, until…the last two frakin errors!
As the log would have it, something, and the log was a bit vauge on exactly which something it was referring to, was looking for a pair of shader.xml files, not in the maps directory or the directory above where all good decent, God fearing, law abiding shader.xml files can be found, but in my mods folder! A quick text search of the map folder showed that the shaders were in fact safely within the confines of the map folder where they should be but had for some strange reason given the unnamed customer of these shader.xml files the wrong forwarding address.
I moved though the first 85 errors in about 20 minutes or so. These last two delinquents defied me for another 4 hours! I found several references to these shader.xmls in my map01.i3d but these all pointed to copies of the shader.xml’s that were just were they should be. Eventually, and it seemed like more than 4 hours, it dawned on me that there were other i3d files in addition to the map01.i3d, and that I had manually added these .i3d’s back in after the exporter has stripped them away.
There was one for the compost master and there were several for particle effects associated with said master of compost. The CompostMaster.i3d was clean but all of the effects .i3d’s contained file paths to the shader.xls that were pointing at a directory one level high than the one in which the shaders could actually be found. You see when I added these .i3d’s back in I added them to /NagceValley rather than /NagceValley/maps because /NagceValley is so much easier to find in the folder structure than /NagceValley/maps.
Now this is a perfectly legitimate move, or would have been if the .i3d’s formerly sitting in /NagceValley/maps which had previously been looking for their shaders in NagceValley/shaders weren’t now looking for their shaders in /oneFlightUpFromNagceValley/shader a location that didn’t exist and couldn’t have been reached even if it had. Once I figured out this little tid bit it was quite easy to point .i3d’s back in the right direction.
In the end though we were victorious the map size for Nagce Valley has been reduced to fewer than 800MB and the log is now error and warning free.