Reply to Re: 2 hero control scheme
If you don't have an account, just leave the password field blank.
I did some work on a smart navigation script a while ago. It successfully scans the landscape and modifies its trajectory to avoid contact with objects. It's one of the creepiest things I've ever seen and I have to use all my strength just not to hide behind my chair whenever I see it. ("It's alive!! ALIVE!!")
Unfortunately though it only works with white hardness (though there might be some way around that) and more problematic, requires about 20k of script to be executed every second or so... Navigating in an intelligent way is really not as easy thing to program, especially when you don't have access to the basic code (as you don't in DinkC).
It could have some uses though. My thoughts were to have a brain 9 enemy that regularly checks if it has a direct line-of-sight to its target and only when it's broken is the navigation activated to override brain 9 movement, then reactivates brain 9 when the direct LOS is true.
I also tried a simpler rule to enable a sprite to navigate an infinitely complicated maze (the never failing hug the left wall trick) but that doesn't work as well as I wanted it to, though sprites can get a bit into the maze.
However getting a sprite to avoid WHITE hardness is pretty easy if you don't care how intelligent the sprite looks to go about it. Blue hardness is harder because it doesn't trigger damage() or destroy missiles (even if sp_flying is 0).
I'm not sure what you mean by shoot script but the best enemy/npc missile shoot script is my one in MouseDink, except it doesn't have any prediction.
Also about 2 players in general, I sent Erwin some code but I haven't heard from him in a month or so. I'm convinced it's possible to produce a 2nd player that can be played at the same time and is identical to Dink except:
a) he will move marginally slower
b) no diagonal movements
c) slight lag between releasing a key and the player stopping (perhaps around 250-400ms)
With an external program that the user must run before Dink.exe, b can be fixed and c decreased.
So if you are only doing it this way because you think the other way is impossible, well, it's not!
The bow would be easy to program for both the NPC and player-controlled "NPC". I don't know what you would have problems with.
Avoiding touch damage is also a simple task. What brain are you using for the NPC? 9? And what modes of attack? How aggressive? An NPC that avoids all enemies and shoots missiles (or produces explosions at certain locations -- even easier) would require very different AI to an NPC that spars with the sword.
Unfortunately though it only works with white hardness (though there might be some way around that) and more problematic, requires about 20k of script to be executed every second or so... Navigating in an intelligent way is really not as easy thing to program, especially when you don't have access to the basic code (as you don't in DinkC).
It could have some uses though. My thoughts were to have a brain 9 enemy that regularly checks if it has a direct line-of-sight to its target and only when it's broken is the navigation activated to override brain 9 movement, then reactivates brain 9 when the direct LOS is true.
I also tried a simpler rule to enable a sprite to navigate an infinitely complicated maze (the never failing hug the left wall trick) but that doesn't work as well as I wanted it to, though sprites can get a bit into the maze.
However getting a sprite to avoid WHITE hardness is pretty easy if you don't care how intelligent the sprite looks to go about it. Blue hardness is harder because it doesn't trigger damage() or destroy missiles (even if sp_flying is 0).
I'm not sure what you mean by shoot script but the best enemy/npc missile shoot script is my one in MouseDink, except it doesn't have any prediction.
Also about 2 players in general, I sent Erwin some code but I haven't heard from him in a month or so. I'm convinced it's possible to produce a 2nd player that can be played at the same time and is identical to Dink except:
a) he will move marginally slower
b) no diagonal movements
c) slight lag between releasing a key and the player stopping (perhaps around 250-400ms)
With an external program that the user must run before Dink.exe, b can be fixed and c decreased.
So if you are only doing it this way because you think the other way is impossible, well, it's not!
The bow would be easy to program for both the NPC and player-controlled "NPC". I don't know what you would have problems with.
Avoiding touch damage is also a simple task. What brain are you using for the NPC? 9? And what modes of attack? How aggressive? An NPC that avoids all enemies and shoots missiles (or produces explosions at certain locations -- even easier) would require very different AI to an NPC that spars with the sword.
