Loading...
  OR  Zero-K Name:    Password:   

Nanoframes should not decloak units

37 posts, 1867 views
Post comment
Filter:    Player:  
Page of 2 (37 records)
sort

11 years ago
Right now it is entirely too easy to plop up a zero-cost nanoframe farm around anything you don't want Skuttled, Scythed, or Athena'd. How can a non-functioning nanoframe detect and decloak enemy units?
+0 / -0

11 years ago
think of it more the enemy units and structures emiting energy that interferes with the integrity of the cloak and it destabilises

nano frame will still bleed energy to its surroundings, more realistic if nanoframes degraded like ba but eh
nothings perfect :P

and please athenas can fly on top of enemy structures most of the time without anything happening
athena OP
+0 / -0

11 years ago
Forget the psudo-physics of it. Is it a behavior that we want? I say no. It unfair to use a zero-cost solution to completely counter several units by abusing mechanics.
+0 / -0
Nanoframe degradation would solve a lot of stupid exploits--decloaking stuff, blocking projectiles, blocking weaponless units, and probably more. These are extremely tedious to carry out but have no drawback and completely mess with balance. It has no place in ZK. How about making nanoframes worth less than 50 metal degrade?
+0 / -0
11 years ago
You forget the wonders that the button "Q" provides? degrading nano's will break a lot of gameplay elements that make playing not so irritating.
+0 / -0
11 years ago
Q-building is a shortcut for easily abusing an exploit. I don't know why someone added that instead of fixing the problem.
+0 / -0
11 years ago
non degrading nan frames>>>degrading nanoframes
END OF DISCUSSION

no seriously... do you really want to bring back degrading nano frame?
+0 / -0
Make starting each nanoframe cost like 10 metal (as in, you need to build 10 metal into it).

Hm, what happens if you stop before that? You get the metal/energy back?
+0 / -0
this is, anyway, only a partial solution. i think removing the anomaly nanoframes is best, but this migth be part of engine? and hard to fix.

@MauranKilom
quote:
Make starting each nanoframe cost like 20 metal (as in, you need to build 20 metal into it).


agree. same as with terrorforming. give it a starting cost and maybe a 5 sec delay.

+0 / -0
I edited it to 10... Didn't i? Hm. Anyways, it might be a bit annoying to get used to, but 10 metal is 1 second for com and like 2 seconds for other cons. It's too high for quickly spamming stuff around you, and shouldn't hinder you if you seriously intended to build that unit.

If you're trying to make a big field of nanoframes, you usually won't use only 1 constructor (no, i don't care about flea spam with 1 athena), so it's not gonna change much. Just make sure the cons actually build to the treshold if q-queued (lol).

PS: Surrounding your fragile stuff with solars has the same effect, but doesn't die to raiders (or scythe hits for that matter) in one shot.
+0 / -0
11 years ago
What... wasn't nanoframes' ability to decloak removed a few updates ago?
+0 / -0

11 years ago
The problem isn't units being decloaked, the problem is apparently the general movement hindering and missile blocking problem of nanoframes.
+0 / -0

11 years ago
The problem is that the best approaches aren't stuff the engine supports - like making early-nanoframes crushable or intangible or something.
+0 / -0
11 years ago
i say its a game mechanic!

i like my blocking nan frames!
+0 / -0
An example: you can plop zenithnanowall around anything you don't want eos'd either. Completely for free, and stop a 600m missile with it.

I've also already considered making a 'panic shield' button that would make my com spam 4 nanos around it to intercept incoming missiles, like rocko fire or whatnot. Instant survivability +50% bonus.
+0 / -0


11 years ago
I would like to fix these issues but many things are difficult or impossible and the available solutions have drawbacks. As far as I can tell these are the issues which are bought up.

These issues would be fixed easily if the engine was able to split things which have completely different behaviours but depend on the same thing. There is one tag for unit radius and center point which controls projectile collision, unit decloaking and unit selection.

Issues

1. Nanoframes decloak.
This would be nice to fix because the tactic is unsightly but ultimately I think it is a low priority issue. There are many ways to decloak things in areas that you safely control so it is not much of a balance problem.

2. Nanoframes block unit movement.
Units can kill nanoframes so I am not sure how much of a problem this is.

3. Nanoframes block projectiles.
I would say this is the most pressing issue and probably the easiest to fix although many fixes have drawbacks.

Solutions

A. Nanoframe decay
This was removed years ago because it enables reclaim with no BP spent. Additionally it is annoying to leave a constructor with Wait enabled to prevent a structure that you want to go back to from decaying. This somewhat fixes 1 and 2 except if you get a nanoturret to wait-poke all nanoframes in it's radius. 3 is not particularly affected because you can make frames when you need them. Implementation is somewhat complicated by terraform.


B. Nanoframes don't exist for the first X metal
After X metal what happens if there is a unit, or even a structure, in the way? Additionally an invulnerable unit for construction cannot be right clicked on to produce it as everyone knows from terraform blocks. Technically this solution is possible because terraform blocks are already nanoframes which have absolutely no effect on opponent units.

To fix my first issue with this solution the nanoframe could constantly check after X metal whether the buildspace is free and then allow construction to continue. This requires AllowBuildStep which is a large source of slowdown.

Invulnerable nanoframes for the first X metal makes turret push more powerful, especially LLTs and MTs if you can make an LLT which pops in able to survive some defender shots.

C. Nanoframe hitvolume rises upwards for the first 33% of the build
This makes a lot of sense give the building animation but has similar, but not so extreme, selection issues to solution B. I think this would solve issue 3.


If 1 is fixed then 2 is a problem because nanoframes built as a wall can stop ground based cloakies.
+0 / -0

11 years ago
quote:
2. Nanoframes block unit movement.
Units can kill nanoframes so I am not sure how much of a problem this is.


Please don't underestimate the impact this creates. Many slow-firing units are forced to be put on holdfire because they waste shots on nanoframes. Lately, I've been using frames quite a bit to counter reapers, scalpels, penetrators, and other high-alpha units.
+0 / -0

11 years ago
Yes, but that's a hard problem to solve... what would you have those units do? Ignore nanoframes? In those cases the problem isn't that the nanoframes are shootable, but that the unit is firing upon a super-low-value target that wastes a precious shot.

There is no right answer, no global rule that is satisfactory for that. There are things that could be done to mitigate the problem, but "should unit X shoot target Y" will always be subjective and context-sensitive question.

I mean, I wouldn't want my scalpel firing on a flea, unless that flea was the only target that was *anywhere near* the scalpel and nobody else can kill it. Near-zero-value nanoframes take this problem to the extreme.
+0 / -0

11 years ago
Using small units to draw fire from long reload units is a legitimate strategy. Ofcouse, using nanoframes moves the cost near zero, but the strategy is generally valid.
+0 / -0
I met this problem when designing the anti-bait part of the now defunk AA micro gadget.

My solution for preventing hacksaws from shooting avengers was to have Hacksaws and Screamers ignore all airunits with <650 (I think) max hp + vamp; as long as they had more than 300 "dps" of other non-hacksaw/screamer AA within half of their maximum range.

A land version of this for sniper/scalpel/pene/warlord/etc. would be to ignore things with less than X cost (using currently built cost of buildings) as long as some manner of anti-light units is present within half this unit's maximum range.
It's still very hacky and certainly edgecases will prevent problems. It depends on whether the edgecases occur often enough to make ordering them to shoot cheap stuff more of a hassle than ordering them not to shoot.

(and whether those cases can be covered by an exception; eg. you almost certainly want a sniper to try to shoot an approaching tick since you might hit and ticks are dangerous)

EDIT:
and it doesn't stop the "wall" use of nanoframes. Spend a constructor to maintain the wall and the snipers won't be able to hit anything, anti-bait or not.
+0 / -0
Page of 2 (37 records)