PDA

View Full Version : Bug, Annoyance, or Misunderstanding in weapons?


Phlagm
January 4th, 2007, 03:40 PM
Here are a list of annoying/illogical things I've discovered in my last several hours trying to get a particularly complicated weapon to work:

On the CSTG comand, you can launch any number of different stages on "expire" however, if you use "findprox" it'll only launch the first. My workaround has been to launch a dummy particle that will immediately die and launch the particles I want on expire. So that problem was discovered and worked around after too long.

My new problem is that I don't know what the hell the "relative" FLAG is for, since everything appears to come out at a relative velocity. I'm attempting to make a missile that will fire stationary objects as it moves along. But if it drops them and they have zero speed, they just cruise along with the missile. I can roughly correct for this particular effect by setting the initial speed of the particles to negative the missile's speed in the x and zero everywhere else. Unfortunately they still drift, and as the missile wiggles around they just get flung off randomly, or if my ship is moving, watch out! I've made sure NOT to use the relative flag, but so far as I can tell all projectiles come off relative no matter what. Is it just for particle effects? And if so, can we have an "absolute" flag from the projectiles, so we can make objects that sit in space?

Furthermore, it doesn't look like "slowdown" does anything on the main projectile. This makes me very sad as I was hoping to use it to simulate a bomber effect on a weapon.

If anyone has any ideas, please let me know.

Also, we should work on a page that details exactly what fields work where on the weapons, as that is sorely lacking. Right now I just have a stripped-down missile I use to experiment randomly with flags.

-Jeremy

Phlagm
January 4th, 2007, 04:35 PM
1) if you use the "homing" flag and a speed of something like 1, you can approximate that effect.

Phlagm
January 4th, 2007, 05:15 PM
PS does anyone know what the CLIP variable is for? I'm not really sure why it has a value unless it's something like how far an object can penetrate in before detonating.

Jamiri
January 4th, 2007, 05:58 PM
CLIP? I think that's how often a weapon fires before it has to reload, like an 'ammo clip' you need for a gun. Guess a good example would be the Fusion Rocket Launcher in the original WW.

Phlagm
January 4th, 2007, 11:22 PM
Ah okay. I do remember reading that somewhere. I had the clipping/noclipping in my head because I was messing with the collision stuff at the time. Also, no worries. I have all of the technical obstacles overcome and this weapon is worth it. It's going to be another one of the gong-type weapons, I think.

Fingers
January 7th, 2007, 05:00 PM
You're confusing particles with weapon stages (projectiles/beams). The two are completely different systems with their own flags and so forth. There's no such flag as "relative" for a weapon stage, only particles use absolute speed if not set to relative. So, unfortunately, you do need to use a slow homing stage to simulate this.

The findprox problem is most likely that when you change stages, it removes the old stage by default and then it can't launch any more stages. To change this, you can add the "repeat" flag to the new stages so the old stage will still be there.

If you want to set up a system that triggers on a findprox event, launches multiple new stages and terminates the first stage, use the repeat flag on all of the new stages except the last one. Make sure the proximity value is the same for all of the CSTG statements so they'll trigger at the same time.

Yes, the CLIP is an ammo clip. How long it takes to reload a new "clip" is defined by the second number of the RATE command.

Fingers
January 7th, 2007, 05:17 PM
Btw, the main reason why non-homing projectiles all use constant (no acceleration/slowdown) and relative velocity is so they can be aimed with precision at a moving target using a relatively simple algorithm.

Projectiles that move in a less deterministic way would be extremely hard to aim, frankly I'm not sure if it's even possible to write AI that could use every weapon that you could script into the game... And of course all the guns are run by AI.