The Dink Network

dink map specs sheet?

December 1st 2002, 02:53 AM
stonegiant.gif


Hey,

It'd be extreemly usefull to me if someone would write a detailed documenat about how the dink map file works (dink.dat). I can open it, and read all teh values, but i have no idea how they work, or what they stand for. a pointer would be really usefull. the WDE source code has a bit, but i must admit, my MSVC skills are next to nothing (for obvious reasons, i think?)

anyone willing?
December 1st 2002, 05:04 AM
wizardb.gif
Kyle
Peasant He/Him Belgium
 
December 1st 2002, 05:22 AM
pq_skull.gif
NO TEXT LADIEZ! Hold on, THERE IS TEXT! THIS MUST BE A CONSPIRACY!
December 1st 2002, 07:33 AM
custom_king.png
redink1
King He/Him United States bloop
A mother ducking wizard 
: Hey,

: It'd be extreemly usefull to me if someone would write a detailed documenat about how the dink map file works (dink.dat). I can open it, and read all teh values, but i have no idea how they work, or what they stand for. a pointer would be really usefull. the WDE source code has a bit, but i must admit, my MSVC skills are next to nothing (for obvious reasons, i think?)

: anyone willing?

Eh... just open it up, use a hex editor, and reverse engineer it. That is what I did for Map.dat and Hard.dat.

The actual Map file is stored in Map.dat anyway...

Hmm... I do have some documentation I wrote up for Paul, in order to motivate him to create Sprite Replacer... I suppose I could paste that here. Some of it might not make the most sense, as it was written for Paul. I might also have some stuff on Hard.dat around...

=-=-=-=-=-=-=-=-=-=-=-=-=-

MAP.DAT: SPRITES

=-=-=-=-=-=-=-=-=-=-=-=-=-

All of this was done by hex-editing and guessing, not talking to Gary or Seth about it, so certain things might not be right. Well, Gary did say there are several un-used variables like rotation and gold amount when he was working on WDE (Seth gave him some of the DinkEdit code to help him make it)... anyway, here is what I've found:



Each map square seems to take up exactly 31280 bytes of map.dat. Of those 31280 bytes, I don't know what the the first 8240 do (not sprites at least). Sprite data starts right after that mysterious 8240 chunk. Each sprite takes up 220 bytes. assuming that the 99 sprite rule is correct, the sprite data is between 8240 and 30020 of the map square. I'm not sure what goes on between 30020 and 31280, maybe tiles, haven't bothered to test yet.



In each 220 byte sprite, most variables seem to take up 4 bytes, with the major exception being the script name, which takes up at least 13 bytes (WDE limits you to this, for reasons I'm not sure. The actual limit seems to be 56 bytes). Maybe Seth left some extra room for directory names and the like.



Note the attached pictures (one being the WDE box that I used, the other being a peek at the map.dat data for that sprite).



(0-3) 2C 01 00 00 is X. (2*16^1 + 12*16^0 + 0*16^3 + 1*16^2) is 300

(4-7) C9 00 00 00 is Y (12*16^1 + 9*16^0) is 201

(8-11) CA 00 00 00 = 202, Sequence

(12-15) 03 00 00 00 = 3, Frame

(16-19) 01 00 00 00 = 1, Type (Background, Person, Invisible)

(20-23) DB 00 00 00 = 219, Size

(24-27) 01 00 00 00 = 1,

(28-31) 00 00 00 00 = 0

(32-35) 00 00 00 00 = 0

(36-39) 0F 00 00 00 = 15, Brain

(40-91) Script? Perhaps some unused variables after it.

(92-95) DA 00 00 00 = 218, Speed

(96-99) CD 00 00 00 = 205, Base Walk

(100-103) CC 00 00 00 = 204, Base Idle

(104-107) CE 00 00 00 = 206, Base Attack

(108-111) 00 00 00 00 = 0

(112-115) D5 00 00 00 = 213, Timing/Delay

(116-119) D0 00 00 00 = 208, Depth Que

(120-123) 01 00 00 00 = 1, Hardness

(124-127) 00 00 00 00 = 0

(128-131) 00 00 00 00 = 0

(132-135) 00 00 00 00 = 0

(136-139) 00 00 00 00 = 0

(140-143) 00 00 00 00 = 0, Enable Warp

(144-147) DC 00 00 00 = 220, Warp Screen

(148-151) DD 00 00 00 = 221, Warp X

(152-155) DE 00 00 00 = 222, Warp Y

(156-159) D2 00 00 00 = 210, Touch Seq

(160-163) CF 00 00 00 = 207, Base Death

(164-167) 00 00 00 00 = 0

(168-171) D9 00 00 00 = 217, Hitpoints

(172-175) 00 00 00 00 = 0

(176-179) D8 00 00 00 = 216, Defense

(180-183) D6 00 00 00 = 214, Experience

(184-187) D3 00 00 00 = 211, Sound

(188-191) D4 00 00 00 = 212, Vision

(192-195) 00 00 00 00 = 0, Nohit

(196-199) D1 00 00 00 = 209, Touch Damage

(200-220) unused.



That covers all of the parameters available in WinDinkedit... and I think thats all thats available in DinkEdit as well (not sure though).



Negative numbers are a bit... odd. I forgot how they usually work in hexadecimal, but they just seem weird here. Anyway:



-1 is FF FF FF FF

-2 is FE FF FF FF

-340 is AC FE FF FF



And so on. Maybe not that weird after all...



To get the Nohit, Hard and the like, I toggled them on and off and compared the new map.dat with an old copy.



There seems to be an awful lot of unused areas, but Gary did mention that there were a lot. And it is odd how Seth used integers for boolean-level operations (nohit and hardness). Heh, he really was a sloppy programmer



Oh, and it doesn't look like there is a variable for the editor number (or at least I didn't find one). Its probably determined by its order in the file.

-=-=-=-=-=-=-=-=-=-=-=-=-

Hmm, it appears I don't have any hard.dat documentation after all... all I have is a Perl program that converts the hard.dat file into a text file and bmp, and then back from a text file and bmp to the hard.dat. No documentation though...
December 1st 2002, 10:25 AM
wizardg.gif
Paul
Peasant He/Him United States
 
A couple additions:

(24-27) is what actually stores whether a sprite exists (1 if yes, 0 if no). So if you delete a sprite in DinkEdit (or the current verion of WinDinkedit I think) that sprite just has that number set to zero.

And that last one "(200-220) unused." should say "(200-219) unused." since the first number is 0.

I can supply Sprite replacer source code to anyone who wants it but since it only deals with sprites is less complete than the WDE source I'm sure.
December 1st 2002, 07:29 PM
knightg.gif
WC
Peasant He/Him United States
Destroying noobs since 1999. 
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
December 1st 2002, 10:11 PM
wizardg.gif
Paul
Peasant He/Him United States
 
You've got some wierd crap in there, are you pasting out of Word or something?
December 1st 2002, 10:29 PM
wizard.gif
Chrispy
Peasant He/Him Canada
I'm a man, but I can change, if I have to.I guess. 
It's H4X0R gone wrong...

December 2nd 2002, 01:39 AM
fish.gif
: -=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

If what you said were the whole truth of hard.dat, how do you assign a hardness number (0 to 799; or 1 to 800 in WDE) to a certain tile square? (I believed redink1 has the answer. )
December 2nd 2002, 02:12 AM
stonegiant.gif
: A couple additions:

: (24-27) is what actually stores whether a sprite exists (1 if yes, 0 if no). So if you delete a sprite in DinkEdit (or the current verion of WinDinkedit I think) that sprite just has that number set to zero.

: And that last one "(200-220) unused." should say "(200-219) unused." since the first number is 0.

: I can supply Sprite replacer source code to anyone who wants it but since it only deals with sprites is less complete than the WDE source I'm sure.

yes please! I'm sure it wuld be very usefull. could you please email it to me??

thomi@imail.net.nz

December 2nd 2002, 02:17 AM
stonegiant.gif
:seem weird here. Anyway:

: -1 is FF FF FF FF

: -2 is FE FF FF FF

: -340 is AC FE FF FF

: And so on. Maybe not that weird after all...

ummm... remember two's compliment?? convert the hex numbers to binary, if the lefthand digit is a 1, it's negative, but you have to do something to them to convert them... i can't exactly remember what tho... sorry, I'm a bit rusty. I haven't used hex nmbers like this for a few years now
December 2nd 2002, 03:59 AM
fairy.gif
: It's H4X0R gone wrong...

Two words. Board. Gnomes.
December 2nd 2002, 05:33 PM
knightg.gif
WC
Peasant He/Him United States
Destroying noobs since 1999. 
That will be in map.dat since you have to assign the tile # and hardness # in map.dat.

--WC
December 2nd 2002, 11:51 PM
stonegiant.gif
: 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.

I'm looking foreward to teh FAQ WC
December 3rd 2002, 08:17 PM
knightg.gif
WC
Peasant He/Him United States
Destroying noobs since 1999.