The Dink Network

What's this?

That's right, I've slipped into the back alleyways of the DN and broke the age old rule of of serving you some GELATIN, so you can have a strong SKELETON.

It's good for your bones.

It's good for your fresh dmods.

It's highly optimised.

It's the most bug-free barebones skeleton available with:
- Fully optimised dink.ini, re-structured, commented, and 130+ set_sprite_info lines removed (duplicates and other terrible ones that shouldn't be there)
- Robj's custom hard.dat re-write, allowing Dink to walk against things without encroaching into them too much. No where to slip through hardness, and all inner and outer islands & match-able beach tile combinations match with hardness too!

Read the dmod.diz upon install for even more info.

*Runs away into the forest, slipping away from the Goodheart guards*

#BuryTheOldBones

Can you upload it in .zip format aswell? I got Dink HD installed and it doesn't seem to support installation of dmods outside of the dmod browser.

Sure, incoming zip file version. I'll upload it momuntarily.

EDIT: Done. Make sure to click versions on the file page to see it.

EDIT2: Actually, I just made the main version .zip format anyway. There's no point it being a .dmod. So there's only the 1 version now.

If anyone's already downloaded it. Make sure to re-name "sounds" folder to "sound".

Silly me.

I already uploaded the update to correct that.

I don't suppose that you have a more elaborate change-log file that I could refer to (aside from the notes you've already made available on the topic) do you?

I've gone back to working on my enhanced version of Bluedy's Northern Lands (known as Dink's First Adventure) and would hate to have to restart (for example) the dink.ini file from scratch. On the other hand, I'd hate to run into any problems because I did not replace or merge some of "my" files with some of the changes and fixes you made.

I don't suppose that you have a more elaborate change-log file that I could refer to (aside from the notes you've already made available on the topic) do you?
- Fully optimised and clean up of dink.ini. See bottom of dink.ini to un-comment extra original Dink graphics that aren't usually loaded by default, if you want to use them.

- Fix applied to start-2.c that fixes a bug that draws a screen twice on game load (a bug with set_mode that has been present forever but noticeable only if you spawn a "load game detection" script in main.c)

- Duplicate sound removed from start.c

- Useless un-used 'required' global variables removed from main.c.

- Re-write of hard.dat, so it's not 'blocky'. Dink can now walk against things, without encroaching into them. All combination of beach tiles that graphically match will match with the hardness too.
No pesky lines that don't line up properly where Dink can slip through.
Feel free to edit any of the empty hard tiles in the middle of the hard.dat (you'll see what I mean if you open the hard tile selector in game), for your own custom hard tiles.
Open the hard tile selector in your dmod editor, Pick a blank tile from the middle section of blank hard tiles, stamp it, and then edit it. That's the correct way to do it without messing up the hardness of all the other non-hard tiles.

- Using Start, continue, and quit buttons from Mike Snyders skeleton (I think that's the original source, unless he used them from somewhere else as well)

- Dink.ini optimisations, removing 136 set_sprite_info lines and cleaning it up/re-structure.

The skeleton is more meant for starting a fresh dmod, but if you wanted to try to import some stuff into an existing dmod. I would first back up each file you try to replace and then load up the dmod and make sure it's all good. As part of the dink.ini optimsations, some of the hardboxes have changed slightly due to some set_sprite_info lines that were removed that Seth included that are barely different from default (when no sprite_ino is decalred). Most of the time this is houses and stuff, which is a waste of set_sprite_info since authors manually tiles those anyway, and it won't affect anything. Or other miscellanous sprites that aren't usually set to hard.

As for the hard.dat, it has been re-written. But when replacing a hard.dat in an existing dmod, any manually stamped hard tiles (where you've copy and pasted hardness that is different to the normal default hard tile) obviously will not be updated.

If your dink.ini is having no issues an an existing dmod, I don't recommend swapping it.

You can try backing up hard.dat, and swapping the new one in to see if your tiles update.. but again, I don't know if they all will without re-stamping the tiles, for an existing dmod.
the start-2.c can be replaced easily for the bugfix mentioned above (even if you don't have a load_game detection script in main.c it won't hurt to apply this bugfix).
The duplicate sound removed from start.c is loaded into sound slot 25, and it's a duplicate of 32. If you want to remove 25 manuallay, you can do that (it's a waste having 2 of the same loaded).
Usless globals removed from main.c are: &speed and &timing. If these are in the 'required globals list' you can remove them, they are used for nothing. Some dmod skeletons already removed them but you can check.
Also &dinklogo is removed form the required global variable list, and instead just declared "int" as a local variable in start.c(the only script it's used in). No need for that being a global.

For all the individual dink.ini changes see here: dink.ini optimisations

Open the hard tile selector in your dmod editor, Pick a blank tile from the middle section of blank hard tiles, stamp it, and then edit it. That's the correct way to do it without messing up the hardness of all the other non-hard tiles.

i thought you assigned all the non-hard stuff to hard tile 0 so itd be impossible to duck it up

edit: oh wait, that was using ebildrone's windinkedit i think. yeah use that too so you dont duck it up

Yeh, basically all the extra tiles that aren't supposed to have have hardness are assigned to tile 0.
So basically just make sure to choose and stamp a blank hard tile from the hard tile selector before editing it(when making your own custom hard tiles). If you just edit a grass tile for example without first selecting a blank hard tile from the selector, that hardness will appear EVERYWHERE.
Or yeh, use Drone's latest windinkeditplus version, he made it so you can't edit hard tile 0, so indeed, you cannot duck it up.

maybe i should get around to sorting out my dink files situation since i made a few pc upgrades and one of those was getting an m.2 specifically to stick windows 10 on (and you know, other stuff that has to be there for shit to work). one broken thing is the dink installation path. always get registry errors and have to locate the game installation when doing anything.

my dink folder is a duckin mess, tho. but trying out the new editor version and this skeleton might be neat.

FYI, you can extract a .dmod file with 7zip or i think winrar just fine.

The .dmod file format is actually just a .tar.bz2 archive.

Although, if I remember correctly, some old dmod-packers didn't respect the .tar file format or the .bz2 file format, forgot which, basically they're missing some empty padding bytes. However, 7zip works fine even with those.

Thanks Robj. I'll definitely look through these detailed notes and will apply the changes that I think are "safe" to make in an already active project. Don't worry, I'll be very careful in applying any changes or fixes.

Speaking of worrying, I always worried about &timing and &speed being used somehow internally to the DinkC engine. It is great to know that these two "variable slots" can be "freed up". I sort of wondered if the duplicate use of CAVEENT.WAV had something to do with some kind of internal DinkC engine use too, though I have been braver about experimenting with replacing either 25 or 32 of the "load_sound" commands. I noticed that only 32 was used in the DinkC files in the original game.

Your notes on dink.ini at https://pastebin.com/CABBMKWr and within the file itself are very good too.

I have a question about this statement: "As for the hard.dat, it has been re-written. But when replacing a hard.dat in an existing dmod, any manually stamped hard tiles (where you've copy and pasted hardness that is different to the normal default hard tile) obviously will not be updated." Does "manual stamping" include copying and pasting a tile (or series of tiles) from the tilesets in the tiles directory? As I'm sure you know, many such tiles come with "built in" hardness elements.

Excellent work!

Does "manual stamping" include copying and pasting a tile (or series of tiles) from the tilesets in the tiles directory? As I'm sure you know, many such tiles come with "built in" hardness elements.

Only if you have manually stamped actual hard tiles, or copy pasted hard tiles, then they won't update, since you've chosen alternate tiles. If you've only copy pasted actual map tiles, the hardness should update to the new hardness defined in the new hard.dat once it's replaced.

Anyone using this, please note I just updated it.

The only change is the hard.dat. Made a beach hard tile fix.

You can simply just take the new hard.dat out of it and paste it into your existing gelatin skeleton dmod folder, or any other dmod you've started using gelatin and that will also apply the fix, rather than replacing the entire thing.

This just received another update. Seseler made me aware of some bugs and also made some suggestions.

Anyone one using this please see below, you might be able to just make the necessary adjustments yourself if you're using this skeleton in a Dmod that's already in development.

@Yeoldedink, hopefully you see this, I believe this skeleton is included via default in something, maybe the dinklua skeleotn or something? Anyway, might wanna update whichever parts you used too.

Fixes have been applied to the following:
- TS32 - Hardness missing from a tile at column 7, row 4.
- TS05 & variants: The convex cliff edges have hardness border that doesn't match other cliff tiles.
- Beach tiles mismatching corners
- Small extrusion on hard tile 133.
- dink.ini - line 1047 typo: "laoded" changed to "loaded" in one of the comment lines.
- sequence 31 (inn walls) set_sprite_info lines added back in for frame 26, 35 and 36.
- sequence 445 (stack of wooden boxes) added back into dink.ini (was deleted by mistake).
- Added the coloured sparkle variations and the sucking vine graphic to the commented out "unused graphics" list.

Thanks for this... I am using it, so will update the hard.dat file I guess.

Just a question, how did you do all the new hardness? Did you use an image that somehow got parsed into .dat info, or did you have to manually re-edit each 50x50 square?

I'm hoping the first and you can explain how. I'd like to edit hardness for tiles, especially now that why have support for 600x550 size. I was hoping there is some nifty way to take an image and get it cut up into the hardness tiles without having to manually draw in WDED+

>I'd like to edit hardness for tiles, especially now that why have support for 600x550 size. I was hoping there is some nifty way to take an image and get it cut up into the hardness tiles without having to manually draw in WDED+

I have made a program that can import/export hard.dat into a PNG image, which would allow you to edit hardness tiles with your favorite graphics editor.

I've been intending to release it along with some other tools eventually (including something that would let you just draw hardness over the tile images), but putting everything together is presumably going to take a few eternities...
But if it'd help you (or somebody else for that matter), I could just release the hardness import/export tool right now in somewhat unpolished state.

I edited every tile manually in windinkedit.

I would definitely be interested in looking at such a program/add on.

I'm redoing tiles at the moment, which is kinda hit or miss, but having the ability to redraw hardness easily would be magnificent.

Oh my, you deserve a cookie... truckload

Okay, here's the programs in hopefully usable state. Make sure to read the included readme. Also note that they are rather bare-bones programs without any of this new-fangled "GUI" stuff so they're command-line only.

Thanks, before I get carried away I did a hard2png test and it outputted one png with all the hardness tiles available, if I want to update... say ts02.png, can it do individual tiles based on the file name while keeping all the others?

While I have backed up my dmod - last night - I thought I'd check first before experimenting.

As I said, it's quite bare-bones tools.

I'm planning to eventually make the program capable of importing/exporting hardness overlay for the tiles, but I have quite a bit of other things to do.

Far enough... so if I was to use the png I exported out as a test as a guide, and in a graphics program add the hardness there, then use png2hard.exe that would work?

Is there a sequential indexing to the tiles, allowing mapping via a grid in a graphics program using a 51 by 51 based grid?

I was hoping it was a case of read left to right, top down, but no... as ts01 only has the forest tiles hard at row 8 column 1 to 4, but the png has these hardness squares at row 1 column 16 and row 2 columns 1 to 3.

So how are tile squares without hardness dealt with? Like all the ones in ts01 that don't have any hardness assign by default before the forest tree floor?

Maybe I'm going to have to just finish creating the new tiles, dump them into a map, manually add hardness via WDED+, then say "bingo".

>Is there a sequential indexing to the tiles, allowing mapping via a grid in a graphics program using a 51 by 51 based grid?
The engine maps the graphics tiles (G's) to hardness tiles (H's) with a G -> H lookup table. If two different Gs map to same Hs, you editing H changes hardness for both Gs.

If you're using the WinDinkEdit Plus 2 Drone Edition (and you really should), you can see the the H of G on the right edge of the status bar (it reads something like DEF. Hard ID:123). Also if you swith to hardness mode and open the tile selector(by pressing 'E'), you'll see the H's number on the same place on the status bar.

>So how are tile squares without hardness dealt with? Like all the ones in ts01 that don't have any hardness assign by default before the forest tree floor?
They have the H mapped to G#0 which is hard-coded to be empty hardness (and which won't be exported by hard2png)

Also here's a numeric map of hard tile numbers. If you use png2hard to insert it to hard.dat, you can check what Gs share the H (or you could just modify the hard tile on the editor and check if any other tile's hardness changes).

Thanks for that.

So I've done a few experiments and have changed your index image to one using the unknown hardness colour for easier viewing so I could screen shot the various default tiles with their index from the GELATIN skeleton dmod. In hindsight I should have used something that overlayed the numbers on the actual original hardness like this.

Here are the various tile screens viewed in WDED+ ver 2.5.13.0 with their hardness index numbers
ts01 - ts06
ts07 - ts12
ts13 - ts18
ts19 - ts24
ts25 - ts30
ts31 - ts36
ts37 - ts41

So, from GELATIN hard.dat tiles index 311 to 745 are available to customise, and you can edit them and stamp them onto a tile set inside WDED+ one by one, but can you assign them permanently to any of the tiles as a default via the png to dat process?

Or, as I suspect, create the hardness in a png, upload it via png2hard.exe, go into WDED+ and manually assign index numbers and then save.

Yeah, you have to swap the tiles default hardness inside the editor.
Edit: just realised that (unlike everything else in Dink Smallwood) the hardness numbers are zero-indexed, so the numbers on the grid image I shared are off by one...

> capable of importing/exporting hardness overlay for the tiles

I already have a program that does this sort of thing. The included PSD and PNG should give you an idea as to how to go about it. The main considerations are that you must paint in pure red or pure blue when making the (RGBA format) mask, and the outputted file is called "harddat.dat".

Invocation goes something like:
photohard myhard.dat mymask.png 5

Which would overwrite the indices of tilescreen 5 with the contents of mymask.png.
There is also a testmod in there ("photohardtest") providing a demonstration of output.
The usual disclaimers apply, and it may not work at all etc.

Okay, maybe I'll give it a whirl...

In the meantime I went manual with editing the png image I had already exported

I just tried doing stuff via Gimp on a test tile I've made, an extension to ts03

This is the hardness edited in Gimp

This is the re-edited png for the png2hard.exe program

This is how the new hardness displays as choices in WDED+ which I then stamped as default on the ts03 window in hardness edit mode.

Was this quicker than just manually editing stuff in WDED+? Maybe. Although selecting which of the "free" hardness squares available is probably the hardest part to manually do in WDED+ without a visual guide, just the numbers in the bottom right hand corner. The whole 1 pixel difference on the bottom and on the right is annoying to say the least, if it wasn't for that, working graphically would be the best.

So.....

I will take a look at your "photohard" program soon, my $10 windows keyboard has died, so using my mac one. It dying while working in WDED+ hardness mode was scary as only some keys stopped working, like H and R and backspace and enter... which kinda freaked me out as I thought I had broken either WDED+ or my dmod or both...

>The whole 1 pixel difference on the bottom and on the right is annoying to say the least, if it wasn't for that, working graphically would be the best.

Here's a version of the program that without the margin area. The reason why the program outputs that gap (which corrensponds to unused data on hard.dat; the game just ignores the last hardness row and column ) is because I originally wrote it for hardness data introspection rather than editing... but I can see how would be annoying for editing. If I ever get around to completing the tool, I'm probably going to make 50x50 vs 51x51 tiles a toggleable option.

So just trying to get that program to work and Python can't find PIL module, allow I do have pillow installed.

I have Python 3.11 installed and using the command at the c prompt of 'pip install pillow' gets me

Requirement already satisfied: pillow in c:\users\simon\appdata\local\programs\python\python311\lib\site-packages (11.0.0)

I noticed that there is a PIL folder in the "_internal" folder in the download.

I've got all the folders in your download inside my test dmod folder C\Users\Simon\AppData\Local\DinkSmallwoodHD\dmods\test>
and I run the photohard.py command from this directory at the prompt and PIL module can't be found.

Should these files be moved somewhere else?

EDIT

so I tried just running the .exe at the command prompt not the .py and it sort of worked

For some reason the top row of new hardness came in as yellow hard, not blue hard although the whole hardness png was blue.

I did confirm that you need all the pre-existing hardness for tsXX as well as the new stuff, which I was pretty sure was the case but used a hardness png that only had the new stuff to confirm this.

EDIT on EDIT

Looking at this screen shot it actually doesn't look like the blue is from my new png, just wondering is there a tile size limit of 450 px high assumed in the coding as it does look like the yellow is from my new png file and the old blue which is thicker is from the original hard.dat which has a ts03 of 600x550

If you post your masking PNG I can look into it.

Indeed it removes the existing indices for the tilescreen. It's also quite dumb, and doesn't reuse existing tile squares if they happen to have the same data, such as for a completely filled-in area.

edit: oh

Here is the png I used to test this

EDIT

also the readme.md file gets the colours wrong, pure red is low hard, pure blue in the png is standard "you shall not pass" hard - I just took a look at your test dmod again and noticed that your rocks show up low hard in WDED+ and your png is pure red.

Good catch, i'll release an update soon. In the meantime if you get your local python environment working, it should be possible to change the bounds on lines 73, 74, and 79 without trouble, and swap the assignation on line 18 with 21.

Sometimes pip has to be invoked with "python -m pip", and python with "py -3" on Windows.

Python and environments has always been a bit of a murky subject for me.

I thought I had this sorted on this PC as Python 3.11 was the only one I installed, so unless windows 10 comes with Python pre-installed (like macOS which was not helpful for me when trying to comes to grips with having both python2 and python3 running at different times), I'm not sure what else I need to do. Certainly just going into IDLE via the command prompt and typing in import PIL comes up with the same error I was getting using the photohard.py command before I switched to photohard.exe

Actually I tell a lie, I just went into IDLE via the command prompt and import PIL didn't flag an error in IDLE

but even adding that line into the photohard.py at the start still generates the error

Here is the revised code at the start of photohard.py

# photohard - a thing for making hard.dat tiles in photoshop
import PIL
from PIL import Image
from sys import argv, exit
import dfile.harddat
from pathlib import Path
#import xdialog
import struct
import array

And the error message
Traceback (most recent call last):
File "C:\Users\Simon\AppData\Local\DinkSmallwoodHD\dmods\test\photohard.py", line 2, in
import PIL
ModuleNotFoundError: No module named 'PIL'

but if I use this

python photohard.py hard.dat ts03newHard.png 3

then I get this

........................................................................................................................................................................................................................
Wrote harddat.dat

so I assume that works

One more minor fix I just made found again by Seseler.

The load_sequence line for sequence 59 has 2 spaces before the 'NOTANIM', which causes a difference in the hardbox/depth dot calculation compared to original 1.08 ini (because NOTANIM gets pushed from the third parameter to the fourth).

Skeleton Gelatin file has been updated already with this simple fix and is available (version 1.07).
Easy for anyone else to open the dink.ini and apply the above fix as well though.

Also worth noting is that the description states that it is provided in Zip format when the more recent releases are not.

"Also worth noting is that the description states that it is provided in Zip format when the more recent releases are not."

You're right. Just added another version, in zip format again.