dink map specs sheet?
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?
NO TEXT LADIEZ! Hold on, THERE IS TEXT! THIS MUST BE A CONSPIRACY!
: 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...
: 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...
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.
(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.
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
You've got some wierd crap in there, are you pasting out of Word or something?
It's H4X0R gone wrong...
: -=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. )
: 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. )
: 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
: (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
: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
: -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
That will be in map.dat since you have to assign the tile # and hardness # in map.dat.
--WC
--WC
: 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
I'm looking foreward to teh FAQ WC