Manipulator arm should always target nearest targetable object instead of locking onto one object and ignoring others. obviously, once it grabs something, it shouldn't drop it to focus on something closer.
#Manipulator arm should constantly target nearest.
nimble thicket
rancid yew
Make it target the object closest to the arm's gripping point, that way once it's holding on, nothing is closer?
tame star
Maybe a tuning option, because "nearest" relative to what? Ship CoM? The grabber? The excavator? The hardpoint?
prisma spear
Tuning options like for PD turret.
rancid yew
Yeah, that could work too
nimble thicket
Make it target the object closest to the arm's gripping point, that way once it'...
yes. I think it would be best if this didn't happen:
nimble thicket
Maybe a tuning option, because "nearest" relative to what? Ship CoM? The grabber...
nearest relative to arm's resting point.
true pine
That makes the behaviour pretty eratic. At some point the manipulator will go back-and-forth between targets, it looks like it has z seizure. I tried it.
tame star
That makes the behaviour pretty eratic. At some point the manipulator will go ba...
Possible to give it a cooldown of a few seconds between switching between in-range targets? Or is that just more hassle for little benefit?
true pine
it doesn't react well in general if it needs to switch to a different target while it's still in range. I think we have an backlog issue open to examine that when we add some tuning to the arm, but it's currently not a priority
prisma spear
At the very least arm should lose target when powered down.
rancid yew
Folds? Yes. Loses target? I've never tested that, but I'm curious now... lol
Just checked, and yeah, current target persists across turning the arm off and back on, as long as it's still in range.
Then as soon as that rock which was already the target drifted out of reach... switch!
prisma spear
At the very least the ability to reset the arm by cycling it would be very handy.
true pine
I mean what probably happens here is that it resets, then goes through the same deterministic selection procedure and picks up the same one.
prisma spear
I mean what probably happens here is that it resets, then goes through the same ...
If so the procedure is deeply flawed.
I may have a valid target lined up right in front and it will keep going for something far away, way to the side and possibly out of reach.
And the targets might have moved since original acquisition too.
rancid yew
I mean what probably happens here is that it resets, then goes through the same ...
It doesn't. In both of those example sets of pics, it's reaching for something OTHER than what it would go for if it was freshly assessing targets. It retains the already-selected target when shutting down and reactivating.
rancid yew
Just checked, and yeah, current target persists across turning the arm off and b...
For this one, the drone arm had previously been holding the rock that's waaay up by the rear of the ship in the pic - in range, but barely. I had positioned the rock there, then let go of it by deactivating the arm, then rotated the ship toward the smaller rock which was drifting towards me. When I activated the arm again, the smaller rock was almost exactly on the arm's default rest point, directly in front of it, and very obviously the most logical thing for it to grab.
It reached for the rock it had previously been holding instead.
rancid yew
With the pics from here down, I show my ship holding the small rock, letting go and letting it drift out of the arm's reach before activating the arm again. It now has the larger rock in its reach, and closer to the line it defaults to aiming into, and it still went for the slightly out of reach smaller rock, because it had been holding that rock previously.
nimble thicket
It's just annoying when trying to grab something when it's trying to grab a large iceteroid out of reach and range.