OR  Zero-K Name:    Password:   

Reclaim+Ressurect aren't friends and we should fix this

13 posts, 354 views
Post comment
Filter:    Player:  
Right now it's almost impossible to play ressurect game in teams. You start ressurecting something and some lobster who had area reclaim Q'ed comes and starts eat away your progress and you begin to lose metal instead of energy.

It's almost impossible to communicate this manually each time, the restriction should exist in the base game.

Once thing has been touched by ressurect it should not be reclaimable. There could exist some force reclaim order, but it should be a distinct command

Discussion welcomed... This issue 's been plaguing team games for way too long
+12 / -0
+0 / -0
7 days ago
Ye. I don't blame the giant area reclaim commands, they're pretty great for saving APM and I do them myself all the time. Stuff being rezzed just needs protection from being nommed by allies.

Possibly even cancel reclaim if someone starts rezzing. I'm more in the fence about this because it could be abused (lobster starts rezzing to interrupt allies' reclaim command, then reclaims instead of rezzing).
+1 / -0
7 days ago
Make it so area reclaim doesn't impact rezzing or partially rezed wrecks while direct commands do reclaim them.
+1 / -0

7 days ago
I'm of the opinion that direct commands should always override area commands when there is potential conflict. It's a different level of intent.
+1 / -0

7 days ago
Yes, things being resurrected shouldn't be hit by area commands (or things like patrol). I think there is a ticket on it.
+5 / -0

3 days ago
Yes, there is a ticket: https://github.com/ZeroK-RTS/Zero-K/issues/3685
+1 / -0

45 hours ago
(Warning: I am a spring / zero-k code newbie)
I am trying to understand how it would work to prevent reclaiming what a friendly unit is resurrecting but it is a bit difficult to dive into the code.
I stumbled upon that though:
AFAIKT it should prevent an internal order (which should apply to area reclaim and patrol) from reclaiming something that is being resurrected unless the control key is pressed (and I think this behaviour can be reversed in the configuration).
(I am not sure this behaviour is documented)
Also this:
This should prevent taking a resurrected unit as target for reclaim.
Could someone else please check if it is supposed to do part of what is asked in this thread?
Is it possible that this kind of reclaim is already prevented?
If so, is there a bug hidden? Are the players having control pressed thus overriding the logic?
The other part about preventing reclaiming if the unit is partially resurrected even if not being resurrected at the moment does not seem to be handled at the moment looking at this code:
Maybe it would require a list of units being resurrected (and units would be removed from it ).

Allowing to stop reclaim if already started seems quite different and not attempted at all (that looks quite tricky unless the unit wakes up periodically to check or if the resurrecting unit can notify the reclaiming units).
+0 / -0
39 hours ago
What if reclaiming while ressurecting just lowers the health of the unit that is ressurected? at 1% metal left, you can't reclaim anymore, and con ignores the wreck.
+0 / -0
39 hours ago
and the outcoming unit has 1 hp.
+0 / -0
37 hours ago
Repairs only cost energy, so you'd be effectively multiplying metal by reclaiming a unit being rezzed, rezzing it, and then repairing it.
+1 / -0

31 hours ago
FRrankduser1 try playing around ingame with combinations of cmdOptions. Zero-K disagrees with the engine about good keybinds and defaults for the various ad hoc behaviours hidden in cmdOpts, so "(c.GetOpts() & CONTROL_KEY)" means "Did a widget modify the command so as to have the Ctrl opt" rather than "The player held the Ctrl key".
+0 / -0

10 hours ago
Thanks for the clarification. So maybe the idea would be to tweak something so that control key is not reported as pressed for the area reclaim. There could be side effects though.
So I would probably need to find how this can be printed, probably at least with a widget and then iterate over the command queue and switch off the control key hoping to not break too many things. I am not feeling too confident that this would work well.
Maybe we ask too much from the control key indicator, but I am not convinced adding more state to the command itself would be welcome.
I guess I will report back if I manage to achieve anything worth it, but please do not hold your breath.
+0 / -0