trying to effect a certain behavior

What I want: A missile that aims for its target, waits a few seconds, then hits the target and explodes. When it explodes it releases a submunition which does the same thing, a total of maybe five or six times. If the missile is jammed I want it to fly away from the target and fizzle at the end of its life, and not make anymore submunitions. Think of it as a "disease" that deals damage over time, and when you "recover" from it, it's gone for good.

What I've Tried: ProxSafety of 150. Count of 180. Turns away if jammed. Not flak-type (doesn't explode when expires). Subs fail when shot expires.

The Problem: It doesn't work. The missiles behave in the exact opposite manner from what I want. When they hit they explode but don't make subs. When they're jammed they fly away and fizzle, but make subs.

A Related Experience: I was able to make the missile get the "wait a few seconds then explode and damage the target and make a submunition" aspect to work by setting ProxSafety > Count and making it flak-type (explodes on expire) and subs not fail on expire, but then when it was jammed it flew away and exploded and made a sub that might or might not be jammed, and so on.

Do you have any suggestions, or is what I want impossible? It doesn't seems like it should be... but I can't think of anything else.

Hey, I had the exact same idea once Never actually tried to make it though. In my idea you could buy an outfit called 'cure' or something which would activate a mission of the same name. Aborting this would grant a PD which would fire at the plague and kill it. At the same time, the PD shot would deal some amount of damage to your own ship as the cost for curing it. The mission would start itself again and a special ship would hyper in to remove the PD after a few secs.

Did you give the weapon some ProxRadius? Weapons won't submunition correctly if they're right on top of whatever they hit - they need some space for the subs to come into existence before those hit something.

As for the Subs Fail flag, I seem to have two conflicting memories, one which says it's currently nonfunctionally buggy, and another where I got it to work as expected, so I dunno what to say there.

This post has been edited by Weepul 884 : 06 December 2005 - 03:31 PM

Okay, the "subs fail" flag does work. But even with a significant proxradius I can't get a missile to release its submunitions at the same time it hits (gets within proxradius and detonates) its target.

So it looks like, unless this is fixed in ~9, I'm stuck with the "doesn't ever hit, just circles around until life count runs out and then detonates and submunitions" behavior, meaning that a jammed missile still submunitions, and those subs can lock on again. Oh well.

So make it unable to be jammed?

I have a functional sub-on-impact against shuttles with a ProxRadius of 25. It has no blast radius, and the submunition has a longer ProxDelay than its life, but I don't know if these affect its functionality. Also, I do not know if it will work against anything larger than a shuttle.

Edwards

I got this to work.
If I understand you correctly, you want a seeker that will mill about for awhile, then target the ship. If it hits, you want it to mill about again for a time, then target the same ship again. If it doesn't hit (jammed) then the shot expires.

I have:
Stage 1
life count 120
speed 100
turn 0
prox saftey 121
prox radius 0
blast radius 0
turns away if jammed
subs to stage 2

Stage 2
life count 240
speed 500
turn 180
prox saftey 0
prox radius 20
blast radius 30
subs fail when shot expires
turns away if jammed
subs to a new weap identical to stage 1 - that stage in turn subs to a weap identical to stage 2, etc. make a number of weap stages to correspond to how many iterations you want.

I think the trick is that you don't actually want stage 2 to physicaly hit the target. You want the prox to trigger and the blast radius to do the damage. So, you may have to ajust prox numbers to be able to handle a potentialy fast closure rate. You need to prevent the sprite from actually making contact.

My tests seem to indicate that this works. Stage 1 never hits the target and will always sub to stage 2. Stage 2 will sub after prox radius triggers. Stage 2 will not sub if prox radius doesn't trigger (jammed)

Edit: I added "turns away if jammed" to stage 1. Couldn't hurt, and I notice that sometimes the seeker will hit before it has a change to turn away. Speaking of which, does anybody know if a jammed missile that later subs will have another change to re-target? Or vice-versa? (not talking about system interference re-targeting effect)

@ Guy:
I would think you would want to Gxxx a special jammer to be the "cure". (you'd probably have to reserve a jamming type for this) Otherwise your added PD weap will fire on all other PD-targatable things too. Also note that any regular PD weap would also fire on the plague.

This post has been edited by Desprez : 08 December 2005 - 01:52 PM

Desprez, on Dec 8 2005, 07:40 AM, said:

@ Guy:
I would think you would want to Gxxx a special jammer to be the "cure". (you'd probably have to reserve a jamming type for this) Otherwise your added PD weap will fire on all other PD-targatable things too. Also note that any regular PD weap would also fire on the plague.
View Post

True. Unless your plug doesn't have any other PDs
The reason for the PD was I wanted the 'cure' to damage your ship as well. Like certain parts of your ship are infected and must be 'amputated' in order to remove the plague. I'm not actually making such a plug though so if anyone likes the idea then feel free to use it.

This post has been edited by Guy : 08 December 2005 - 03:46 PM

I suppose you could also have the mission ship that warps in attack you, instead of having 0 armor.
It would be invisible, and launch an invisible weap at you that also causes it to self destruct.
The weap does the appropriate ammount of damage to reflect the "cure" side effect.

Desprez, on Dec 8 2005, 01:40 PM, said:

Stage 1
life count 120
speed 100
turn 0
prox saftey 121
prox radius 0
blast radius 0
turns away if jammed
subs to stage 2

Okay, this'll mill about for a while.

Quote

Stage 2
life count 240
speed 500
turn 180
prox saftey 0
prox radius 20
blast radius 30
subs fail when shot expires
turns away if jammed

And this'll go "boom"... but will it submunition on-explode? And if it does, why can't you just give it a 120 prox safety and make it submunition recursively?

Quote

subs to a new weap identical to stage 1 - that stage in turn subs to a weap identical to stage 2, etc. make a number of weap stages to correspond to how many iterations you want.

Because this is going to burn through wëap resources like nobody's business.

Quote

I think the trick is that you don't actually want stage 2 to physicaly hit the target. You want the prox to trigger and the blast radius to do the damage. So, you may have to ajust prox numbers to be able to handle a potentialy fast closure rate. You need to prevent the sprite from actually making contact.

Yeah, this seems to be the problem.

Quote

My tests seem to indicate that this works. Stage 1 never hits the target and will always sub to stage 2. Stage 2 will sub after prox radius triggers. Stage 2 will not sub if prox radius doesn't trigger (jammed)

What happens if Stage 1 is on top of the target when it expires? Then it'll sub into Stage 2, which should immediately detonate, and it'll be touching the target, so will it submunition properly?

Quote

Edit: I added "turns away if jammed" to stage 1. Couldn't hurt, and I notice that sometimes the seeker will hit before it has a change to turn away. Speaking of which, does anybody know if a jammed missile that later subs will have another change to re-target? Or vice-versa? (not talking about system interference re-targeting effect)View Post

A missile that's jammed 50% of the time and recursively submunitions into 2 identical missiles makes for lots of fun. Long after the first few iterations are spent, missiles will keep raining down. So, in short, yes. The submunitions are treated as new missiles, and may or may not be jammed on their own merits.

Qaanol, on Dec 9 2005, 12:10 AM, said:

And this'll go "boom"... but will it submunition on-explode? And if it does, why can't you just give it a 120 prox safety and make it submunition recursively?
View Post

It will sub, if it is far enough away from the target.

The reason that submunitioning recursively doesn't work is because it will lead to a situation that will put the weapon too close to the target. (And the subs will not fire properly)

I guess I should have mentioned that the other trick is to try and keep stage 1 away from the target. Ideally, you don't want it to sub within the stage 2 prox distance.

Having a slow speed and 0 turning was suficient to do this for my tests, however your universe may vary. (YUMV)
If you need more agressive measures, you can use a faster speed with negative guidance. This makes stage 1 run away from the target, practaly guarenteing that stage 2 will begin far enough from the target to function properly.

Now I suppose you could engineer a situation where recursive subs might work, but your valid targets will probably be severly constrained. Basically, you'd need a fast weapon with a low turning rate (very tailored to the target) The idea being that the weapon will "arm" while at the far side of its turning circle, but then must not miss the target on the way back. I don't know how this weap is being used so this will likely not be realisticly possible.

Now, it does use a number of resources. I was under the impression that this was for a specialty weap with only 5-6 recursions. Is a one time usage of 10-12 weaps too costly? I guess you'll have to answer that. If this isn't a one time special weap, then I can see where resources would be a problem.

Qaanol, on Dec 9 2005, 12:10 AM, said:

A missile that's jammed 50% of the time and recursively submunitions into 2 identical missiles makes for lots of fun. Long after the first few iterations are spent, missiles will keep raining down. So, in short, yes. The submunitions are treated as new missiles, and may or may not be jammed on their own merits.
View Post

Interesting. So a missile that subs into itself every frame or so will be unjammable from a practical standpoint?

Since the missile will fly for some ammount of time before checking if jammed, it will never get to check.

Oh wait, never mind, it will never seek either. (There is a pause before turning begins)

Ok, so you make the missile not turn away if jammed. Then sub into itself every 60 frames. That way evey, 60 frames it gets a chance to re-acquire the target while coming ever closer.

Hmmm. Actually, this is closer to how real missiles work. If it gets spoofed right at the terminal phase of flight, the target has a small window of opportunity to get out of the missile's flight envelope.

Desprez, on Dec 9 2005, 10:11 AM, said:

(There is a pause before turning begins)
View Post

I think that pause is actually dependant on the speed and/or count. Though it's much shorter than it was in EV/O - missiles would be half spent before the guidance kicked in.

@qaanol, on 06 December 2005 - 11:59 AM, said in A question on recursive submunitioning:

What I want: A missile that aims for its target, waits a few seconds, then hits the target and explodes. When it explodes it releases a submunition which does the same thing, a total of maybe five or six times. If the missile is jammed I want it to fly away from the target and fizzle at the end of its life, and not make anymore submunitions. Think of it as a "disease" that deals damage over time, and when you "recover" from it, it's gone for good.

I have working solution now. The missile is fired, homes on its target, waits a certain duration, then if it is near its target it explodes, releasing an identical submunition. If it is not nears its target when the duration ends, the shot expires and does not submunition. This can also be done so that it will explode, after the duration, if it is near any ship, not just its target, in which case the disease can change from infecting one ship to another.