No, no, and no on the shield problem. I just converted a tetrahedron and looked at the shield chunk output. The vertices are fine. The faces get their normals converted correctly, I think, (I'm not computing those by hand today) but the game treats that ok and even if it were wrong you wouldn't get a crash. Furthermore, because this defines the shield geometry, it shows up fine in editing programs. However, the last little detail, the three neighboring shield faces, is seriously wrong. For my sample tetrahedron, I got the following for the four faces (in decimal, for the sake of clarity):
Face 0: Neighboring faces [5280,5520,0]
Face 1: Neighboring faces [0,0,0]
Face 2: Neighboring faces [0,0,0]
Face 3: Neighboring faces [0,0,0]
Now, obviously 1, 2, and 3 should be something other than all zero, but at least here we're looking at a valid index. Unfortunately, index 5280 from face 0 is not only out of the range of the shield face index, and out of the shield chunk, it is out of the file. Now I could be misinterpreting this, but I think that's the problem.
EDIT: Omni, your "shields always render on the opposite side" is probably one of two things. It could be that your shield mesh is getting inverted. I assume that you are reseting X-form on the shield as well, and that you check it after the fact to make sure it's not inward-facing rather than outward-facing. Alternatively, you could be seeing this neighboring faces bug in a non-crash situation; in the case above, a shield shot on face 1 would cause the edges (all three edges) of the shield-hit animation to render on face 0. Since we've got impact effects and the shield is generally hard to see under the laser anyway, this may make it look like the animation is playing in the wrong place. At least, that's how I think it works.