Export gremlins and shader.xml’s on the lamb

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.

BulletBill saves the day!

Map mods are rarely, if ever, solo projects. All of the maps assets, the tree's, barn's, roads, fences, silos, etc. come from other sources. There are a few map makers that create some of their own assets but by and large we are reliant on the work of others. There are a number of sources for finding assets for a map. Giants is one and assets are often pulled from one or more of the Giants maps. A second source is to pull assets from another map mod. A third source is when the asset creator uploads the asset to a mod portal. Often they do so as a placeable mod so that anyone can add the asset to their map without needing the gIants editor to do so..

One of the placeables that's making its way into a lot of maps is Dorsets's Animated Seven Bar Galvanized Gates. Dorset did a bang up job with these gates which is one of the reasons they are so popular, but the fact that he uploaded them as placeables means a bit of extra work needs to be done when importing them into a map through GE. I won't go into details here but I will post a link at the bottom of the post to a thread on FSUK that describes how to do so. 

The other day when I was discussing my problems with the additionalMapTypes script I mentioned there were no errors in my log file. Well that wasn't quite true, there were errors, just not ones I felt were related to the crop problem. There were however error relating to the way I had implemented Dorset's gates into my map. The gates all functioned correctly but when I reviewed the log I found the following error 

Error: Adding onCreate loaded object with duplicate saveId AnimatedObject_visable_gate

I knew why I was getting the error but was surprised to see it as I thought I'd taken the proper precautions to avoid it. I reviewed my .xml and everything looked right to me. I even tried deleting my code and re entering it but the errors persisted. The issue can come about when adding more than one gate to the map. What needs to be done to prevent the error is that each gates needs a unique name. So instead of three gates all named  sevenbar_gate_RH you need to name them something like sevenbar_gate_RH_01, sevenbar_gate_RH02, and sevenbar_gate_RH03. Which is what I had done and why I couldn't understand why I was getting the error.

As much as I like to solve my own problems there comes a time when you need to turn to those who really know what they're doing for help. So I posted my problem on the FSUK modding help forum and as luck would have it BulletBill83 (creator of Coldborough Park Farm) spotted my error and in short order provided me with a work around. Here's what it was, I had in fact given each gate a unique name, just not in all of the places I needed to. 

Massive thanks to BulletBill83 for helping out the new guy!

This brings me to my final point, the importance of checking the error log on a regular basis. Those errors had likely been there for a couple of weeks. The gates were working and I hadn't bothered to check the log in quite a while. I got lucky here as it was a relatively easy fix that didn't break anything else. I wouldn't be so lucky if fixing the error meant losing a week's worth of work just because I didn't check the error log consistently. 

 

Link to thread on implementing Dorsets gates with Giant Editor

Link to thread where Bill saves the day