Nanoframes should not decloak units

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

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?

Q-building is a shortcut for easily abusing an exploit. I don't know why someone added that instead of fixing the problem.

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?

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.

The problem isn't units being decloaked, the problem is apparently the general movement hindering and missile blocking problem of nanoframes.

i say its a game mechanic!

i like my blocking nan frames!

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.

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.

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.