Melee Arcive Viewer (MAV) in development project.

[Tcll]

here is a little something I've been re-doing:

import struct as S
off = open("import.dat", 'r')
out = open("export.obj", 'w')
t0 = off.read(32)#header
a = 0
while (a == 0):
    h1 = off.read(2).encode('hex')
    h2 = off.read(2).encode('hex')
    h3 = off.read(2).encode('hex')
 
    #this returns the hault error as a value
    #and can be deleted after it is fixed
    if (h1 == ''):
        h1 = '00'
    if (h2 == ''):
        h2 = '00'
    if (h3 == ''):
        h3 = '00'
 
    c = S.pack("<HHH", int(h1, 16), int(h2, 16), int(h3, 16))
    c = S.unpack("<hhh", c)
    x = float(c[0]) * 0.01
    y = float(c[1]) * 0.01
    z = float(c[2]) * 0.01
    v = "v "+x.__str__()+" "+y.__str__()+" "+z.__str__()
    if (v == 'v 0.0 0.0 0.0'):
        a = 1
        out.close()
    else:
        print v
        out.write(v+"\n")

it takes the raw data from the dat file and converts it from there.
instead of taking the hex values from a txt file...

there is a bug however...
when you run the program, it will only convert so much before ending the conversion process...

if anyone knows what I'm missing..., please help.

[revel8n]

Models are free to have a vertex at (0,0,0) so that is not a reliable check. Is there a way yo break out of a loop early in python? The check for a null return from the read calls is far more accurate in telling when you have reached the end of the file. So if any of the '' checks pass you are at the end of the file can exit the loop. Probably want to check before even attempting the encode calls at that.

[Tcll]

well... thanx for letting me know that...

but during the conversion process,
there's not enough data converted before it reaches the 0 loop

ther's alot more data converted from the txt file

with his there's only about 1/8th of that data converted.
thus the name "The HAULT Error"
it haults at a certain point somewhere at the beginning of the vertex data

I need some help here...

[Milun]

Oh, also, make sure you are treating values as signed when necessary.

To take an example from Milun's page:
(F5 50 becomes 62800) as unsigned is very different when compared to
(F5 50 becomes -2736) when treated as a signed value.

Sorry for my late answer (time zones), but my particular '-256...' equation was for the occasion on which you would convert F5 50 separately, so the final value would be:

F5.50 or 245.(1/256)*80 when converted.

I don't know if you've already solved this, so disregard my post if that's the case, also sorry that I can't be much help in the programming. The best I could do to help is to send you my god awful Game Maker (don't laugh) file that converts the hex to dec (btw I fixed the bad placement of the points in this version). So if you want the file, just say and I'll upload it.

Oh, and with your check with the 0's, my advice would be to look for an occurrence of 00 00 00 00 00 00 00 00 00 00 00 00 (2 vert's in 0,0,0). I've never encountered a time where there were two points in that location, so it could work.

Oh, and I've noticed a little something when hacking actual Pl.dat's: The edges are separated constantly.

For instance, if Jigglypuff has 1300 vertices, there will be a section of hex for faces, but it will only connect vertices 1 - 54, then another section of codes (seperated from the previous one with a heap of 00's) that goes from vertice 1 - 48. My best guess, is that where the model vertice hex is stored, vertice's 1 - 54 are one object, then vertices 55 - 102 (54+48) are another. Don't qoute me on this, I have no proof, and the figures I used aren't really in Jigg's hex.

[Tcll]

that's still not what I ment by the 0 loop...

here's what I ment:

v -1.92 31.36 -1.28
v 62.08 120.96 -3.84
v 81.28 41.6 -1.28
v -66.56 27.2 -1.28
v 42.56 58.88 2.56
v -5.12 57.28 1.28
v -34.24 21.44 0.0
v -4.8 1.28 -0.96
v -0.64 -1.6 0.96
v 42.24 33.6 -18.88
v -0.96 22.72 0.32
v 75.52 28.16 -18.24
v -71.04 5.44 42.56
v 0.0 17.92 88.0
v 71.04 5.44 42.56
v -56.0 6.08 -54.4
v -78.4 5.12 -17.6
v 0.0 3.52 -69.76
v 56.0 6.08 -54.4
v 78.4 5.12 -17.6
v 19.2 13.12 11.52
v 17.92 -0.32 17.6
v 14.72 -12.8 8.0
v 13.44 -9.28 -8.0
v 16.0 8.0 -10.88
v 18.56 16.0 -2.24
v 13.12 -1.92 8.96
v 8.0 -0.32 0.64
v 7.36 -5.12 -0.32
v 13.44 8.0 6.72
v 12.8 -8.96 3.52
v 13.76 9.92 -1.28
v 12.48 -6.72 -5.76
v 12.8 6.4 -4.16
v 12.8 3.52 -8.32
v 6.72 -2.56 2.24
v 11.2 6.08 0.0
v 11.84 -7.04 -8.0
v 6.08 -9.28 1.28
v 11.2 -8.32 -0.64
v -49.6 -32.0 -54.08
v -77.76 -11.2 -5.76
v 16.0 12.8 -17.28
v 20.48 16.96 3.52
v 49.6 -32.0 -54.08
v 0.0 -27.52 -65.6
v -56.96 -33.92 43.84
v -9.6 -39.68 25.92
v 20.48 16.96 -3.52
v 16.0 13.12 16.96
v 9.6 -39.68 25.92
v 0.0 -39.68 74.56
v 0.0 12.48 87.68
v -6.4 16.32 85.44
v 0.0 18.24 84.8
v 0.0 22.4 75.84
v -40.64 5.12 76.16
v -43.84 -23.68 52.8
v -41.28 -2.56 58.88
v -66.56 -14.72 39.04
v -43.2 -21.76 62.72
v -43.84 54.08 -26.88
v -29.44 76.8 -0.96
v -53.44 58.56 17.92
v -30.4 75.2 21.76
v -19.52 73.6 39.36
v -62.4 -20.8 30.72
v -72.64 -16.32 -5.76
v -59.84 7.68 45.12
v -65.28 0.96 28.48
v -46.4 56.32 49.6
v -50.24 17.28 65.28
v -64.64 28.48 3.84
v 6.4 16.32 85.44
v 40.64 5.12 76.16
v 0.0 72.96 43.84
v 0.0 80.0 23.68
v 0.0 0.0 0.0
v 0.0 0.0 0.0
v 0.0 0.0 0.0
v 0.0 0.0 0.0
v 0.0 0.0 0.0
v 0.0 0.0 0.0
v 0.0 0.0 0.0
...
v 0.0 0.0 0.0
v 0.0 0.0 0.0

there's not nearly enough converted data here.
but what is converted works perfectly.

and yes..., this is straight from the dat file.

and the main reason for the 0 loop is well...
the original char is blank..., so I replaced the blank with '00' (0 loop)
so yea you could basically say I made the 0 loop
but it comes after the hault error (when conversion comes to a hault)

[Tcll]

I've made a little bit of code here that you can play with:

import struct as S
off = open("import.dat", 'rb') #'r') bugfix :P
out = open("export.obj", 'w')
t0 = off.read(32)#header
 
switch = 1 #flip this to display hex data
 
a = 0
while (a == 0):
    h1 = off.read(2).encode('hex')
    h2 = off.read(2).encode('hex')
    h3 = off.read(2).encode('hex')
 
    h = S.pack("<HHH", int(h1, 16), int(h2, 16), int(h3, 16))
    h = S.unpack("<hhh", h)
    x = float(h[0]) * 0.01
    y = float(h[1]) * 0.01
    z = float(h[2]) * 0.01
    if (switch == 1):
        v = "v "+x.__str__()+" "+y.__str__()+" "+z.__str__()
    else:
        v = h1+" "+h2+" "+h3
 
    """
    if (v == 'v 0.0 0.0 0.0'):
        a = 1
        out.close()
    else:
        print v
        out.write(v+"\n")
    """
 
    print v
    out.write(v+"\n")

this includes a switch which displays between the hex or the converted decimal

[Tcll]

hey Milun...
IDK for sure...
but I was looking at your page and well...

that hex you found...
(the distrbed group of '00' with the occational row of 'FF')

I'm thinking that might be the V-Group data.
if not..., then my 2nd guess would have to be bone data.

[revel8n]

Oops. that may be my fault, heh. Forgot i changed things to read in text mode when i was messing with the python code. Not sure if this is it but change the open mode from 'r' back to 'rb'. Didn't fully understand what you were talking about earlier, so hopefully this might help. Though i am not even sure if that would make a difference in python. i will try out the code in a little bit. i am making some finding on my end, will have to see where they lead.

[Tcll]

so that's the differance between 'r' and 'rb'...
KK I think I get it

again amature here...
but yea it worked perfectly

and it was probably my fault for not pointing you in the right direction earlier...

[Tcll]

I wanted to mention something too...

in brawl:
the animation is in a separate file...
FitCharname00.pac = model
FitCharnameMotion.pac = animation

well...
Melee has the same thing.
Pl**Nr.dat = model
IDK what the anamation data is named...