Editing DAT with hex editor?

  • Thread starter Thread starter ARMs
  • Start date Start date
Status
Not open for further replies.
A

ARMs

Guest
Instead of creating another thread I mgith as well ask it here since its related to the question earlier.

Ok so i manage to find the DAT file i was looking thanks to your Advice.   I'm reading the wikki's discriptions of the Fields DAT file, and in the script section I'm having trouble trying to figure out what it means under "Event Script Subsection." 

I managed to understand "Event Script" "Dialog Subsection" and "Akao blocks".   And i even managed to figure out where the Dialog section seperates from the event script.

So if anyone can spare some time could you explain how i can use the pointer table at the beganning of the file to determin where each script starts and ends?

I tried reading and reading it over and over but I can't make any sense out of it.   

I tried using the knowledge i learned about the Kernel, scene.bin, and text editing to figure this one out but this ones pointer is just wierd.
 
It could make for some interesting custom battle arena sets.
" Nope it would "

 It would be good to test custom battle models

 I wish you good luck on getting this done

 I would use it
 
Wow it's still too complicated for me to understands since thats a program.   

I suppose I should have mentioned that I did everything by using a hex editor.  I have nearly no knowledge of C++ or C or anyother programing language. 

In the other parts of FF7,  like kernel, scene.bin, text, etc.  it was easy since the pointers tell you how far you have to jump to get to the beganning of any script.   And the pointers was always 2 bytes.

In the field scripts DAT file its 4 bytes long.   And the last 2 bytes always seems to be the same.   Even if i ignore the last 2 bytes and only use the first 2 bytes.   It points me to areas that doesn't seem likes it the beganning.   

I just need to find a way to seperate the scripts.  Then i think i'll be able to figure nearly everything out with the information from the wikki. 


Well maybe i'm not making any sense.  I think the bolded area is the pointer.   Can someone tell me how to use this or make any sense out of it, or am I totally off and the pointers are located somewhere else?


Offset      0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

00000000   00 50 11 80 54 A7 11 80  8C B1 11 80 A4 F0 11 80   .P.€T§.€Œ±.€¤ð.€
00000010   DC F0 11 80 C0 F3 11 80  F0 F3 11 80 02 05 18 0F   ÃœÃ°.€Àó.€ðó.€....
00000020   9A 21 02 00 00 02 00 00  00 00 00 00 68 69 72 6F   Å¡!..........hiro
00000030   6B 69 00 00 63 6F 6C 6F  69 6E 31 00 64 69 63 00   ki..coloin1.dic.
00000040   00 00 00 00 63 6C 6F 75  64 00 00 00 65 61 72 69   ....cloud...eari
00000050   74 68 00 00 62 61 6C 6C  65 74 00 00 74 69 66 61   th..ballet..tifa
00000060   00 00 00 00 72 65 64 00  00 00 00 00 63 69 64 00   ....red.....cid.
00000070   00 00 00 00 79 75 66 69  00 00 00 00 63 61 69 74   ....yufi....cait
 
Last edited:
Hi, If you can recommend a good hex editor I can show you how to work your way around the scene file.
Im at work and there doesn't seem to be any good hex tools.
 
No, you're totally off, the script pointers come after the entity names (tifa, red, cid, yufi, cait in your example) and also any Akao pointers (4 bytes each, check "nExtraOffsets" on the wiki to found out how many there are) that may be after the entity names. Then you get "nEntities" lots of 32 two-byte pointers. These are your script pointers. Follwing the nEntities*32*2 bytes, the script immediately begins. That should be enough to get you going.

[Edit] If we could keep this thread on topic, or a mod could split into two topics, that would be good.  :-)
 
Do you have a link to the wiki page you read that from, as I didn't see it on the field page?
 
Thanks guys/gals!!!!!  alot easier to understand now.   Heh time for me to get to work and test the opcodes out.


Well I do have one more question.   How do i read this memory layout.   There is a small rectangle and a larger rectangle that is double the size.       The small rectangle should indicated that its only 1 byte long right.   And the large rectangle should be 2 bytes long.     So what does the [B1 / B2] stand for?

Opcode: 0x16
Short name: IFSW
Long name: If (Signed Word)

Memory layout
[ 0x16 ][ B1 / B2][           A         ][         V         ][   C   ][   E   ]
 
Last edited:
Thanks guys/gals!!!!!  alot easier to understand now.   Heh time for me to get to work and test the opcodes out.


Well I do have one more question.   How do i read this memory layout.   There is a small rectangle and a larger rectangle that is double the size.       The small rectangle should indicated that its only 1 byte long right.   And the large rectangle should be 2 bytes long.     So what does the [B1 / B2] stand for?

Opcode: 0x16
Short name: IFSW
Long name: If (Signed Word)

Memory layout
[ 0x16 ][ B1 / B2][           A         ][         V         ][   C   ][   E   ]
Click to expand...

            // Signed word conditional with byte relative jump
            case IFSW: // 0x16
            {
                u8  memory_bank_1 = GetU8(script_position + 1) >> 4;
                u8  memory_bank_2 = GetU8(script_position + 1) & 0x0F;
                u16 offset_1      = GetU16LE(script_position + 2);
                u16 offset_2      = GetU16LE(script_position + 4);
                s16 value1        = GAMESTATE->MemoryBankGet(memory_bank_1, offset_1);
                s16 value2        = GAMESTATE->MemoryBankGet(memory_bank_2, offset_2);
                u8  relation      = GetU8(script_position + 6);
                u8  jump          = GetU8(script_position + 7);

                bool result = false;
                switch (relation)
                {
                    case 0x00: result =  (value1 == value2);       break;
                    case 0x01: result =  (value1 != value2);       break;
                    case 0x02: result =  (value1 >  value2);       break;
                    case 0x03: result =  (value1 <  value2);       break;
                    case 0x04: result =  (value1 >= value2);       break;
                    case 0x05: result =  (value1 <= value2);       break;
                    case 0x06: result =  (value1 &  value2);       break;
                    case 0x07: result =  (value1 ^  value2);       break;
                    case 0x08: result =  (value1 |  value2);       break;
                    case 0x09: result =  (value1 & (1 << value2)); break;
                    case 0x0A: result = !(value1 & (1 << value2)); break;
                    default: LOGGER->Log(LOGGER_WARNING, "Strange relation: %02x", relation);
                }

                if (result != true)
                {
                    script_position += jump - 1;
                }

                if (CONFIG->m_DumpScript == true)
                {
                    LOGGER->Log(LOGGER_INFO, "%s(bank%02x[%04x] = %04x, bank%02x[%04x] = %04x, relation = %02x, jump = %04x)", opcodes_names[opcode].c_str(), memory_bank_1, offset_1, value1, memory_bank_2, offset_2, value2, relation, jump);
                }
            }
            break;
 
Thanks again.   I managed to understand what the first part of the file is now and I have no trouble navigating with the pointers now.  Even the scripts are beganning to make sense to me even though i wont be able to use some of the opcodes like 16 for a while.   I probably shouldn't be messing with the if codes anyways heh.

If I need more help i'll be sure to ask.

Edit:   Hi again I need alittle help once again.  Ok so I did some editing and I tried to compress it the file size is too big for me to put back in the PSX version.   I tried compressing the file before when I haven't modified any data and I still get the same problem.   My only hope now is try compressing with QHIMMLZS.DLL but I can't find it anywhere.   I couldn't find it here and I coudn't find it on google. 

Please help.
 
Last edited:
Hmmm i foudn something very interesting or wierd.    Ok I started with clean PSX DAT file.   I decompressed it with LZS 1.20.    When i compress the file the file size increases.  When i decompress the newly compressed file the new uncompressed file is also larger then the uncompressed original file.

The data appears to be the same except it adds an extra 14 bytes of 00's

This extra 14 bytes of 00's is somehow adding an extra 243 bytes of data when compress.   Theres no way those zeros could add that much of data when compressed so are there any programs out there that will compress the PSX version.   The PC version might have extra data that the PSX version is not using.
 
Last edited:
Status
Not open for further replies.
Back
Top