[10:45:57] <Dominus> marzo, wjp, apparently Exult still runs on Windows NT 3.51 :) http://www.vogons.org/viewtopic.php?f=31&t=52094&p=557755&hilit=exult#p557755
[12:40:42] <Dominus> marzo, I'm struggling again with u7chunks. Did we change the file structure at some point? Old mods seem to have the 8 byte header you mentioned last month (and probably consist of the 768 bytes. While new u7chunks saved with ES have no header and and consist of 512 bytes
[12:41:18] <Marzo> It depends on whether the chunk needs a shape >= 1024 or a frame >= 64 (or was it 32?)
[12:43:13] <Dominus> Ok, so if that is a case the u7chunks file switches to 8bytes header and 768 bytes per chunk? (or is the header something no longer done?)
[12:49:27] <Dominus> Marzo, could it be that it is a 10 bytes header? Because then the u7chunk files with 768 bytes fit
[12:50:30] <Marzo> I'd have to check, but I do remember that Exult switches from using 2 bytes for (shape, frame) to using 2 bytes for shape and 1 byte for frame
[12:57:36] <Marzo> Dominus: If first 10 bytes of chunk file are these: 0xff, 0xff, 0xff, 0xff, 'exlt', 0, 0
[12:57:54] <Marzo> Then it is a Exult chunk with 2 bytes for shape and 1 byte for frame
[12:58:38] <Marzo> There are 256 (=16*16) such sequences coming after the 10-byte header
[12:59:06] <Dominus> thanks that makes sense
[12:59:07] <Marzo> If the first 10 bytes are *not* equal to that, then it is a regular chunk with 2 bytes per entry, with no header
[13:00:36] <Dominus> thanks, I stumbled over that when I wanted to write an advanced guide for restoring u7chunks files but stumbled over different u7chunks files on my first test with another mod :)
[16:17:18] <Dominus> Marzo: http://pastebin.com/khBULkcA <- a bit of explaining hex editing of u7chunks - I will have to verify which frame count triggers the larger u7chunks file
[21:39:37] <Marzo> Dominus: I think it it frames > 63 because the high bit is used for flipping NS with WE
[21:44:45] <Marzo> Dominus: also, with stock chunk format, it is first byte shape (low 8 bytes), second byte shape and frame (low 2 bits = 2 top bits of shape, the rest is frame shifted up by 2)
[22:11:29] <Dominus> Thanks Marzo, I will need to experiment a bit with hex editing to understand what the second byte does (you ARE telling me, I just don't understand it and will need to see to completely understand)
[22:13:10] <Marzo> Dominus: basically, it goes like this: in the second byte, the top hex digit is entirely for the frame; the bottom hex digit is half for frame (the top half) and half for shape (the bottom half)
[22:13:43] <Marzo> You divide the second byte by 4 to get the frame number, or get the remainder of division by 4 for shape
[22:14:06] <Marzo> To combine with the other shape byte, you multiply it by 256 (0xFF) and add