the dashstructure and dashpad are usually misscaled, seems like the dashpad is following the steeringwheel scale wrong position/scaling is a known issue for moveable parts. Didn't know about the dash, but I consider it as a minor issue (as for the moveable parts I can't change it atm). and dashstru...

I'm not familiar with the PS2 savestates, what they contain exactly. I'm surprised that they contain textures and part of a level (arena) because for PC savegames the senseful philosophy is to save only changes of states (this is what PS2 save states claims to be but seems it isn't?). So I'd expect ...

if the header itself is read in as a float wouldn't that cause the resulting vertex coordinates to be one off would spoil things, yes. Just read 11 vertices per block after the 4 bytes header and you're fine. So the vertices are not so bad (displaying 11 verts per block you can even see two steps, ...

it just means that I logged 33 floats (11 vertices) starting 4 bytes after each pattern find address (1523 vertices) ah, ok, re-read your posts, seems I misunderstood your problem. Why exactly did you stick to a general search again after having performed a more specific one. Wouldn't it make more s...

I think the uvmaps are ok (BMW_i8_15, exterior), more or less, it's a matter of manually inserting grouping lines so far: (updated sig to -q1, which inserts (modulo 1000) grouping lines)

for the vertices shown by your script there's a more selective way to find them:
search for 0480xx68 (xx being a wildcard) in eeMemory.bin, there's 1523 finds.
After find address +4 log 11*3 floats each (11 vertices).

depends on what your extractor extracted. Did it create 70 TIM2 files? If the extracted files in sum + 5 MB + 7 MB = 32 MB (=size of eeMemory.bin ) I'd say: no. (but that formulae is only applicable for uncompressed data) Did you read here, for example? http://forum.xentax.com/viewtopic.php?f=10&...

thx; so your'e at the very beginning.
Why not split the eeMemory.bin into smaller parts and treating them seperately?

There's blocks of zeroes at 0x990BB0 to 0xE78360 (5 MB), another at 0x016E1280 to 0x01DC1300 (7 MB).

There's 70(?) TIM2 textures contained. Maybe identify/cut them first?

, but is your tool can see mesh is lod, or no? obviously: "no" j version merge lods in this lamborghini like: glass (3 lods), body_a (one lod) and in some meshes like bumpers, hood, trunk, lods contains parts of lod0 meshes. -j uses a brute force algorithm, as already mentioned several ti...

you mean body_a_4?
If so, my fears come true: qsort merges the lods?

I'm sorry to say, that I don't have a clue how to fix that other than using previous versions of the exe (-gc, -j).
Reason is that the different algos are incompatible, i.e. I can't "mix" them.

well, long story short: quicksort seems to be the solution. (now, it wasn't! see version j2 and ignore this post) I thought of quicksorting the faceindices from the very beginning but for some unknown reason I feared there'd be a reason for their scrambling and Qsort would spoil erverything. gosh, i...

thx, but I don't have that bin file.

(used with eeMemory.bin the script fails:
"struct.error: unpack requires a bytes object of length 4")

wow, I'd really like to have that car (I mean when it's complete :D ) btw: meanwhile I found that I already had a "solution" for the problem but the code line was commented out because it led to an infinite loop. :cry: (I placed the 'g missing' line manually) gosh; I've solved it (too ridi...

ok, then, did you try the Bad Company 2 import script with a BC2 sample successfully?
If so, then 1) how did you get it work?
and 2) could you provide a BC2 sample?

But last part of LODS0 (for carpaint material) merged with some polys from first part of LOD1 (black/invisible): yeah, that's a known bug I forgot to fix. :D (to be honest, I didn't know WHY the algo missed it because it clearly should be able to "see" the delta of (1128-22356= -21228) be...