The Dink Network

Hello guys!
Making a d-mod and downloaded some tiles from the dink-network.
The desert tiles are showing in the editor, but the icecave tiles I really need not!
What can I do?
Can I replace normal Dink-tiles i dont need?

Im NOT using FreeDinkEdit because my program has problems with .exe.;(
Or is there another FreeDinkEdit (not .exe)?
Thanks for help

Sorry, meant WinDinkEdit (any version)

did you name the desert tiles after the cave tiles in the original game? if so, it replaced them. if there's some tiles you probably won't use, you can just rename it and replace those instead.

You can replace tiles from the original game with your own versions. For this your DMOD needs to have a 'tiles' folder containing the new tiles. The tiles are named tsxx.bmp where xx is a number between 01 and 41. You can put the file containing your custom tiles into the 'tiles' folder under the name of the tiles you want to replace. I wouldn't replace the animated tiles because they animate (not sure which ones exactly, I believe ts08 - ts10 and ts19 - ts23 are animated).

You can see the 'dink' folder in the installation folder for Dink Smallwood to see what the original tile files look like.

Hope this helps.

hmm. i think i thought you replaced the "in-cave" tiles.

I couldn't get windinkedit to work on my computer either. I've been stuck using FreeDinkEdit. Unfortunately, you can't use this to alter the map as a whole, you can only edit individual screens. If you start any new squares, it will make the map file HUGE very quickly. There is also no way to delete map squares.

This is a very big weakness of FreeDinkEdit and a source of frustration. What I have had to do is to use existing maps from other dmods and alter the screens one at a time.

This is one of several reasons that I am not planning to make any new dmods (although I plan to release an updated version of my first dmod).

Good luck ghost.

WHAT?
You were using the normal DinkEdit and did "Echoes of the ancients" ?
Wow...
Anyway, that has helped me alot.
I hadn't thought, the answer would be so fast here.
Thx

If you start any new squares, it will make the map file HUGE very quickly. There is also no way to delete map squares.

This is a very big weakness of FreeDinkEdit and a source of frustration. What I have had to do is to use existing maps from other dmods and alter the screens one at a time.

That sounds weird. Are you saying that if you create new map screens in Freedinkedit, the map file gets a lot bigger than if you edit an existing map that has a similar number of screens?

I had a bug like that a long time ago (with Sky Number 13, the map.dat was literally hundreds of megabytes), but I haven't experienced anything like that since.

Sky Number 13

scratcher, are you drunk again

"That sounds weird. Are you saying that if you create new map screens in Freedinkedit, the map file gets a lot bigger than if you edit an existing map that has a similar number of screens?"

That's correct. Touching a purple (unused) square makes the file grow by several megabytes. Before I realized this happens, I ended up with a file that was over 200 Gigabytes at one point.

When I made Echoes, I used the map from SOB. This was a full map with no unused screens. It was nice because I didn't have to worry about touching a purple square making the file bigger. I don't know if this is mainly a Linux issue or what, but it is an unfortunate bug in FreeDinkEdit. It wasn't a one-time thing either. It will happen every time I would start a new square. It's far better to have unused screens than to risk a giant file.

Actually, it depends on the size that the file is already. It grows exponentially.

Just now I downloaded EvilDink to test it. It uses only 8 screens an is 250.2 KB. Very small.

When I add one square, the map file grows to 437.9 KB. Then at 10 screens it becomes 750.7 KB, then 1.3 MB, then 2.1MB, then 3.4, 5.6, 9.3, 15.3, 25.2, 41.6, 68.5, 112.8, etc....

So just going from 8 screens to 20 screens increases the map file from a mere 250.2 KB to a ridiculous 112.8 MB and it just grow exponentially from there. The entire MAP.DAT file for echoes if just 24.0 MB. So the only recourse for a linux user (as far as I can figure) is to use a map that is larger than you need and have leftover squares.

can you run windinkedit with wine?

No, I tried that and it wouldn't work.

It's okay for me because I'm not planning to make any more dmods, but I think other Linux users will run into the same problem.

I'm not sure who (if anyone) maintains FreeDinkEdit. Is it Beuc? Maybe Shevek will successfully get his editor up and running. If so, maybe he can get it to go in the Linux repository with the FreeDink package.

beuc might know. he's like, a warlock or something.

Before I realized this happens, I ended up with a file that was over 200 Gigabytes at one point.

That's amazing.

I'm not sure who (if anyone) maintains FreeDinkEdit. Is it Beuc?

Yep, that's him. He's actually been very good with addressing bugs in the past, so I'm sure he'd fix this if he knew about it. (Unless he happens to see this thread, someone should probably post on the bug-freedink mailing list)

EDIT: Oh god, you're not alone. I just tried creating a new map and filled the top row with new screens: 1.74GB.
EDIT2: I posted on the mailing list

how the hell has this not been an issue until now? did you two install some really ducked up os update that requires all files to be thousands of times as big as they used to be?"

beuc should totally post the explanation for this in this thread in the most complicated way he can. just because.

how the hell has this not been an issue until now?

Almost nobody uses (free)dinkedit. I found it so unusable that I started writing my own editor. My guess is most others just gave up doing editing on GNU/Linux (which means that either they booted Windows and used windinkedit, or they gave up on making D-Mods altogether).

I haven't looked at this at all, but my guess is that this may be something "new", like it only breaks on a 64-bit machine. Because obviously dinkedit used to work when there was nothing else.

It's pretty surprising that this hasn't been an issue until now since I have used FreeDinkEdit in the past and everything seemed hunky dory. I did a little test where I made a few map screens and saved them and the file size of MAP.DAT was indeed much larger than it should have been.

An examination in a hex editor revealed that FreeDinkEdit writes the string "Smallwood" to map.dat every once in a while (upon saving?) when it should only ever be in Dink.dat which first off suggests that it may be writing the wrong data to the wrong file, and that something may be wrong with how files are being handled.

After making more than eight screens, I noticed that upon pressing Q to save and exit, map.dat wouldn't increase in size and upon starting back up, the minimap wasn't showing screens but instead displaying tiles in every screen past those eight (presumably due to dink.dat saying there's screens where there aren't). I don't really know what le heck is going on though. For reference, I was using the 2012 build on Windows 7. Not sure if getting the newest version from the source tree fixes this but it may be worth a shot.

My guess was right, it is a 64 bit problem. In src/freedinkedit.c, lines 595 and 596, the code uses sizeof(struct small_map), but that struct is not defined in a way to keep its size the same on all architectures.

Either that should be done by changing the "int"s into "int32_t"s in its definition (and adding "__attribute__((packed))"; it may work without it, but is appropriate for this situation), or (easier but worse for maintenance) it should be replaced by the number, as in save_map in src/dinkvar.c: 31280 (line 1044, which includes a comment warning about this exact problem; see what I mean by "worse for maintenance"?)

Although I can't get Windinkedit to run under wine, the 1.08 engine does run under wine. The bizarre thing is that some of the problems people have described under 1.08 with my dmods are not an issue under wine. The screens looked exactly as they should have. It did crash on sometimes though. The midis didn't play, although that might be just my machine. You can't speed the engine up with the TAB key the way you can with FreeDink. Also there are a bunch of obnoxious sounds in 1.08 that are thankfully not there in FreeDink.

I tried it to see how my artwork displayed in 1.08 to see if I could get it to work properly. But since my art appears in 1.08 under wine the same as it does under FreeDink, this will be no help.

Should I bother to upload a package of some of my best graphics if they don't show properly in 1.08 under Windows. And why do they show properly in 1.08 under Wine in Linux? It's very strange....

Thanks for going through the source although a quick glance shows the newer SDL2-based source on Savannah appears to do away with dinkvar.c and changes a lot of things around with freedinkedit.c no longer using small_map (or at least I can't find it in there), however the problem is still there in the 2014 FreeDinkEdit build which is presumably based off of it.

Hi,

Sorry I couldn't check this in detail until now.

AFAICS I ditched the buggy code recently when cleaning-up the code, and only use a safe, portable version (freedinkedit.c:editor_save_screen() and editor_screen.cpp ave_screen).

Can anybody check if the problem is still present in http://www.beuc.net/tmp/freedink-109.0-bin.zip (which is the SDL2-based in-progress version you mentioned) ?

(I suspect there may be an issue in DINK.DAT, as it says where each map square is saved, and it could very well tell to save it at +200GB in MAP.DAT, which would then be 1) huge and 2) mostly full of zeros.)

@yeoldetoast: the "Smallwood"s you saw in MAP.DAT is a filler for an unused "name" field, but I see this is confusing. We could just delete those.

I suspect there may be an issue in DINK.DAT
I haven't checked your new version, but I know exactly what the problem is: When creating a new map, the size of map.dat is used to determine how many maps are currently in use, so it gets the new map number from that. Then it writes that ID to dink.dat.

The problem is that it uses the size of a clean struct for this computation, as opposed to the thing that is actually saved which contains a lot of unused junk. So when there are 10 maps in map.dat, the actual size of it (if it works well) is 10*N, with N the large size of a single map screen. But it then computes the id of the next map using (10*N)/n, with n the small size of the junkless single map screen. That's a pretty big number, much bigger than it should be. And it gets bigger when the map gets bigger. So the map number explodes, and when writing a map screen with a very high id, it will seek to its position in map.dat, thereby expanding it to whatever size it needs for that.

So my original explanation was wrong: this is not a 64 bit issue; in fact, it's worse on 32 bit, because the packed struct is even smaller there.

Anyway, you have replaced the code with something new, so unless you introduced the same error in the new code, which is unlikely, it will be fixed by that.

Agreed. Copy/pasting my answer from the FreeDink mailing list : This is due to an incorrect computation of the screen index in DINK.DAT. Opening and saving the file in a map packer such as WinDinkedit should fix the file size.

I can't reproduce in 109.0 so this oldity from the original Dink seems definitely fixed