-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assisting engineers track new construction orders #6169
Conversation
…function to UEF ACU and SACU
…ulder pods "sticky"
Looking for feedback on num 3--I'm a little skeptical of the implementation, but in practice it's very smooth. |
This seems like it could be troublesome as there will end up being orphaned unfinished structures since all the builders, even assisting ones, moved on to another project before the first/original was finished. If ordering all assisting engineers to switch from the first/original project to the new project could be accomplished via hovering over the lead/main engineer & then using a key bind, then that might be a compromise as it will still be in the hands of the player if they want to change which project takes priority. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issues:
- Pods/engineers don't stop construction when the leader gets a stop order.
- Pods/engineers that are assisting other pods don't retarget when the main pod switches targets.
- Assist orders to pods don't go away when the sticky assist order is removed from the parent unit. Undock pod -> assist pod with engi -> dock pod -> remove assist order from parent -> undock pod (assist order will return, but logically it shouldn't)
If ordering all assisting engineers to switch from the first/original project to the new project could be accomplished via hovering over the lead/main engineer & then using a key bind
I agree this would be a nice hotkey, similar to interrupt pathfinding. Currently you can accomplish the task of retargeting assisters by dragging the assist order and placing it back on top or by selecting all the engis and assisting the main one again, but of course these options don't work perfectly with multiple assists or engis close to each other assisting different units.
Assist orders for UEF shoulder pods are "sticky"--when the shoulder pod attaches to storage, the assist orders are transferred to the parent unit, and then transferred back when it detaches.
It does look smooth in my testing, but is it necessary? It seems like it obfuscates assist orders overall and makes them harder to manage, since you visually lose track of the assist you placed on the drone for whatever special reason.
Also assisting engineers don't cancel/retarget reclaim orders, even though they seemingly should since they immediately start assisting in reclaiming. |
The motivation for "sticky" pod orders is that A. I see people potentially getting a lot more use out of shoulder pods as independent actors if other engineers (but really mostly kennel pods) can assist them properly and B. it's a pain to send a shoulder pod off to build Template X, assign some kennel pods to assist, then have those assist orders disappear as soon as construction is complete and the shoulder pod redocks. Another solution is giving the shoulder pod an assist order to the base station instead of the (silent) "AssistCommander" order they get now--that just prevents it from docking, and is arguably much cleaner in that it's visible to the player and doesn't involve any backend processing. |
Accidentally did this on the main branch, closing and remaking. |
Additions: