



GoogleFrog 3 years ago

(edited 3 years ago)

To stick with the theme of crazy Defender changes we've cooked up something that few thought was even possible. Defender now has a reload bar. Trident is another benefactor of this change and its fancy new bar even convinced Angler and Hacksaw to make the switch to Defender-style independent reloads.



Aside from the Defender we have mostly been working on polish, fixes and stability. Constructor movement is much improved with the application of raw move. The crash reporting system is working well as the engine seems to have become much more stable over the last few months. A noticeable performance boost should be noticeable thanks to the fixes for this ticket:



Balance



Flail:

Removed weapon AoE [?]

Movement speed 106.2 › 105 elmo/s

Angler:

No longer has to use all 4 missiles at once [?]

Delay between individual missiles in a salvo 0.40 › 0.32 s

Range 750 › 820 [?]

Hacksaw:

No longer has to use both missiles at once [?]

100% faster vertical aim [?]

16% slower missile speed [?]

Solar Collector:

No longer toggleable manually (still closes on damage)

Increased the footprints of some units. This reduces their ability to clump so whether it is a buff or a nerf depends on the situation.

Roach, Tick, Flea and Skuttle footprint sizes increased to 2x2 (up from 1x1).

Buoy, Hammer, Thug, Outlaw and Felon footprint sizes increased to 3x3 (up from 2x2).

UI



Added reload bars for the special reload system used by Defender and Trident (as well as, now, Angler and Hacksaw).

Added a setting to remove non-terminating commands (guard and patrol) from constructor command queues when they have a command added to their queue. Guard orders now cancelled by further commands unless they are given just after Guard. Enabled by default, lives under under `Settings / Unit Behaviour`.

Camera fast/slow movement can be bound as a hotkey in the misc hotkeys menu.

Builders now take a straight path towards their repair/reclaim/construction targets (if possible) and are much less likely to become stuck. This behaviour is already present for move commands.

Factories now draw an arrow indicating their exit direction. Drag the mouse to change their exit direction.

Added an option to show build ETA for icons on strategic zoom.

Added an option to set tooltip opacity.

Waiting units now have an overhead icon to indicate that they are waiting.

"catching up please wait" now shows server time and a more accurate ETA.

Enemy resign votes no longer show vote buttons.

Unit value lost/killed is now tracked by endgame graphs.

Added an option to deselect units that start retreating (default enabled).

Add an option to make retreating units treated as different selection rank (default enabled, rank 1).

Units now obey direct orders when retreating - the unit is still considered retreating during that time (for selection rank override and icon purposes) and will resume retreating (potentially getting deselected) after it becomes idle.

Miscellaneous



Roach, Tick, Skuttle models are 20% bigger. This change does not affect game mechanics. Flea is similarly 10% bigger.

Replaced 2D tree sprites with 3D models on some older maps.

Added boxes for Trojan Hills v03.

Zombies now raise commanders from the dead.

Fixes



Fixed being unable to go back to the default camera if it was changed to another

Fixed Smart Bombers disobeying manual fire state override

Fixed tooltip overlapping the minimap when looking at ping on the default layout.

Fixed a COFC free mode crash.

Fixed a crash when killing a nanoframe and using old engine.

Fixed double click attack move no taking into account mouse movement.

Fixed teamcolors looking very similar.

Fixed gesture menu with raw move.

Fixed keep target with line move.

Fixed Limpet using a weird metal chunk for wreck.

Fixed Mace leaving a lingering green trail.

Fixed a crash when a spectator moves to a player team (with cheats).

Fixed many shader errors.

Fixed bombers circling a target unable to reach it properly.

Fixed Cobra aiming from hunched position (potentially thinking it's blocked).

Fixed Flea burrowing while attacking.

Fixed a chicken queen morph crash.

Fixed Stardust not prioritising close enemies.

Fixed construction at zero storage when on a team of players who are also constructing.

Fixed cases where very low income (eg from just a factory) would not be spendable without storage.

Fixed Pylon and Zenith tooltip description not updating.

Fixed disabled economy units income icons not updating.

Fixed some cases where missile OKP failed to work against rapidly incoming enemies

Fixed killed nanoframe debris tooltip showing full value.

Fixed Engineer commander failing to shoot at very close targets.

Fixed weapon lights rendering.

Fixed crashing unit translations.

Fixed shield colours.

Fixed Circuit AI to obey unit disabling.

Fixed Crude player list showing dead teams as alive.

Fixed tactical AI getting stuck on useless targets such as Solars.

Fixed Engineer commander and Infiltator spider having bad walk animations. To stick with the theme of crazy Defender changes we've cooked up something that few thought was even possible. Defender now has a reload bar. Trident is another benefactor of this change and its fancy new bar even convinced Angler and Hacksaw to make the switch to Defender-style independent reloads.Aside from the Defender we have mostly been working on polish, fixes and stability. Constructor movement is much improved with the application of raw move. The crash reporting system is working well as the engine seems to have become much more stable over the last few months. A noticeable performance boost should be noticeable thanks to the fixes for this ticket: https://springrts.com/mantis/view.php?id=5672. Increased the footprints of some units. This reduces their ability to clump so whether it is a buff or a nerf depends on the situation. +8 / -0

Orfelius 3 years ago quote:

Solar Collector:



No longer toggleable manually (still closes on damage)

Why? I thought it was a neat interaction that allowed solars act as a decent damage sponges. Why? I thought it was a neat interaction that allowed solars act as a decent damage sponges. +2 / -0





Firepluk 3 years ago

pointless change ruining some more of the fun because lob lob develobpointless change ruining some more of the fun +0 / -0

Skasi 3 years ago Probably because it adds brainless micro. There is absolutely no reason not to close a Solar when a heavy hitting projectile flies at it, so it's trivial and dull having to do that. It's something a computer could do perfectly if gadgets/widgets were allowed to see projectiles (can they? idk). +0 / -0



gajop 3 years ago If I remember correctly, it would only close after receiving damage, meaning that high alpha could kill it before it become armored. +0 / -0

Orfelius 3 years ago

(edited 3 years ago) Well sure it can be brainless mirco but its not like it closes automatically before a high alpha unit comes in like for example puppy. Now you don't even get an option to close it yourself. Its not like the solar got better with closing itself when it thinks its in danger. +0 / -0





GoogleFrog 3 years ago

(edited 3 years ago) there are two ways to make units smart. The first is to change their unit AI to better take advantage of the active abilities available to them. The second is to remove active abilities which they are currently using sub-optimally. A unit with no active abilities is, by definition, always behaving optimally. Solar used to have the abilities:

Active: Can be turned off. Can be turned on if it has not taken damage in the last 7 seconds.

Passive: Turns itself off upon taking damage and then turns back on 7 seconds later. The active ability was removed. Some issue related to the ability was bought up, I pointed out that it could be removed, and removed it. I've never been happy enough with a solution to take action myself.



I've always been in two minds about the active ability. These facts point to it having poor AI:

Solars instantly gain armour when they begin to close. I've been unable to a Scalpel (622 damage) to 1-shot kill a Solar (500 health), the bonus is that instant.

Closing a slightly early is likely to have no economic impact but can gain the Solar a lot of survivability.

Technically, it is often straightforward to predict when a Solar is a split second away from taking damage (with some edge cases such as Scythe and Moderator).

The straightforward improvement for Solar unit AI would be to give it 2000 health, remove its armour bonus, and remove its active ability (since it is now useless). This change would be effectively equivalent to creating perfect Solar AI and bypasses all the hassle of tracking projectiles in flight and watching where Moderators are aiming. With some hax in the UI people wouldn't even know that Solar doesn't technically have an armour bonus. The issue with perfect Solar AI is that few people ever micro their Solars so they would become a lot tankier and removes their practical weakness to burst damage. This is why their active ability was removed instead.



Personally I dislike both of these solutions (most of the time). Microing Solars is very rarely effective and when it does come up it can make you feel clever. My solution would be to make Solars gain armour once they are closed, making the unit AI much less trivial to write. However this would effectively be a reduction in tackiness, which I would rather not do. So Solars would need some health buff to compensate and the whole issue has become too hard to justify looking into while there are important things to do. Orfelius there are two ways to make units smart. The first is to change their unit AI to better take advantage of the active abilities available to them. The second is to remove active abilities which they are currently using sub-optimally. A unit with no active abilities is, by definition, always behaving optimally. Solar used to have the abilities:The active ability was removed. Some issue related to the ability was bought up, I pointed out that it could be removed, and Sprung removed it. I've never been happy enough with a solution to take action myself.I've always been in two minds about the active ability. These facts point to it having poor AI:The straightforward improvement for Solar unit AI would be to give it 2000 health, remove its armour bonus, and remove its active ability (since it is now useless). This change would be effectively equivalent to creating perfect Solar AI and bypasses all the hassle of tracking projectiles in flight and watching where Moderators are aiming. With some hax in the UI people wouldn't even know that Solar doesn't technically have an armour bonus. The issue with perfect Solar AI is that few people ever micro their Solars so they would become a lot tankier and removes their practical weakness to burst damage. This is why their active ability was removed instead.Personally I dislike both of these solutions (most of the time). Microing Solars is very rarely effective and when it does come up it can make you feel clever. My solution would be to make Solars gain armour once they are closed, making the unit AI much less trivial to write. However this would effectively be a reduction in tackiness, which I would rather not do. So Solars would need some health buff to compensate and the whole issue has become too hard to justify looking into while there are important things to do. +0 / -0

Orfelius 3 years ago

(edited 3 years ago)



For example: why give a choice to a player in a matter of whether a screamer can fire or not? I mean the AI can't distinguish good and bad targets so we should remove that interaction to not allow the player to compensate for the dumb behaviour.



Also I agree that the implementation of armour is kind of lazy in general. It just instantly gives the armour bonus, which is why for example you can slide as a Crabe for example and that looks very silly and unnatural. I don't think I would agree that removing an option to micro makes the unit smarter. It just removes the possibility of overriding it as a player. Neither it is behaving optimally because the optimal way to do it for a solar would be to close everytime a solar is in danger. Its only optimal in a sense that it's atm just as good as the player (because of the removed interaction). I believe any interaction could be described and removed as such.For example: why give a choice to a player in a matter of whether a screamer can fire or not? I mean the AI can't distinguish good and bad targets so we should remove that interaction to not allow the player to compensate for the dumb behaviour.Also I agree that the implementation of armour is kind of lazy in general. It just instantly gives the armour bonus, which is why for example you can slide as a Crabe for example and that looks very silly and unnatural. +1 / -0

Skasi 3 years ago

(edited 3 years ago) quote:

For example: why give a choice to a player in a matter of whether a screamer can fire or not? I mean the AI can't distinguish good and bad targets so we should remove that interaction to not allow the player to compensate for the dumb behaviour.

That's a bad argument. Screamer targets require thinking and planning. It's something based on a player's ideas and strategy. Closing solars is not. Closing solars is an extremely trivial thing and almost only relies on calculation/prediction (something computers were made for, something that humans shouldn't have to do manually). That's a bad argument. Screamer targets require thinking and planning. It's something based on a player's ideas and strategy. Closing solars is not. Closing solars is an extremely trivial thing and almost only relies on calculation/prediction (something computers were made for, something that humans shouldn't have to do manually). +1 / -0





GoogleFrog 3 years ago quote:

I don't think I would agree that removing an option to micro makes the unit smarter. It just removes the possibility of overriding it as a player. Neither it is behaving optimally because the optimal way to do it for a solar would be to close everytime a solar is in danger. Its only optimal in a sense that it's atm just as good as the player (because of the removed interaction). I believe any interaction could be described and removed as such. Are we now arguing about definitions? My definition is precise. A unit has a set of abilities. Some abilities are active in that the can be directly controlled by players and are fairly independent of the situation. Other abilities are passive - they trigger automatically depending on the situation. For example, aiming and firing (possibly at a restricted set of targets) is an active ability because it can be disabled and controlled directly by players. Dying when you've taken too much damage is a passive ability.



My definition of unit AI is simple. Unit AI is the way in which units automatically use their active abilities. I don't see why you dislike such a simple definition. Perhaps you are worried about a bait-and-switch where I define a word in a particular way but then try to sneak in positive connotations. I am a little worried that you are subconsciously doing this with 'optimally' and 'smarter'. Do people want smarter units than dumb units in all cases? Surely they do. I aim to use 'unit AI' free of connotations. 'Better unit AI' means a reduction in the gap between how optimally a unit is automatically using its active abilities. It doesn't necessarily mean that the unit has better behaviour/mechanics/whatever or that better unit AI makes the game better.



quote:

For example: why give a choice to a player in a matter of whether a screamer can fire or not? I mean the AI can't distinguish good and bad targets so we should remove that interaction to not allow the player to compensate for the dumb behaviour. The answer is that design is not driven by what would maximize a single parameter. If you remove all the active abilities from Screamer then it has perfect unit AI. It would also be a badly designed unit. Your example doesn't forward your argument though because the Screamer example is simply one failed way to optimize for unit AI for one unit. You haven't shown that unit AI should not be a factor is design.



Perhaps, what you want to say, is that the Screamer in your example has unrealistic or inconsistent abilities. Every other unit can select its target and it doesn't make sense that a complicated missile launcher would have so much inbuilt impulsiveness that it cannot hold its fire. If you imagine a berserker type unit in a fantasy/medieval game perhaps it would make sense that this unit cannot actually resist chasing and attacking enemies. For Screamer it would make no sense. You could also say that hold fire makes Screamer a better designed unit. Screamer is useless if able to be drained with drones or Blastwings. Perhaps 'behaviour' is a good word for what the unit does when not directly controlled by the player. What it does will be a result of its passive abilities and unit AI.



Solars already had dumb behaviour and few people are complaining about it. They have the passive ability 'close for 8 seconds when damaged'. If Solars did not have this ability and instead had unit AI that caused them to do the same behaviour then this would be bad unit AI. Whenever a Solar is poked it costs the owner at least 16 energy and it is common for early raiders to poke many Solars that they would have no chance of killing. The passive ability exists to allow for small gains from light raiding and is too good to remove.



Writing these walls of text has been useful. I think I'd like Solars to take about 1.5s to become armoured after they start closing and to buff their health a bit in compensation. Then preemptive Solar closing would be a less trivial decision and they would be a bit beefier as walls.



quote:

Also I agree that the implementation of armour is kind of lazy in general. It just instantly gives the armour bonus, which is why for example you can slide as a Crabe for example and that looks very silly and unnatural. This is false in general and false for Crabe. Are we now arguing about definitions? My definition is precise. A unit has a set of abilities. Some abilities are active in that the can be directly controlled by players and are fairly independent of the situation. Other abilities are passive - they trigger automatically depending on the situation. For example, aiming and firing (possibly at a restricted set of targets) is an active ability because it can be disabled and controlled directly by players. Dying when you've taken too much damage is a passive ability.My definition of unit AI is simple. Unit AI is the way in which units automatically use their active abilities. I don't see why you dislike such a simple definition. Perhaps you are worried about a bait-and-switch where I define a word in a particular way but then try to sneak in positive connotations. I am a little worried that you are subconsciously doing this with 'optimally' and 'smarter'. Do people want smarter units than dumb units in all cases? Surely they do. I aim to use 'unit AI' free of connotations. 'Better unit AI' means a reduction in the gap between how optimally a unit is automatically using its active abilities. It doesn't necessarily mean that the unit has better behaviour/mechanics/whatever or that better unit AI makes the game better.The answer is that design is not driven by what would maximize a single parameter. If you remove all the active abilities from Screamer then it has perfect unit AI. It would also be a badly designed unit. Your example doesn't forward your argument though because the Screamer example is simply one failed way to optimize for unit AI for one unit. You haven't shown that unit AI should not be a factor is design.Perhaps, what you want to say, is that the Screamer in your example has unrealistic or inconsistent abilities. Every other unit can select its target and it doesn't make sense that a complicated missile launcher would have so much inbuilt impulsiveness that it cannot hold its fire. If you imagine a berserker type unit in a fantasy/medieval game perhaps it would make sense that this unit cannot actually resist chasing and attacking enemies. For Screamer it would make no sense. You could also say that hold fire makes Screamer a better designed unit. Screamer is useless if able to be drained with drones or Blastwings. Perhaps 'behaviour' is a good word for what the unit does when not directly controlled by the player. What it does will be a result of its passive abilities and unit AI.Solars already had dumb behaviour and few people are complaining about it. They have the passive ability 'close for 8 seconds when damaged'. If Solars did not have this ability and instead had unit AI that caused them to do the same behaviour then this would be bad unit AI. Whenever a Solar is poked it costs the owner at least 16 energy and it is common for early raiders to poke many Solars that they would have no chance of killing. The passive ability exists to allow for small gains from light raiding and is too good to remove.Writing these walls of text has been useful. I think I'd like Solars to take about 1.5s to become armoured after they start closing and to buff their health a bit in compensation. Then preemptive Solar closing would be a less trivial decision and they would be a bit beefier as walls.This is false in general and false for Crabe. +0 / -0

Orfelius 3 years ago

(edited 3 years ago)



quote:

The answer is that design is not driven by what would maximize a single parameter. If you remove all the active abilities from Screamer then it has perfect unit AI. It would also be a badly designed unit. Your example doesn't forward your argument though because the Screamer example is simply one failed way to optimize for unit AI for one unit. You haven't shown that unit AI should not be a factor is design.

No, thats not what I meant. This is not about balance nor about design goals of ZK, this is about removing ways that a player can interact with the game itself. Removing his options just because its taken for granted that he is going to perform suboptimaly.



It really boils down to a one argument:



1. Is it a fun and rewarding interaction for a player?



The answer is yes.



quote:

I think I'd like Solars to take about 1.5s to become armoured after they start closing and to buff their health a bit in compensation. Then preemptive Solar closing would be a less trivial decision and they would be a bit beefier as walls.

I think this is a great idea. Eh. Maybe I should have been speaking more clearly from the start instead of giving half-assed examples.No, thats not what I meant. This is not about balance nor about design goals of ZK, this is about removing ways that a player can interact with the game itself. Removing his options just because its taken for granted that he is going to perform suboptimaly.It really boils down to a one argument:1. Is it a fun and rewarding interaction for a player?The answer is yes.I think this is a great idea. +1 / -0



Aquanim 3 years ago I don't really consider microing my solars a "fun and rewarding" interaction, personally. +4 / -0





Firepluk 3 years ago

(edited 3 years ago)

it gives me needed time to make a counter response(yea, now I have 10 seconds instead of 2,5)



I agree this ability is useful like in 1% of all cases, but when it is I'm happy I can buff my barricades HP x4 at the cost of E they generate.

The human decision and trade off here is how much u disable - preemptively disabling more solars means more E loss, but less likely to lose those disabled solars and letting the enemy inside ur perimeter(what wonders does it guard? is it singu cluster? is it nuke? DRP maybe?)



For me it's enough to leave it as a valid game mech. Don't bother with creating perfect AI for this 1% edge case - just remove AI here all together, make decision manual

Manual on/off would prevent easy E gen disruption in early game(when you sure you can kill dat glaive)

you don't bother making DDM closing AI, right?



The perfect way would be to have some smarter AI here though, what is enough in my opinion for AI here:

- start CLOSING with the first hit, let's say duration: 1.5s

- do NOT instantly give HP bonus while it's CLOSING

- gradually reduce E gen during CLOSING phase

no projectile tracking needed, leave this 1% edge case to human decision like described above(sometimes, rarely this will be useful and u will be happy to have it)



but again, for pro players who do a lot of 1v1 this AI may have certain negative impact and there should be an option to disable it :D



This is a very small detail of game, but it makes it look just a tiny bit more diverse, authentic and more interesting

Just my 5 cents I do find closing my solar array barricades (all at once) fun and rewarding, in case when it helps me stop raider/assault swarmit gives me needed time to make a counter response(yea, now I have 10 seconds instead of 2,5)I agree this ability is useful like in 1% of all cases, but when it is I'm happy I can buff my barricades HP x4 at the cost of E they generate.The human decision and trade off here is how much u disable - preemptively disabling more solars means more E loss, but less likely to lose those disabled solars and letting the enemy inside ur perimeter(what wonders does it guard? is it singu cluster? is it nuke? DRP maybe?)For me it's enough to leave it as a valid game mech. Don't bother with creating perfect AI for this 1% edge case - just remove AI here all together, make decision manualManual on/off would prevent easy E gen disruption in early game(when you sure you can kill dat glaive)you don't bother making DDM closing AI, right?The perfect way would be to have some smarter AI here though, what is enough in my opinion for AI here:- start CLOSING with the first hit, let's say duration: 1.5s- do NOT instantly give HP bonus while it's CLOSING- gradually reduce E gen during CLOSING phaseno projectile tracking needed, leave this 1% edge case to human decision like described above(sometimes, rarely this will be useful and u will be happy to have it)but again, for pro players who do a lot of 1v1 this AI may have certain negative impact and there should be an option to disable it :DThis is a very small detail of game, but it makes it look just a tiny bit more diverse, authentic and more interestingJust my 5 cents +2 / -0

Skasi 3 years ago quote:

I do find closing my solar array barricades (all at once) fun and rewarding, in case when it helps me stop raider/assault swarm



Then turn Solars into SC2 Terran depots and let them work like road blockers! ;P Then turn Solars into SC2 Terran depots and let them work like road blockers! ;P +0 / -0

Topkack 3 years ago Why cant we target buildings out of sight but groundfire them? +0 / -0