The Dink Network

Full Install - Beta 3 (15.17 MB)

Patch for v1.06, v1.07, or v1.08 - Beta 3 (1.18 MB)

Fixes

* "button7" through "button10" scripts will be run when extra gamepad buttons are pressed.
* Level-up no longer lost if in inventory screen, fixed several other experience count issues.
* Status is drawn on load so the magic-level is always displayed.
* Dink's speed reset to normal (3) on load to prevent 'hyper-sword' bug.
* Fixed issue of a phantom keyboard key causing the Map to not be displayed.
* loopmidi(bool loop) - If 1, all midis will automatically loop. If 0, midis will not loop.
* playavi(str avifile) - Removed command.
* set_dink_base_push(int dinkbasepush) - Sets the base-push for Dink. Default is 310. Not saved with save games.
* show_console() - Shows the console, which accepts DinkC commands as input (Escape to cancel).
* sp_freeze(int sprite, bool freeze (-1 to return)) - If 1, acts like freeze. If 0, acts like unfreeze. -1 will return whether the given sprite is frozen or not (basically a better 'busy' function).
* Made it so barrels, chests, and boxes can no longer be hit more than once and drop multiple items.
* Fixed several instances of incorrect grammar and spelling.
* The pillbugs at Smilestein's farm now act like pillbugs, with proper sounds and experience and such.
* Several small map tweaks.

Fixes for new bugs in previous betas

* A stone giant at the end of the world had a bpotion script attached to it???
* Some items (like those that appear after hitting chests) appeared somewhere else briefly
* Fixed issue where the last row and column of every bitmap was cut off.
* Fixed issue where you could get experience even if you don't kill the enemy
* Sped up windowed startup process slightly
* Sped up true-color fade down dramatically
* Fixed error where Dink could walk through hardness, if a script instructed him to walk off the screen.
* Fixed issue of phantom-keyboard key causing the Map to not be displayed.
* Updated readme.txt to include troubleshooting information for starting windowed/true color mode.
* Stone of Balance - doesn't crash on pig man (accidently fixed)
* DFArc2 - Swapped position of ok / cancel to be more consistent with standard windows GUIs.
* DFArc2 - DFArc2 doesn't crash if it can't find dink.exe or dinkedit.exe.

Todo

* Complete writing the DinkC Reference.

D-Mods Requiring Updates

* Alliance Command - Change off-white to pure-white on various graphics.
* Cloud Castle 2 - Change off-white to pure-white for one of the desert plant sprites.
* Cycles of Evil - Add check for palette mode, use load_palette instead of show_bmp to change palette.
* Initiation - Fix Blackjack script to use new argument-passing technique.
* Lyna's Story - Add check for palette mode, use load_palette instead of show_bmp to change palette.
* Victim of Life - Fix scripts that used weird syntax for sprite reference.

Questions and comments:
1) How exactly will button7 and button10 be implemented?
2)Aww... I'll miss the hyper-sword bug, though I usually put in extra lines of code to prevent it in my dmods.
3)loopmidi = Hell YES!
4)show_console() = Aw HELLS YES! This could be very interesting to fool around with.
5) Experience even if you didn't kill an enemy? Hmm... I always thought that was there to balance out the cheap tactic of letting the badguys beat the crap out of each other.
6)True color fade sped up, eh? We shall see how well it works this time around \
7)I still haven't figured out what the phantom key is.

1) Just like a key-##.c script. So if you want key-65.c to be mapped to gamepad button 7, just rename (or copy it) to button7.c. D-Mod authors who implement extra keys (like SimonK with PQ and me with FIAT) should probably implement them, but users are welcome to do it themselves.

2) Aye, I'm not quite sure why I fixed it in the engine itself.

3) Yes

4) Aye, mapping a quick script like:

void main(void)
{
show_console();
kill_this_task();
}

to the ~ key is awesome. All keyboard control (for Dink) is disabled, but you can still use the gamepad to move around. You can also use the up and down keys to go through previous commands you've typed.

5) Whoops, I phrased that wrong... in one of the previous betas, I accidently made it so enemies were killed by something else would give experience to Dink. I fixed it so it works like it used to, where you don't get experience unless you kill the enemy.

6) I haven't sped it up since the betas I've given you, so it isn't going to be 'omg' cool, but still a noticeable improvement.

7) Yeah, weird.

This beta is truly a beautiful thing. (tears of joy)

I could probably find a few small things in need of working out, and I do plan on running around and trying to break things, but I must say this seems pretty close to release candidate material.

Mmm.

Black bg on "oars" in story 1 Map 323 - even though this sprite is a white bg one (but I do have white and black (item) bg sprites in the same sequence.)

Also the magic item is still not displayed sometimes on loading a game. I loaded a saved game from SOB, story 1 and while magic was all charged for fireball, the fireball item graphic wasn't displayed. I rearmed the magic, then saved in a new slot and reloaded, and the magic item graphic was once again missing from the status bar on reloading.

3)Oh yeah, this should save some fooling around with them midis, nice job!
4) dang, quite a powerful enhancement. I've yet to see it in action, but man, it could be extremely cool.
5) Agreed with Striker. Good thing you turned it back.
6) I liked the fading, I'm gonna check if it;s even cooler this time.
7) Ok. M is more logical than button 6 is anyway.

how exactly would i get the "pure" white i tried changing it to the default white on my ninja graphics (using mspaint), but it still doesn't seem to work...

I'm assuming that you borrowed the graphics from somewhere else? You'll have to modify the palette in some fashion. Outside of using Paint Shop Pro or Photoshop, I'm not sure if there's an easy way.

SimonK,

Hmm... I went to screen 323, and the oars looked normal. I tried windowed mode in 32-bit and 16-bit color. This was a problem for windowed mode, right?

And, hmm, I'll look into that magic item problem.

Yeah, map 323 windowed mode - I'll post a screen grab...
Oars Full Screen v1.08
Oars Windowed v1.08

Ok, this is very weird. In the version I installed, it works without a black background.

If I dir.ff the graphics/sitems/ bmp files, I see the same behavior. But I can't find any explanation for it... I thought maybe the palette of the oars had mixed the black and white colors, but it's the same as the regular Dink graphics and other graphics in that sequence. I'm stumped. I'll continue looking into it, though.

Oh, and the 'WHITE' keyword doesn't do anything. Dink only recognizes the 'BLACK', LEFTALIGN, and NOTANIM dink.ini keywords.

it would be cool if there was an option of more transparent colors like (red blue or green)...and it would be better if you could put all of the ini crap on the same line when you set the transparent color to black. i've noticed that you can only put the sequence number and frame delay on that line when you use BLACK...

Again you have seen your way to adding some cool new features. I'm not likely to use the commands for quite some time if at all. The console one has got me confused though. What exactly does it do?

I did some more testing on the engine, and came up with the next results and ideas...

- When in 32 bit windowed mode, one of my custom graphics has white instead of transparent. The new graphic DOES have a Dink palette...

- The game still won't run fullscreen on my Windows 98 compy... It opens and closes without any warning. There is nothing reported to debug.txt, not even in debug mode.

- I keep my Dink editors somewhere else than in the Dink directory... What about making a browse button for the editor program in DFArc?

- In windowed mode, how about STORING the last window position the game was closed with? Or at least automatically center it on the screen?

- Also, what about showing the mouse cursor when the game is being played in windowed mode? I prefer that...

- When giving input while Dink is minimized (in windowed mode), the game reacts to it when returning to the game.

I tried some of the new functions too, and they work like a charm. I now have a shop discount-at-christmas!
You implemented some good new options!

Oh, and I noticed my nickname is in credits.txt. Could you insert my real name, Vincent Beers instead?

EDIT: I used the patch btw.

Okay, I played around in my D-Mod, and the graphical glitches are gone. However, I liked the previous fading in/out much better. It gave a nice touch (it was slower). Maybe put in an option that you can choose? Or just change it back I really dislike this one, it's just as bad as the old one, imo.

I agree

I found something really weird (which also occured in v1.07):

If you push the down button then the right and left buttons (keeping all three pressed in at the same time) Dink stops moving, he just freezes in his last moving seq.
The same thing occurs when pushing the right button and then the down and up buttons.

But it gets stranger:
If I push the up button then the left and right buttons Dink simply continues moving upward.
The same thing occurs when pushing the left button and then the down and up buttons.

I know I'm probably really strange to even try this.

Metatarasal: agreed, that is a bit odd. I remember something similar in v1.06, but I could be wrong.

What do you think should happen when you press more than 2 directional keys at a time? I'm not sure what I would do to 'fix' it.

Christiaan: I may slow it down a tad... hrm.

DaVince:

When in 32 bit windowed mode, one of my custom graphics has white instead of transparent

Could you e-mail me that custom graphic that has a white background? Thanks.

The game still won't run fullscreen on my Windows 98 compy...

Hmm, shoot, I forgot about your full screen problems... I'll get back to you about that. Is this for both true-color and 256 color mode, or just one?

I keep my Dink editors somewhere else than in the Dink directory... What about making a browse button for the editor program in DFArc?

But... why I was going to do this, but as the dink.exe must exist in the Dink directory to function properly, I thought it would be better to make it consistent. I am undecided.

In windowed mode, how about STORING the last window position the game was closed with?

Probably not going to happen... it would take a surprisingly large amount of work. You can drag it around, even though the mouse cursor isn't visible.

Also, what about showing the mouse cursor when the game is being played in windowed mode?

I'll see what I can do.

When giving input while Dink is minimized (in windowed mode), the game reacts to it when returning to the game.

You could go into the Inventory screen when you lose focus... but yeah, there should be a way to do this. I looked a little bit, but I'm not done yet.

And thanks, yeah, I'll update your name in credits.txt.

Draconic:

I made a screenshot showing the console.

When show_console is executed, the keyboard no longer controls Dink at all. Instead, everything you type is displayed at the bottom of the screen, immediately above the status bar. Once you hit Return, Dink will process what you typed as DinkC.

In the above example, I typed the create_sprite command, and hit Return. The Dink facing down was instantly created. The '29' number above the create_sprite command is the value returned by create_sprite. So, the fake Dink I created is sprite number 29.

To get the create_sprite command to display again without typing it, I pressed the up key to go through previous commands I typed in.

You can also use local variables in the console, so you could type something like this:

int &temp = 0;
&temp = create_sprite(500, 300, 0, 72, 1);
sp_brain(&temp, 9);
sp_speed(&temp, 1);
sp_base_attack(&temp, 100);
sp_target(&temp, 1);

Of course, if you're going to type that much, you might as well create a temporary script that you can use over again.

Could you e-mail me that custom graphic that has a white background? Thanks.
I will mail it to you tomorrow... Gotta go ta beds now.

Hmm, shoot, I forgot about your full screen problems... I'll get back to you about that. Is this for both true-color and 256 color mode, or just one?
It closes in any fullscreen mode... Just like that. I tried both 256 colour and 16/32 bit colour, to no avail.

But... why I was going to do this, but as the dink.exe must exist in the Dink directory to function properly, I thought it would be better to make it consistent. I am undecided.
What about just making the EDITOR have the browse button, then?

Probably not going to happen... it would take a surprisingly large amount of work. You can drag it around, even though the mouse cursor isn't visible.
I understand... But why exactly would it be so hard? Are the x and y variables of the window so hard to access or impossible to change by programming?

Well, I'll try some more stuff tomorrow. I must say that the game has improved! And that's great.

You better the fudge not, man. It's plenty slow as is. Going back to waiting over six seconds for fading in/out is ridiculous.

Are the x and y variables of the window so hard to access or impossible to change by programming?

Not really. The hard part would be storing/retrieving them. I could:

a) Use the registry to store and retrieve the x and y coordinates. However, Dink doesn't access the registry at all right now, so I'd have to figure out how to create and retrieve the registry keys. And from what I can recall, the registry is not much fun to work with using raw C++.

b) Modify dinksmallwood.ini to store the x and y coordinates. Could break backwards compatibility with utilities like WinDinkedit.

c) Create a new .ini file to store the x and y coordinates.

In any case, I'd have to implement a fair share of error checking. What if the x and y coordinates have values that are not valid, and the Dink window would be off the screen?

Centering might be possible, but it runs the risk of messing up on computers with multiple monitors.

That, and it has to be extensively tested.

That's why I said it was too much work.

*nodnod* What on earth are they talking about? I'd rather have it be too fast than too slow, and right now the fade down/fade up process in true color and windowed modes is still a bit slow.

Some people like myself like to keep WinDinkedit in a seperate folder, not the Dink directory. That's why you should make a browse button.

Umm, okay. Thank you for answering my question, but why did you put it in. I don't see what use it could possibly be, except for BinaryCode's dmod.

D-Mod development. Right now a D-Mod developer usually has to create temporary scripts in order to figure out why things don't work.

For example, say if I talk to Phillip, the &story global variable should be 3. But I have a typo, and the command in the script is actually '&sory = 3;'

I talk to Phillip, and I talk to another character, and it isn't acting like I want. So I open the console, type say("&story", 1); and then Dink will say '2' or whatever. Then I can go about and figure out why &story wasn't properly set to 3.

Or if I'm creating a new weapon, I can add it to Dink's inventory real quick by typing add_item("item-new", 437, 1);

It was possible to do all of this using temporary scripts, but that requires you to leave Dink, create a new text file, write a procedure, etc.

There are a billion uses for this.

Tal found a bug in Mystery Island... whenever you hit anything, your experience will reset to 1.

Awesome.

It's the &missle_source problem in a different skin.

So... from now on, &missle_source will be one of the required global variables. It will need to be added to all existing D-Mods, but it should exist in most of them already.

Umm, where do you add it? Also did you get the Private Message I sent you a few days ago?

Umm, where do you add it?

Well, how about the place where the other required globals come, main.c?

Oh, I must of missed the word global before.

"the world global"

You did that typo on purpose? It fits well.

Opps, sorry, I've corrected it now.

I have a big problem. When I'm in 32-bit color, windowed or fullscree, I enter another room, or I use fade_down(), the screen gets dark real slow, then it reveals again slow. I use windows xp.

cypry: That's a known problem with older video cards... there is a slight possibility I can speed it up.

That's a known problem with older video cards
Is FX 5200, 128MB an old video card?

* sp_freeze(int sprite, bool freeze (-1 to return)) - If 1, acts like freeze. If 0, acts like unfreeze. -1 will return whether the given sprite is frozen or not (basically a better 'busy' function).

bools are only 1 bit long so I don't think they can be -1... (correct me if I'm wrong)

bools are either true or false or 1 or 0 but in Dink, the -1 value is used for returning a value because there are no get_hardness();, get_size();, get_x(); etc functions/methods. For example:

int &mydir = sp_dir(1, -1);

This returns the direction instead of setting it to -1.

cypry:

Weird. That's the same video card I have in my old computer, and it worked with the fading fairly well over the summer.

I shall look into this more.... thanks.

Dink generally only supports integers and strings, but for values that will usually be used as a '1' or a '0', they are referred to as 'bool'.

You're right. bool's are only 1 bit long; A 0 is false and any other value is true.

Doesn't bit-being imply that the other value is 1 (as a bit is either 0 or 1)?

But yeah, you could also write any other value when it checks for 0 or non-zero

Not necessarily. If you cast it out it could change depending on the platform, and if you cast it in any value besides 0 changes to 1.

Perhaps it has to do with RAM? My two computers only have 256 and 384mb respectively, and they both fade pretty slowly.

Ah ok, well I've got enough to learn as an undergraduate I guess

Perhaps it has to do with RAM? My two computers only have 256 and 384mb respectively, and they both fade pretty slowly.
Yeah, I have 256DDRAM, but other games like gta, fifa, aom works fine.

That should be way more than enough for Dink. I've used Dink on two systems that ran happily on 256MB. Although the second of them, my current one, now has 512MB RAM. So I often run Dink in windowed mode with other things running without a drop in performance for either program.

So, the fade up/downs aren't around 5 seconds long on the machine with 256mb RAM when running 1.08 in windowed?

If you minimize the game window and bring it back up, the status bar will be drawn despite of whether it was there before. Small, but a bug nevertheless.

scratcher: Cool, thanks, should be fixed for the next release.

I like it. One question: Source code?

I downloaded the patch and I didn't find the engine source. I'm a bit reluctant to download the whole thing since I'm on dialup, but I will if it has source code.

I'm interested in getting that and the new game source myself, but I thought I'd hold off till the release of the final version to ask since I don't think either will be released until then. But now I'll just add to your request by joining you instead.

I've been told that Dink 1.08 source will be released following the release of 1.08 itself.

Cool. i'm a bit of a nerd. I love to look at code just for the sake of it. Also I intend to port Dink to Linux one day and I'd prefer to use the source for 1.08 rather than 1.07 if possible.

By the way is that the engine or game source? Or is it both?

Well, Dink 1.08 is the engine, and the source of the game (of the main game) is in the develop/source.zip file (the .c scriptfiles). The engine source would be like this but then with code added for v1.08 You'd likely be able to find the new parts of code by searching for //redink1 or just by looking for parts of code that don't look like a complete Sethmess

The source.zip file is the scripts for 1.07. I want to see some of the altered scripts for 1.08.

Yes but the full install of Dink v1.08 (and probably the patch as well) would update the source.zip file in the develop directory so you'd have the scripts for v1.08. The engine source code would be released as a seperate file I assume.

I hope your right about the source.zip file. And I assumed the engine source will be seperate, just like with 1.07.

To clarify, the Dink 1.08 game source (.c scripts and such) will indeed be updated and included in the develop folder. (Funny thing, Seth didn't repack the source.zip with his 1.07 release, leaving out his two altered scripts. But we have not forgotten. ) The Dink 1.08 engine source is what I was originally referring to, and while I doubt that redink1 plans to include it in the 1.08 installer, he does plan to release it alongside or shortly after Dink 1.08 arrives.

And since a certain somebody is browsing - hey dude, you screwed up the Mog fix

You should make it so DFArc doesn't list things like DFArc.exe as a thing to play or edit dmods with.

I second that, I accidently told DFArc to do that earlier today...and it was not very useful

Yes, well it was your mistake that got me to suggest it, though I had noticed that you could before and wondered why and thought it shouldn't be that way. I didn't think about suggesting it, though.

What if I rename my Dink.exe to DFArc.exe and DinkEdit.exe to Dink.exe and the current DFArc.exe to DinkEdit.exe

Why would u do that?

To get the computer really confused

About the new screenlock - is there no way for missiles to go over the edge of the screen? One of the screens in Scarab has missiles coming in from the top of the screen during a lock, so if not I'll have to rework the screen a bit.

I haven't tested extensively, just ran through a bit of the Temple of the Ancients while working on the new Scarab patch, highlighting the arrow problem. There's also a weird disappearing wall bug on the first spear trap, but I haven't figured out which of my bugs the new engine has exacerbated yet

Edit - yup, the spear thing was definitely me.

Right. How's the bug fixing coming along? Found any solution to the white space in images & my Windows 98 crash yet?

edit - threading noob. Sorry

Arik: Hrm, I shall put that issue on the list.

DaVince: Right now I'm trying to finish the DinKC Reference v4. Going a bit slow, as reading the old entry, looking through the code to confirm behavior, and typing the new entry is not a short process.

Ah, okay then. I'll be running in windowed mode then, because Dink 1.08 seems to work correctly in windowed mode.

For the third time I wish you luck with the reference.

I noticed a problem in the external(); command in v1.08:
If you have an external which links to a non-existing script dink crashes. I tested it and it wasn't a problem in v1.07.

I know you shouldn't link to a script that does not exist, but it would be convenient if it was fixed.

It should be fixed (so should any bug, mind you) because the more likely reason for that bug to occur is; you made a typo when you wanted to call an existing script using external(), like "scirpt" instead of "script"

metatarasal: thanks, I've added it to The List.

Heh, interesting... I found that bug out last night when I was playing Knight's Tale 3, but didn't have net access.

Funny, I found it out when I was playing AKT 3 too.

Just wondering my new dmod uses more colors than are on the dink pallet. Will this new version have a higher bit rating.

Dink made my cool grass look horrid

Sorry if this has been covered I haven really followed these threads

I think it supports up to 24bit colour

So ill be able to have my better collor then? Good.

SimonK:

Figured out the oars problem... the bmp file is not in an appropriate format. Something is a little bit off, and its screwing up the engine. I can't narrow it down more than that.

If I open up the .bmp in Photoshop, convert it to RGB color, convert it back to the Dink palette, save, and re-compile into a dir.ff file it works fine.

I was wondering if you can add a function to the engine that would flush the keyboard buffer, or limit it to only a couple of entries?

I have seen posts about Alt-Tabbing back from windows and errant keystrokes are returned to the engine.

I also notice that when in a massive pillbug fight, you can stack 1 or 2 additional attacks while attack1 is in progress.

The result is:
Attack 1 finishes, Dink cannot move.
Attack 2 occurs, Dink still cannot move.
Attack 3 occurs, dink can now move but, movement keystrokes are not always left in the buffer.

My thinking is if we limit the buffer to 2 or 3 keystrokes, or flush it at appropriate times {perhaps fflush(stdin) in stdio}, then both of these issues might be resolved.

mm.

"My thinking is if we limit the buffer to 2 or 3 keystrokes, or flush it at appropriate times {perhaps fflush(stdin) in stdio}, then both of these issues might be resolved."

Input streams cannot be flushed. (Flushing invloves commiting buffers to disk and only works on output.) There is probably a special function provided by Windows or DirectInput to clear the input buffer.

However, we end up with even more problems: keys get dropped all over the place, requiring the player to hold the key down for a duration of time so that the key hits the delay between clearing and reading, which might be a smaller delay than between reading and clearing.

I got kinda a late idea, but I hope it could be implemented...

I am used to using Linux next to Windows, and would like to see all debug stats put in the console window when running Dink from a console. Maybe the command inserter could be put in that console debugger too. It would be very useful (as you can see more than two lines of code in the command inserter).

Input streams cannot be flushed. (Flushing invloves commiting buffers to disk and only works on output.) There is probably a special function provided by Windows or DirectInput to clear the input buffer

I'm a network guy and not a programmer per se, but in the real world, flushing means to purge, but committing means to keep.

In my greenness, I am assuming that the key-data enters an 'application defined' buffer, and sits there in a que until our application asks for it. Theoretically, as long as it is in que ehr buffer, we should be able to mangle it as we see fit; Altering, Deleting, etc. Of course, we would need to ensure that the data pointer remaind accurate.

Is there not a way for an application to recognize when it is no longer the active application, i.e. when Alt-Tabbing to windows? Perhaps flushing the buffer prior to losing focus and again when our Application regains focus would be sufficient.

This would not solve the repeat attack problem but should remove the errant key-data coming out of a windows session.

Just a thought,
mm

um....isn't there supposed to be a way to look at the D-Mod's map. In DFArc2, i cant look at the maps, or "edit" them...

There's an edit button, but it's hidden by default. So go to the options menu, and activate "show developer buttons".

Ummmmmmm...Options menu? What options menu?

Edit --> Options.

"I'm a network guy and not a programmer per se, but in the real world, flushing means to purge, but committing means to keep."

The first Rule of C Club: If you expect X, you're wrong.

Flushing, in the context of streams, refers to the buffering of output. Disk latency issues makes it faster to store the output in memory until it can all be written to disk. Hence, "flushing the output buffer (by committing it to disk)".

As for how input works, it depends. Some systems buffer the input, but some don't. If I remember correctly, DirectInput has an array that represents the keys and the keyboard has to be polled to check its current state. Thus, no actual buffering. The problem I was describing can be better explained as a doctor's office which admits everyone in the waiting room at the top of the hour and vaporizes everyone in the waiting room at half-past. What happens if you show up at 2:15? (Or, to put it more generally, a race-condition. It took me some thinking to realize that's what I was describing.)

"Is there not a way for an application to recognize when it is no longer the active application, i.e. when Alt-Tabbing to windows?"

Yes, windows will send the app a message. Dink tried to recognize this, and I think I might have fixed it in unDink. The problem might be caused by not checking the appropriate global variable when processing input. (I only think I fixed it because I rewrote the input handling before I knew there was a problem and subsequently didn't consider it a problem.)