The Dink Network

So what's holding me back in dmod making? That I always end up creating tools to do it better, and never get to actually making a dmod.

I'll start with some history. While thinking about writing a dmod, I read some threads on this forum about problems people were having with DinkC. I was shocked by the solutions. How can a language be so broken? Still, it is appearantly possible to write some impressive things in it.

Anyway, I thought it'd be nice to write a dmod. But now that I knew about this language, I really didn't want to use it. It's just asking for problems. Many of the quirks in it lead to bugs which are almost impossible to find. So what did I do?

As I wrote: I started writing a tool to fix this problem. That would be a DinkC preprocessor. I'm writing something that resembles normal C (no whitespace problems; for and while; no goto (I know C accepts it, but it shouldn't), real expression with operators that do what they seem to do (a *= b / 3 + 2)

Also, I don't like to memorize or look up numbers. So I use names where appropriate (for referencing sound, graphics, brains)

The next thing that stopped me from working on a dmod is that I wanted to "see" what the edited dmod looks like, without starting the editor. I think this is something most Windows users will not really understand, because they're not used to that being possible anyway. The point is that I want a file format which allows me to create statistics or do mass edits (like sprite replacer does) by using simple text manipulation tools. So I designed a format where this is possible, and a "builder" to turn that format into a dmod that can be played with freedink (and I suppose with dink.exe, but I don't have Windows and can't test that).

Now there was a new problem: this new format can obviously not be edited with dinkedit. I could edit it by hand (with a text editor), but that is not very good for many things. Can you imagine what I did to solve it? I suppose you can...

I wrote a gui to edit the map and sprite properties. This pretty much turned the project into a complete dmod editor. It's still full of bugs, but in general it works. I'll write a simple dmod to get rid of most of the bugs (which I'll encounter that way). Of course, you're all free to use the editor.

However, I like to get some form of "payment" for it, which very much suits the problem I have with uploading it to this site: I need an account to do that. So here's the deal: any of you puts enough pressure on redink1 to make him create my account and send me a new password, so I can use it, and I upload the editor.

Final detail about it: it's written in Python. I know some people dislike it, but in my experience Python code is much easier to write, and therefore more likely to get finished. And anyway, it's my editor, so I choose the language. It does make it cross-platform, too; I wouldn't be too sure about my C++ code in Windows, and anyway I wouldn't know how to compile it for Windows (and I'm not interested in learning).

I don't think DinkC has got that many bugs that are actually hard to find. Sometimes peoples' common sense just don't work for their favor.

DinkC is a little broken, but some talented and clever developers can actually take advantage of this in some cases. I think DinkC is all about bending its laws, so you can create the kinda D-Mod you want with it.

Yes, I agree. The bugs in DinkC are not hard to find, and anyway they are known. What I'm saying (well at least I meant to say that) is that DinkC allows you to create bugs in your code that are hard to find. Such as putting a space in the wrong place. If it wants to make a problem of that, that's fine, but it should shout a sensible error message then (syntax error parsing "a+=3" or something). If it does allow it, that's fine too, but then it should work. There is no feature in such behaviour that allow any cool special things to be done.

My preprocessor doesn't limit anything. You can still write anything you can write in DinkC (well, except goto into another function. I just dislike it too much. If you have a really good use case, I might consider adding it, but it will still give a big fat warning when anybody uses it).

The point is not to create a simplified DinkC, but to be able to write the same things in a sane way.

As for gotos into other functions:

void main( void )
{
  int &blah = 5;
}

void talk( void )
{
  goto proc;
procend:
  say_top("Bye &blah",1);
}

void proc( void )
{
proc:
  say_stop("Hey &blah",1);
  goto procend;
}

This makes Dink say "Hey 5" followed by "Bye 5".

void main( void )
{
  int &blah = 5;
}

void talk( void )
{
  proc();
  say_top("Bye &blah",1);
}

void proc( void )
{
  say_stop("Hey &blah",1);
}

This makes Dink say "Hey &blah" followed by "Bye 5". Once you know what's going on, this isn't too surprising. Only the engine and the run_script_by_number() function can call procedures of existing script instances. Any other procedure call launches a new script instance.

Sadly, run_script_by_number(&current_script,"proc") *will* run the procedure, make Dink say 5 instead of the variable name, but it won't return back to the code it came from.

In short: custom procedure calls launch a new script instance, with no local variables in scope. More scoping fun:

void hit( void )
{
  int &blah = 5;
}

void talk( void )
{
  say_stop("&blah",1);
}

First talking: Dink says "&blah".
Hitting: No visible effect.
Second talking: Dink says "5".

One thing I noticed is that DinkC takes the move -commands much more crucially, than say -commands. If there's an error in a say -line, then it will just skip that part of the dialog and move onward. However, if there's an error in move -line, the script will just jam up, which is quite annoying, to say the least.

I don't think it jams for move commands, only move_stop, which makes sense as it calls for an action to be completed before continuing.

I've tried contacting Redink1 on his gmail, but no replies so far. I don't think it's a good idea to "demand" that as part of the release process, because it's likely Redink1 no longer uses the email accounts that are known to us

I do really want to see what you've created^^

But shouldn't it also jam in say_stop commands? Yet it doesn't. Weird.

Good point xD

I've tried contacting Redink1 on his gmail, but no replies so far. I don't think it's a good idea to "demand" that as part of the release process, because it's likely Redink1 no longer uses the email accounts that are known to us

Someone could message him on Facebook. If no one else wants to, I will, but I think someone he's actually heard of will carry more weight.

I don't ever use facebook nor do I have an account Not my thing to go and use that xD

Heh... I'm sure you have your account faster than your editor will load my DMOD...

Okay, maybe with more than 500 mb my DMOD might be a little bit faster...

You don't absoulutely *have* to own an account to upload files. In the past, all files were uploaded by emailing them to someone, usually redink1. You can still do this. You should bug him about the account at the same time too. =)

Here's a thought on looping:

void main( void )
{
int &num = 0;

void proca( void )
{
if ( &num < 5 )
{
procb();
}
}

void procb( void )
{
&num += 1;
say_stop("Loop &num", 1);
proca();
}

I haven't given this a shot, but if I am thinking correctly, this should loop 5 times then quit. Has anyone else tried this? Will this work in dinkc like it works for C/C++?

Doesn't work. Dink doesn't say anything.

Every running script has a script number. If the same script is running twice (en-pill, for example, but it could be anything), there are two script instances, with each their own local scope. It gets better: if you use "return" in a procedure, the script instance isn't killed. This is what kill_this_task() is for.

Calling another procedure, like procb() and proca() will spawn a new script instance, with their own script number, and own local scope.

So... why even have this whole script-instance stuff? A sprite stores a script number as well, and when you punch it, the engine will make sure that the "hit" procedure of the corresponding script instance is run. The only way to control it through DinkC is the run_script_by_number() function. If a script instance is busy in a wait() somewhere (or in some of the other "pausing commands"), and suddenly the engine, or run_script_by_number() redirects its attention somewhere else, it won't go on past the pausing command. So:

void talk( void )
{
  say("Hello!",&current_sprite);
  wait(10000);
  say("Bye!",&current_sprite);
}

void hit( void )
{
}

If you talk to it, and then punch it within 10 seconds, you'll never see "Bye!", because the engine has redirected the script to run the hit() procedure.

I'm not sure if the hit() actually needs to be present. It probably does.

So is this why it does work when you use an external script? Why can the external script still use the current sprite variable, yet not interrupt the flow of the original script attached to the sprite?

Not sure what you mean. I have the following code:

// sprite.c
void talk( void )
{
  say_stop("Hi",&current_sprite);
  external("waiter","proc");
  say_stop("Bye",&current_sprite);
}

void hit( void )
{
}

// waiter.c
void proc( void )
{
  wait(5000);
}

And when I talk and wait 5 seconds, it says "Hi" and then "Bye".
When I talk, then hit it before the 5 seconds are over, it says "Hi" but no "Bye".

With &current_sprite being available in an external() script... Let me start somewhere else for a moment.
Every in-game sprite has a script-number. Anything that happens to the sprite (talking, hitting, death, push, desire to attack... those kind of things) will launch a procedure of that script. You can get this script number in DinkC by using the "is_script_attached()" function.

The other thing is that every script has a sprite number. This is the value of &current_sprite. However, it is *not* necessarily true that is_script_attached(&current_sprite) == &current_script. For example: calling external() will keep &current_sprite, but the external-script will be a separate script instance and thus have a different script number than the script that did the call to external().

Finally, using script_attach(), you *only* modify the value of &current_sprite. Checking if &current_sprite is 1000... might actually work. If it does, it'll be the case for spawn()'ed scripts, and for scripts that have used script_attach(1000).
However: It doesn't override the is_script_attached() value of the sprite you attach it to.

As far as I know, the only command that changes the is_script_attached() value of a sprite is sp_script(). However, this spawns a new script number (which gets returned, so you're not completely left in the dark). As far as I know, it's not possible in DinkC to tell the engine "Any hit/talk/etc stuff on this sprite should now run a procedure in this other script number".

About the account, why not create it yourself?

You need a confirmation email and it seems that the email server is non-operational.

Its a ploy to close down the DN, squeeze any potential joiners up out (sparodically) hence slowing the rate of newbies to a trickle then they plan to choke the life out of the place and eventually (probably) kill off the last few hangers on and shut it daown Sucks to be a dinker in these tough times.

Heh... I'm sure you have your account faster than your editor will load my DMOD...

For this, I have now added a "low memory"-mode. It doesn't use a backing store for the pixmaps, meaning it will draw directly to the window. Since drawing consists of clearing the area and then redrawing it, this makes the view flicker quite a lot. However, it can now run on my computer even without using swap.

Also, I've added goto support (including warnings).

Awesome

The e-mail server is fully operational. It's just that some people tend to use e-mails that won't delete the spams, and the e-mail boxes eventually get full.

Best e-mail address for joining TDN seems to be @gmail.

Can i suggest uploading to something like megapo... er... megaupload while the account gets created?

Can i suggest uploading to ...

You can always suggest, of course. However, I have enough places where I can put it. The thing is I want an account, and I'm hoping to make that happen.

Of course I could just use a different email address, but then I'd need a different name as well. A variation on the name I really want would be best. I could put a "1" after it, for example.

Somehow, I think that redink1 will understand that problem.

Shevek, please email me your emailaddress so I can bug redink about it.

Shevek, please email me your emailaddress so I can bug redink about it.

For anyone who wants to bug him: it's wijnen@debian.org or shevek@fmf.nl. Both receive enough spam anyway, so I don't mind to make them more public.

Which one did you use to try to register your username?

Which one did you use to try to register your username?

I used wijnen@debian.org, thinking my actions here are related to me writing free (open source) software.

Unfortunately I still don't have an account.

However, in the mean time, I do have some updates about features.

I've improved the "low-memory" support. Now it uses the same system as Dink itself, caching graphics. That works so well (and surprisingly fast) that I switched off the missing backing store, so it doesn't even flicker anymore.

I've changed the interface so it now uses only two windows instead of 5, making it easy to see everything.

I've added shortcut keys for everything, mostly inspired by vim and blender. For those not familiar with these, it may feel strange at first. The good thing is that just about everything can be done by pressing a single key. For example, to move a sprite, press m then move the mouse. Click or press enter when done.

It is now possible to select multiple sprites and move or copy them together. Other editing operations such as resize will follow.

Warp targets can be edited mostly like sprites (as far as that makes sense). In particular, they can be selected and moved. Also, when looking at a room which is the target of a warp, you see the target symbol. It is possible to go to the sprite which owns the target as well.

If people are interested, I can post screenshots (or perhaps a video, once I learn how to record that). And of course the source, but I do insist that I want an account first.

I would like some screenies

And why is it you can't make an account? Could you have a friend make one for you and just login?

He made one with the name he wants and it didnt send him an activation email so now his names taken and he cant use it. I recon keep bombarding redInk with emails surely he can reset passwords and stuff

We need someone who has access to the SQL server to make the account manually, but I don't think even Tal has the authority for this.

Shevek, what @ are you using? If already not, create a en e-mail at @gmail.com and then try to create an account. I've noticed most other @ aren't always working. Redink also uses Gmail, so I bet that's the most tested @, as well in TDN.

Note: When doing what I said above, try to use a different username than before, if it first fails. Do this, cause although it may seem the network didn't realize you're trying to make an account, it's still possible that it created the account, just never sent the activation e-mail.

Shevek, what @ are you using? If already not, create a en e-mail at @gmail.com and then try to create an account. I've noticed most other @ aren't always working. Redink also uses Gmail, so I bet that's the most tested @, as well in TDN.

As I wrote above, wijnen@debian.org. The people at Debian are all programmers. I'm pretty sure our mail system works very well. I don't particularly like Google to read my mail. They are too eager to get privacy-sensitive information about too many people.

I understand very well what happened, it is indeed as you wrote. The name is reserved by me, I just don't know how to get to it. Saying I lost my password should help, but appearantly that doesn't either (I don't get a mail from that).

I know I could get a differently named account, but I don't miss it that much. I can wait a bit longer. And it really shouldn't be such a big thing...

Gmail doesn't ask that much info at all. I've had my past e-mails on sites that asked much more questions. I'm not saying the problem is with the actual @. It's just that TDN may screw up sending the e-mails to some @. From what I've seen, everyone who has made an account recently, is using Gmail.

I'm not talking about the questions they ask, but about the fact that they read the emails that are received there. Think about it:

- They know what's in the e-mail you send
- They know what's in the e-mail you receive
- They know what you search for
- They know where you are (if you have an iphone)
- They know where you want to travel
- They know when you have an appointment, and what you're doing
- They know who your friends are

For the moment, let's assume that they aren't evil and that they will never become evil. Then still, I find it disturbing that they have a database with all this information in one place. This is a very popular target for crackers. Eventually someone must succeed in breaking into it. And I don't even want to think about what would happen if the government decides that it will use it for anti-terrorism or some other vague goal.

But as I wrote, I'm in no hurry. This certainly isn't a reason for me to request a gmail account.

They know where you are (if you have an iphone)

Apple removed this.

Yes screenshots please

Screenshots don't really show the cool features, I think. So I recorded a video. Which took a bit longer than I had hoped.

However, now it's finished. Enjoy.

Wow...that looks really, really good! One question so far: Since sprites appear to be named, will be able to search for sprites with text in addition to browsing the sprite screen?

I've named many things. Sprite sequences, brains, sprite instances, midi files, probably more. You can't search for a sprite name, but you can simply type it in. The box for that is not in the video, it's in the "extra" tab. Everything that can be adjusted in the map screen can be typed in there as well (position, size, etc).

For sprite instances, there is currently no way to find them. However, I plan to add "select sprites by regular expression", which means you can do things like
- select all sprites named "King"
- select all sprites with a number in their name
- select all food
- select all sprites with size > 100
- select all sprites with a warp set
and so on. And combinations with "or" and "and".

That, plus a drop-down box of selected sprites, which centers the view on the selected one, should give you all the search capabilities you want, I think.

However, I haven't started this yet. There are some other features I also want, which I also haven't started yet.

In other words, all this may take some time. But it's already usable.

I love the depth que and resize features!

It looks a little less fancy than WDE though, but I can see you're working on functionality first and foremost, which is clever

Looking forward to seeing this evolve, thanks for the video!

Terminalvenster

This is looking quite good indeed! I might actually go and create a Dmod myself again if you finish this, since it looks really useful and addresses a lot of the problems in DinkC and adds a lot of little useful features that would make it a joy to create maps.

Looks very useful, great work

Impressive Shevek, well done! Of course I love the multi select sprites *claps*

This looks awesome... If you don't finish it, I will personally hunt you down.... and then offer you cookies in exchange for the completion of this awesome editor.

You are my hero <3

What gui toolkit is that?

Thank you all for your kind words.

Some responses to your comments:

Kyle: Yes, I only go for functionality at this stage. But everything is very configurable (which button is where, what colours are used), so making it better-looking should be easy to do later.

DaVince: The editor is actually whatever you choose to make it spawn for you. My favorite editor is vi, which runs in a "terminalvenster". Many people here might hate vi, but that's no problem: you can set it up to spawn another editor. And for easy map making, you'll love some of the ideas I have for future versions. However, to avoid Necromancer-like problems, I'll not give details about it until it's (almost) done.

MsDink: I forgot to show that you can also move them together, but I'm sure you expected that.

Robj: I'll remember that if I want cookies, I'll suggest to you that I might not finish it.

yeoldetoast: It's Gtk+, or actually pyGtk (python wrappers for Gtk+). But the map area is just a gtk.DrawingArea which is completely handled by my code.

Looks great! I really liked the demo... have to try it out myself.

Look at that. Nicely done, shevek!

Looks awesome. Love how the Pillbug, for example, has the script already added. However, why did it move the first time you entered the screen, but didn't when you entered it the second time?

Also, get rid of all the pink. It burns my eyes!

Nice
Looking forward to this!

if (!have_fist)

Hey, that works? Pretty sure I tried it once and it didn't... off to try again

Sparrowhawk: No, that probably doesn't work for you. I'll quote my original post to explain:

I started writing a tool to fix this problem. That would be a DinkC preprocessor. I'm writing something that resembles normal C (no whitespace problems; for and while; no goto (I know C accepts it, but it shouldn't), real expression with operators that do what they seem to do (a *= b / 3 + 2)

There's more in that script which doesn't work in DinkC. Some things you can see there:
- "Normal" expressions (see above)
- No & before variable names
- No whitespace problems
- Sequence names ("item-w" is really a number, I don't want to know which; it's the sequence with weapon item images)
- Global variables don't need to be declared separately, if you define something without declaring it local, it is a global (not sure if I keep that one; I may add a "global" statement to mean this)

This script preprocessor is actually the reason I started this. The gui editor is just "extra".

Ooo yes didn't notice all that... ok now I'm really looking forward!

Now I'm really excited too! xD

Does this means that you can more than 200 globals?

Does this means that you can more than 200 globals?

No, unfortunately not. It's only a preprocessor, so after my program is done with it, it's code which (free)dink must execute. My code doesn't change the limits of dink itself, it only makes script writing less error-prone (and if you do make errors, it will (try to) tell you, so you can fix them before releasing the dmod.

I am the ghost of dinkers past.I have been brought to show unsupportive dinker's,the error of their ways.Fear me.
*makes ghostly sounds*

Global variables don't need to be declared separately, if you define something without declaring it local, it is a global

Not sure if you would want this then. Could be a real pain if you're working on a large mod and you're careless and forgot to declare one or more variables as locals.

(not sure if I keep that one; I may add a "global" statement to mean this)

Yeah, this.

Sounds great. I guess one could also add checks to see if the text in say command exceeds the allowed number of characters, and check if freeze() commands are missing matching unfreeze()?

I guess one could also add checks to see if the text in say command exceeds the allowed number of characters, and check if freeze() commands are missing matching unfreeze()?

Yes. Currently there are only checks for functions which are rewritten (like add_item, where a string argument is turned into a number), that their arguments are correct. I want to add more checks to detect errors in scripts.

If you like, I can test it for you and give you bug reports. I know enough about python to be helpful, if not enough to write anything myself. Just email it to me at dark.sign.13@gmail.com.

By the way: Excellent work! You have really done an outstanding job on your editor.

I've added "extern", which can be used at global scope to declare globals. You don't need to define them in a central place.

Also, I've made a video demonstrating my tile hardness editing. I like it a lot. Watch it here.

Do you need to have 4 corners for hardness editing or can you for example click on the corners all over that house and have it filled in to be totally hard or do you have to do it in 4 sided bits?

Looks really good shevek, hope you are writing a manual to go with it hehe

Instead of writing a preprocessor, did you ever consider adding Python (or something else) to Freedink as a scripting interface to replace DinkC? I know Beuc was planning to add Guile support at one stage.

Wow! Editing hardness has always been pain, this looks user friendly!

Do you need to

No, you don't. The editor creates an image like this:
- It creates an image with the screen and current hardness
- It then starts whatever editor you want to use for editing the image. What I showed is just how I like to edit images. You can use any other program (paint, photoshop, whatever you like). The only thing that matters is what pixels are in the image in the end.
- When you're done, it will read the image and set hardness according to what you made of it.

yeoldetoast: I considered two things:
- adding game play support to the editor (which would avoid the significant delay when testing the dmod). This would mean the editor turns into an alternative for freedink (and dink.exe). Bonus would be that I could ignore all the crazyness of dink instead of copying it. Downside is that games using the features would require my "editor", and would not be playable with original dink or freedink.
- Using python-style input for my preprocessor, instead of C-style. This would be pretty easy and has no downsides I can think of. I didn't do it so far because I assumed that most people would be more comfortable with writing C, given that dinkC does slightly resemble that.

I can't wait to try this out, I'll defiantly make another D-Mod

Omg that hardness editor I want! But, I don't get how it works internally. Does it still try to make a mix of existing hardness blocks to try to match the shape of the white area you set? Or is it pixel perfect hardness? If so, that's amazing and a giant leap forward for editing (I hate houses and churches so much >_< .

I can see a benefit to using a different language, especially if it would support math in one line, nested conditionals, ...

Man you have no idea how much I want this thing to be finished for me to play around with I saw it has gold as a setting for sprites, one of the big things WDE+ is missing so thanks for that

But, I don't get how it works internally. Does it still try to make a mix of existing hardness blocks to try to match the shape of the white area you set? Or is it pixel perfect hardness?

In hard.dat, there are 800 hardness tiles. Every tile in the tile screens has one of those assigned as default. Lots of the 800 are not the default for any tile. Some (especially the empty one) are the default for multiple tiles.

Tiles in game screens can either say "use default hardness", or they can say "use this one", which is any tile from the 800 options (except 0, because that means "use default").

In my editor, things work differently:
- Every tile screen is two images: one for the tiles, and one for the hardness.
- Every game screen either uses the default hardness for all tiles in it, or has an image containing the hardness for the entire screen.

When building a dmod, it will compute hardness for every tile in every tile screen, and for every tile in every screen which is not using default hardness. Any duplicates are detected. All unique hardness tiles are inserted into the list. If there are more than 800, it won't work, of course.

So yes, this is pixel perfect hardness. If you don't make too many hardness screens, everything works without a problem.

Oh, and there's a reason that the hardness has a name. If you use the same hardness name for two screens, they use the same image. If you are getting over the 800 limit, you can move some houses a few pixels and make the hardness of several screens identical.

I can see a benefit to using a different language, especially if it would support math in one line, nested conditionals, ...
That already works. However, I haven't checked if nested for loops work as well. I think they should...

I saw it has gold as a setting for sprites
Well, duh. Everything that ends up in the dmod can be set with the editor. (Except for all the junk bytes that are not usable by the game anyway.) I didn't know this wasn't true for WDE+.

So to optimize hardness tile usage, it would be best to try and position houses and such so the hardness will only cover the least possible amount of tiles, instead of positioning it so one edge crosses over into another tile for just 3 or 4 pixels. I get how it works now, genius, I love it

Could you provide a few examples of the new coding? I think I have a general idea of what it will look like but it's always cool to see it and dream up some stuff to use it for

One more thing, is a cutscene "builder" or assistant still in the cards?

So to optimize hardness tile usage, it would be best to try and position houses and such so the hardness will only cover the least possible amount of tiles, instead of positioning it so one edge crosses over into another tile for just 3 or 4 pixels.

That, or (and) give all houses the exact same shape and move them only multiples of 50 pixels in both directions. That way the hardness tiles can be reused.

Could you provide a few examples of the new coding? I think I have a general idea of what it will look like but it's always cool to see it and dream up some stuff to use it for

I'm working on that, but it may take a while. I haven't done a dmod before, so I'm not familiar yet with "normal" ways of doing things.

One more thing, is a cutscene "builder" or assistant still in the cards?

Yes. I was thinking of a feature to record editing operations you do. Then you can paste this into the script editor. What gets pasted are the commands to do what you edited (move, create sprite, etc). I haven't thought of the details yet, though, and might not get to implementing it any time soon.

Yes. I was thinking of a feature to record editing operations you do. Then you can paste this into the script editor. What gets pasted are the commands to do what you edited (move, create sprite, etc). I haven't thought of the details yet, though, and might not get to implementing it any time soon.


So sort of like using macros... VERY clever idea and probably the best way to handle this. I was thinking that such a thing would be much easier if you had game and editor merged, but I realize there are some negative points to this too.

>Does this means that you can more than 200 globals?

>>No, unfortunately not. It's only a preprocessor, so after my program is done with it, it's code which (free)dink must execute. My code doesn't change the limits of dink itself, it only makes script writing less error-prone (and if you do make errors, it will (try to) tell you, so you can fix them before releasing the dmod.

I assume we'll still be stuck with the same number of screens per map as well?

Yes, this is a limit set in the engine and savefile.

The limits imposed by Freedink are to maintain compatibility with the official engine presumably.

I am guessing you could simply find the arrays in the engine and increase them to whatever you'd like and recompile.

There are DMODS that do have more than 768 screens per map.dat file (Quest for Dorinthia) meaning it would be nice to support it.

Well, Seth once compiled a version of Dink for me that had all limits raised by just changing the constant value used in the array. This led to the game crashing or visually flipping out before you could even start playing :/

It would be very interesting if someone looked into this, as in, someone with significant programming skills and patience

Limits of what?

Could you provide a few examples of the new coding?

Here's a script for an axe item while being a knight:

void use ()
{
        // disallow diagonal hits, the animations don't exist.
        int d = sp_dir (1, -1);
        if (d == 1 || d == 3)
                d = 2;
        if (d == 7 || d == 9)
                d = 8;
        // use attack sequence for this direction.
        sp_seq(1, seq_code ("silverknightattack 2") - 2 + d);
        sp_frame(1, 1); 
        sp_nocontrol(1, 1); 
}

This is compiled into hardly readable but working:

void use(void)
{
	//disallow diagonal hits, the animations don't exist.
	int &tmp0 = 0;
	&tmp0 -= 1;
	int &tmp1 = sp_dir(1, &tmp0);
	int &m3d = &tmp1;
	int &tmp0 = 1;
	if (&m3d != 1)
	{
		if (&m3d != 3)
			&tmp0 = 0;
	}
	if (&tmp0 == 1)
	{
		&m3d = 2;
	}
	int &tmp0 = 1;
	if (&m3d != 7)
	{
		if (&m3d != 9)
			&tmp0 = 0;
	}
	if (&tmp0 == 1)
	{
		&m3d = 8;
	//use attack sequence for this direction.
	}
	int &tmp1 = 722;
	&tmp1 -= 2;
	int &tmp0 = &tmp1;
	&tmp0 += &m3d;
	sp_seq(1, &tmp0);
	sp_frame(1, 1);
	sp_nocontrol(1, 1);
}

...

...

Give?

I'm sure Robj will throw in a cookie jar.

Well, I suppose shevek's conditions must be met first for him to upload it.

Yes but I can't do anything about that xD

...

...

Give?

I'm sure I can nick an extra cookie jar from Kyle.

One thing though, DinkC is known to cause problems when changing variable values after an if statement without the braces. In your compiled script it only does that inside a nested if, dunno if that still might be better with all braces...

if (&m3d != 1)
{
  if (&m3d != 3)
  {
    &tmp0 = 0;
  }
}

And it also seems to make the code a lot longer, might this sometimes make it slower to run than "real" DinkC? Especially when it gets more complicated stuff. Eg, here one variable is split into three (problems with hitting the limit?) and some are initialised several times which seems a bit superfluous.

Yeah there could be a problem with hitting the concurrent variable limit this way, hadn't thought about that yet.

Actually, is there a chance you'd consider changing this limit in the FreeDink code to accomodate this? You wouldn't have to test it, we can do that for you

I read the if problem was only when using if (a) if (b) ...
Anyway, I'll just add the braces.

Yeah there could be a problem with hitting the concurrent variable limit this way, hadn't thought about that yet.

I don't think that should be a problem. The temporaries are reused for every expression. Only when putting complex expressions in a very big choice statement, could things get out of hand (all choice conditions are computed before choice_start()). Some optimizations would be possible for that. How big is the limit anyway? I'd like to add an error message for it.

Speaking of optimizations, there is obviously more room for them. Constants don't need to be put into a variable before being used. An operation on two constants can be performed compile-time instead of run-time. Just to name a few.

Is this slower than raw dinkC? Yes, a bit. Is Python slower than assembly? Yes, a bit more. Do I want to write assembly if speed isn't absolutely essential? No, thank you.

Actually, is there a chance you'd consider changing this limit in the FreeDink code to accomodate this?

I don't really have a problem changing FreeDink to be more sane, and it should be pretty easy (although the source is not very nice). However, I consider it pretty high priority to allow dmods written with this editor to be playable by others without extra effort. Installing a special version of FreeDink (or even the standard version) does seem too complicated to me. So I'd prefer to stick to the limits of dink.exe, to stay compatible, even if FreeDink would be changed.

Yeah of course the editor should function within the boundaries of the original Dink

But seperately from that improving FreeDink would be a huge boon for the d-modders in this community And I'm serious about being up for intensive testing of whatever changes you would make and don't want to spend hours testing yourself. I'm sure others here would be willing too.

One thing I've noticed now that I've been doing a lot of mapping, is that I constantly find myself begging that a "nohit" hotkey would appear out of nowhere. We needz it, Shevek! We needz it!

YES! Oh yes, we do need that xD

a "nohit" hotkey

Not sure if it's so useful with the editor (because you're more often copying than making new, and that copies the attributes as well), but I've added it anyway.

I've also added a "zoom" function, which allows you to see more tiles on a small screen. The main reason for this is that I want it to run on the Ben NanoNote, a very small computer with a 320x240 screen.

Not sure if it's so useful with the editor (because you're more often copying than making new, and that copies the attributes as well), but I've added it anyway.

Yeah, but when you add grass or flowers and small things like that, and don't want them all to look the same, it's a lot easier to just use a hotkey for it, than to always open up a new window or something like that, and click on the nohit box.

Yeah, but when you add grass or flowers and small things like that, and don't want them all to look the same,

Ah, but I have better defaults. Sprites which have several directions (creatures) are not nohit by default; other sprites are. So normally you wouldn't need to change anything.

it's a lot easier to just use a hotkey for it, than to always open up a new window or something like that, and click on the nohit box.

The nohit box is always visible, so it's just a matter of clicking it. Still, I don't like moving the pointer away to the box and back, so I prefer a hotkey as well. I just don't think it's used a lot, but that's ok.

But what about tables and rocks and such? Would they be nohit?

But what about tables and rocks and such? Would they be nohit?

Yes, they would. By default anyway. Of course you can change it. Is that not good? I can easily give them a per-sprite default.

What is the difference between nohit and 0 hitpoints anyway? Is it important? Does a missile "hit" a 0 hitpoint non-hard sprite if it isn't nohit, or something? Does the hit script of a nohit script ever get called?

Yes, nohit is a very very important concept in DinkC.

When a sprite is set to nohit, it is unable to be hit by anything. For example, you would want the fireball to fly over a mushroom, but you'd want it to explode when it hits a table.

The hit script still gets called as normal, otherwise it acts as Kyle described. Yes it is important! Having tables, rocks etc as nohit by default would be annoying.

Usually flowers, mushrooms, anything else ground level would be set to nohit, anything bigger is hittable.

Perhaps you can use image size as a way to check for hardness default. For instance:

if imageHight * imageWidth < ###
setNoHit = true

(or the like).

EDIT: or just go by hight. Whichever you think is best.

That doesn't work, because the image file of some files is actually much bigger in height and width than the actual object, with the white acting as transparency

True.

Whatever happened to "use only what you need"?

I think that is because of the'movement' within the file,the white space actually is needed. The sprite its "anchored" at one point so the animation doesnt hop all over the place - So the additional space is usually needed if the file is animated if not then yus its totlal waste .

shevek wondered if it would be too hard to make an option to "reverse" the sprites direction - this would give a little more room for creativity without increasing the file size of the mods... just a thought (as I sit here and make more sprites so I have the directions I want... )

Flipping isn't built into the engine, so no.

Whatever happened to "use only what you need"?

This discussion is only about defaults. You can always change the nohit property per sprite.

I think that is because of the'movement' within the file,the white space actually is needed. The sprite its "anchored" at one point so the animation doesnt hop all over the place - So the additional space is usually needed if the file is animated if not then yus its totlal waste.

AFAIK dink.ini allows setting a different hotspot per frame. So it shouldn't ever need the whitespace. I never noticed it was there, actually...

wondered if it would be too hard to make an option to "reverse" the sprites direction - this would give a little more room for creativity without increasing the file size of the mods... just a thought (as I sit here and make more sprites so I have the directions I want... )
Flipping isn't built into the engine, so no.

Well, I can add it to the preprocessor. That makes the sources smaller, and removes the work of flipping from the artist. But indeed, the resulting dmod file must contain the reversed graphics, so that file won't get smaller from it.

AFAIK dink.ini allows setting a different hotspot per frame. So it shouldn't ever need the whitespace. I never noticed it was there, actually...

This is true, but for some reason even within one sequence the size of the images isn't equal. Messing with the depth dot across multiple frames is realllly annoying let me tell you xD You could however write something that reads the top most non-white pixel and determine height from that. Most (all?) sequences have white space above a sprite but not under so this would work.

Hmm then its possibly not worth your time shevek thanks for considering it tho

Any news on this?

I've been feeling like making another D-Mod for some time now.. and this looks so cool that I don't want to use anything else! XD

Shevek doesn't have a user account yet.

Any news on this?

Yes. It's Christmas! And I don't seem to ever get an account, so instead I'll just publish the thing anyway. Consider it a Christmas present.

First, how to get the stuff: you need git; then you get it with

git clone http://83.163.111.92/git/pydink
git clone http://83.163.111.92/git/libgui-py
git clone http://83.163.111.92/git/xmlgen/.git

Also make sure you have Python and PyGtk installed.

In the pydink directory, do

ln -s ../libgui-py/gui.py

Then run

./makecache

Then edit pydink/config.py in your configuration directory (~/.config on unix).
Also edit the first lines of pde.gui.in to make it start you editors instead of mine.
To create an empty dmod, run

./build directory

After that, running this command again will (try to) build a dmod from the files in the directory.

The files can be edited by hand, but more easily with the editor:

./pde directory

Every command is a single key. Undo is not implemented, nor is auto-save, so be careful. Auto-backup is implemented, so if you want an undo-option, just save a lot.

The controls are:
Left mouse button: select sprite, select multiple when dragging. Keep old selection when holding control while clicking. During an operation: confirm and finish the operation (move, resize, etc).

Middle mouse button: paste selected sprites or tiles.

Right mouse button: select tiles. Similar to left button.

Keys (TODO are not implemented yet):
a set attack
b set walk
c start cropping TODO
d set die
e edit script
f fill tiles
g make group TODO
h toggle is_hard
i set idle
j jump to selected
k kill sprite
l start resizing (largeness)
m start moving
n jump to next TODO
o open group TODO
p play
q start que change
r random fill tiles
s save
t toggle show tilescreen
u undo TODO
v set visual? TODO
w enable warp and toggle select warp target or sprite
x exit (without saving!)
y yank (copy) tiles
z start screen zoom

0-9 run script TODO
/ search sprites TODO
' toggle nohit
` enter command TODO
- unselect all
= view world map
backspace restore 100% zoom
home center screen
ins insert screen
del delete screen
escape cancel current operation
enter finish current operation
space start screen panning
numpad 12346789 new sprite from collection with given direction
numpad 5 new sprite from collection with any direction
numpad 0 new sprite from non-collection sequence

In the sequence selection screens, the mouse buttons mean:
Left: change selected sprite's sequence and frame to selected frame.
Middle: add new sprite with selected frame.
Right: unused.

For many commands the pointer position when the key is pressed is important.

Screen zoom is so slow that you should only use it by pressing cursor keys, not by moving the mouse.

Feedback is very welcome.

One thing I forgot: before starting pde, you need to prepare the gui:

../xmlgen/xmlgen < pde.gui.in > pde.gui

You need to do this again only when you change pde.gui.in.

If you have make installed, you will want to edit the Makefile to edit your dmod instead of test. Then you can just use make to start the editor.

Oh, and always start things from a commandline; it sends errors and warnings to it.

Hooray

Will try this when I get the time... where's the easy .exe version?

Will try this when I get the time...

That's why I'm publishing it at the start of the holidays. That's when most people should have time.

where's the easy .exe version?

exe? What's that?

More seriously, the reason it's cross-platform is that it's written in Python, so it doesn't need an executable for every platform. Still, Windows is a bit different and I hope it works well. Please let me know if it doesn't.

My instructions were targeted at other platforms, and I should add this for Windows-users:
Like on other platforms, use a commandline to start things.
However, to start a program, Windows will not recognize it as an executable. So you have to explicitly call Python. For example

python build my-dmod
python pde my-dmod
python build my-dmod

The first line will create a directory my-dmod with some initial files. The second will start the editor. The third will build the dmod for playing with freedink or dink.exe.

Also, I'm not sure how hard it is to get git working on Windows. If that is a problem, let me know and I'll turn it into a release. However, at this stage releasing is a bit premature, which is why I recommend using git: that way you can run git pull and get the latest changes.

Ok, it's appearantly still (much) too hard. I'll try to post better instructions soon, and make it easier too.

Anyway, for now some things I learned so far:

You need python (2.7), pygtk (for python 2.7) and the python imaging library.
I created a zipfile with all you need from me here. Unpack it in the python directory, then run things as described above.

There's currently a bug in displaying the tile selection screens. I'll probably fix that soon.

Its looking very very nice does so much we always wanted it to, MD is in heaven heh!

Excellent work shevek. I am trying to get it working on Windows however when I run ./makecache it spits out this error

Traceback (most recent call last):
  File "./makecache", line 296, in <module>
    dinktree = buildtree (dinkconfig.dinkdir)
  File "./makecache", line 289, in buildtree
    for l in os.listdir (d):
WindowsError: [Error 3] The system cannot find the path specified: '/usr/share/games/dink/*.*'

I've changed what I thought was the relevant line in makecache but it still doesn't work, where can I change this path?

Here are the two lines shevek changed in mine if it's any help (and yes it was in makecache)

dinkdir = r'c:\program files (x86)\dink smallwood\'
dinkprog = r'c:\program files (x86\dink smallwood\dink\dink'

Assume you would change this to point to the path for your own dinky goodness

Epic work!

i used archlinux (but being mainly a windows user), i had to install python imaging library and since there's now python 3 and python2, had to use python2 explicitly.

Also had to change the dink dirs (/usr/share/games/dink and freedink executable) in the makecache script like mentioned above. i didn't know what to edit in pde.gui.in so i left it as it was.

i didn't understand how to edit tiles, but already managed to insert sprites and save changes. it's nice how for some itens (like gold heart) the editor defaults its script to gheart

Also, something i expected was the ability to edit existing dmods. Is this possible or not at all?

Some news. First, I have fixed some bugs, in particular one that made it impossible to change tiles.

Second, I added a feature that people who don't like the commandline will like: if you start it without arguments, it will open a directory selection window where you can select a game to edit. If you select an empty or nonexistent directory, a new game is created there.

Windows-users will want to rename pde to pde.py so they can double-click it to make it run. I think you'll need to rename pde.gui to pde.py.gui as well (not entirely sure; you'll get an error message when starting from the commandline if it's wrong).

There are two big missing features: one is editing of existing dmods. This is planned using the decompile script (which is already there, but not completely working). The other is custom artwork.

Final note for now: the editor doesn't let you edit title.txt or info.txt, but you really should edit them. In particular title.txt has some important keys:
title-script: script to run to finish building the title (for coolness on the title screen)
intro-script: script which is run directly after starting the game, before actually starting it.
setup-script: script to set everything up for starting the game.

When pressing p in the editor (if everything is set up correctly), it will playtest. In that case, the title and intro scripts are skipped, but the setup script is run. Also, it will make dink start at the pointer coordinates, not at its starting position from title.txt.

Hmm, didn't work for me. I guess I just miss out.

Still haven't got around to trying this (yet!) but a quick question: is the DinkC preprocessor built into the editor, or is it possible to use as a standalone thingummy without the map editing part?

Tried it a bit more today. Confirmed the tile copy/pasting works properly but i had trouble figuring out what to do to do it. The steps are these:

- Once started the editor with a new d-mod created with the build script, press "T"
- Select the tiles to copy with right-mouse button
- Press "Y" to copy
- Should be back to the screen that was being edited. Select the tiles you want to replace with right-mouse button
- Press "F" to fill

Also, reading your newest post, your project looks not just like a map editor, but a whole IDE-like to edit map, hardness, scripts, and an almost-completely new game engine.

Looks good

Yeoldetoast: What didn't work? The download link? That's probably because it's on my real slow computer which was busy at that moment. Try again later and it should work.

Sparrowhawk: The build script will build a dmod from a game directory. If you create a very simple game directory with only a scripts directory in it, it will only preprocess those (and create start.c and main.c). So that would mostly work. However, you cannot use the "get editor num of named sprite" feature then. But I'm sure if you want to use it this way, you'll live with that. After all, you're not naming your sprites.

anon: That works for filling an area with floor, for example. If you want to copy some tiles (from a tile screen or another part of the world), you can select them with right mouse button and paste them with middle mouse button. That's why the size of the selected tiles is visible: that's where the middle mouse button will paste to. So for pasting from tile screen, press t, then select with right button, then press t again (or y), then click middle mouse button.

The same thing works for copying sprites, but selecting them uses the left mouse button, and you can't select sprite from the sequence selection screen (but you can "use" them to be pasted or to replace the selected sequence and frame with the middle or right mouse button).

Oh, and starting things got easier. If you start pde without an argument, it will ask you to select a game directory. If you select an empty or nonexistent directory, it will create a new dmod in it. But it will have no screens. Use insert to create one (or more).

The project intends to be a complete dmod generator, so including everything you may want to use. "pde" is only the editor, but it can fire up a script and hardness editor. There's one thing it cannot and will not do, and that's editing the artwork (tiles, new graphics and music, hardbox and depth dot). I want to support using it (isn't supported yet), but not changing it. I do intend to write a separate program for doing that, though. The idea is that the build environment (what graphics you use, etc) is separated from the actual game you're making.

The game engine is completely new (not almost), but not finished yet. Also, it will not be completely compatible. It's documented a bit in the README. I'm pretty sure some people will be very happy with it.

shevek wrote:
Yeoldetoast: What didn't work? The download link? That's probably because it's on my real slow computer which was busy at that moment. Try again later and it should work.



Even though I followed Msdink's recommendation, it still produces the same error.

hmm shevek did more than that on my version ...

If you would like, yeoldtoast, I can copy the files I have in the pydink dir and send? (its working great on here) just add them to over write (tho i use psp so it will need correcting to the photo editing software u use). Lemme know where if you want it.

Just a side note shevek - did you add that one file missed out of the first zip back in??

Just a side note shevek - did you add that one file missed out of the first zip back in??

I did. However, it makes me think of something I needed to do to make things work for you.

The values that you fill in in makecache are only defaults. If the actual configuration file doesn't exist, it will write a new one with those values. If it does exist, the existing file is used.

This means that if you tried running makecache before you made those changes, it will have written a configuration file with the incorrect values. If you change them in makecache, that doesn't work, because it will not overwrite the configuration file.

So, if you want to make changes after you tried running it, make them in the configuration file instead of makecache. This means you must find out where it is.

It is in the user settings directory, called pydink\dinkconfig.py. I don't remember where the user settings directory is on Windows, though. Something like c:\users\<name>\settings\ or so. If you add a line to makecache saying

print name

directly after

name = os.path.join (p, 'dinkconfig.py')

it will tell you (before the error message) when you try running makecache again.

When writing values with backslashes in it, please make sure that you have an 'r' before the opening quote, so r'c:\...', like MsDink showed.

As to Anon's question about what to change in pde.gui (.in if you use xmlgen to generate it; the .in-file is much easier to read IMO, but if you edit pde.gui it means you don't need run (or have) xmlgen, which may be worth more for some people), you should change the values for run-script and edit-hardness. They should be commands to run in order to start a text or bitmap editor respectively. In Windows, make sure you specify the complete path to the executable. If there are spaces in it, put quotes around the command (make sure to use different quotes from the ones around the entire value). Also, if your eyes hurt from the colours, this is where you can change them. Don't touch the names, only the values. In the rest of the file, if you reorder the fields (or comment them out), the gui will show the changes that you made (after restarting pde).

Especially for those who have trouble editing the configuration file, I wrote a graphical editor for it. Get and unpack the new zip file, and run editconfig.py (by double-clicking it). Fill the fields, click save and exit and you're done.

I'm not sure if playtesting will work with anything but freedink, but feel free to try.

Thanks for your help. It works now, however it threw a few pickle.py errors along the way which then magically resolved themselves. The paths on Windows are very strange and I simply ended up changing them to local paths.

It works now

Great! I wouldn't want you to miss out, especially after your support for my attempt to get an account.

it threw a few pickle.py errors along the way which then magically resolved themselves.

It should throw some warnings about bugs in the original dink.ini. I don't think there should be errors from pickle.py, though. Ah well, if the pickling fails the thing will not start at all, so if it works, it's no problem.

The paths on Windows are very strange and I simply ended up changing them to local paths.

If you use my configuration editor, you don't need to specify anything yourself, you can just browse through the file system to select the path. Anyway, if it works, no need to change it.

In an other message, I present my first dmod. It's a nice story, which I hope will bring you some fun. It's also the first result of my editor. If you want to use the editor, and in particular the preprocessor, reading the sources may be helpful. So I published them as well. They're here.

I like especially karel/script/nocontinue.c. What and how it works, I leave as an excercise for the reader.

Oh, and it's really easy to finish the dmod. So I recommend doing that before reading the sources. That way, you also understand what you're reading.

By the way, there were still lots of bugs in the preprocessor which I fixed. So if you want to make changes and recompile, make sure that you get a new copy of the editor, or it won't work.

Like in the dmod, this link is wrong. The file is here.

Ok, it's not, because I made the same mistake again.

Now then, is it here? I should hope so.

Is it time for you to create an account? Do it.

Weird, the links got screwed but the other times they worked ok?

Link

Actually i'm the blind one since the last link shevek posted works ok. Nevermind the last post i made

i just tried to test in a simple way the while and for loops.
Either i don't know how to write them, or the preprocessor wrote it wrong.

About the while loop, i wrote (loop.c):

void talk()
{
    int i = 0;
    freeze(1);

    while(i < 6)
    {
        say("i", current_sprite);
        wait(300);
        i += 1;
    }
    unfreeze(1);

//    int j;
//    for(j = 0; j < 6; j += 1)
//    {
//        say("j", current_sprite);
//        wait(300);
//    }
}

i assigned it to some sprite, pressed "P" in the editor to test, and when talking to the sprite, Dink just froze and nothing happened.
When using the build script to compile it into a dmod, loop.c turned into this:

void talk (void)
{
        int &m0i = 0;
        freeze(1);
        while0:
        if (&m0i < 6)
        {
                goto while1;
        }
                        say("i", &current_sprite);
                        wait(300);
                        &m0i += 1;
        goto while0;
last_textwhile1:
        unfreeze(1);
}

About the for loop, i commented it in the first loop.c because when pressing "P" in the editor, it threw some errors.

Thanks

i just tried to test in a simple way the while and for loops.

Thanks. There were several bugs in there, indeed.

I think I fixed all of them. I also added support for break and continue.

The indentation of the built code may seem a bit weird, but I think it makes sense to indent the actual body of loops, even if they are implemented with goto. And it shouldn't matter for dink anyway.

Please let me know if there are any more problems.

Thanks man!

What feature should we expect next?

What feature should we expect next?

There are three things I really want soon:

Graphical cropping (now you have feedback while changing the "box" numbers, but I want it the same way as move and resize)

Custom artwork (actually, support for sound at all, and support for non-standard graphics and sounds).

Fixing decompile to allow editing of existing dmods. Well, at least everything except the scripts. I mostly want this for analyzing, and reading the original scripts will be easier than reading decompiled versions.

And of course I want to implement all the stuff that is marked as TODO in the command list.

It's been some time since I necro'd this thread, and it's about time.

As you could see in my recent screencast, the editor improved a lot. What you couldn't see there, is that I also tried to make things as easy as possible for people without a commandline (meaning Windows users). For all details, see the included README. In short:

To install, install python, PIL and pygtk and unpack the zip file.
To use it, run pde.py. The first time this should automatically run makecache.py which asks for some settings. To change them, rerun makecache.py.

To use external programs (in particular, the text editor for scripts, and photo editor for hardness), you need to change the relevant settings in pde.gui.

Please post questions and comments in this thread. In particular, I'm interested to know if makecache.py is run automatically when first starting pde.py.

The zip file is at the usual location.

More news: despite the lack of feedback, I have made improvements again.

The main feature I have added is the ability to decompile existing dmods. This means that they can now be sort of edited with PyDink. Sort of? Yes. I don't decompile scripts. So it is possible to see the tiles, the sprites (including warp), the custom artwork (which can then also be reused by other PyDink projects), but it is not possible to compile them back into a dmod. If you want that, you will need to convert the scripts yourself.

As a bonus, decompiling has several sanity checking features which may catch bugs in particular in dink.ini. For example, I used it on MsDink's shady stranger graphics pack, and it saw that she was setting some details of sprites that don't exist.

And I'll be a bit more explicit this time: I'd really appreciate you to try this out and tell me what you think about it. For example, just try to copy my actions from my dmod-making screencast. And if you want to, but don't have time, tell me when you do expect to try it out. It motivates me to know that people appreciate my work. I like the positive replies to my previous messages and would really like to hear people's experiences with the editor.

The lack of feedback isn't related to a lack of interest or enthousiasm about your editor, it's just that most remaining d-mod authors are seasonal animals. We pop up when the time is right to work on it and are dormant the rest of the time So, when I get back into d-modding full force, chances are very good that I'll use this editor to get acquainted with. I'm guessing it will be the same for others too

Yeah, chalk me up for that. I've been intending to try this out, but haven't really felt like dmodding.

It would also help if installing the editor wasn't such a huge ducking process. It does seem somewhat manageable this time though, so I'll get around to it sometime.

It would also help if installing the editor wasn't such a huge ducking process.

You do need to install some dependencies, but they're all "download, install" links. I don't know what else I could do to make it easier. There's no "installer", but that's fine because you can just run it without installing.

The only moderately hard part remaining (I think) is that you should set up your image and text editors. But if you don't do that, you can't edit hardness or scripts from inside the editor, but it will work fine otherwise. Same thing for freedink: if you don't have it, playtesting won't work, but it doesn't stop you from using the editor otherwise.

If you have a suggestion for how I can make it easier, let me know.