Balanced Annihilation V6.21

[KDR_11k]

I really think leveler should damage itself.... Its a game feature after all.

It's a feature until it is removed. Keeping things just because they are features is dumb, should we keep OP weasels?

[Jim_Hatana]

game physics that affects gameplay thats a main feature of TA why remove it. It will be starcraft or smthing. Now u need to think where leveler needed an where it will cause more problems.

really I starting to play Sring after SupCom. These are grat games but TA really much more interesting because of its features terrain that matter friendly fire. Its a pity that Aircraft collision removed...... Ever see ASF blob in supcom? like 60 planes in one big crowd/

[1v0ry_k1ng]

supcom sucks a dick so no. the aircraft collision was removed because enabled it causes lag. units damaging themselves is not a feature unless it is intentional; since the noselfdamage tag in spring inexplicably fails, its a bug

[Pxtl]

Well, the simplicity angle is a good point - it is nice to have the rule be dead simple: the weapon does X damage with Y radius. Not "unless the explosion is close to itself" and so on. Conceptual simplicity should not be undervalued, although it does result in tactical complexity (maintaining a minimum range).

[Orakio]

Not to sure if this bug/feature has been listed or not. Anyway I was playing speed metal and the enemy build a huge number of nuke launchers. We had just enough anti nuke launchers to hold it together.

Part of my base spontaneously blew up and a nuke hit my ally even though we had enough anti nukes. That tok out a load or our antis amongst other things.

A few of the anti nuke launchers were still loaded though. Another load of nukes came in and I think I had just enough antis, but randomly one of my launchers blew up and one got through again.

Upon watching the replay it turns out that the antinuke missiles hit some conplanes that were patroling a nearby T2 vehicle plant.

Because of that we lost that game when we had the chance to win, if we kept up and built enough anti nukes.

If you consider this a bug, fix it. If not, BA players, keep planes away from antinukes! I know this was a problem with nuke launchers so it shouldn't be hard to fix.

[MR.D]

All Antinuke weapons should have a faster rate of fire.

Seriously, the Nuke flood launch is ridiculous, where you can multi launch nukes and overtake an Antinuke regardless of how many missiles you have stocked.

ANS missiles acceleration and travel time is fine, so that nuke launches aren't intercepted before the missile is airborne, but as long as you have ANS missiles stocked enough to destroy a volley, you should be able to.

If the launch rate was faster for Antinuke (mobile and fixed), a silo wouldn't be overtaken by what I consider a bug/exploit just to finish a game.

However rare this is to actually happen, its not just a speedmetal issue, and should be looked at carefully.

Honestly though, all Spring really needs is a Unit limit adjustable for each individual unit, just like there was in OTA multiplay.

Being able to limit how many of any specific unit can be built during a game was pretty nice in helping balance overpowered units without having to remove them completely.

A good example is limiting how many LRPC would be in any given game.

[Evil4Zerggin]

AFAIK antinukes fire as rapidly as the engine allows atm. It'll need an engine fix. As for colliding with friendlies, the relevant tag is collideFriendly = false (or "0" for non-Lua peoples). It might even be worth putting it on all vlaunch.

[Pxtl]

AFAIK antinukes fire as rapidly as the engine allows atm. It'll need an engine fix.

Doesn't the engine simply allow one-anti-per-nuke? So to fix that, wouldn't making the anti-projectile hellishly fast solve that? Of course, as always, I'm talking out of my ass - I have no knowledge. But it seems like fast-moving antinukes would let the launchers try/fail many times before the nuke hits.

[KDR_11k]

AFAIK antinukes don't check if the missile hit, once one antinuke as fired at a nuke that nuke is considered done, they won't try again.

[Evil4Zerggin]

Okay, so a look at the source code and a brief test shows the following:

• Stockpiled weapons have a hardcoded 2s time between shots (the reloadtime tag controls how much time it takes to stockpile one projectile; I'm talking about time between shots that are already stockpiled). Therefore, an antinuke can be overwhelmed by firing so many nukes that the later antinuke missiles do not have time to track and intercept the target. The maximum number of missiles intercepted is determined by the hardcoded time between shots, the nuke's and the antinuke's flight characteristics, and the distance between the nuke and the target. If one wishes to increase the number of nukes an antinuke can intercept, one can try the following:
  • Makes nukes slower, or increase their weaponTimer so the vertical phase lasts longer. However, this reduces the effectiveness of EMP-and-nuke (since the EMP is more likely to wear off before the nuke hits), which may or may not be something you want.
  • Make antinukes faster (although even if they were instant, you would still be limited by the 2s hardcoded time between shots). You probably don't want it to be too quick, though, unless you want nukes detonating ten feet above their silo on intercept.
  • Engine change or LUA h4x to reduce the hardcoded time between shots.
• Once a nuke is tagged as having an antinuke on the way, it never gets untagged, so it appears KDR_11k is correct.

[Acidd_UK]

... As for colliding with friendlies, the relevant tag is collideFriendly = false (or "0" for non-Lua peoples). It might even be worth putting it on all vlaunch.

Nooo, I think this is one of the great things about the Spring engine. Jusy don't let stuff fly over your nuke/anti when it's firing!

[KDR_11k]

Are you sure it's 2 seconds, not 200 milliseconds?

[Pxtl]

Wait, so there's no way to control the rate-of-fire of any stockpiled weapon? Teh suck.

[Evil4Zerggin]

Code: Select all

if(weaponDef->stockpile)
    reloadStatus=gs->frameNum+60;
else
    reloadStatus=gs->frameNum+(int)(reloadTime/owner->reloadSpeed);

Hooray for hardcoding >_>.

[Pxtl]

Icky. No way to fix that in a sensible way without breaking backwards compatibility. If you remove the exception and add a stockpilebuildtime tag for the stockpile construction (which would make sense) you break backwards compatibility. If you add new tags for firingcost and reloadtime for stockpiled weapons, then you have an ugly inconsistency.

I guess the only reasonable solution is to roll-your-own stockpile using a Lua widget or something, but that creates its own problems.

[Rubenes]

Why not keep the reload tag, and add a new "stockpilereloadtime" tag or something. That would not break compatability, but you could still control the reload time in between stockpiled shots. Of course, it would be somewhat confusing, but I think this is the best solution to maintain backwards compatability.

[Evil4Zerggin]

On the plus side, multiple antinukes seem to work correctly as far as I can tell, as long as the antinukes are reliable.

[Elkvis]

It makes perfect logical sense that with enough nukes, you can overwhelm even an infinitely stockpiled anti-nuke.

If you let your enemy have 10+ silos, and you only ever build 1 anti. Then you are asking to die. Because, even assuming that the anti-nuke is going to be able to fire enough nukes in the required time, your enemy is going to be able to out-produce you.

[MR.D]

1 anti-nuke could have 30 missiles stocked, but has a fixed rate of fire.

Anti-nuke missiles don't accelerate in the air, Nukes do.

Anti-nukes fire 1 shot per nuke launched, as long as ammo is available, so if a Nuke is missed, the anti will not fire again like mentioned above, it simply considers an Anti missile launch as problem solved and percieves no more threat.

Problem is that Nukes were changed to accelerate during flight, to gain a pretty massive speed advantage in travel, anti-nukes can intercept as long as it can meet the Nuke halfways or closer to the Nuke launch origin.

There is a distance at which the anti-nuke could fire a missile, and it wouldn't be able to catch the nuke in time because of its higher speed.

Another problem is that players think a single anti-nuke is all they will ever need, which is a pretty common misconception.

I'm pretty sure that 3 Nuke silos which launch 1 missile each, will overtake 1 single Anti-nuke at a 20x map distance just because of Anti-nuke's slow launch cycle, regardless of how much ammo is stocked.
Can sombody confirm that its 3 nukes, and not more or less?

Edge tolerance seemed to be another thing mentioned, where if you fire a nuke just inside the outer boundary for protection, that the Anti-nuke will launch, miss and the Nuke will hit regardless.
Can anyone elaborate on what the details are of that scenario?

[Acidd_UK]

Mr D, I don't think any of the points you raised are a problem. The exception is the range issue where you think at a certain range an anti cannot intercept the nuke before it hits. Can you provide a replay to demonstrate this?