ID:138435
 
I just decided to experiment with making the missile() effect better by adding an animation to the missile, so that on each turf you see it cross the turf.

By having two frames that show the missile progressing across the turf, I found that it considerably smooths out the look and removes the jumpiness effect.

Of course you need to make sure that you provide an animation for all 8 directions.
About spl_missile():

My SPL Demo looks pretty good so far. I have 11 starfield generators shooting little missiles at targets off-screen, which look for all the world like stars. They look fantastic, believe me. All I have to do is add an infinite supply of enemies, and then it'll be ready. They look jumpy at times, but because I can define lag with spl_missile(), they don't look that bad at lower speeds.

The demo's a bit big, but hey, what can you do. I went for "big bang" instead of "demonstrative". At least I didn't go all out like CATs or something... =)

No one seems interested in my little project here, though... I'm wondering if anyone really cares. Everything I say isn't responded to. =\
In response to Spuzzum
On 8/21/00 4:45 pm Spuzzum wrote:
No one seems interested in my little project here, though... I'm wondering if anyone really cares. Everything I say isn't responded to. =\

You know I'm interested, I'm just waiting to have a look at it! Although, I'm still tempted by Tom's offerings of straight line travel (I assume this could easily be incorporated into sp_missile anyway). If the two get combined it will be a major bonus for byond.

Don't stop now!

Thanks
In response to Spuzzum
If I may borrow a phrase from Smucker's: With a name like Spuzzum, it's got to be good!
In response to Spuzzum
On 8/21/00 4:45 pm Spuzzum wrote:
No one seems interested in my little project here, though... I'm wondering if anyone really cares. Everything I say isn't responded to. =\


I know the feeling, but I definitely care. I am holding off on worrying about line-of-site missile issues until your version comes along.

What I'm figuring is that a mob will have another mob targeted and fire, but by that time the other mob won't actually be in line of site (like having passed a window).

Without doing a bunch of coding myself, the current missile() proc will just bust through the wall and hit them -- and I know players will complain about that!

So my hope is that I'll be able to use your missile object to see if it has hit a wall or something, in which case it will stop or blow up in place...
In response to Deadron
Wow, thanks everyone! I feel a lot better now. Since I've just about finished the firing code of the demo now, it'll probably be ready sometime tomorrow, and, failing that, sometime within the next few days. Note that the functionality is done, but hasn't been tested. It works excellently for the four major cardinal directions, but I haven't had a chance to test angles. That's why I'm holding back on you; it's not because I'm lazy! (which I am, unfortunately =)

Remember, the features are:

- Creation of "graphical only" objects or of physical objects

- Ability to change speed of projectiles through "lag" var

- Ability to specify whether missiles should "home in" on targets, or simply go to wherever they were standing

- Angle calculation (thanks Al!) ensures missiles go on as straight of lines as is possible

- A proc, walk_line(), is provided so you can move mobs or objs on straight lines, like walk_to() except a lot less curved

- 4 different usages:
--- spl_missile1(icon,icon_state,start,end,lag=1,homing=0)
--- spl_missile2(ref,start,end,lag=1,homing=0)
--- spl_missile3(icon,start,end,lag=1,homing=0)
--- spl_missile4(/obj/spl_projectile,start,end,lag=1,homing=0)

- And a really cool looking demo... a little large and obscure, but the end effect is quite staggering =)




So my hope is that I'll be able to use your missile object to see if it has hit a wall or something, in which case it will stop or blow up in place...

Yep, if you use the fourth or second usages, you can create a new object, then define stuff in the object's Bump() procs. I tried to get around allowing people to create objects that are dense, then realized that if you actually could, it would open up a whole new field, not just as a missile() replacement (more of a supplement, really), but as a generic tracking system too. Suffice to say, I immediately halted that restriction. The demo itself is partially based on that aspect. Note that if you don't want an object to get deleted when it reaches its target, you should use walk_line() instead.

(Good thing this forum isn't as controlled as the Bug Report forum, or Tom would be angry about the fact that I'm totally deviating from the topic of your original post =)