The arrow keys
Does anybody know where the commands for the arrow keys are located, and if it's possible to change it so they won't do anything?
Nope
That's what I wanted to do in "Platform Dink" and "Falldink", but they are hardcoded.
THere are workarounds... Like if you want to disable them you can place dink in hardness (and force one direction) or freeze him... or have another sprite as a main character that doesn't have a dink brain and make the actual dink invisible...
If you say exactly what you want to do me and other people can help you come up with ideas how to solve it!
That's what I wanted to do in "Platform Dink" and "Falldink", but they are hardcoded.
THere are workarounds... Like if you want to disable them you can place dink in hardness (and force one direction) or freeze him... or have another sprite as a main character that doesn't have a dink brain and make the actual dink invisible...
If you say exactly what you want to do me and other people can help you come up with ideas how to solve it!
Actually, Platform Dink is exactly what I'm trying out here. I'm attempting to make that annoying stuttering go away when jumping. While I'm at it, I'm also trying to come up with a better key to use for jumping, which seems to be beyond the same problem.
Oh! Cool...
Well try to do what "Someone", suggested in his review! Make an invisible wall that is just above dink and let it follow his x-movement and jump. This would prevent the player from walking up!
Also I think the best key to use for jumping is actually the "Use item"-key (That means, make it an item-script), this would ensure that the key is easy to use on all versions of dink!
Well try to do what "Someone", suggested in his review! Make an invisible wall that is just above dink and let it follow his x-movement and jump. This would prevent the player from walking up!
Also I think the best key to use for jumping is actually the "Use item"-key (That means, make it an item-script), this would ensure that the key is easy to use on all versions of dink!
Well try to do what "Someone", suggested in his review! Make an invisible wall that is just above dink and let it follow his x-movement and jump. This would prevent the player from walking up!
I could be totally wrong on this, but wouldn't that still cause stuttering when Dink is falling down? I can see how the invisible wall would work when jumping up, but am not sure if it'd work when coming back down.
And about the Use item -key thought, that's a splendid idea! Can't believe it didn't occur to me.
I could be totally wrong on this, but wouldn't that still cause stuttering when Dink is falling down? I can see how the invisible wall would work when jumping up, but am not sure if it'd work when coming back down.
And about the Use item -key thought, that's a splendid idea! Can't believe it didn't occur to me.
And about the Use item -key thought, that's a splendid idea! Can't believe it didn't occur to me.
Haha.. well it didn't occur to me when I was making it, so don't feel bad
I could be totally wrong on this, but wouldn't that still cause stuttering when Dink is falling down? I can see how the invisible wall would work when jumping up, but am not sure if it'd work when coming back down.
Hm.. yeah that was the part that confused me back when I read the review, so I never updated it.. buit you could make it so that the platform under dink moves down in the gravity-script along with dink, and also is pushed up by the platforms at the same rate as dink. All you'd need is a global variable to define the platforms so that you can move them from your gravity, platform and jump script!
Hope that's not too confusing
Haha.. well it didn't occur to me when I was making it, so don't feel bad
I could be totally wrong on this, but wouldn't that still cause stuttering when Dink is falling down? I can see how the invisible wall would work when jumping up, but am not sure if it'd work when coming back down.
Hm.. yeah that was the part that confused me back when I read the review, so I never updated it.. buit you could make it so that the platform under dink moves down in the gravity-script along with dink, and also is pushed up by the platforms at the same rate as dink. All you'd need is a global variable to define the platforms so that you can move them from your gravity, platform and jump script!
Hope that's not too confusing
Hm... I just thought, wouldn't it be almost better if the jumping itself was completely removed, and instead an invisible platform that followed Dink, would raise him up from the ground, and lower him back?
EDIT: Or it could just be removed when Dink's in the air and then he'd fall back down on his own, of course.
EDIT: Or it could just be removed when Dink's in the air and then he'd fall back down on his own, of course.
A much better way to do the whole platform/collision thing than I did it would be to use the button-brain (brain 14) for the platforms, the same brain that is used for the buttons on the main menu.
I've read that this is also usable for dink when he is not a mouse pointer.
This way you could have a variable that said that you only fall when it is 1. Then when you hit a platform the platforms "buttonon()" function is played, which sets the variable to 0, which means the script of dink falling is not run. Then when you jump off or walk off the platforms "buttonoff()" function is called (in the main menu you can see how the button changes when you move off it again). This function would set the falling variable to 1 again allowing dink to fall.
This would keep dink from constantly shaking from the pushdown/pushup functions that are in place in my dmod!
God I'm brilliant, XD
EDIT:
"Hm... I just thought, wouldn't it be almost better if the jumping itself was completely removed, and instead an invisible platform that followed Dink, would raise him up from the ground, and lower him back?."
Hmm I'm not sure I understand what you mean.. :/
EDIT 2:
Here is the section in DinkC reference:
"Info on brain 14 (button brain):
ManaUser: "Brain 14 'can be used in game as well.' I never really took
notice of that before, but I think it may have some real potential in-game.
Brain 14 can call three special procedures: buttonon(), buttonoff(), and
click(). Click() only works when sprite one is a mouse pointer, but the
other two work with Dink as well. buttonon() is a lot like touch(), but
it's called only once each time Dink touches it. It will only be called
again only if he moves away and back again. Buttonoff() is called when
when he breaks contact with it. This could be even more useful since there
is no 'untouch' procedure."
Hmmm. Sounds like using buttonon() instead of touch() could do away
with all that nonsense of toggling sp_touch_damage() between -1 and 0...]"
I hope you understand what I was trying to say after reading that!
I've read that this is also usable for dink when he is not a mouse pointer.
This way you could have a variable that said that you only fall when it is 1. Then when you hit a platform the platforms "buttonon()" function is played, which sets the variable to 0, which means the script of dink falling is not run. Then when you jump off or walk off the platforms "buttonoff()" function is called (in the main menu you can see how the button changes when you move off it again). This function would set the falling variable to 1 again allowing dink to fall.
This would keep dink from constantly shaking from the pushdown/pushup functions that are in place in my dmod!
God I'm brilliant, XD
EDIT:
"Hm... I just thought, wouldn't it be almost better if the jumping itself was completely removed, and instead an invisible platform that followed Dink, would raise him up from the ground, and lower him back?."
Hmm I'm not sure I understand what you mean.. :/
EDIT 2:
Here is the section in DinkC reference:
"Info on brain 14 (button brain):
ManaUser: "Brain 14 'can be used in game as well.' I never really took
notice of that before, but I think it may have some real potential in-game.
Brain 14 can call three special procedures: buttonon(), buttonoff(), and
click(). Click() only works when sprite one is a mouse pointer, but the
other two work with Dink as well. buttonon() is a lot like touch(), but
it's called only once each time Dink touches it. It will only be called
again only if he moves away and back again. Buttonoff() is called when
when he breaks contact with it. This could be even more useful since there
is no 'untouch' procedure."
Hmmm. Sounds like using buttonon() instead of touch() could do away
with all that nonsense of toggling sp_touch_damage() between -1 and 0...]"
I hope you understand what I was trying to say after reading that!
You're blowing MY mind.
Not that that's hard to do >_>;
Not that that's hard to do >_>;
Hmm I'm not sure I understand what you mean.. :/
I was just thinking that if you put an invisible platform above and below Dink, you could not only eliminate the arrow key stuttering issue, you could also lift and lower Dink by using the below platform. This way, it would also eliminate the stuttering that the jump button causes (cause there'd technically be no jumping) and make the jumps much more smooth.
I'm not sure how well it would actually work, but it's a theory.
I was just thinking that if you put an invisible platform above and below Dink, you could not only eliminate the arrow key stuttering issue, you could also lift and lower Dink by using the below platform. This way, it would also eliminate the stuttering that the jump button causes (cause there'd technically be no jumping) and make the jumps much more smooth.
I'm not sure how well it would actually work, but it's a theory.
How would the block below "move" dink? If you move a hard object into dink it doesn't push dink away... it just goes through. You'd still have to move them both :/
But if that's the case, putting a platform above Dink's head wouldn't stop the player from going up either, cause Dink would go straight through, wouldn't he?
Dink collides with hard objecs, but they don't collide with him..
Did... you just capitalize your name?
If you log in with caps, your name will appear with caps.
Ahh! Your name is shouting at me
This probably would deserve its own thread, but I don't wanna flood the forum, so I'll just ask here.
Is there a way to check from which direction Dink is walking? You know, if I'd like a script to act differently when Dink walks into a sprite from the right side, than when he walks into it from the left?
Is there a way to check from which direction Dink is walking? You know, if I'd like a script to act differently when Dink walks into a sprite from the right side, than when he walks into it from the left?
The cheap way would be checking Dink's direction with sp_dir(1,-1). Am I missing something?
You could just check which direction dink is facing.
void touch()
{
int &face = sp_dir(1, -1);
if(&face == 4)
{
//dink touched object from the right side
}
if(&face == 6)
{
//dink touched object from the left side
}
}
void touch()
{
int &face = sp_dir(1, -1);
if(&face == 4)
{
//dink touched object from the right side
}
if(&face == 6)
{
//dink touched object from the left side
}
}
If your sprite is stationary, you could also check Dink's coordinates. I did this recently to make sure Dink wasn't looking at a bookshelf from the back.
Yeah, both methods should work, but getting sp_dir would be better because it requires less code. If you did the coordinates thing you'd need to check coordinates both for dink and the object and then compare them.
sp_dir, however, isn't perfectly accurate. What if the dir is 7? He could be walking at the sprite from below, or from the right.
If going with the coordinate method, I'd suggest looking at Paul's enemy shoot, or anything similar. Getting the correct direction from 4 different possibilities can be surprisingly harrowing (to your hair).
If going with the coordinate method, I'd suggest looking at Paul's enemy shoot, or anything similar. Getting the correct direction from 4 different possibilities can be surprisingly harrowing (to your hair).