The Dink Network

I've always felt MouseDink has been a little underappreciated in two ways. First, I think that many people didn't figure out how to properly play MouseDink and were consequently overly negative about the gameplay. And second, the [almost] lack of use of any of the elements from MouseDink in any newly developed DMOD, even though I tried to describe many of them in my advanced DinkC tutorial. Since creating MouseDink I've wanted to create a video where I'd talk/walk the viewer through MouseDink and show how to play it, but I've never got around to it because of the difficulty and effort it would take to record my own video. Since I'll probably never get around to it, I'm just going to write it down here as best I can remember.

First, the gameplay. I was quite explicit in the readme that MouseDink is a demonstration of a set of scripts and the gameplay was not optimised. However, I did actually give some thought and spent some time tweaking the gameplay. Unfortunately, without the video it may be hard to see that MouseDink is quite playable once you figure it out.

The gameplay was designed to still feel like "Dink" while being mouse-based. The gameplay of Dink is absurdly simple: you hit, back off, hit, back off, etc. In MouseDink you do the exact same thing. Admittedly, it's a bit weird with touch-based enemies [e.g., pillbugs] because the challenge is to stop Dink from running into the pillbugs, but it feels natural with attacking enemies [e.g., the bonca]. You click the bonca, Dink runs up and hits it, and you have to click away at just the right time then repeat. It's Dinky, and it's mouse-based, and in my opinion it feels a little bit more natural with attacking based enemies than the original Dink. Once you give it a bit of practice you should be able to kill all the enemies without much trouble. Yes I made Dink a bit quick and the "window" where you have to click back a bit small, but I wanted to make it challenging and both these things can be changed with a single number anyway. I think people may be criticising the gameplay before they master it. Also you need to click in the hitbox of the enemy.

I really like bows [at least in the Elder Scrolls series and some other games] so I wanted to make a worthy Dink bow mechanic. All ranged weapons in Dink are pretty much broken because either they work way too well or they take too long to kill and patience wears out. In sum, if they do work, there's no skill to it and no risk of you getting hurt. There's no strategy to it. So to combat this, [if my memory serves me correctly], the delay for the pullback is quite slow relative to how fast the bonca moves. You have to aim and fire quickly before retreating for the next shot. This makes the bow both useful but a little tricky and requires a little bit of skill - something not present in the original Dink.

Of course the gameplay can be altered. MouseDink can be altered to make Dink kill and dodge enemies by just clicking on them. Diablo gameplay can be completely replicated. Either of these changes are relatively trivial to the task of programming the base framework for MouseDink so I don't think the criticism that a few people have had that I didn't optimise the gameplay according to their particular preference is really fair..

MouseDink clearly also spawns ideals of using the keyboard and mouse together to control Dink. I've probably talked about this before. My desire for bow-based combat has attracted me to think about this as well, because I think it would be superior for bows. Using the keyboard to control Dink and the mouse to aim is possible and I've scripted it. It's not hard and although I've lost the scripts I could write it again. I've also written scripts such that a second player can control a second Dink, which is similar to the issue of having mouse+keyboard together.

There is a problem though, and that is being in mouse-mode disables all keyboard input except for wait_for_button. That includes disabling the key-X.c inputs. Wait_for_button only responds to a few keys [arrow keys, ctrl, shift, esc...]. So no WASD control when the mouse works. The other bother is that there is no way to know if the player is holding down a button with wait_for_button. With the key-X.c, I came up with a [lagged] solution to that, because key-X.c is run every 50/100ms or something when the button is held down. However no such solution works for wait_for_button. So, you can use the keyboard but you would have to tap the keys for the player to start moving or stop.

It's not that bad though and I was working on an arcade-like game [one screen deathmatch sort of thing] where you control Matridge and cast spells with the mouse. I didn't finish it though. I was also flirting with selecting spells based on making patterns with the mouse cursor [ala black and white] but I wasn't confident it would work perfectly. Anyway, because I'm more motivated by the challenge of scripting than a polished product, I didn't finish it.

Second, people not using elements from MouseDink. OK, I will really be blowing my own horn here, because it will require a summary of scripting inventions introduced in MouseDink. The scripting in MouseDink has obviously been more appreciated than the gameplay but still many elements that could be borrowed for new DMODs haven't been. Perhaps that is more of a reflection of the dearth of DMODs in the last few years . Nevertheless, I'm going to indulge myself here. I'd also like to offer my apologies if any of these inventions were used prior to MouseDink and I am unaware of them.

Scripting elements:
* Use of juggle variables. Juggle variables are variables used for multiple purposes. I described them in my tutorial. You need to have some idea of how waits work to use them reliably. Through using them, MouseDink uses at most 16 variables at any time, despite its unholy complexity. This makes the code hard to read yes, but it's not without purpose because of the variable limit.

* More systematic use of "supervars". Supervars are variables that hold multiple "pieces" of information in one variable. They were well described by other authors prior to MouseDink but somewhat simplistically, tending to limit variables to be values 0-9 rather than the range needed for that variable. My contribution was scripts that read/write to supervars, allowing you to choose the range so you can store variables that range for example between 0-20 or many variables with small ranges.

I believe in my tutorial I've stated that the original Dink could be rewritten to use 4-6 or so variables at max on top of the engine required variables, using juggle variables and "supervars". I think this is pretty significant because of how common it was [and still is] for people to claim they can't do something because of the variable limit. In MouseDink the data required to store the inventory is tremendous because the order of the inventory is saved. There is no way you can dedicate eg 40 variables for the inventory; it is way too much. Instead the inventory is stored in 4 [I think] variables.

* Basically rewriting all behaviors associated with brain 1 and sprite 1 into DinkC [e.g., moving, getting hit, triggering screen changes, hitting, dying]. This is the essence of what MouseDink is and I wish people would judge it on that. Anyway, replacing the important brain 1 code internally in Dink.exe with DinkC code means much more power to the developer in tweaking things.

* Dividing with integers. 1 problem which limited some developments is that you can't easily store the value of a decimal in Dink. So my solution was to inflate values by some number so that you can effectively. I think I described this in my tutorial too. So instead of trying 7/2 = 3 we can do 7000/2000 = 3500 and get that bit of information [the .5] that would be lost otherwise. Of course it's better to multiply our variables by a number such that the largest possible value we would store in the variable becomes the largest possible value that can be stored in the variable to maximise the amount of information that can be saved. [e.g. multiplying by 1000 will help us save more information than 100, but it might cause a value to overflow, so we pick the largest constant that won't cause overflow.]

The dividing with integers thing allows Dink to shoot his bow in any direction. Dividing like this may seem kind of obvious in hindsight, but it's not. For ages one of the major "problems" people were interested in were enemy-shoot scripts. There are a few that are uploaded here. They can only shoot in 4-8 directions, but in MouseDink there is an example of an enemy-shoot script that shoot in any direction [almost infinite number of directions!]. There was actually another difficulty to do this. For example, shooting an arrow 5 points right and one down is tricky. You can't just do sp_mx[x,5] because the arrow will jump across 5 pixels at time, and you can't do something like sp_mx[x,2.5], sp_my[x,-.5] because Dink only allows integers. So instead you have to do something tricky like move the arrow right by 2 every x milliseconds and move the arrow down by 2 every 5*x milliseconds. The brain smooths over motion so it's imperceivable. To write that down to deal with every possible ratio of mx to my ends with some hard to read code, but that's because it's complex, not because I was trying to make things look more technical than they are.

* Heavy use of the missile brain. Admittedly this isn't original as I've later found out that other DMODs have seen how wonderful the missile brain is [at least Dinkanoid uses it similarly]. Basically exploiting that the Dink engine enables a lot of functionality for the missile brain [animation, movement and touch] but otherwise leaves it alone [unlike the enemy brains]. From memory, in MouseDink the enemies as well as Dink and basically everything else except for the cursor and an invisible catch-all button are all missile brains.

* Use of infinite loops. Basically the use of a loop with minimal wait [eg wait 0 or 1] that runs constantly and checks for certain conditions. Very powerful
and MouseDink wouldn't be possible without it.

* Having a script constantly waiting_for_button at all time. This is how MouseDink receives keyboard strokes while the mouse is active. Also, I think I put a large invisible sprite under everything to catch mouse clicks.

Last and least

* Smooth pushable objects [check out the barrel!] Admittedly it's not quite as nice in normal Dink as it is in MouseDink, but it works there as well. For someone [Christiaan?] I modified it so momentum can travel from one barrel to another if one gets hit into another, and also so the pushing animation comes up.

There might be one or two I missed as it has been a long time since I wrote MouseDink. The health of enemies is 'saved' if you exit/re-enter a screen, for example, by using editor_seq to store the health. I'll also take this time to confess that Dink getting hurt and dying when he tries to enter a screen that doesn't exist... I don't know why that happens but it's awesome and looks intentional so I left it. The poison thing where poisoned arrows have the poisoned effect wasn't originally intentional either but it too looks awesome so I put it in properly.

So these are two things I wanted to do for a long time. Describe how to actually play MouseDink [although I wanted to do so in a video..] and describe in some more detail script innovations in MouseDink to encourage people to use them in their own scripting. I'll admit a little vanity gave me the final motivation to finally write something like this up. I think the least of my innnovations, the smooth pushable barrel, deserves more than a 6. Or finally coming up with a decent enemy shoot script after years of suboptimal ones, even by godly scripters like Paul/manauser? Let alone MouseDink that was twenty times more complex than either of those? And MouseDink isn't needlessly difficult to decipher, it's hard to decipher because it is really complicated. Picking the largest possible value to prevent overflow when "dividing," dealing with projectiles that can move with weird x/y ratios, trying to respond to keyboard input when dink.exe has disabled all but wait_for_button, trying to immediately respond to events when dink.exe doesn't inform you when they occur, having a fake Dink with a fake brain 1, optimised supervars and especially juggle variables make the code needfully difficult to decipher. Also, the thought that someone can write their own version of MouseDink without using any of my scripting technologies, using MouseDink as just a "handy reference" is totally naive to how MouseDink works. The idea of someone optimising the gameplay of MouseDink and calling it their own version while mine was merely a "reference" is offensive to me. Gameplay optimisations are the icing on the cake and 95%+ of the code would be unchanged. MouseDink with CTRL as attack is still MouseDink.

I don't think there was any malice in the review and in my opinion it probably reflects common misunderstanding of MouseDink because I've neglected polishing it or previously defending it.. so please forgive my self-indulgence to do so here, in hopes people can see MouseDink in fair light I hesitated to mention the review, but I figure it's kind of obvious it was the last bit of motivation it took for me to write this. Besides, I think I'm justified to express my offense to the idea of someone using MouseDink as a "handy reference" to "do it yourself." The solutions I came up with are too fundamental to just tackle the problems differently and yes it's vain but they are mine. I already had my Fairy Goodness DMOD bastar dised without my permission.

I'd still love to see a MouseDink DMOD, and hopefully this post reminds potential developers of the possibility

EDIT: dang, longest post ever?

TL;DR.

Well, I read the first paragraph which said you were too lazy to record your own video of MouseDink, and decided I'd record one for ya. Coming soon to youtube, buddy!

Now, to put this on the Dink Smallwood PT channel or my own? Gotta find that password for the first option.

Ha cheers dude. If you could practice it enough so you can kill the enemies without getting hit so people can see how to do it, that would be pretty awesome. Also check out the poison and the homing missiles The homing missiles target the closest enemy to the cursor but they can't make sharp turns so they miss sometimes.

say what?

I just read what you posted now, after making the video?
Guess a part 2's in order then!

Extremely interesting post. I don't think I was around when this was released and I only looked at it once for some code that I needed That means I never really got into playing it just for fun, which I think I should. Of all the files on TDN this one is by far the most elaborate and intricate scriptingwise. Too bad I really lack the math skills to figure out how all of that works.

Video's rendering, so you could always just watch someone else stuffing around in cofusion as well once its up.

I think the biggest problem is that Dink is simply meant to be played with the keyboard.

It would be interesting to see how Hotel of the Middle Night would turn out with the MouseDink. To give it more of that "Chzo Mythos" feeling.

Viiideo!
Edit it into the first post if ya want.

Thanks, it was very interesting and enlightening to see someone play it for the first time. So much confusion lol. Still doesn't replace me doing a video and you didn't master the combat, so I guess I'll still have to feel guilty about not making a video myself

I was surprised that it lagged when you entered the pillbug screen. It seemed like that had something to do with the warcries. I was also really surprised that you couldn't use arrow keys when you tried to quit. No idea what that was about, especially because you could use the arrow keys on the menu the other times you brought it up?

The man is to demonstrate that you use items to interact with the environment. You can give him the bow from your inventory by clicking the bow, closing the inventory, and clicking on him. Also the homing missiles are supposed to miss if the angle they have to turn is too strict [ignoring the weird thing they do at first].

nice place to make videos Awaits the massa playing

I was too lazy to read that. Maybe I'll play around with mousedink sometime, but right now I'm still on my first dmod, so I'm going to get through that one and then we'll see. It is coming along quite nicely though if anyone's wondering.

Mm, the menu thing might have been due to the Spacebar Equals Console thing.
Seemed to be the case somehow, it was messing me up a fair bit.

It was a pretty harsh review for sure, but I don't think I was too unfair about the things I criticized. Are you sure you're not just blind to how the gameplay is due to having played/developed the thing to death? Sure, I guess you can get accustomed to it after a while... I played MouseDink a fair bit, and the most challenge I got out of it was accidentally clicking past the critter you're trying to hit; that's just not riveting gameplay no matter how you look at it.

How much trouble optimizing it to be really good would be, I'm not sure, but it's not really a 10.0 development file in my book if you have to considerably alter it in order to make it work in a satisfactory manner. (Especially since that's difficult to do, due to the complexity, the generic unidentifiable juggle variables, jumping all over different scripts, and just generally since it's difficult to add on top of someone else's work and follow/use their scripting conventions).

Also, the thought that someone can write their own version of MouseDink without using any of my scripting technologies, using MouseDink as just a "handy reference" is totally naive to how MouseDink works.

That's obnoxious. Not every potential mouse-controlled dmod released in the future is going to be a modified version of MouseDink, even if it they borrow some scripting technologies (out of necessity). By the same logic, MouseDink is just a modified version of redink1's basement.

The solutions I came up with are too fundamental to just tackle the problems differently

Such as? Certainly there are only so many ways to go if you want screens to change by scrolling, and using missile brains for pickables/touchers is ideal, but I think there's plenty of leeway to make two mouse-controlled dmods that are quite different internally.

The idea of someone optimising the gameplay of MouseDink and calling it their own version while mine was merely a "reference" is offensive to me. Gameplay optimisations are the icing on the cake and 95%+ of the code would be unchanged. MouseDink with CTRL as attack is still MouseDink.

Ahhh, of course, if someone just modifies MouseDink it's still MouseDink. But to me, it would be offensive to call someone else's custom made mouse-controlled dmod a modified version of MouseDink when they do most of the work themself, and merely use MouseDink as a "handy reference". =)

I do think that MouseDink is a great file (and I tried to imply that in the review too, sorry if that didn't come across so strongly), I just find it to be far from perfect, hence the lowish score/blunt criticism.

And original Dink is riveting gameplay? Or point and click Diablo? Besides the gameplay is a secondary issue to MouseDink because MouseDink is the set of scripts that make it work. The gameplay is a relatively easy to optimise thing on top of that.

Such as?
Did you read my post?

The difficulty in creating a mouse based Dink game is a number of difficult problems that I offered novel solutions to in MouseDink. If someone else created a mouse-controlled DMOD it would by necessity use the same scripting technologies. But the scripting technologies are MouseDink. The other DMOD would be MouseDink with different gameplay. MouseDink is not a modified version of redink1's basement because redink1's basement doesn't have any pioneering scripting technologies that I used. It is not obnoxious. No one would blink about someone defending their graphics against use without credit in other DMODs.

I think there's plenty of leeway to make two mouse-controlled dmods that are quite different internally
You're wrong.

And original Dink is riveting gameplay? Or point and click Diablo?

Yes, I actually quite like the gameplay in Original Dink. I thought it was great when I initially got into Dink. It does get boring dmod after dmod, but it's easy to add more to, by e.g. creating new monster abilities (like enemy shoot). I don't like the bows though.

Diablo not so much, but it's okay... If MouseDink worked equally well to Diablo, I don't think I would have much to complain.

Besides the gameplay is a secondary issue to MouseDink because MouseDink is the set of scripts that make it work. The gameplay is a relatively easy to optimise thing on top of that.

In that case, I really hope you'd have optimized it. As I see it, gameplay is of foremost concern: All the coding in the world is meaningless if the end result doesn't work well. I'm also not convinced it's that simple, that there aren't fundamental problems with improving many things in the gameplay. (E.g. changing it so that you could click monsters/NPCs on the head instead of the feet)

Did you read my post?

The difficulty in creating a mouse based Dink game is a number of difficult problems that I offered novel solutions to in MouseDink. If someone else created a mouse-controlled DMOD it would by necessity use the same scripting technologies. But the scripting technologies are MouseDink. The other DMOD would be MouseDink with different gameplay.

It didn't really address this. Innovations that are difficult to imagine doing otherwise (for action/RPG type gameplay):
* using a giant button that covers the entire screen to detect clicks
* using wait_for_button() to detect keyboard strokes
* ?

..Seriously?

Diablo not so much, but it's okay... If MouseDink worked equally well to Diablo, I don't think I would have much to complain.

So if I made it so when enemies got close they just stopped and wacked at Dink, and when Dink got close he also stopped and just wacked away, then suddenly that would be great gameplay relative to the crap gameplay as it is now? What?

As I see it, gameplay is of foremost concern

So I can't release a set of scripts and have to judged on that. Like if someone releases a graphics pack and it gives criticised for the 1 screen DMOD the author adds to the zip to show the animation.

I'm also not convinced it's that simple, that there aren't fundamental problems with improving many things in the gameplay.

It is that simple because so much that you see in MouseDink is controlled in DinkC, include the actions of 'Dink' entirely.

(E.g. changing it so that you could click monsters/NPCs on the head instead of the feet)

Since when is not being able to click on the head a fundamental problem? It is 1) a design choice and 2) so easy to fix as just having a sprite with a larger hitbox shadow the enemies. Two would be easy to add because enemies already have the health bar code. Or an enemy below could be checked for when the beacon is placed.

It didn't really address this.

Go read my scripts. I commented them for you.

Honesty I wasn't that annoyed by your review, even if I do admit that it was what gave me the final bit of motivation to write the above. But that you expect me to defend my set of scripts to someone who obviously doesn't particularly appreciate scripting, doesn't understand the code, doen't understand what can be changed and doesn't appreciate or apparently even recognise the number of innovations MouseDink contains and requires.. that annoys me greatly. I have no idea what motivated you to review my file in the first place as you obviously have no interest in it.

I have to agree with Scratcher on everything he said. Don't take this personally Someone. I do appreciate MouseDink cause it's a step forward in people creating mouse controlled D-Mods. Sadly, there's a lot of bad stuff in it too. Plus, I don't feel Dink is meant to be played with a mouse. Too complicated even for a simple game like Dink.

I once had this FPS -style D-Mod in the makings. MouseDink would have been perfect for that.

Guys, it's a tech demo >_> It's not meant to be seen as the be-all-end-all way to play Dink, it's just a demonstration of an alternative control scheme. It's not competing with the default control scheme, but rather offering a novel way to play a d-mod. I agree that to use this in a d-mod one would have to design the gameplay around it in different ways than has been the norm for aaaaaall those years, but that's normal. Every editor for every game has people trying new stuff like this and it is generally well appreciated DESPITE it rarely being actually used later on. It's a testament to Someone's ingenuity and scripting prowess, mastering certain parts of the scripting process that other d-mods have rarely even touched on

Often these demonstrations lead to breakthroughs for people struggling with one novel feature in a mod. MouseDink has already done this for me

I have no idea what motivated you to review my file in the first place as you obviously have no interest in it.

Uh... So you should only ever review files you like? No wonder most reviews we get nowadays are 9+. Since we haven't really had that many people reviewing files I think it's a good thing if people just review files they feel need to be reviewed. I've also reviewed files in the past that I did not have any intention of using myself, does that make me a substandard reviewer? If a file doesn't have any purpose, does that make it unreviewable?

Now I haven't actually tried MouseDink myself, but I think it is strange to say that gameplay is unimportant for such a file. It is not like criticizing someone for the dodgy one screen DMOD that goes along with a graphics pack but more akin to criticizing someone for the dodgy hardboxes that go with his graphics. Having a good gameplay mechanism is just essential for releasing a new combat system.

It is indeed like releasing your new monster graphics with bad hardboxes saying that's not a problem as it can easily be fixed. Perhaps it can, but it limits the 'out of the box' usability of the file, so it is a valid point of criticism. In fact I recently spend some time reviewing some development files that didn't have any scores yet (inspired by this thread) and I know I used similar arguments for other files.

And if it isn't a development file but just a demonstration the point is even more valid: What's the point of setting up a demonstration that isn't optimalized? Isn't that a waste of good scripting?

Also, you don't have to defend your scripts. It is you who choose to do so by posting this thread at this point in time and by having a defensive attitude towards Scratcher's posts. I mean, if it wasn't for your responses I wouldn't have felt the need to post this particular post...

EDIT: The recent reviews I mentioned haven't actually been posted on TDN yet, I still have them in some .txt files for submission later.

EDIT2: Also, what annoys me greatly is that people who are critical of a file should have much better arguments than people who enjoy a file. It seems like giving out straight nines without much of an argument is no problem, but giving out sixes should require a well balanced essay.

I did look at MouseDink when it was released, but I admit pretty briefly and not at all since.

Anyway, a few of my thoughts:

"I think people may be criticising the gameplay before they master it."
Even if the normal hit-and-run Dink gameplay style might be a bit boring, this may be a reason why MouseDink isn't used by anyone yet.
Your D-Mod would have to be very good to make people want to continue playing it and learn the new movement and fighting system.

Plus, many developers have a fairly basic knowledge of DinkC and how it works (not that you need advanced knowledge to make good D-Mods!) and implementing MouseDink would be a right headache.

As for the scripting elements from MouseDink, people don't use them because normally there's no need to unless you're doing something fancy.
Your FIFO tutorial is great though, and really helpful

Perhaps I should give MouseDink another try sometime soon...

Edit:
I have used several of your scripting tricks:

Juggle variables: Or at least juggling scripts with wait() to keep the mouse position when changing screens. This is used in Bug Mania (with your help )

Supervars: I'll be using your scripts in Shrine of the Dragon probably.

Infinite loops, and looping with a wait_for_button: used a lot in Broken Windows.
Didn't get these ideas from you though

Dividing with integers: I've often wanted to move things in odd directions, with smooth corners and more diagonals, so this may come in useful one day...

Uh... So you should only ever review files you like?

I didn't say like, I didn't say no intention of using, I said no interest.

Fine, 6, whatever. It is this comment

Therefore, Someone hasn't created a mouse-controlled gameplay system for use in dmods: What he has done is show that a mouse-controlled dmod with actual gameplay can be done! Now you just need to do it yourself, with this file as a handy reference on how you might tackle certain problems involved with such a conversion, and what works and what doesn't.

I clearly describe MouseDink in the readme as:

This is a demonstration and public beta test of a bunch of scripts under the working title "MouseDink" which allow a mouse controlled Dink. [...] this is a demonstration of functionality.

and the file description

A demonstration of a set of scripts that enable a mouse controlled Dink interface akin to more modern RPGs.

The scripts do enable a mouse controlled Dink interface. Yet Stratcher has no interest in that achievement, no interest in the scripts, only in the gameplay. "gameplay is of foremost concern" So he has no interest in MouseDink. And the implication that the whole thing should be rewritten to make superficial [in terms of scripting] changes and this somehow makes it a new product despite that the majority of the scripting would have to be the same again frustrates me with lack of respect for scripts to be a product and a property in themselves just like graphics or music etc.

The readme also says I would help people interested in using MouseDink, implying that I would make the gameplay optimisations according to their preferences. It's not that there is a one correct way like proper hardboxes. There are many optimisations compatible with MouseDink and what is optimal would also depend on stuff like the number, speed, size etc of enemies, subjective preference and other stuff. So comparing it to a faulty hardbox is a crude comparison because gameplay optimisation is something that needs a lot of thought and to work with the developer who wants to use MouseDink. And in all honesty, I like the way MouseDink works now anyway and think it's no worse than Diablo [that is, no more crap. It's the other stuff in Diablo that distracts you from how simple the gameplay actually is]. Anyway, this is secondary.

To clarify, I was annoyed that I have to defend my scripts in the sense supposedly people can make statements such as "I'm also not convinced it's that simple, that there aren't fundamental problems with improving many things in the gameplay.", and expect me to convince them there aren't, and if I don't, apparently assume there are fundamental problems. The responsibility should be on the one wanting to make the assertions to confirm they are true, not me having to confirm they are false.

more akin to criticizing someone for the dodgy hardboxes that go with his graphics

More like releasing graphics without hardbox information and having comments on it rather than the graphics, with little concern for the quality of the graphics. And one comment suggesting someone should release the file with hardbox info and call it their own

Waah waah, cry some more. Scratcher is a meanie.

Why did this degrade into a nonsensical mess of a personal attack?

Why did this degrade into a nonsensical mess of a personal attack?

Internet arguments always turn into that.

lack of respect for scripts to be a product and a property in themselves just like graphics or music etc.

scripts are a product in themselves, just like graphics or music. However, like with graphics or music functionality is paramount. If a fantastic looking enemy graphic happens to be twice the size of a screen in Dink then the graphic is flawed. I don't see why scripting would be exempt. In fact, I think for scripts by far the most important property is how well they work. And for a system showing a mouse-based control system how could gameplay be not a part of the workings of the scripts?

Also, if a file is a demonstration file having non-optimalized gameplay makes even less sense. Like I said in my previous post: What's the point of setting up a demonstration that isn't optimalized? That's like letting people taste your new lemonade recipe but pointing out that with a little more sugar it would taste even better. It just doesn't make sense to not add the sugar yourself if you are merely interested in showing people what can be done.

I didn't say like, I didn't say no intention of using, I said no interest.

I might have phrased that wrongly, though in general you'd only be interested in files you'd like. Unless you happen to be sadomasochist.

What I really mean is that you can't redirect all criticism by redefining the purpose of your file. Some basic things that I always look for in development files are usability and ease of use. Failing on those points pretty much always results in a lower score when I review a file. Of course if the scripts need to be very complicated because what you're trying to do is very complicated you'll obviously get some leeway. (Or if doing something in a complicated manner will increase efficiency.) Just saying that your file is a demonstration of functionality doesn't change that. Though I will probably be a little bit more lenient on ease of use and more critical of actual functionality.

And personally I'd describe something that shows that something can be done without doing it itself as a missed opportunity. Like an unfinished lemonade.

Note that I actually liked reading your first post.

This is all reasonable. I admit I haven't always been that clear and I conflated separate issues somewhat. I don't think scripting is exempt from gameplay issues. And I think your earlier point that negative reviews shouldn't need to hold up to a more strigent criteria than positive reviews is a good point [although personally I think we should be encouraging as a community]. There are tons of poorly articulated positive reviews so I guess there can be some poor negative ones too.

I guess what got lost is what really irritates me is this comment

Therefore, Someone hasn't created a mouse-controlled gameplay system for use in dmods: What he has done is show that a mouse-controlled dmod with actual gameplay can be done! Now you just need to do it yourself, with this file as a handy reference on how you might tackle certain problems involved with such a conversion, and what works and what doesn't.

because I don't think it recognises scripts as a product and doesn't recognise that it is impossible to re-invent something. With all intellectual property, the first person get credit. Another mouse controlled game with a fake brain 1 [fake Dink] would be 90% MouseDink and it would be 10x easier for someone to make that than it was for me to do it first. Maybe Scratcher doesn't think that is the case but if he spent as much time thinking and coding as I did about these issues it would be obvious, and I don't think it's my responsibility to have to spend an enormous amount of time having to walk him through it.

That comment from the review bothers me much more than the score. I thought maybe I had misunderstood Scratcher on what he meant by that but he is yet to correct me so I guess not.

So to be clear, that is what bothers me the most. What bothers me slightly is that, as it should be clear from the MouseDink readme, I always intended that MouseDink is a demonstration of the scripts and I'd optimise the gameplay on interest. So reviewing MouseDink with gameplay as the primary criterion is, I think, somewhat foolish because if someone wanted to use it I could have optimised the gameplay for them. The main reason I didn't when I made it is because I didn't put in the thought on what optimal gameplay would look like. If someone else did, I would implement it. [And if it needs to be said, no one has displayed interest to me in using MouseDink.] [And finally, I think even if I made the gameplay identical to Diablo or Nox or something people would still say it's crap, because I don't think many people realise it's all the little things like spells, sound effects, graphics, item collecting etc. which give illusions of better gameplay. So without them... Honestly look at the video of the Diablo warrior I posted. Horrible gameplay, yet I like Diablo.]

Why are you calling Scratcher's review poor? He explained everything he liked and disliked about MouseDink. And why are you also calling it a negative review? I mean, he did give you more than half of the possible scores. I think 6.0. isn't that bad at all. Scratcher *could* have tried to give more constructive criticism in his review, but at least he was giving an honest piece of his mind.

But Someone, you are correct. MouseDink does do everything it promises to do. Sadly, what it promises to do doesn't seem to be of a very high value.

because I don't think it recognises scripts as a product and doesn't recognise that it is impossible to re-invent something. With all intellectual property, the first person get credit.

That comment from the review bothers me much more than the score. I thought maybe I had misunderstood Scratcher on what he meant by that but he is yet to correct me so I guess not.

I'm not sure. Do you consider your enemy shoot to be a modified version of Paul's enemy shoot? (or was it redink1 who did this first, I forget.) Because I don't, they barely resemble each other.

Another mouse-controlled dmod would only be MouseDink in the same sense, since it's the same concept (all enemy shoots need a projectile, a point of origin, and a target point). If you meant to establish MouseDink as a sort of general term for mouse-controlled dmods (in the same way I said "your enemy shoot" in the first paragraph), then sure I'd agree.

Another mouse controlled game with a fake brain 1 [fake Dink] would be 90% MouseDink ... Maybe Scratcher doesn't think that is the case but if he spent as much time thinking and coding as I did about these issues it would be obvious, and I don't think it's my responsibility to have to spend an enormous amount of time having to walk him through it.

This is just bullshoot. I'm not ignorant on the subject, and the more I think about it the more obvious it seems just how much another mouse-controlled dmod would differ from MouseDink. I doubt most authors would use self-made movement calculations for Dink for example, or the same manner of shoot calculation; both of which are a rather integral part of MouseDink.

Instead of writing an essay, you could just fill the following list with things that need to be identical in all mouse-controlled dmods.

Innovations that are difficult to imagine doing otherwise (for action/RPG type gameplay):
* using a giant button that covers the entire screen to detect clicks
* using wait_for_button() to detect keyboard strokes
* ?

And why are you also calling it a negative review? I mean, he did give you more than half of the possible scores. I think 6.0. isn't that bad at all.

Yes, I also wonder when I went from saying someone's favourite child isn't perfect in every way to hating it with passion.

Do you consider your enemy shoot to be a modified version of Paul's enemy shoot?

Yes. Paul's enemy shoot was limited to simple gradients since he didn't know about the 'divide with integer' trick. My enemy shoot script is Paul's enemy shoot script with divide with integer. I had a bit of a dilemma on whether to mention this in the scripts or readme, because Paul used the wrong gradients in his file. I have functions like his to determine the crude direction between two points [globals4.c.. compare to my enemy shoot in globals3.c] and I didn't want to have to point out why they differed. It seemed like mentioning it might degrade respect in an otherwise great file and I'm sorry to have to mention it now. I certainly would have credited Paul if I released my enemy shoot separately though.

I gave credit for building off magicman and rabidwolf's health bar and Ted Shutes' hit code examples, even though both are so heavily modified I could have written them from scratch. See the comments at the top of hbar.c to see how much I changed, and compare hitcalc.c and hitcalcf.c to Ted Shutes' example in the help file [Ted Shutes' original code didn't even work but I still gave him credit].

If there is any other code in MouseDink based on other authors that I have neglected to credit then I would like to know and correct it. As far as I know, all the other code are my tricks or just using functions in the standard ways they were designed for by Seth.

Because I don't, they barely resemble each other.

and hence I say you don't respect scripts as a product and a property. Maybe now you can understand why it bothers me that there is a comment that promotes this disrespect on the page for my file. The enemy shoot scripts are identical except Paul had to avoid divisions that produced remainders, and I didn't. All other differences are superficial differences in the implementation. The logic is in common.

[What a great example to make my point, thanks.]

This is just bullshoot.

Do you not think it would be 10x easier to make a mouse controlled game with a fake Dink now then before MouseDink?

authors would use self-made movement calculations for Dink

It's not an important point, but for the record, Dink moves by sp_target'ing the beacon, not self-made movements. It is better to use dink.exe/internal functions where possible because they are more efficient than with DinkC [but the other side of the coin is that recoding in DinkC gives you more power over the process]. Part of the reason why it would be much easier to make a mouse controlled game now is because I've already considered many design decisions like that, selecting what to rewrite in DinkC and where I can use internal code functions [like sp_target], saving another developer from having to take the time to consider those decisions.

same manner of shoot calculation

If they don't care to shoot in any direction, ok. If they shoot in any direction, they are using my code.

Ok I've tried to stay out of this, but here's how I see it.

Nobody will ever make a mouse controlled D-Mod, in that sense the file is worthless, It's too complicated and the results aren't good enough for it to be worth it.

I still think this is a fantastic file, it's not suppose to be a useful file, it's suppose to explore DinkC and show us what is possible to do with it (at least that's how I see the file).

Who cares if the controls aren't flawless if it's never really going to be used in a D-Mod? It's just an experiment and a way to showcase new scripting, and I think you guys are missing the point of it. The file is extremely important from an development standpoint, as it shows what probably is the most clever scripting of any D-Mod around.

I think the proper way to play this D-Mod is to constantly go: "Ooooh, how did he do that?"
Then look into the source, and learn new scripting techniques.

I'd rate it one of the best development files on the site.

I had a bit of a dilemma on whether to mention this in the scripts or readme, because Paul used the wrong gradients in his file. I have functions like his to determine the crude direction between two points [globals4.c.. compare to my enemy shoot in globals3.c] and I didn't want to have to point out why they differed. It seemed like mentioning it might degrade respect in an otherwise great file and I'm sorry to have to mention it now. I certainly would have credited Paul if I released my enemy shoot separately though.

Wow, you didn't even credit him? ...Yeah, giving credit can often be seen as a sign of disrespect.

and hence I say you don't respect scripts as a product and a property.

I think I'm just going to take your idea of respect with a grain of salt after reading the first quote.

Maybe now you can understand why it bothers me that there is a comment that promotes this disrespect on the page for my file. The enemy shoot scripts are identical except Paul had to avoid divisions that produced remainders, and I didn't.

I didn't actually find the actual calculations before; sorry, that's my bad, I can see they are essentially the same. (WHY are these calculations in scripts called globals.c? I understand its shorthand for "global functions" or something, but that's the least intuitive label imaginable.)

All other differences are superficial differences in the implementation.

Yeah, the nudgy movement. Because it uses this I jumped to the conclusion it calculates it differently too... I still assume the calculations don't work if you use move_x and move_y normally (wouldn't make sense to nudgify otherwise). EDIT: I see you mentioned this in the OP. It's not imperceivable.

Do you not think it would be 10x easier to make a mouse controlled game with a fake Dink now then before MouseDink?

I didn't quote that part because it's the only part that wasn't BS; I said as much in the review. It's primarily easier because 1) MouseDink serves as an inspiration, and 2) you can borrow/check out some of the problem solutions from MouseDink when you get stumped (which doesn't include most of MouseDink).

It's not an important point, but for the record, Dink moves by sp_target'ing the beacon. It is better to use dink.exe/internal functions where possible because they are more efficient than with DinkC [but the other side of the coin is that recoding in DinkC gives you more power over the process].

He does? He moves with the code in c-dms.c as best as I can tell. I admit I have a hard time reading these scripts though: I can understand individual patches of code just fine, but finding what I'm looking for and keeping up with how related functions run all over the place is really painful. (Hence why I came to the conclusion it's needlessly difficult to decipher.)

Part of the reason why it would be much easier to make a mouse controlled game now is because I've already considered many design decisions like that, selecting what to rewrite in DinkC and where I can use internal code functions [like sp_target], saving another developer from having to take the time to consider those decisions.

Such as implementing nudgy movement. I didn't mention things like this in the review because I figured picking everything apart in detail would be truly unfair, but it's a clearly visible difference from how projectiles move in OD. Under no circumstances would I want to use this kind of projectile movement over traditional use of move_x and move_y.

If they don't care to shoot in any direction, ok. If they shoot in any direction, they are using my code.

You mean they would be using Paul's code which you made superficial changes to. ;/

As an aside, I can't accept that if hell is the best method. Even a supersimple calculation like deducting the source X and Y from the target X and Y (then using move_x and move_y) gets the right direction, there has to be a better way.

Do we really need to know all the ingredients of the cake and the baker of it to know if we like the taste of it or not? Same goes here. Do we really need to know the creator of the code and everything about DinkC to know if we like the finished file or not? I don't think so.

As I said, in my opinion there are numerous faults in MouseDink that make me never want to use it or even like it. Arguing about the code and who created it isn't going to help.

And is it such a big deal anyway? I mean, yes, not everyone likes your file, Someone. Boo hoo! You're not gonna die because of that.

I didn't say superficial changes, and I didn't say I made changes to it. I said the logic is in common - they are similar approaches except for that difference, so in that sense my enemy shoot is a modified version of Paul's. Paul's script works effectvely by checking whether the gradient of the line between two points is within certain ranges. My script works by just calculating the gradient directly, with some complicated calculations to maximise the amount of information retained in the division. So the code is totally different, but Paul's is still the 'spiritual ancestor'. Maybe I should have put more emphasis on that but I thought it was more respectful to avoid potentially having to point out the silly error. Even if I didn't show proper respect, it's a moot point on what proper respect is. You can see what I meant with the health bar example. I could have just written it myself but instead I used the existing one, called mine a "fairly heavily modified version" in the readme and even put that credit on the intro screen of my DMOD. There is no point continuing if you are going to unreasonable by ignoring my comments by making jabs at me.

He does? He moves with the code in c-dms.c as best as I can tell.

Yeah you're right.

Skull: And is it such a big deal anyway? I mean, yes, not everyone likes your file, Someone. Boo hoo! You're not gonna die because of that.

That's not what it's about.

Yes, that is exactly what it is about. It's obvious you feel disappointed that your file isn't loved by everyone. Now the conversation has taken a new direction and you're forgetting your original point.

You should be glad so many people seem to like MouseDink. Honestly, I'm surprised so many people do.

So the code is totally different, but Paul's is still the 'spiritual ancestor'. Maybe I should have put more emphasis on that but I thought it was more respectful to avoid potentially having to point out the silly error.

I don't understand what's disrespectful about pointing out an error, as long as you don't do it in a nasty manner. This is my idea of respect: Give credit for anything that you used or that inspired you, then do whatever you like.

Even if I didn't show proper respect, it's a moot point on what proper respect is. You can see what I meant with the health bar example. I could have just written it myself but instead I used the existing one, called mine a "fairly heavily modified version" in the readme and even put that credit on the intro screen of my DMOD.

There would have been nothing disrespectful with just writing it yourself, and crediting Magic / Rabid for the original work, though.

There is no point continuing if you are going to unreasonable by ignoring my comments by making jabs at me.

Hmm, well I'm not too proud of my last few posts. I kind of lost the overall focus on what I was trying to get across, and it's meaner than it needs to be. Often happens with the unholy quotefest discussion format.

Yes, that is exactly what it is about. It's obvious you feel disappointed that your file isn't loved by everyone.

I agree that is at the heart of it. Like I mentioned before, this really does remind me of a father who is a bit overprotective over how perfect his boy is. =)

The father: "My boy is special!"
The son: "I'm unique!"

And that he is Whether the boy will succeed in life or not is another matter entirely. But that doesn't take away from his characteristics.

I have the feeling people would be more willing to accept this scripting wonder if it was implemented in a real d-mod, but obviously that wasn't the intent of this file. I love a challenge, but even I wouldn't be very inclined to "risk" my d-mod not being played because it uses mouse controls. Yes, it apparently works if you master it, but in this day and age who will sit through hours of learning a new control scheme when they're used to the same old controls for more than TEN years? It would have to be VERY good indeed.

Hmmm... Perhaps a late reaction, but still my 2 cents:

I guess what got lost is what really irritates me is this comment

Therefore, Someone hasn't created a mouse-controlled gameplay system for use in dmods: What he has done is show that a mouse-controlled dmod with actual gameplay can be done! Now you just need to do it yourself, with this file as a handy reference on how you might tackle certain problems involved with such a conversion, and what works and what doesn't.

I'm not sure I really lost that. Like I said I think that a demonstration can be held against even higher functionality standards than if it where a 'normal' development file since demonstrations aren't meant to be fixed up and used like a 'normal' development file. So what I simply tried to say is that the point scratcher made doesn't become any less valid because mousedink is a demonstration file. And, having read the readme file myself I don't think it is all that clear from the readme that MouseDink is meant to be a collection of mouse control technologies rather than an actual working control system. I think the other reviews see things the same way. (Or am I now misreading your posts by calling MouseDink 'a collection of mouse control technologies'?)

Perhaps you can say that there is a lack of appreciation for what has been achieved, but I think this is a personal preference. Some people love crazy new gameplay ideas while others always look for a well working project no matter how revolutionary the concept is. Most people (I think (and hope)) are somewhere in the middle of this but you'll always have some tendency to think one way or the other. You can also see that in the other reviews mousedink got, those people really loved the revolutionary gameplay aspect. Personally I'm more leaning towards actual usability of a file, so if I where to ever write a review for MouseDink I'd probably also be more critical about usability...

Now one thing that has been hanging over this discussion a bit is something I really loathe: The idea that MouseDink was developed to patent mouse control so that everybody who uses mouse control must credit you. As if you can release a file without complete functionality (Just a demonstration, not a file for actual implementation) to claim a certain technology so that everybody using that technology in the future must credit you. That's something I hate because it isn't helping anybody if you can just release a file to patent a DMOD-making technique. Now I'm not saying you shouldn't credit someone when you used a lot of his ideas to make your own variety, it's just the fact that I don't think any file should ever be released just for this purpose. Should every cheat file that allows you to unlock a screen credit this file?

I think this discussion about Paul's enemy shoot is a good example. I finished my own version of enemy shoot for my contest entry just two days ago. Now I took a look at Paul's script and decided that it was needlessly complex for what I was trying to do. The demands I had for my enemy where very different, I think it would perhaps have been more work to get it to work exactly as I wanted then to rewrite it from scratch. So obviously I decided to rewrite it from scratch. This also meant I developed a quite different algorithm. For a large part this was because I had different demands for functionality but for another large part this was simply because I happen to be a different programmer. I think an algorithm closer to mine could have worked for enemy shoot as well, and I think an algorithm closer to Paul's could have worked for me.
Now should I credit Paul for his enemy shoot system? Not in my opinion, I have looked at his file to get some general ideas about how aiming works but fundamentally I have developed my own system which has its own distinct algorithm. I'd only credit someone for being the spiritual ancestor if he has had a major contribution to the ideas for (a distinct part of) my own work.

And if I happen to reinvent something that has been used before? Should I still credit that person even if his work hasn't at all contributed to my own? I think everybody should just be honest about whose work they have used so nobody can resort to release development files just for patenting a technique.

EDIT: Actually, reading through some of the posts on this thread I see that I perhaps should have looked at your enemy shoot as one of the things I did differently was to have more angles at which the enemy could shoot. Having said that, I honestly haven't looked at your file, so in line with what I said I don't think I have to credit you for your enemy shoot when it hasn't had any influence on my own. Even though I might have reinvented some things.

And, having read the readme file myself I don't think it is all that clear from the readme that MouseDink is meant to be a collection of mouse control technologies rather than an actual working control system. I think the other reviews see things the same way. (Or am I now misreading your posts by calling MouseDink 'a collection of mouse control technologies'?)

I don't know what you mean that to imply. This is what I say in the readme

Just to make it clear: this is a demonstration of functionality. So, the graphics are just placeholders, and some gameplay things haven't been considered.

It is meant to be a working control system, but not in an optimised state. If it wasn't a working control system it wouldn't be a full demonstration. It should be clear from the inventory screen how I intended MouseDink. The inventory screen is fully functional, the graphics are done enough to demonstrate its function, but it's not optimised any further [e.g., I didn't even bother to label the 6 equipment slots].

I think both Kyle's description of MouseDink as a tech demo and iplaydink's description of MouseDink as an exploration of DinkC are accurate [and I thank them for their kind comments]. Kyle's description is more accurate to how I presented MouseDink, but iplaydink's description is more accurate to why I wrote MouseDink. I have been focusing on the former because focusing on the latter and denying gameplay issues were relevant at all seemed lame and I hoped to seek middle ground. I'm happy for people to comment on gameplay issues. I just think focusing primarily on them devalues the worth of scripts/tech demos. If everyone judged MouseDink primarily on the gameplay or how easily it is adopted into other DMODs, I wouldn't have optimised MouseDink for those things; I would have simply not released it.

The idea that MouseDink was developed to patent mouse control so that everybody who uses mouse control must credit you.

"Patent"? First, I didn't "patent" anything. The code is freely used by anyone. Second, I didn't release MouseDink for credit. I wrote MouseDink for the challenge. Not that why I developed MouseDink has any relevance to anyone but me.

That's something I hate because it isn't helping anybody if you can just release a file to patent a DMOD-making technique

How is releasing MouseDink not helping in any way? Any way?

Should every cheat file that allows you to unlock a screen credit this file?

No, because that file has no novel scripting, unlike MouseDink. Even Scratcher accepts that it would be 10x easier to write a mouse controlled Dink using MouseDink as a guide. That is a product in itself, something that is worth releasing for that reason alone, and something that is worth being recognised as a valid contribution to the website even if only for that reason. That is where my 'credit' comes in. It is not to limit or control ["patent"] scripting, it is to recognise that scripts is a product in itself and a valid and welcome contribution.

...resort to release development files just for patenting a technique

Why is their motivation relevant? If they released a developmental file with novel scripting that enabled authors to better their DMODs, then why haven't they made a contribution? [Or even if their novel scripting is merely an interest to people like iplaydink and me for the sake of scripting itself?]

Should I still credit that person even if his work hasn't at all contributed to my own?

If you claim to invent something, you should mention you weren't first

should have looked at your enemy shoot as one of the things I did differently was to have more angles at which the enemy could shoot

Really. How does it work?

You know what, with about 3-4 developers left that could make something like MouseDink (and that's stretching it if you think of the difficulty) I don't see why it matters who gets credit for what anymore. Point is, nobody else will attempt a MouseDink, of this I'm sure. So there is no patenting to speak of. It's also a silly term for use in an open community I think at this point anything that's released or was released in the past is public property. Story of abandonware applied to development files Doesn't mean that credit shouldn't be given anymore of course, but I think nobody here would skip credits if they know who they're taking it from.

I agree with Kyle. Also, I think a debate reaches a point where people must agree to disagree and leave it at that.

I don't know what you mean that to imply.

What I mean is that in this thread you've focused on the performance of actually writing these scripts rather than the performance of their function. So I deduce from that that according to you the real merit of this file is the scripting technology behind it, not the functional performance. This is not something I would deduce from the readme, which starts with:

This is a demonstration and public beta test of a bunch of scripts under the working
title "MouseDink" which allow a mouse controlled Dink. I'm pretty happy with the
result. I think it's superior to the standard way of controlling Dink.

From this I really get that you're trying to show off a mouse control system for Dink, not just a demonstration on how such a system could be realized. That's why I can't see why the comment you where so unhappy about wouldn't be valid criticism. Now as I wrote in my previous post I too think we should find a middle ground between appreciating novel scripting techniques and focusing on functionality only. However that doesn't make the criticism invalid. Perhaps a little bit more text spend on the quality of scripting wouldn't have hurt, but the basic points that where addressed don't seem at all unreasonable.

If everyone judged MouseDink primarily on the gameplay or how easily it is adopted into other DMODs, I wouldn't have optimised MouseDink for those things; I would have simply not released it.

Well, I suppose it's good people have different opinions then.

The idea that MouseDink was developed to patent mouse control so that everybody who uses mouse control must credit you.

Glad that is cleared up. Note that I didn't say MouseDink was released to patent mouse control. I said that that feeling hangs over this thread which is because of all the discussion of crediting people I suppose. I would loathe a file being released purely to claim a certain scripting technique.

How is releasing MouseDink not helping in any way? Any way?

A file purely released for claiming a DMOD making technique wouldn't be helpful, that's what I meant to say. I was never trying to say that MouseDink wasn't being helpful, I'm sorry if you understood it that way.

What I mean by saying that it isn't helping (perhaps I should have left out the 'in any way') is that if a script has limited functionality but does demonstrate a technique could lead someone wishing to develop something similar himself to be discouraged because he has to credit someone else for a lot of work (since the other person used this file to 'patent' the technique) but he still has to do a lot of work himself. Doing a lot of work yourself without getting the credit for it yourself is highly counter-productive. That's what I mean by releasing a 'patent development file' not being helpful in any way.

If a script is a good help that really reduces the amount of work someone else has to do to get something to work, of course that is a helpful contribution. The 'patent' development file I'm talking about is the kind of file that is not helpful but does contain a certain technique. Releasing such a file is, in my opinion, indeed not helpful, period.

If you claim to invent something, you should mention you weren't first

That's a long way off having to credit someone for their work. Of course you can't say that you where the first to think of something when you weren't. However I wouldn't have a problem with not mentioning the other file and just writing it from scratch yourself. You shouldn't say you 'invented' it, but you did 'create' it.

Really. How does it work?

Short answer: Wait and see

Long answer: Here's the aiming part of my script, comments are the ones also in the original script:

//And do the shooting:
//For that we first need to figure out where Dink actually is..
&dix = sp_x(1,-1);
&diy = sp_y(1,-1);
//and the monster's position:
&mox = sp_x(&difper1,-1);
&moy = sp_y(&difper1,-1);
//Now let's see how they compare:
&dix -= &mox;
&diy -= &moy;
//Firstly, when Dink is at the exact same location as the monster
//No shots will be fired:
if (&dix == 0)
{
if (&diy == 0)
goto loop;
}
//Now for simplicity's sake I just work with positive numbers now
//I'll add the negative values later, but this reduces the amount
//of work quite a bit... So &mox and &moy now hold the positive
//values for &dix and &diy
&mox = &dix;
&moy = &diy;
if (&dix < 0)
&mox * -1;
if (&diy < 0)
&moy * -1;

//Okay, now that the negative values have been removed
//we save directions in &posx and &posy.
if (&mox > &moy)
{
  &posx = 4;
  &posy = 0;
  if (&moy > 0)
  {
    &posy = &moy;
    &posy * 4;
    &posy / &mox;
  }
}

if (&mox <= &moy)
{
  &posy = 4;
  &posx = 0;
  //Just so we don't divide by zero:
  if (&mox > 0)
  {
    &posx = &mox;
    &posx * 4;
    &posx / &moy;
  }
}

//Okay, now we have directions we will need to reintroduce negative values:
if (&dix < 0)
&posx * -1;
if (&diy < 0)
&posy * -1;
//Yes, it's easy as that.

From there onward the values of &posx and &posy will be used as values for sp_move_x() and sp_move_y() to aim where Dink roughly is. You can edit the speed of the projectile by choosing a different value than '4' in this script. The higher the speed the more accurate the aiming. Of course this script truncates x and y values rather than rounding them off, but I'm happy with the accuracy I obtain using truncation.

Oh, and &difper1 is a juggling global that I use a lot to refer to sprites other than the one the script is attached to. In this case the firing loop is in a spawned script so that the hit/talk procedures don't interrupt the firing loop.

EDIT: Reading over my (and your) post again I don't feel we really disagree much. Mostly a difference of opinion regarding how to trade off functionality with scripting achievement.

I wish I could write scripts like that

EDIT: Reading over my (and your) post again I don't feel we really disagree much.

Yes. I don't like the word patent.

Long answer: Here's the aiming part of my script, comments are the ones also in the original script:

Yes, I don't think you should credit me. However, although I probably exaggerated the similarities between my script and Paul's, I would have gladly called my script an optimised version of your script if you had released it first and I saw it, and I wouldn't think that means you would get credit for my script or it would discourage me in any way.

Anyhow, for purely constructive reasons I'd like to compare my script and yours. Both scripts work by dividing:

50.&posx = &mox;
51.&posx * 4;
52.&posx / &moy;

so lines 50 and 52 are the heart. My script has the same heart. However your script is inaccurate, very much so at some angles, and the speed of the projectile is dependent on the angle [i.e., at some angles it will travel faster]

My script differs for three reasons:
1) It optimises how much information is retained in the division
2) It uses a DinkC loop to move the projectiles so they can move with non-integer mx/my
3) It tries to ensure consistent speed regardless of direction [I forgot about this while describing it in the original post]

Three is done by ensuring the equivalent of &posx + &posy is equal to a constant independent of angle. It should really be the sum of the squares of those two values, but squaring stuff leads to overflow really easily, so I took the sum as an approximate equation.

The result is that my script has no visible inaccuracy and the speed is more consistent. Check out aiming is globals3.c and movement in w-fire.c [firloop]

Note that distances in Dink are often calculated in a square rather than a circle. Common logic dictates that every velocity on a circle centered around (0,0) will have the same speed. However you walk a couple of screens to the right with Dink (just keep on pressing the right button) and while keeping the right button pressed you also press the down or up button you'll see that Dink's horizontal velocity isn't really changed by the fact that he is now moving diagonally.

So really the speed distribution I'm using is in line with Dink's general gameplay mechanism. We also see this with the original fireball which has a speed of 6 and diagonally also gets a horizontal speed of 6. So I wouldn't say my missile script has a less consistent speed, it rather has a different philosophy about what a constant speed is.

Actually I'm convinced that the speed of my missiles is more consistent. As using a constant sum of &posx and &posy also distributes the velocity values over a square but now tilted around 45 degrees. This biases the speeds in the same way as mine, but now biased along the axis rather than around the diagonals. As I explained earlier Dink itself has a speed biased towards the diagonals, so I'd say my system is more consistent in its speed.

Obviously your script is quite a bit more elaborate, with a more efficient use of variables (though mine could be rewritten to use only 4 locals too). It's obviously weighing off advantages, my script is easier to write/edit while yours can aim more accurately.

And as far as crediting people goes, for me there is just one rule: If you use someone else's work give him due credit. If you don't, don't. For graphics/music this can easily be checked, for scripts it can't. So it just comes down to honesty.

EDIT: Now we've discussed this script so much, I think I'll rewrite it so it rounds rather than truncates directions. Shouldn't be too difficult.