Reply to Funny someone brang it up...
If you don't have an account, just leave the password field blank.
I'm working on a FAQ right now...more like a tutorial for the format of the files, but I have to hex edit some more of mapp.dat to relearn the file format. Here is what I have so far.
____FAQ_____
Ultimate Dink File Faq
First off, this is written based on my experiences working on WinDinkEdit and with the files itself. Some things could be slightly wrong (as in I wasn¡¦t involved in the makings of dink). If you find any problems or errors, please e-mail with (WC@rpgplanet.com ) with the corrections.
-=HARD.DAT=-
Description: Hard.dat is a simple file that basically stores the hardness of the tiles and nothing more, here is the format.
Format: Basically it just lists all the hard tiles (which there are 800 slots) with 58 bytes of useless data between them.
<TILE><JUNK><TILE>¡Kect
Each tile is 2550 bytes big, but with 50x50 pixels of hardness how do we get that size, Simple.
SAMPLE TILE
X = hardness
1¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K..50
1: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
3: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.
.
.
51: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
As you can see the last row consists of nothing but junk data (dang seth) since there are 50x51(width x height) and it¡¦s supposed to be 50x50. The 50x51 equals 2550 exactly, but you will have to kill that last row of junk data.
Now each ¡¥X¡¦ has a value, and this value determines the type of hardness, here is a quick chat for you.
0 = no hardness
1 = Normal hardness (fireballs can¡¦t ¡¥fly¡¦ over it)
2 = Low Hardness (like water that fireballs CAN ¡¥fly¡¦ over)
3 = Unknown hardness
To answer you question, no one knows what #3 hardness is for.
That¡¦s it for hard.dat, I hope you learned something
-=DINK.DAT=-
Description: Dink.dat is basically a file that stores which screens ¡¥exist¡¦ and their properties. However it does have a rather complicated format, so listen carefully.
Format: First there is 24 bytes of worthless data; this may have been something that Seth wanted to add for a future ¡¥feature¡¦, who knows, all I know is it says ¡¥smallwood¡¦ ƒº.
<24 bytes of crap>
ok, now looking at it the next part it is actually the ¡¥screen order¡¦ in which the screen exist or not exist. If the screen does not exist, it will be 0, if not, it will be the screen ¡¥order number¡¦ which makes no sense. Lets take a look, right now we are going to pretend we have 4 screens (#1-4) and #3 does not exist, here is what the file would look like in the value of the bytes.
1203
screen 1 = 1
screen 2 = 2
screen 3 = 0
screen 4 = 3
Since screen 3 was null, screen 4 was the next in the order and has the value of ¡¥3¡¦¡Kweird eh?
After reading all the screens which should be 768 bytes total (1 byte for each screen) we come across yet more junk data which is 4 bytes big (oh the joy).
<JUNK>
now, looking at the next section we come across the ¡¥midi number¡¦ which is the midi that plays on that screen (0 being no midi on screen, and anything else of a positive value being the midi). Again, the size of this ¡¥block¡¦ is 768 bytes (768 being the number of screens, and 1 byte per screen). But yet again we run into 4 bytes of worthless data.
<JUNK>
Yet again, we find another block of 768 bytes of data¡Khumm now what can this be? This is (if you haven¡¦t guessed) the ¡¥indoor¡¦ status (if you don¡¦t know what this is, I can¡¦t help you), and basically 0 = outdoor, 1 = indoor (or cave). Guess what, that¡¦s the whole file right there, congrats, but it gets harder in map.dat ƒº
-=MAP.DAT=-
Description: Stores the sprite, tile, and tile hardness info for the screen, it¡¦s basically the monster of the files, and the most important, it¡¦s the bulk of the map.
Format: It lists the entire screen (which I will cover in a second) and each screen is 31280 bytes in size. This is why the complicated format of dink.dat comes in handy, because if the screen does not exist, Seth doesn¡¦t write/read it therefore decreasing the file size.
The Screen
Here is the format of the screen and how it is setup
<20 bytes junk data>
<TILES> (which is 8x12, height x width)
<TILE HARDNESS> (same as above, but the hardness)
<540 bytes of junk data>
<SPRITES> (100 of them)
<BASE SCRIPT> (Size of 21 bytes)
<1090 bytes of junk data>
--WC
____FAQ_____
Ultimate Dink File Faq
First off, this is written based on my experiences working on WinDinkEdit and with the files itself. Some things could be slightly wrong (as in I wasn¡¦t involved in the makings of dink). If you find any problems or errors, please e-mail with (WC@rpgplanet.com ) with the corrections.
-=HARD.DAT=-
Description: Hard.dat is a simple file that basically stores the hardness of the tiles and nothing more, here is the format.
Format: Basically it just lists all the hard tiles (which there are 800 slots) with 58 bytes of useless data between them.
<TILE><JUNK><TILE>¡Kect
Each tile is 2550 bytes big, but with 50x50 pixels of hardness how do we get that size, Simple.
SAMPLE TILE
X = hardness
1¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K¡K..50
1: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
3: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.
.
.
51: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
As you can see the last row consists of nothing but junk data (dang seth) since there are 50x51(width x height) and it¡¦s supposed to be 50x50. The 50x51 equals 2550 exactly, but you will have to kill that last row of junk data.
Now each ¡¥X¡¦ has a value, and this value determines the type of hardness, here is a quick chat for you.
0 = no hardness
1 = Normal hardness (fireballs can¡¦t ¡¥fly¡¦ over it)
2 = Low Hardness (like water that fireballs CAN ¡¥fly¡¦ over)
3 = Unknown hardness
To answer you question, no one knows what #3 hardness is for.
That¡¦s it for hard.dat, I hope you learned something
-=DINK.DAT=-
Description: Dink.dat is basically a file that stores which screens ¡¥exist¡¦ and their properties. However it does have a rather complicated format, so listen carefully.
Format: First there is 24 bytes of worthless data; this may have been something that Seth wanted to add for a future ¡¥feature¡¦, who knows, all I know is it says ¡¥smallwood¡¦ ƒº.
<24 bytes of crap>
ok, now looking at it the next part it is actually the ¡¥screen order¡¦ in which the screen exist or not exist. If the screen does not exist, it will be 0, if not, it will be the screen ¡¥order number¡¦ which makes no sense. Lets take a look, right now we are going to pretend we have 4 screens (#1-4) and #3 does not exist, here is what the file would look like in the value of the bytes.
1203
screen 1 = 1
screen 2 = 2
screen 3 = 0
screen 4 = 3
Since screen 3 was null, screen 4 was the next in the order and has the value of ¡¥3¡¦¡Kweird eh?
After reading all the screens which should be 768 bytes total (1 byte for each screen) we come across yet more junk data which is 4 bytes big (oh the joy).
<JUNK>
now, looking at the next section we come across the ¡¥midi number¡¦ which is the midi that plays on that screen (0 being no midi on screen, and anything else of a positive value being the midi). Again, the size of this ¡¥block¡¦ is 768 bytes (768 being the number of screens, and 1 byte per screen). But yet again we run into 4 bytes of worthless data.
<JUNK>
Yet again, we find another block of 768 bytes of data¡Khumm now what can this be? This is (if you haven¡¦t guessed) the ¡¥indoor¡¦ status (if you don¡¦t know what this is, I can¡¦t help you), and basically 0 = outdoor, 1 = indoor (or cave). Guess what, that¡¦s the whole file right there, congrats, but it gets harder in map.dat ƒº
-=MAP.DAT=-
Description: Stores the sprite, tile, and tile hardness info for the screen, it¡¦s basically the monster of the files, and the most important, it¡¦s the bulk of the map.
Format: It lists the entire screen (which I will cover in a second) and each screen is 31280 bytes in size. This is why the complicated format of dink.dat comes in handy, because if the screen does not exist, Seth doesn¡¦t write/read it therefore decreasing the file size.
The Screen
Here is the format of the screen and how it is setup
<20 bytes junk data>
<TILES> (which is 8x12, height x width)
<TILE HARDNESS> (same as above, but the hardness)
<540 bytes of junk data>
<SPRITES> (100 of them)
<BASE SCRIPT> (Size of 21 bytes)
<1090 bytes of junk data>
--WC
