The Dink Network

There's not much to show really, except that it works mostly as you would expect. I've done a very fast play-through of Karel ende Elegast. If you're interested in the story, don't watch this, but play the DMod.

I've commented a bit on what you can see. One thing I didn't show is the inventory screen. It doesn't look strange, but it's not built into the player, but implemented as a script (enter.c). I needed some extra commands for it, which were useful for inventory control anyway.

Anyway, here is the video.

I like your accent. I probably should have said that the first time I heard it.

Anyways, it seems like you already know what to work on.

It seems to function very well right now, and that's good.

I'm not sure what you're looking to hear… Is there something in particular you'd like comments and opinions on?

Very nice!

The way it sounds, this editor/engine combo is something Dinkers have been waiting for for quite some time.

If you need someone to test it later down the road when you've finished the important features, just ask, as I'd love to help with that.

Also, I have a little better knowledge of Python than I do of C++, but I doubt I have enough to work on the source with you. However, I may have enough to be able to help you reach some kind of solution to problems if you are having trouble.

Good luck Shevek!

Thanks.

Is there something in particular you'd like comments and opinions on?

Not really. I'm mostly posting because Kyle asked me to. However, general encouragement and feedback about what should or shouldn't be included is always welcome.

Well, once you implement everything you talked about in the video, it sounds like it'll be a great improvement of the original. As for anything that I'd like to see added that I'm not sure you've done/mentioned:

-I would love it if the game was properly paused when the inventory was opened. In the original game, any wait timers that are in effect when the inventory is opened will continue running.
-Fixed missiles would be cool (where they always go the proper speed, and where they don't hit text or dying enemies) and something I can actually probably help you with a bit if you need it. You can also use my exploding missile fix as a reference, and check out my post (#31) at this link to see how I managed to abate the doubled speed problem, although fixing it in the editor would be a little different, I think.
http://www.dinknetwork.com/forum.cgi?MID=172046&Posts=31
-You mentioned something about the editor converting scripts? A script converter from DinkC to ShevekC would be an awesome addition if this doesn't already exist. I realize a reversed converter that goes from ShevekC back to DinkC would probably not be possible, but that is fine.
-Adding a delete savegame() function. (minor, but it could be useful)
-Make it so sp_kill_delay() works in weapon functions to get rid of the attack delay. (also minor, and whether you add it should depend on whether you want the engine to be like Dink, or like an improved Dink)

Some of those are changes I was planning to make to engine before I figured out I didn't know what I was doing. Even if you don't add any of the stuff above, it'll still be a really cool engine. If I could only pick one thing from my list, my most prized choice would be a script converter. If I could pick a second, it would be fixing the inventory wait() glitch.

If I think of any more, I'll let you know. And thanks for your hard work.

Thanks for the feedback! I'll reply to every suggestion twice, because PyDink has two target platforms: it can compile things into a real DMod, which can be played with Freedink or any other "old" engine, and it can be played natively in the player that this video was made from.

The compilation is bound to the limits of the original engine. The native player is not. However, because I want to support compiling to a DMod, the editor has some limitations.

the game was properly paused

Compiled DMods can't fix this.

For my engine, it is already done, and it is one of the reasons I didn't implement editor_type() for temporarily killing a sprite yet; I want this to work properly as well.

Fixed missiles would be cool

I didn't do anything about it for compiled DMods; it would be good to implement your script as part of the compilation.

My engine doesn't check for collisions with text sprites; I think death sprites are not nohit, I'll change that. I don't think my engine has the speed problem.

You mentioned something about the editor converting scripts? A script converter from DinkC to ShevekC would be an awesome addition if this doesn't already exist. I realize a reversed converter that goes from ShevekC back to DinkC would probably not be possible, but that is fine.

It's the other way around. When compiling, I convert from PyDinkC (I like it better to name the engine than the author ) to DinkC. I originally planned to write a script decompiler as well, to allow converting DMods to my file format. However, that is often not possible and I would have to support goto for it, which I really don't want. So I dropped that idea. This means that the following are possible:

- A DMod made with my editor can be played with my engine and compiled to a normal DMod and played with other engines (and edited with other editors, although I wouldn't recommend it; generated code is not nice to read).
- A DMod made with an other editor can not be played in my engine. I do have a decompile script, which builds a world with tiles and sprites from it. I'm planning to add hardness as well. However, it does not decompile the scripts, so these have to be rewritten before it can be played. Still, this is a great debugging feature, because my editor can jump to warping/warped to location (I never used wde, but it is a feature I missed in dinkedit).

Adding a delete savegame() function.

Good idea. I still have to implement saving. I want to implement a feature that saves are abused for as well: inter-instance communication. I want to add a config file which can be read and written by dmods, which can contain things like "player has seen this ending".

Make it so sp_kill_delay() works in weapon functions to get rid of the attack delay.

I'm not really sure what that function is supposed to do, and if I find that useful at all. I don't think I have implemented this delay that is supposed to be killed.

Thanks for the feedback.

No problem, thanks for taking my feedback into consideration.

It's a bummer that a DMOD that's already being created can't be very easily converted. I imagine that a method to convert DinkC to PyDinkC ( ) would be possible, but it could take some time to make. On the other hand, it's nice to know that you can compile an older compatibility version of a DMOD you are making.

As for the things that are fixed in your engine, like the wait() not being paused in the inventory: awesome! It's fine that they aren't fixed when compiling to an old engine format because, well, that only makes sense.

The config idea sounds great! That way, it's easier to save raw numbers/strings instead of just true/false.

sp_kill_wait() was originally designed to skip to the proper frame for attacking with Dink, so that he doesn't stand around paused for a while. It doesn't actually do anything at all though from what I can tell. Thus Dink can end up standing around for a moment after you hit the button before he actually begins his attack. If you are changing the frame the moment that the button is pressed in your engine, you have already fixed this problem.

Also...
I don't have any idea how you do it now, but for things like editor sprite limits on a single screen, I guess a warning could be displayed when a screen is no longer compatible with the original Dink Engine (when you've passed the max number of available without the PyDink engine).

I'm wondering though, does your engine support strings as variables? If so, how would this be reverted back into normal DinkC to make a compilation for an older engine?

I'm going to be thinking a bit on how goto statements could be converted systematically. I've already come up with a basic idea, but it only works if the goto and the loop start are done a specific way. I think that it is possible, but it will be tough since gotos can even jump from function to function. But I'll give it a try anyways. You should continue working on the more important things; I'll look into the goto problem and see if I can help you once you get to the stage of development where you can focus on this kind of stuff.

In case you are wondering, this is the basic idea I came up with, that isn't very comprehensive at all; I'm going to try and expand upon it to make it more useful:

loop:

choice_start();
"Yes"
"No"
choice_end();

if (&result == 1)
{
	say_stop("You said yes", 1);
}
else
{
	say_stop("You can't continue till you say yes!", 1);
	goto loop;
}

could be rewritten as:

do
{
	//add this to the beginning of every goto conversion
	&success = 1;

	choice_start();
	"Yes"
	"No"
	choice_end();

	if (&result == 1)
	{
		say_stop("You said yes", 1);
	}
	else
	{
		say_stop("You can't continue till you say yes!", 1);
		//goto loop;
		//replace goto loop with a failure, causing a restart
		&success = 0
	}
}
until (&success == 1)

It's a bummer that a DMOD that's already being created can't be very easily converted.

I agree. It might be possible to convert all "sane" scripts, but those with weird patterns of jumping through the code, and certainly those with gotos between functions, will be extremely hard to convert. However, it might be possible by duplicating the function that is jumped to instead of jumping to it.

By the way, my engine works slightly different when it comes to execution anyway, so not everything may behave the same, even when writing in PyDinkC and running in PyDink vs a diffeent engine. In particular, PyDink spawns a new script for every callback (which means your previous script doesn't get aborted when the new one starts) and has "static" variables per sprite, not per "script instance". This is often the same thing (a variable can be referenced from both hit and talk, and it will be the same variable), but not always (a script spawned from talk can still access the statics in my engine, but it can't in regular Dink, I think).

So in general, even if decompilation works, you may need to check if the result does what you want. Which means it would be a great benefit if the decompiled code is readable. Not easy at all...

It's fine that they aren't fixed when compiling to an old engine format because, well, that only makes sense.

It does, but if things can be fixed using workaround code, like your missiles fix, I'm happy to include it.

for things like editor sprite limits on a single screen, I guess a warning could be displayed when a screen is no longer compatible with the original Dink Engine

That's not very easy to detect (it would make the editor slow to check this all the time). I'm doing several such checks when compiling into an "old-style" DMod. I have to check it anyway; otherwise the data doesn't fit into the file.

does your engine support strings as variables?

No, it doesn't. It seems impossible to compile that into something that DinkC would understand. And I only recently started adding an engine to PyDink; originally it was only a preprocessor, which was intended to make writing (good) DMods easier, not to add features that weren't possible before. So I didn't implement things that could not be compiled. Since I'm working on the engine, I've added a few of them, but only things that can be mostly ignored. Although I imagine that DMods could make good use of "compare script of inventory item X". Apart from creating an inventory screen, as I did. Even though DMods creating their own custom inventory screen (not just the background, but all of it) was the main reason for moving this stuff out of the engine into a script.

It's certainly an improvement over the original, that much's for sure.

I do hope you'll eventually cross the bridge of no return for compatibility and just break free of any chains binding you from implementing truly new things like the passing of strings and other such features

We've had 15 years of the old Dink, a new one without compatibility won't be the end of the world

I agree. It might be possible to convert all "sane" scripts, but those with weird patterns of jumping through the code, and certainly those with gotos between functions, will be extremely hard to convert. However, it might be possible by duplicating the function that is jumped to instead of jumping to it.

Yeah, after some experimenting this is basically the conclusion I came up with too. Maybe you can convert the "sane" ones in the way I mention previously (since overall the code stays clean), and for others return an error message and leave them be, to keep the code from getting really messy. Then it would be up to the DMOD author to fix up the remaining goto statements that aren't sane. Since these types of goto statements are kind of rare in comparison to the "sane" ones, I think it would be a major step above having no ability to convert at all.

As for the warning when the old Dink sprite limit has been reached, you would only need to check when a new sprite is added to a screen, you don't need to check continuously; so I can't imagine it affecting the speed too much. But even if it can only be checked when you compile the DMOD for an older engine, with a message returned on which screens are incompatible, that would be good enough.

support for strings would definitely be nice, but it's not critical and it could really mess up compatibility of the new scripts, so do whatever you think is best.

Maybe you can convert the "sane" ones in the way I mention previously (since overall the code stays clean), and for others return an error message and leave them be, to keep the code from getting really messy.

Yes, I think that would be a good idea. As you write, it would be very useful to be able to edit and play existing DMods with as little work as possible.

support for strings would definitely be nice, but it's not critical and it could really mess up compatibility of the new scripts, so do whatever you think is best.

I think I'll add it at some point, but for now I wouldn't recommend using it anyway: the engine is very experimental, so I think people should use the editor to build old-style DMods. Which means they must not use any features that are incompatible with it.

the engine is very experimental, so I think people should use the editor to build old-style DMods. Which means they must not use any features that are incompatible with it.

Someone's gotta be the guinea pig who bug tests the new stuff

I don't mind doing some testing for you when the engine reaches a closer to finished state. I can test both the old DMOD style features and the new style DMOD features and let you know if I notice anything is wrong.

Also, will you be making a help file for the new engine?