Ambrosia Garden Archive
    • Caution when using prox+blast radius+subs


      A caution, and a feature!

      If you have a plug and have been including missiles that have represented multiple stages using submunitions, (launch, guiding, terminal)
      Take care when also using a proximity trigger and a blast radius.

      Depending of the size of the prox and the closure rate, you can accidently create situations that lead to your missile doing vastly more ammounts of damage than intended.

      The reason for this is that a "hit" scored by the prox trigger will still allow subs to function, unlike a hit scored by an actual impact.

      Let's say you have a missile with 3 stages, launch, guidance, and terminal.
      Say we wanted these stages to represent different flight characterstics of the same missile. But this missile was also supposed to detonate if it got close to the target, say 50 pixels with a blast radius of 60 pixels, and these characterstics are applied to every stage.
      This example missile will do 200 damage and also have a speed of 1000 (or 10 pixels per frame)

      In this example, say the missile was launched, but found its target before it even got into its second stage.
      So what happens is this...
      During the first stage the missile got to within 50 pixels of the target. The prox trigger went off and did 200 damage to the target.
      Now because the missile didn't physicaly hit the target's sprite, the missile will still sub into stage two.

      The next frame, the stage two missile travels 10 pixels closer. Now the missle is within 40 pixels of the target so the prox trigger goes off again and deals another 200 damage to the target.

      Since the missile still has not yet physicaly entered the target sprite, it subs into stage 3.

      One frame later the third stage travels to within 30 pixels, prox triggers, and another 200 damage is dealt.
      At this point, it doesn't matter if the missile has physicaly hit the target yet, because there are no more submunitions, and this missile instance will finally end.

      Obviously this is a big problem if your 200 damage missile ends up dealing 600 points of damage.

      One more wrench for the works. Let's now say the target was also moving towards the missile at 2000, for a combined closure rate of 3000 (or 30 pixels per frame). Let's also say that 1 frame before prox is triggered the missile happened to be 60 pixels away, so:
      frame 0 - range 60: Nothing yet happens, missile continues inbound to target.
      frame 1 - range 30: prox triggers, 200 damage dealt, subs to stage two.
      frame 2 - range 0: target impacted, 200 damage dealt, subs do not function because of physical contact, missile instance ends.
      In this case 400, not 600, damage was dealt to the target.

      Ok, now some options to handle this:

      1. Not use the prox trigger.
      2. Only use the prox trigger on the last stage.
      3. Split up the total potential damage amongst the stages. This will make the missile do less damage the later in it's life it happens to hit the target, but would likely need some explanation scenario-wise.

      For exmple, an energey based missile that losses intensity the longer it remains in space.
      Stage 1 - 85 Damage, Stage 2 - 65 Damage, Stage 3 - 50 Damage
      So if the target is struck during stage 1, all 200 points would be dealt over 3 frames. If the target was struck during stage 3, only 50 points of damage are dealt.
      Then, you could either talor your prox radius and speeds to ensure that a too great of a closure rate would be very unlikely, or explain why a fast closure rate may result in less damage.

    • I can confirm this behavior. I bumped up against it while trying to make a damage over time "curse" type weapon. Actually, I bumped up against it in the opposite direction, and the problem for me was that a physical impact didn't launch submunitions. But still, I can confirm what Desprez is saying here.

    • I suppose it's worth mentioning that a recursive submunition in the last stage is particularly problamatic in this regard...

      "...what do you mean I took an infinite amound of damage??"

    • Maximum possible damage from a press of the fire key would be, um, one hundred thirty-eight billion, five hundred four million, two hundred seventy-four thousand, forty-eight mass and energy damage.

      • 128 launchers for one weapon firing simultaneously (max shots on screen = 128)

      • 255 distinct weapons that submunition in a nonrecursive chain (max weapon types = 256)

      • 1 weapon that comes at the end of the chain and recursively submunitions 32,767 times for a total of 32,768

      • All dealing 32,767 mass and energy damage

      • 128 shots per cycle * 32,767 damage per shot = 4,194,176 damage per cycle

      • 255 nonrecursive cycles (including the initial firing) + 32,768 recursive cycles = 33,023 total cycles

      • 4,194,176 * 33,023 = 138,504,274,048

      Yeah. 138,504,274,048 **** mass and energy damage. That's 128 shots each dealing 32,767 damage per frame for 33,023 frames. 33,023 frames, of course, is 1,100 and 23/30 seconds, or 18 minutes and 21 seconds. Fairly useful as a mine to lay near a planet for domination, although if fired at you the first wave of shots would deal 128 times more damage than necessary to kill even the toughest of ships (and, indeed, even invincible ships) so the rest would be a little superfluous.

      I suppose if one of the weapons were a turreted beam with duration 32,767 and damage 32,767, so the daisy-chain submunitions would only have 254 cycles, and you had 64 of them (max beams on screen = 64) then the total damage would be substantially greater per press of the fire key...

      • 4,194,176 * 33,022 = 138,500,079,872 projectile damage

      • 64 beams * 32,767 damage per frame per beam = 2,097,088 damage per frame

      • 2,097,088 damage per frame * 32,767 frames = 68,715,282,496 beam damage

      • 138,500,079,872 projectile damage + 68,715,282,496 beam damage = 207,215,362,368 total damage

      Two hundred seven billion, two hundred fifteen million, three hundred sixty-two thousand, three hundred sixty-eight mass and energy damage. Assuming the fire key to have been pressed at a range that triggers the first projectile's proximity radius immediately, that's 6,291,264 damage per frame for the first 32,767 frames and 4,194,176 damage per frame for the next 255 frames (after the beams' duration expires, while the last of the projectiles submunition.)

      Now, obviously this all assumes there are ships for the beams to hit and to trigger the projectiles' proximity fuses. Since the beams will vaporize everything in range, there won't be. In the first example, though, with just submunitioning projectiles, in theory they could exist long enough (32,767 life count each wave) for new ships to jump in. I suppose defense fleets that send one ship at a time would also work. Sixteen spöbs in the system and all.

      This post has been edited by Qaanol : 05 April 2006 - 04:05 PM

    • Just make it so that the earlier stages have a very tiny or 0 proximity trigger. Done.

    • Just a thought when I was reading qaanol's "curse" type weapon thing. You can set a proximity delay higher than the weapon's life, this way the weapon will never trigger from impact but will still launch the subs and deal damage at the end of its life if set to.

    • @qaanol, on Apr 5 2006, 02:03 PM, said in Caution when using prox+blast radius+subs:

      Maximum possible damage from a press of the fire key would be, um, one hundred thirty-eight billion, five hundred four million, two hundred seventy-four thousand, forty-eight mass and energy damage.

      • 128 launchers for one weapon firing simultaneously (max shots on screen = 128)

      • 255 distinct weapons that submunition in a nonrecursive chain (max weapon types = 256)

      • 1 weapon that comes at the end of the chain and recursively submunitions 32,767 times for a total of 32,768

      • All dealing 32,767 mass and energy damage

      • 128 shots per cycle * 32,767 damage per shot = 4,194,176 damage per cycle

      • 255 nonrecursive cycles (including the initial firing) + 32,768 recursive cycles = 33,023 total cycles

      • 4,194,176 * 33,023 = 138,504,274,048

      Yeah. 138,504,274,048 **** mass and energy damage. That's 128 shots each dealing 32,767 damage per frame for 33,023 frames. 33,023 frames, of course, is 1,100 and 23/30 seconds, or 18 minutes and 21 seconds. Fairly useful as a mine to lay near a planet for domination, although if fired at you the first wave of shots would deal 128 times more damage than necessary to kill even the toughest of ships (and, indeed, even invincible ships) so the rest would be a little superfluous.

      I suppose if one of the weapons were a turreted beam with duration 32,767 and damage 32,767, so the daisy-chain submunitions would only have 254 cycles, and you had 64 of them (max beams on screen = 64) then the total damage would be substantially greater per press of the fire key...

      • 4,194,176 * 33,022 = 138,500,079,872 projectile damage

      • 64 beams * 32,767 damage per frame per beam = 2,097,088 damage per frame

      • 2,097,088 damage per frame * 32,767 frames = 68,715,282,496 beam damage

      • 138,500,079,872 projectile damage + 68,715,282,496 beam damage = 207,215,362,368 total damage

      Two hundred seven billion, two hundred fifteen million, three hundred sixty-two thousand, three hundred sixty-eight mass and energy damage. Assuming the fire key to have been pressed at a range that triggers the first projectile's proximity radius immediately, that's 6,291,264 damage per frame for the first 32,767 frames and 4,194,176 damage per frame for the next 255 frames (after the beams' duration expires, while the last of the projectiles submunition.)

      Now, obviously this all assumes there are ships for the beams to hit and to trigger the projectiles' proximity fuses. Since the beams will vaporize everything in range, there won't be. In the first example, though, with just submunitioning projectiles, in theory they could exist long enough (32,767 life count each wave) for new ships to jump in. I suppose defense fleets that send one ship at a time would also work. Sixteen spöbs in the system and all.

      :blink:

      Wow, congradulations. You just earned yourself a giant donut.

      Posted Image

    • Hmm...could this be used for a weapon that submunitions into different shots when it 'hits' an enemy ship? Something like the Dr. Device in Ender's Game (only without beams), maybe?

      I think I'll play around with this, if I get the time.

      This post has been edited by UE_Research & Development: 07 April 2006 - 10:12 PM

    • @ue_research---development, on Apr 8 2006, 03:12 AM, said in Caution when using prox+blast radius+subs:

      Hmm...could this be used for a weapon that submunitions into different shots when it 'hits' an enemy ship? Something like the Dr. Device in Ender's Game (only without beams), maybe?

      I think I'll play around with this, if I get the time.

      I'm unfamiliar with this device. What does it do?

    • The Dr. Device is a nickname for the Molecular Disruptor Device from Ender's Game by Orson Scott Card. It's a weapon that sets off a chain reaction of molecules destabilizing, and thus can vaporize any object of any size. The mass of the object being destroyed dictates how wide of a radius is also disrupted, and the masses of objects in that radius, on disruption, do the same. This continues as long as there's more matter to disrupt. It is used in space to destroy Bugger ships, and at the end of the book Andrew Wiggin daringly and perhaps unwisely unleashes it on a planet, destroying the entire world and all ships nearby in space.

    • @ue_research---development, on Apr 8 2006, 03:12 AM, said in Caution when using prox+blast radius+subs:

      Hmm...could this be used for a weapon that submunitions into different shots when it 'hits' an enemy ship? Something like the Dr. Device in Ender's Game (only without beams), maybe?

      I think I'll play around with this, if I get the time.

      Based on the information in the Wikipedia article, you don't need to display any beams as one version of the device was scaled to be encased in a missile. The reaction starts inside it, and uses the mass of the missile to jump-start it.

      Anyway, this would be an interesting expirement to try and model.
      My initial thoughts run something like this...
      Have a missile that, upon detonation at a predetermined point, subs into 8 radial parts.
      These parts have a somewhat large proximity radius, and don't move all that quickly. If one of these parts finds a target inside the proximity radius, it will do a large amount of damage via the balst radius, then sub into itself recursively. Check the 'subs fail if shot expires' flag, and an individual shot will end without subbing if it doesn't find a target.

      This way, a "hit" will trigger a new radial bloom of shots, simulating the idea of feeding off of mass. The more things hit, the more shots produced.

      Though I had a trick to make a projectile be able to hit both missiles and ships, I don't think it can be adapted in this case to make a weapon that hits both planets and ships. - unless every ship registers as a planet type ship, and every weapon registers as a planet type weapon.
      Does anyone even know if a planet can trigger the prox fuse of a planet type weapon?

      I'm not sure there's much use for a weapon that destroys everything, though... what fun is that?

      What could be more interesting, IMHO, is a weapon that subs into itself as it travels around the system, destroying anything in its somewhat unpredictable path, and continues on after. Make the subs fire no matter if a target is hit. Add some small randomization of the sub direction to get it to change its path.

      With some graphical trickyness, you could make this look like a deadly cosmic disturbance, (kinda like a space storm, what ever that would be) Stay out of its path! With a few initial set-up sub stages (to make the storm appear from a random location), you could make this a planet fired weapon, and time it so when the storm gets to it's recursion limit, the planet fires out a new storm, or two, or three.

      If you don't need to save resources, and make a chain of weapon resources that describe the evolution of the storm, you can add even more special effects.
      Perhaps make it so that it grows in volume (multiple subs) before it begins to dissipate (single subs, less damage) maybe even fade in and/or out (falloff).
      You could eat weap resources pretty quickly though. I'd say around 10 to make a nice complex, and dynamic storm in this fashion.

      Otherwise, just 3 weaps would make a nice storm that appears so materialize out of a random location, and fly around a bit before ending. The last sub is recursive. With well tailored sprites, you can make it fade in and out without using falloff.
      Make the graphic so that is doesn't suggest a particular direction (leave that to its actual direction of travel) but rather use the 'spin continuously' feature to show a sprite animation that progress from a fade in, to a fade out. Make the number of frames in the sprite equal to the individual subs' life span.
      The storm will then appear to fade in and out as it changes direction at the begining of each leg.

      Hmmm. You have to make it kill a ship pretty quickly though, otherwise it will act funny if it needs many subs to destroy a ship...

      Though if you use the non-recursive weap version you could address this issue too... and make it so that a hit from the storm won't kill you, and won't make the storm awkwardly appear or dissapear.

      Here is a 10 weap mock-up. Each one subs to the next in the chain.
      1 - random direction, long (invisible, harmless)
      2 - random direction, shorter (invisible, harmless)
      3 - fade in, main storm, 2 subs
      4 - main storm, 2 subs
      5 - main storm, 2 subs
      6 - fade out (harmless planet type weap)
      7 - fade-in, main storm
      8 - main storm
      9 - main storm
      10 - fade out (harmless planet type weap)

      The idea here is that, if a ship triggers a prox hit durning one of the main storm stages, it will immediatly sub into the next one, untill one of the fade out stages are reached. At which point, the weapon can pass through the target and continue on its way, or gracefully end. The '2 subs' stages will make the storm appear to grow.
      If you wanted, it may be desirable to insert a couple more stages for fade in 'padding', to help prevent catching a ship before the storm is fully visible (thus 'popping' into exsistance) or to help prevent a sub from becoming active while it happens to be on top of a ship sprite (and then not subbing properly)

      Well, that certianly became a long rambeling reply...

      Maybe I could make a "Weather in Spaaaaace!" plug.