Ok I guess this can go here... not sure where to put this.
So Ive been gone from byond for awhile and quite a bit has changed in the language (not so much in the games unfortunately, same ones are always the most popular guess they did something right) but i digress. Was wondering if anything has changed in the method to do Projectiles. I found the Shadowdarke had one of the best libraries for this before I left. What Im wondering is if any new features has changed this and if theres a new/better way
ID:151521
 Jul 14 2010, 10:04 am
|
|
Zecronious wrote:
Well you can use the missile() proc and it will travel in the quickest way possible to the enemy. This is good for spells that track your opponent. Also good for A.I, saves any more complex code. Except it's completely useless for actual projectiles as missile()'s only purpose is to create strictly-graphical effects. As there's no way to interact with missile()'s effect at all, you can't use it for any proper projectiles, since the 'missile' can't really ever miss its target, you can't tell when it hit its target and how, etc. Then there's also the fact that 'missile's don't go in a straight direction and use pathfinding to reach (or home onto) their target. Not what most projectiles are about. You can do it in what I think is the old way. Basically create an object and use New() to send it in the direction the mob is facing. There isn't really any 'old' or 'new' ways in this concept. Anyway, if the projectile needs to have some sort of graphical representation, then you must use an atom (or its cousin /image) somewhere along the way. Making the projectile itself a movable atom leads to a clean, sensible and object-oriented flow of things. There is also the really really old way which is to make a shooting animation for character and then get it to detect a mob in the direction of the character. You can do this if the projectile has no graphical representation, i/e/ isn't meant to be seen. Again, your "old" comment is irrelevant. | |
Kaioken wrote:
As there's no way to interact with missile()'s effect at all, you can't use it for any proper projectiles, since the 'missile' can't really ever miss its target, you can't tell when it hit its target and how, etc. You can determine ahead of time if the projectile will hit or miss. If it hits, the third argument to missile is the target. If it misses, the third argument is the tile the target is standing on. Back on topic: There are so many ways that projectiles could be handled, no library is going to cover all applications you might come up with. You're better off writing your own routine so it's easier for you to customize it. | |
Forum_account wrote:
You can determine ahead of time if the projectile will hit or miss. No, you can't. You can decide what it's going to hit. That's all. Naturally, even that isn't absolutely certain, since the target could be deleted before the graphic reaches it. As with anything else with missile(), you don't have any way to tell that, other than messing around by doing manual computations to try to assume what happened. If it hits, the third argument to missile is the target. If it misses, the third argument is the tile the target is standing on. I hope you didn't word that right. Otherwise, you got very confused, or worse. missile() is a global proc, a built-in instruction to be specific. What the arguments are is determined only by what the programmer inputs when calling the proc. It's not 'a hook proc', i.e. a proc you can override, check the arguments given to it and do stuff accordingly, since it's not an object proc. Back on topic: I know the trend around is to instantly deem any subthread as "off-topic", but it's on-topic, seeing as it's still related to the topic of projectiles implementation. There are so many ways that projectiles could be handled, [...] Yes, and even what shape or appearance (or lack thereof) you want them to have has quite a large effect on how your design and implementation is going to look. | |
Kaioken wrote:
Forum_account wrote: Hopefully an example will be more clear: mob/proc/shoot(mob/target) | |
Forum_account wrote:
Kaioken wrote: Yes, that does confirm what I already understood from you, hence I rephrased your sentence to be more accurate. "You can decide what it's going to hit". You still have no means of knowing anything nor any control. In other words, you can't know when the graphic reached its target, you can't control its path, you can't make the 'missile' "dense" or otherwise be stopped by anything, you can't know what obstacles were in its way, etc. In short, you can't do anything you'd want to do with an actual projectile. Hence I don't consider missile() being usable for projectiles, since while you can try to use it for that purpose, the result is so very crude and limited that I don't consider it generally passable. missile() is good for other things. | |
Kaioken wrote:
In short, you can't do anything you'd want to do with an actual projectile. The OP didn't specify what he wants to do with projectiles. The missile proc might be completely adequate for what he has in mind so we can't write it off just yet. | |
Forum_account wrote:
The OP didn't specify what he wants to do with projectiles. Some of my statements have been very general - more than enough. The missile proc might be completely adequate for what he has in mind so we can't write it off just yet. If what he has in mind is not a projectile (something that travels towards something else, and can cause an effect when it reaches things), then yes. Otherwise, according to me, you can write it off. | |
You can do it in what I think is the old way. Basically create an object and use New() to send it in the direction the mob is facing. Use Bump() to detect the hit and Istype() to detect if it's an enemy. This way is good for guns and A.I that you only want to shoot straight.
There is also the really really old way which is to make a shooting animation for character and then get it to detect a mob in the direction of the character. This involves no projectile, only the illusion of one.