Detecting Tile Hardness
Is there any way (in DinkC) to check if any point on a screen has tile hardness? I've tried to think of a few ways (creating a missile that checks, and so on), but missiles require movement in order to check for hardness, and they don't work very well.
Mind you this would take some time. And you'd have to know the spot. Hmmmm. I dunno. What have you tried?
: Mind you this would take some time. And you'd have to know the spot. Hmmmm. I dunno. What have you tried?
Yeah, tried that, and it did take a while... in the script it has to access about 300 spots on the screen, determining their hardness. If you don't use wait(1), then it does it rather fast, but using wait(1) makes it take about 15 seconds to do them all. And move has to have a wait(1) in there, for obvious reasons.
I was hoping someone might be able to find a way that doesn't use any wait(1) commands at all... but it seems unlikely.
Yeah, tried that, and it did take a while... in the script it has to access about 300 spots on the screen, determining their hardness. If you don't use wait(1), then it does it rather fast, but using wait(1) makes it take about 15 seconds to do them all. And move has to have a wait(1) in there, for obvious reasons.
I was hoping someone might be able to find a way that doesn't use any wait(1) commands at all... but it seems unlikely.
: Is there any way (in DinkC) to check if any point on a screen has tile hardness? I've tried to think of a few ways (creating a missile that checks, and so on), but missiles require movement in order to check for hardness, and they don't work very well.
How about creating a sprite with brain 9 at every point you want to check, then checking a moment later if the x and y coordinates have changed or not? If not, it's in hardness. This is probably a dumb idea and it would take even longer than the move thingy. I don't even think this will work...
How about creating a sprite with brain 9 at every point you want to check, then checking a moment later if the x and y coordinates have changed or not? If not, it's in hardness. This is probably a dumb idea and it would take even longer than the move thingy. I don't even think this will work...
Well, I know you said "tile" hardness, but if I were doing this I would consider using sprite hardness instead. Of course that means you wouldn't be able to use sprite hardness for sprites you actually want hard, but you could try and substitute tile hardness for those cases.
Make sense?
Also, I don't think I see where you're going with this... would you need to know not only if hardness exsisted, but its location as well?
Make sense?
Also, I don't think I see where you're going with this... would you need to know not only if hardness exsisted, but its location as well?
: Well, I know you said "tile" hardness, but if I were doing this I would consider using sprite hardness instead. Of course that means you wouldn't be able to use sprite hardness for sprites you actually want hard, but you could try and substitute tile hardness for those cases.
: Make sense?
: Also, I don't think I see where you're going with this... would you need to know not only if hardness exsisted, but its location as well?
(While the following isn't a script I'm working on (mine places much more sprites), but it follows the same basic ideas):
Imagine a random monster generator script for a screen, using my hard.dat (where all 'internal' hard areas (on cliffs, in water, etc.) are filled in with hardness). Now, you want to place a random monster (pretty easy) at a random location. You want to make sure the location isn't hard, otherwise the monster will be stuck.
: Make sense?
: Also, I don't think I see where you're going with this... would you need to know not only if hardness exsisted, but its location as well?
(While the following isn't a script I'm working on (mine places much more sprites), but it follows the same basic ideas):
Imagine a random monster generator script for a screen, using my hard.dat (where all 'internal' hard areas (on cliffs, in water, etc.) are filled in with hardness). Now, you want to place a random monster (pretty easy) at a random location. You want to make sure the location isn't hard, otherwise the monster will be stuck.
Why don't you just have the monsters move towards Dink's spot with a move set to 1... as part of their main procedure... that would get them going until Dink either attack them ... then put something in each attack procedure that checks to see if the creature is stuck based on it's current position sort of check the x variable, wait check it again... if it hasn't moved more than a couple of points run the move set to one procedure tracking Dink's new x position. Does this make any sense?
: : Well, I know you said "tile" hardness, but if I were doing this I would consider using sprite hardness instead. Of course that means you wouldn't be able to use sprite hardness for sprites you actually want hard, but you could try and substitute tile hardness for those cases.
: : Make sense?
: : Also, I don't think I see where you're going with this... would you need to know not only if hardness exsisted, but its location as well?
: (While the following isn't a script I'm working on (mine places much more sprites), but it follows the same basic ideas):
: Imagine a random monster generator script for a screen, using my hard.dat (where all 'internal' hard areas (on cliffs, in water, etc.) are filled in with hardness). Now, you want to place a random monster (pretty easy) at a random location. You want to make sure the location isn't hard, otherwise the monster will be stuck.
How about first createing the monster invisable, unhitable, touch_damageless, etc, but with it's normal brain, then doing wait(1), or longer if needed, and checking if it's still in the same spot. If so, assume it's stuch and pick a new location to try again. If not, give the monster it's real set of attributes.
: : Make sense?
: : Also, I don't think I see where you're going with this... would you need to know not only if hardness exsisted, but its location as well?
: (While the following isn't a script I'm working on (mine places much more sprites), but it follows the same basic ideas):
: Imagine a random monster generator script for a screen, using my hard.dat (where all 'internal' hard areas (on cliffs, in water, etc.) are filled in with hardness). Now, you want to place a random monster (pretty easy) at a random location. You want to make sure the location isn't hard, otherwise the monster will be stuck.
How about first createing the monster invisable, unhitable, touch_damageless, etc, but with it's normal brain, then doing wait(1), or longer if needed, and checking if it's still in the same spot. If so, assume it's stuch and pick a new location to try again. If not, give the monster it's real set of attributes.
: Imagine a random monster generator script for a screen, using my hard.dat (where all 'internal' hard areas (on cliffs, in water, etc.) are filled in with hardness). Now, you want to place a random monster (pretty easy) at a random location. You want to make sure the location isn't hard, otherwise the monster will be stuck.
How about putting the monsters on the screen using editer on the screen, and initially giving them the following attributes:
sp_size: 1
sp_speed: 6 (or the fastest Dink engine allowed)
sp_timing: 0
sp_brain: 9 or 16
And then add a wait(100) or something longer, then change them back to normal attributes?
The only drawback of this technique is those monsters would appear some time AFTER Dink enters the screen. If you have tons of monsters, that could cause some problems. But if the wait time delay is too short, the monster would appear right at the same area...
How about putting the monsters on the screen using editer on the screen, and initially giving them the following attributes:
sp_size: 1
sp_speed: 6 (or the fastest Dink engine allowed)
sp_timing: 0
sp_brain: 9 or 16
And then add a wait(100) or something longer, then change them back to normal attributes?
The only drawback of this technique is those monsters would appear some time AFTER Dink enters the screen. If you have tons of monsters, that could cause some problems. But if the wait time delay is too short, the monster would appear right at the same area...
Redink, if you're going along the lines of generating random monsters, something i've thought of doing is this:
Pick like 20 spots on a screen that you know are good, hand picked spots. Then when you enter, just randomly generate a few monsters at some of those spots. A few problems are the delay then, you'll scroll to the screen then the monster will appear. Also, if you were going to make it so the monster dies and comes back after 5 mins or whatever...don't really know a good way.
What i might end up doing, is creating like 20 monsters on the screen, but have them initialy be type 2, then when their script gets loaded, when you enter the screen, it has a chance to either kill them, or change their type to 1. Yes, they'll still appear when you enter, but better than seeing 20, and 15 suddenly dissapear, that would be weirder. And also this way you can have em die for a certain amount of time still. I dunno, just something i've considered.
Pick like 20 spots on a screen that you know are good, hand picked spots. Then when you enter, just randomly generate a few monsters at some of those spots. A few problems are the delay then, you'll scroll to the screen then the monster will appear. Also, if you were going to make it so the monster dies and comes back after 5 mins or whatever...don't really know a good way.
What i might end up doing, is creating like 20 monsters on the screen, but have them initialy be type 2, then when their script gets loaded, when you enter the screen, it has a chance to either kill them, or change their type to 1. Yes, they'll still appear when you enter, but better than seeing 20, and 15 suddenly dissapear, that would be weirder. And also this way you can have em die for a certain amount of time still. I dunno, just something i've considered.
