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

sort
Firepluk 4 years ago (edited 4 years ago) 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
Forever 4 years ago (edited 4 years ago) . +0 / -0
Manored 4 years 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
Tarkin 4 years ago Make it so area reclaim doesn't impact rezzing or partially rezed wrecks while direct commands do reclaim them. +1 / -0
Birdulon 4 years 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
GoogleFrog 4 years 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
duser1 4 years ago Yes, there is a ticket: https://github.com/ZeroK-RTS/Zero-K/issues/3685 +1 / -0
duser1 4 years 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: https://github.com/spring/spring/blob/develop/rts/Sim/Units/CommandAI/BuilderCAI.cpp#L1004-L1013 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: https://github.com/spring/spring/blob/develop/rts/Sim/Units/CommandAI/BuilderCAI.cpp#L1569-L1570 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: https://github.com/spring/spring/blob/develop/rts/Sim/Units/CommandAI/BuilderCAI.cpp#L1440-L1472 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
kema 4 years 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
kema 4 years ago and the outcoming unit has 1 hp. +0 / -0
Manored 4 years 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
GoogleFrog 4 years ago duser1 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
duser1 4 years 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

Forum index > General discussion >