Reply to Re: Why Can't I Quit You, DinkC?
If you don't have an account, just leave the password field blank.
I'm pretty sure it's possible, but let me first explain what the problem is you're seeing.
DinkC has a pretty weird way of multi-threading. There are several threads ("scripts") that can run concurrently, but not in the way they do in other systems.
Firstly, there is no preemption (they don't interrupt each other). This means a running script will not be interrupted by another script; events are not handled except when no script is running. This is ok, because the script stops running when it does wait (or *_stop), so at that point another script can run. This means it feels like all scripts run at the same time.
However, here's the tricky thing: while every other program I know would start a new script for a new event, DinkC DOES NOT. When you hit an enemy, it checks if there is already a script attached to that enemy and if so, it will tell this script to continue running from the event function. This is fine if it's doing nothing (the last event was handled and has returned), but it is very bad if the last event was still running, for example doing a move_stop. Because in that case the old event function will be aborted and execution will instead go to the hit function. When that returns, it will not go back to the original event (which would have made sense), but it will just stop and wait for a new event.
You can imagine that a sprite which has an endless loop of move_stop commands does not like this at all. When you hit it, the loop is interrupted and it is not resumed.
As a solution, I'd say you should keep a counter of which part of the move is currently being done in a variable (it doesn't have to be global; non-global variables are per-script, and all this is within one script, that's the whole reason this problem exists in the first place), and at the end of the hit function (and any other function that you want to work) explicitly restart the loop. The loop must then check this variable to know which part of the move it needs to continue with.
Does that make any sense?
DinkC has a pretty weird way of multi-threading. There are several threads ("scripts") that can run concurrently, but not in the way they do in other systems.
Firstly, there is no preemption (they don't interrupt each other). This means a running script will not be interrupted by another script; events are not handled except when no script is running. This is ok, because the script stops running when it does wait (or *_stop), so at that point another script can run. This means it feels like all scripts run at the same time.
However, here's the tricky thing: while every other program I know would start a new script for a new event, DinkC DOES NOT. When you hit an enemy, it checks if there is already a script attached to that enemy and if so, it will tell this script to continue running from the event function. This is fine if it's doing nothing (the last event was handled and has returned), but it is very bad if the last event was still running, for example doing a move_stop. Because in that case the old event function will be aborted and execution will instead go to the hit function. When that returns, it will not go back to the original event (which would have made sense), but it will just stop and wait for a new event.
You can imagine that a sprite which has an endless loop of move_stop commands does not like this at all. When you hit it, the loop is interrupted and it is not resumed.
As a solution, I'd say you should keep a counter of which part of the move is currently being done in a variable (it doesn't have to be global; non-global variables are per-script, and all this is within one script, that's the whole reason this problem exists in the first place), and at the end of the hit function (and any other function that you want to work) explicitly restart the loop. The loop must then check this variable to know which part of the move it needs to continue with.
Does that make any sense?
