As some of you know, I'm working on a Dark Engine static model addon for Blender:
http://sourceforge.net/p/blenderbitsbobs/wiki/Dark%20Engine%20model%20importer-exporter/
The tool is still incomplete. This thread is for discussions of ways to improve it, update announcements, and bug reports.

Latest snag (resolved 15 May 2014)
One problem that I haven't been able to tackle for a long time is packing lighting normal vectors (the ones at the corners of polygons). In Dark Engine models, the three-component vector is crammed into four bytes (with a terrific loss of precision for anything other than zero, one, 0.5 and the like). For example, the 00 0c 00 00 sequence in a .bin would be 0.0, 0.0, -1.0 (straight down).
Here's what the leaked model header says about the compression format:

// Each element, x,y,z has 1 bit of sign, 1 bit of integer, and 8 bits
// of fraction, for 10 bytes total.  So the x, y, and z values of each
// lighting normal can be extracted in the following manner:
#define X_NORM(norm) ((short)((norm>>16)&0xFFC0))/16384.0
#define Y_NORM(norm) ((short)((norm>>6)&0xFFC0))/16384.0
#define Z_NORM(norm)  ((short)((norm<<4)&0xFFC0))/16384.0

This bit about light extraction doesn't extract enough to shed on how you actually pack three floats to get there. Previously, I tried using the leftmost bit in each component for the sign and the remaining nine bits for the absolute value (an integer on the 0 to 256 scale), like so:
def pack_light(xyz):
    result = 0
    shift = 22
    for f in xyz:
        sign = int(f < 0) * 512
        val = int(abs(f) * 256)
        result |= (sign + val) << shift
        shift -= 10
    return pack('<I', result)
This resulted in obvious shading artifacts (http://5.firepic.org/5/images/2014-02/21/h26n6fgntr52.png). Then I tried using two's complement values for negative components:
def pack_light2(xyz):
    result = 0
    shift = 22
    for f in xyz:
        fi = int(f * (511 + int(f < 0)))
        result |= (1024 * int(fi < 0) + fi) << shift
        shift -= 10
    return pack('<I', result)
And this is the current situation. The results are better, but the lighting is still weird on movable subobjects.
It turns out that the compression format is a strange mix of plain values (as written by the first snippet) and two's complement values (as written by the second one), often for the same vector. Worse still, the two's complement values are not necessarily used for negative components. Can someone here help me understand when to use which method (or suggest a better solution)?

In that model there are only two shared lighting normals, which are the same as the polygon normals in the absence of smoothing:

• (0.0, -1.0, 0.0) / bytes (LE): 00 00 30 00 / binary: 00000000001100000000000000000000 / dec: 3145728
• (0.0, 0.0, 1.0) / bytes (LE): 00 04 00 00 / binary: 00000000000000000000010000000000 / dec: 1024

Seems like looking at the part of the leaked source that actually uses the unpacked data would provide the best information on how to pack it.

Update 0.1.20140515
Resolved issues:

• The lighting normal packing method is closer to the original; this should mean fewer smoothing artifacts and differences from traditionally-processed models
• Lighting on child subobjects is no longer broken

(Yes, these turned out to be two separate bugs.)

Please re-export any enhancement pack models that you used this addon for.
Download: https://sourceforge.net/projects/blenderbitsbobs/files/

Well, I mimicked what I observed in the bsp output: 0 is 0.0, 1..256 goes up to 1.0, and 1023..768 goes down to -1.0. Wherever I looked, that seemed consistent.

I'm kinda sad, but it seems like I already found some bugs again.

1. When you look at the nori (the green square sticking out of the bowl) from the front it looks fine. But when you look at it from the back it doesn't turn the alpha channel invisible and you can see a fine grey line around it. It's kinda hard to see on this model but would be bothersome if you have something with a bigger invisible area on a texture.
I converted the model to a bin through bsp.exe and there it is rendered fine. (Included this one in the bugreport.zip under "bsp converted").

2. When I place an Empty/vhot it doesn't get the position where it was placed.
You can also see it in the picture. The blue circle is where ShockEd displays the vhot, but it should be in the middle of the bowl. And that's where it is on the blend file.

I tested it out and the vhots are working properly now.
Thanks for the quick update!

I tried to reproduce the same error again I get with the transparent issue.
Strange thing. I made a new model and just created some similiar scenario in many different ways and never get something like that. I can only reproduce it with the noodle bowl model.
I'll be trying around a bit more tomorrow.

I tried messing around a bit with it again to get rid of this bug or do some workaround. Now something really strange happened. Maybe it will help you out with something.

Whether it will be rendered correctly is somehow dependent of the angle you look at it.
I tried adding sharp edges or seperating it into different objects, but nothing helped.

This object has no need for it.

You certainly don't see the importance of nori!

That being said, have you tried adding Renderer/Transparency (alpha):1 to it?

I don't even get what you mean.

yeah, careful with that - editor transparency is not the same as ingame transparency, learned that the hard way when trying to do something about those trams.

I started up ShockEd and then went into game mode.
Don't know how else to test things as I have very limited knowledge about editing levels or game related stuff.

Update 0.1.20140527
Fixed a bug where import crashed due to incorrect material parsing.
https://sourceforge.net/projects/blenderbitsbobs/files/