Better tractor beam speed management

[tibetiroka]

Problem Description

Currently, a Tractor Beam's tractoring velocity is some base value divided by the tractored object's mass. While this is fine for asteroid mining, it does not scale well to heavy flotsam, such as engines.

Heavy flotsam is partially frozen in place (as seen from the ship) by the tractor beam. While this is not the intended use case, it still makes it a lot easier to retrieve the cargo, though only with sufficient maneuvering. Balance-wise this is an important distinction, because it helps more maneuverable ships more than less maneuverable ones that generally have a greater need for tractor beams.

Related Issue Links

#9398

Desired Solution

There could be a minimum velocity based on the tractor beam attribute that would be guaranteed even for the heaviest flotsam. Alternatively (or additionally), the scaling could be changed to be less aggressive; maybe similarly to how protection attributes work.

Alternative Approaches

The tractor beam could be left as-is. This only affects factions that would want to scavenge flotsam from destroyed ships, and they are generally already capable of that without resorting to a tractor beam. Also, making the flotsam stationary is already helpful, even if it cannot be pulled in.

Additional Context

No response

Tasks

Beta Give feedback

No tasks being tracked yet.

[Zitchas]

A combination of values comes to mind:

• Target mass (what size thing is this tractor beam most effective against)
• Target speed (how fast the ideal mass Target will be pulled in.)
• Below Mass Dropoff (how aggressive is the reduction in speed for things that weigh less)
• Over Mass Dropoff (how aggressive is the reduction in speed for things that are heavier)

For the mass Dropoff: 1 is default, current rate. 0-1 reduces the Dropoff rate, >1 makes it Dropoff faster, negative inverts it so it moves stuff the opposite direction.

This would allow a full range of variety, including being able to have it repel things. For instance for the Remnant and Korath. The Korath have a beam that attracts things <= 10, and repels stuff that is bigger, while Remnant could have the opposite that attracts things above 10, and repels things lighter than that.

[Amazinite]

Yeah. I'm thinking of changing it so that it takes the square or cubed root of the mass of the object being pulled, then reducing the strength of the current tractor beam by the same factor. Some minimum velocity applied to the flotsam regardless of mass would also work.

[SomeTroglodyte]

Best test case: Yottrite, imho. With an agile ship and a TB, you can "push it around", if desired, even in amusing patterns.

[Quotatron3000]

Just wanted to sound off on the tractor beam.

Currently, if an object is stationary, and your ship is making pace towards it, and the flotsam happens to be heavy, the tractor beam mechanics actually 'pushes it away' from you, making it take longer to retrieve or sometimes even malfunctioning and giving the flotsam additional unwanted acceleration.

The tractor beam needs to factor in the acceleration and angle of the ship itself also. So if I'm speeding towards the flotsam, it should include ship's acceleration + tractor pull rate to determine speed, not just tractor pull rate.

[SomeTroglodyte]

Entirely unordered observations - from joke level to might actually work:

• Ship.cpp L2062: "flostam"
• Ship.h L455, L691: set vs unordered_set: Seems to me the sorting is wasted, but yes, not a drop-in replacement (Flotsam lacks the hash method or somesuch?), and C++ >=11 ...
• Ship.h L455, L691: Other ships of the same faction don't know this, which explains the endless tug-of-war player escort vs. player escort. I offer the vague idea to drop this and instead store a set of governments whoIsTractoringMe or somesuch on the Flotsam class. The avoid tests would be similar complexity, but this would also allow Flotsam lifetime to interact with being tractored. As is, with Yottrite you can notice you will lose some to tug-of-war. Not too annoying, but create a minable dropping, say, an armageddon core, and you'll get to the point that having tractor beams will reliably prevent you from ever picking it up. The changed data model could allow niceties such as reduced rate of lifetime decay (I know it's an int, just scale it up) while being tractored, or even awarding the bounty if it would die while being pulled - if only one contender is participating in the tug-of-war.
• AI.cpp L2930, L2845: count vs contains - I get it, high C++ requirement (my Mint 21 box says no), but readability is blargh. Pity.
• AI.cpp L2930: Seems to me this guarantees a ship will not "hold on" to a Flotsam - as soon as a tractor armament can actually fire on it, target will be in the avoid set. unless something guarantees it is reacquired immediately, like less flotsam in range than tractor turrets - BUT Random::Int(10) - I believe this is most of the cause for the "slingshot" effect.
• AI.cpp L2930: This won't release the Flotsam if it has gotten out of tractor beam range as far as I can tell - is Hardpoint::FireSpecialSystem the only place checking range?

Testing now:

Index: source/AI.cpp
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/source/AI.cpp b/source/AI.cpp
--- a/source/AI.cpp	(revision 8524a76e3d50d946f06d526191068a52036b98a8)
+++ b/source/AI.cpp	(date 1713903542010)
@@ -2927,7 +2927,7 @@
 	shared_ptr<Flotsam> target = ship.GetTargetFlotsam();
 	// Don't try to chase flotsam that are already being pulled toward the ship by a tractor beam.
 	const set<const Flotsam *> &avoid = ship.GetTractorFlotsam();
-	if(target && (!ship.CanPickUp(*target) || avoid.count(target.get())))
+	if(target && !ship.CanPickUp(*target))
 	{
 		target.reset();
 		ship.SetTargetFlotsam(target);

... I believe that's a marked improvement. The 'catapult away' effect is still there, but far less pronounced. The sibling rivalry effect is of course still there, but even that's better since they lose less. At least it's not making things worse. It's difficult to capture, but I tried below. I've managed to get better starting positions - but not capture the result. Idea was - I got a flagship with no tractor and no cargo space left, six "pickup" slaves - two tractor beams each, lots of storage, fast - then "H" park them in at best all directions and similar distances, then provoke a massive flotsam cloud and "G" recall them and "Z" let the dogs loose...

Unpatched:

Peek.2024-04-23.unpatched.mp4

Patched:

Peek.2024-04-23.patched.mp4