Return to the Dark Side: Hoverbombing

[IceDreamer]

Right then... I had a brainwave today. As many of you know, a lot of people consider hoverbombing an exploit, and broken. Others disagree, and still more don't care. A while back, Resin_Smoker attempted to make it impossible to do using code, but his success was... Marginal. He couldn't make it work without unacceptable changes to bomber reliability in normal bombing runs.

Today, using a different approach, I have succeeded in (For my testing at least) disabling the ability to hoverbomb without affecting any of the rest of a bomber's behavior. Now... Zock plans to poll the community on this topic in 6 months or so, once the currently developing balance patch is well deployed. However, I appreciate that some people will want this as a mod, so, if demand is high enough, that's what I'll do.

THIS POLL IS NOT OFFICIAL
http://strawpoll.me/6347415

I recognise some will also be curious, so I'll just post the actual code here too:

Code: Select all

    OnGotTarget = function(self, Weapon)
        local x, y, z = self:GetVelocity()
       
        -- Get speed per second
        x = x * 10
        z = z * 10
       
        -- Square them. Don't use x ^ 2, it returns some really odd numbers...
        x = math.pow(x, 2)
        z = math.pow(z, 2)
       
        -- Find the resultant speed
        local vel = math.sqrt(x + z)
       
        -- If the plane is too slow, disable the weapon
        if vel < (self:GetBlueprint().Air.MinAirspeed / 2) then
            ForkThread(self.BombTimer, self, Weapon)
        end
    end,
   
    BombTimer = function(self, Weapon)
        Weapon:SetWeaponEnabled(false)
        WaitTicks(20)
        Weapon:SetWeaponEnabled(true)
    end,

[Petricpwnz]

Voted nothing, bomber is love <3

Spoiler: show

if the poll will be in favour of removing hover bombing i will cry loud and tell my mom

[Kalvirox]

Zock plans to poll the community on this topic in 6 months or so,

I have succeeded in (For my testing at least) disabling the ability to hoverbomb without affecting any of the rest of a bomber's behavior.

So what you are saying is we have a "solution" for it "now" but we are not going to bother with polling it officially now but rather in 6 months or so.

This seems silly to me.

Why is this delay necessary?

[Cuddles]

vote yes to nerf micro

[IceDreamer]

Zock plans to poll the community on this topic in 6 months or so,

I have succeeded in (For my testing at least) disabling the ability to hoverbomb without affecting any of the rest of a bomber's behavior.

So what you are saying is we have a "solution" for it "now" but we are not going to bother with polling it officially now but rather in 6 months or so.

This seems silly to me.

Why is this delay necessary?

Because Zock? *Shrugs*.

I didn't want to keep this secret, so I put this up for people, but it's not the official thing, so I had to make that clear. Take it how you will.

[Zock]

Zock plans to poll the community on this topic in 6 months or so,

I have succeeded in (For my testing at least) disabling the ability to hoverbomb without affecting any of the rest of a bomber's behavior.

So what you are saying is we have a "solution" for it "now" but we are not going to bother with polling it officially now but rather in 6 months or so.

This seems silly to me.

Why is this delay necessary?

Proper testing and implementing "solutions" to make sure they are real solutions and not just attempted ones takes time. There are a couple hundred "solutions" for all kinds of real and imaginary problems, and hoverbombing is just one of them. Is there anything that makes it special over all the other things? That's why it's necessary to choose which ones to work on now, and which ones to do later. The scope for the next patch was polled and decided to have the focus on t3, exp buildtime and related things instead of something like hoverbombing. This set of changes is already very big and interacting with each other, making things complicated. Adding even more changes to work on would make the patch take even longer and increase the possibility to make bad changes.

Trying to change everything at once is not a good idea for many reasons, it is better to go step by step, and our next step will already be quite big. I don't think it'll take 6 months, but it'll be done when it's working well and tested carefully, not after a certain time has passed. Then, we can decide what should be in the scope for the patch after and work on that.

[Morax]

It's about the same level of "this is just something that's always existed" as the legendary "attack-move" out of a factory with engineers to mass reclaim fields of rock and trees.

I say keep the hover bombing because it's micro-intensity detracts from other actions in the game. I've successfully countered and exposed the cost of early bomber hover tactics plenty of times so I'm sure others can do it.

On the flip side, it is odd that a bomber can just sit in the air and keep firing. This seems more like the actions and capabilities of a "gunship."

Keep the hover bomb as one of those "only in this game" things. The cost to get an early t1 bomber has already made it more difficult to abuse and I see no reason to spend time on it.

[ZLO_RD]

this does make some sence, but i will only vote after i can test it, so after this change instead of waiting X seconds before drop we will just have to reach X speed before drop... not sure how reliable it will be and how much pain it will give to people that just want to slow down a bomber so it does not act like a retard (they tend to be sometimes extremely retarded, you know....)

funny how this change actually may open possibility to buff (lower) reload time of bomber

[FunkOff]

Right then... I had a brainwave today. As many of you know, a lot of people consider hoverbombing an exploit, and broken. Others disagree, and still more don't care. A while back, Resin_Smoker attempted to make it impossible to do using code, but his success was... Marginal. He couldn't make it work without unacceptable changes to bomber reliability in normal bombing runs.

Today, using a different approach, I have succeeded in (For my testing at least) disabling the ability to hoverbomb without affecting any of the rest of a bomber's behavior. Now... Zock plans to poll the community on this topic in 6 months or so, once the currently developing balance patch is well deployed. However, I appreciate that some people will want this as a mod, so, if demand is high enough, that's what I'll do.

THIS POLL IS NOT OFFICIAL
http://strawpoll.me/6347415

I recognise some will also be curious, so I'll just post the actual code here too:

Code: Select all

    OnGotTarget = function(self, Weapon)
        local x, y, z = self:GetVelocity()
       
        -- Get speed per second
        x = x * 10
        z = z * 10
       
        -- Square them. Don't use x ^ 2, it returns some really odd numbers...
        x = math.pow(x, 2)
        z = math.pow(z, 2)
       
        -- Find the resultant speed
        local vel = math.sqrt(x + z)
       
        -- If the plane is too slow, disable the weapon
        if vel < (self:GetBlueprint().Air.MinAirspeed / 2) then
            ForkThread(self.BombTimer, self, Weapon)
        end
    end,
   
    BombTimer = function(self, Weapon)
        Weapon:SetWeaponEnabled(false)
        WaitTicks(20)
        Weapon:SetWeaponEnabled(true)
    end,

This code is bad. With the weapon diabled, you wont be able to tell the bomber to attack stuff because it will have no active weapon.

My solution was more elegant. I mode the bomber weapon itself. When the bomber drops a bomb, the bomb retains the bombers initial speed. Have the bomb check if it's current speed is more than half of the bombers max speed. If it's not, kill the bomb. This never disables the bomber but causes the attack to fail if the bomber is moving too slowly

[IceDreamer]

This code is bad. With the weapon diabled, you wont be able to tell the bomber to attack stuff because it will have no active weapon.

My solution was more elegant. I mode the bomber weapon itself. When the bomber drops a bomb, the bomb retains the bombers initial speed. Have the bomb check if it's current speed is more than half of the bombers max speed. If it's not, kill the bomb. This never disables the bomber but causes the attack to fail if the bomber is moving too slowly

Errrm... No? I have tested this extensively, it works fine. You can still order the unit to attack despite a disabled weapon, it just doesn't fire. Could do it on the projectile, but it's considerably easier to hook into the unit class functions to do this because the projectiles are all over the map. Perhaps actually test things out before you make a sensationalist claim like 'This code is bad'?