Customizable capture requirements for ships

[Amazinite]

Feature: This PR implements the feature request detailed and discussed in issue #2948.
Resolves #2948

Feature Details

This PR adds the ability for ships to have requirements in order to be captured, and for specific outfits to be able to meet those requirements. This is done via a new "capture class" attribute of ships and outfits.

This PR only adds the mechanic for this to be possible, and does not implement its use into any ships or new outfits.

Syntax

• "capture class" <name>: The name of the capture class that the ship or outfit is in. When attempting to capture a ship, you must have an outfit with a capture class that matches the ship. If a ship has no capture class, then no outfit is required to capture it. A ship or outfit can have multiple capture classes, allowing one outfit to hijack multiple types of ships, or one ship to be susceptible to multiple types of outfits.

A capture class can have any of the following five children. If any of them is not specified, then a default value of 0 is used. If a ship or outfit has multiple capture classes, then each can be given a different set of children.

• "success" <odds#>: A value from 0 to 1 that denotes the odds of success. For the outfit, this means the chance that it successfully hijacks the ship. For the ship, this means the chance is successfully fends off a hijacking attempt. The odds of a successful hijacking are then (outfit success) * (1 - ship success).
• "self destruct" <odds#>: A value from 0 to 1 that denotes the odds of the ship self destructing after a failed hijacking attempt. If both the outfit used and the ship have this capture class attribute, then both will roll independently to determine if the ship explodes. That is, the odds of a ship self destructing are 1 - (1 - outfit self destruct) * (1 - ship self destruct).
• "lock down" <odds#>: A value from 0 to 1 that denotes the odds of the ship locking down after a failed hijacking attempt. A ship which has locked down can no longer have any hijacking attempts made against it. This is a weaker form of self destruct, preventing you from capturing the ship but still allowing you to plunder from it. The game checks if a ship has locked down after checking if the ship has self destructed. As with self destruct, if both the outfit and ship have this attribute then both roll to determine if the ship should lock down.
• "success break" <odds#>: A value from 0 to 1 that denotes the odds of the outfit breaking on a successful hijack. An outfit breaking means you lose it, with one outfit of the type used being removed from your flagship. As above, both outfit and ship having this attribute means that both roll.
• "failure break" <odds#>: A value from 0 to 1 that denotes the odds of the outfit breaking on a failed hijack. As above, both outfit and ship having this attribute means that both roll.

outfit "Crook's Shim"
	"capture class" "low security"
		"success" <#>
		"self destruct" <#>
		"lock down" <#>
		"success break" <#>
		"failure break" <#>

ship "Sparrow"
	attributes
		"capture class" "low security"
			"success" <#>
			"self destruct" <#>
			"lock down" <#>
			"success break" <#>
			"failure break" <#>

Gameplay Behavior

Aside from how each attribute functions as described above, there are some additional gameplay behavioral notes worth making:

• If you lack the tools to capture a ship, then the game won't even let you engage in hand to hand combat and tells you that it's because you lack a tool. I wanted to avoid a scenario where the player boards a ship, wipes out the crew, and only then finds out they can't actually capture it. If a ship requires a tool to capture and you have a matching tool, then the boarding panel lets you know that a tool is required.
• If a ship has multiple capture classes and you have multiple tools for each class, then the game sorts the capture classes of the ship from lowest to highest success rate (i.e. least likely to most likely to resist capture), and then sorts the tool for each capture class by highest to lowest success rate (i.e. most likely to least likely to capture the ship). No other factors such as self destruct, lock down, or break chances are taken into account at the moment. If a tool breaks, then the next best tool by this metric is used. If you run out of tools then no more capture attempts can be made on the ship.
  • Future enhancements could perhaps take more attributes into account, sort by absolute capture chance (e.g. Consider class A on a ship has a 0% defense chance and you have a tool for that class with a 50% success chance. This ship also has class B with a 10% defense chance and you have a tool with a 100% success chance. Your odds of capturing for class A are 50% while your odds of capturing for class B are 90%, but right now since class A is weaker, that attempt is made first.), or in some way give the player the option to choose which tool to use.
• The odds of your next hijacking attempt succeeding are included in the capture odds stat displayed on the boarding panel, similarly to how the self destruct chance is included. That is, if the tool you are about to use has a 50% chance of succeeding, then the capture odds line will say 50%. This does not take into account how many tools you have (e.g. if you have two tools to use, each with a 50% success rate, then your capture chance is more like 75%) or the chance of your tools breaking (a tool with a success rate of 50% but that never breaks is technically a 100% capture chance) or the ship self destructing or locking down (the aforementioned 50% success rate tool that never breaks would lose capture chance if it also caused the ship to self destruct 10% of the time on failure).
  • Future enhancements could perhaps make the capture odds "more accurate" to your actual chances given repeated capture attempts and all the tools at your disposal.
  • The above change may not be made, though, if the CaptureOdds class is removed, as has been discussed as a potential course of action in the past (to solve issues like ships with 28k+ crew crash game on boarding #5811). I did not remove CaptureOdds within this PR due to it being tied up with how the opponent ship decides when to attack or defend, and so I feel that this PR isn't the place to make any changes to CaptureOdds.
• The message written to the boarding panel UI when clicking "Attempt Capture" now changes depending on if this is your first attempt since boarding or not. (Leaving the boarding panel and returning will reset this "first attempt" check.)
• Changed the behavior of the existing "self destruct" attribute to only run on the first capture attempt. That is, defending and pulling back then deciding to attempt to capture gain won't be able to cause a self destruct on the second attempt.

UI Screenshots

Boarding a ship with no capture requirements. Looks the same as before, and killing the crew captures the ship.

Boarding a ship with capture requirements where you have the correct tool. You're told that a tool is required, and clearing the crew moves on to a "hijacking" phase of capturing. If you attempt to hijack the ship, you're told what tool was used and the outcome of the attempt. If your tool succeeds then the ship is yours.

If you lack the tools to capture the ship, then you won't be able to engage in hand to hand combat. If you run out of tools, you'll be unable to make more capture attempts unless you return with more tools.

If the ship self destructs then you're kicked out of the boarding panel and met with a dialog.

If the ship locks down then no more capture attempts can be made. Leaving and returning to the ship, even reloading the save, it will remain uncapturable.

Usage Examples

The following could be a way to create a two-tiered capture system for automata ships. Different automata ships could be given different self destruct or lock down rates, or even different success rates if that was desired.

outfit "Automata Interface Kit"
	"capture class" "generic automata"
		"success" 0.2
		# No break chance means an interface kit could be used repeatedly.

outfit "Hacked Control Transceiver"
	"capture class" "sestor specific attack"
		"success" 0.85
		# A hack control transceiver would always break when used.
		"failure break" 1
		"success break" 1

ship "Kar Ik Vot 349"
	"capture class" "generic automata"
		# 80% of the time, the interface kit fails. 80% of that time, the ship self destructs.
		# So 16% of the time you get a second chance.
		"self destruct" 0.8
	"capture class" "sestor specific attack"
		# 15% of the time, the hacked control transceiver fails. 50% of that time, the ship self destructs.
		# The remaining 50% of the time, the ship locks down, giving you no second chances, but allowing
		# you to still plunder the ship.
		"self destruct" 0.5
		"lock down" 1

Testing Done

Created a mission with a derelict Headhunter, Aerie, and Cruiser that spawned.

• The Headhunter received no changes. Boarding the Headhunter provided the same behavior as right now; clearing the crew causes the ship to be captured.
• The Aerie was made to require a "Hijacker's Toolkit" outfit to capture. If the player lacks this outfit, the Aerie could not be captured. If the player has the outfit, they're told before engaging in H2H combat that a tool is required. Upon clearing the crew, the player must use the tool to capture the ship. The success chance was not 100%, and so sometimes capturing the ship failed and would need to be attempted again. The toolkit had a chance to break on failure, and so sometimes did. If all toolkits were expended attempting to capture the ship, then the ship could no longer be captured. Outfits that broke were removed from the player's flagship.
• The Cruiser was made to require a "Navy Clearance" outfit to capture. As with the Aerie, not having this outfit prevented capture of the ship, and the crew must have been cleared before attempting to use the clearance outfit. This time, instead of breaking on failure, a failure could result in the Cruiser self destructing or locking down. 25% of the time the ship self destructed, with those times where it didn't self destruct on failure causing it to lock down. A ship which has locked down could no longer be captured. Leaving the boarding panel and returning, the ship still could not be captured. Reloading the save file, the ships could still not be captured.

These were the stats on the outfits tested:

outfit "Hijacker's Toolkit"
	"capture class" "human medium warship"
		"success" 0.5
		"success break" 1.0
		"failure break" 0.5

outfit "Navy Clearance"
	"capture class" "navy ship"
		"success" 0.9
		"self destruct" 0.25
		"lock down" 1.0

Automated Tests Added

N/A

Performance Impact

N/A

[Ferociousfeind]

These changes were gone over during one of Derpy's streams, and everyone present agreed these were good and useful changes. That includes me. Here's my seal of approval.

[petervdmeer]

I just reviewed the PR text (and the screenshots), not the code yet; the new mechanism looks nice. I like the idea that the capture tool can be used up in the capture attempt.

The text "a tool is required to capture" sounds a bit strange to me (but I'm not a native speaker);

• I guess it could be improved to "you need [whatever relevant outfit you have] to capture", but I'm okay if this is kept for a follow-up PR.
• The text "lack the tool" might be improved to "you don't have the equipment/tools to capture this ship". I would expect some outfits for capturing to use up quite a bit of outfit space.

Some considerations:

• Maybe we should differentiate the keywords a bit? "capture enabler" (for the attacking outfit) and "capture blocker" (for the defending ship)?
  • Can ships also have a "capture enabler" built-in for capturing other ships?
  • Can outfits (like the "security station") also provide additional "capture blocker" protections against being hijacked?
    • For example the "security station" requiring the attacker to have "grenades".
    • For example the "pug biodefenses" requiring the attacker to have "gas protection".
• Can we change the "capture blockers" from "OR" to "AND", so that one needs the "enablers" for all the "blockers"?
  • With this ships with more "blockers" would be harder to capture, instead of easier to capture.
    • For example ships with the "security station" and with "pug biodefenses" requiring both "grenades" and "gas protection" from the attacker.
• Can a "locked down" ship still be repaired by friendly ships?
  • If yes, can we then try to capture again?

[Amazinite]

The text "a tool is required to capture" sounds a bit strange to me (but I'm not a native speaker);

I will note that we are VERY limited in what we can put in this UI at the moment. We have five lines of text max, with very little width to work with, and it doesn't even automatically word wrap longer lines. Without overhauling the boarding panel UI we can't have text as long as your suggestions, and such an overhaul would likely warrant its own PR.

• Maybe we should differentiate the keywords a bit? "capture enabler" (for the attacking outfit) and "capture blocker" (for the defending ship)?
  • Can ships also have a "capture enabler" built-in for capturing other ships?

Ships can't have "enablers" right now, and they can't be allowed to while the keywords are the same. Although I'm not sure what the behavior of a ship having a built-in enabler would be. Tools that are used for capturing are capable of breaking. How would a ship's built-in tool break? Would it be unbreakable? Would the desire to have a built-in capture tool not be met by just having an uninstallable outfit?

• Can outfits (like the "security station") also provide additional "capture blocker" protections against being hijacked?
  • For example the "security station" requiring the attacker to have "grenades".
  • For example the "pug biodefenses" requiring the attacker to have "gas protection".

Outfits can only ever be tools for capturing at the moment, never for preventing hijacking. "capture class" on the ship itself is always the defense, and "capture class" on an outfit is always the offense. Having distinct keywords for what is offense and what is defense could allow us to have outfits add to a ship's defense, but how would that behave? What if a ship has multiple security stations? I did not design this in such a way as to have multiple defenses stack on top of one another, or multiple offenses stack either.

I designed this with locks and keys in mind. A ship can have one or many doors to enter. These doors come built into the ship, and you cannot add or remove doors (just as there are various attributes which we can't change on our ships). These doors are locked (the "capture class" on the ship), and each requires a certain key to open (the "capture class" on your outfits). Although opening a single door is enough to capture the ship (there are no doors behind doors), and no door has multiple locks, which does lead into your next point:

• Can we change the "capture blockers" from "OR" to "AND", so that one needs the "enablers" for all the "blockers"?
  • With this ships with more "blockers" would be harder to capture, instead of easier to capture.

I'd rather there be a future enhancement to provide both OR and AND behavior (or some equivalent mechanics that causes multiple outfits to be required), instead of replacing OR with AND. Note that although a ship with multiple capture classes will be easier to capture with certain outfits, those outfits will also be harder to get your hands on. The purpose of the OR behavior is to provide a progression with capturing ships of the same type as well as ships of varying types. (That is, with better gear you can capture A better than you used to be able to, but you can also capture B when you used to be unable to.) Switching to AND behavior would only allow us to have progression of capturing ships of varying types. (That is, you either can or you can't capture A. Once you can capture A, it never gets easier.)

• Can a "locked down" ship still be repaired by friendly ships?
  • If yes, can we then try to capture again?

Yes and no. Although note that a ship can only become locked down after hand to hand combat has ceased, which means that the ship will have zero crew. I'm unaware of whether ships will try to repair friendlies that are empty husks, but if they do, it's not like the ship is suddenly functional now. It's still dead in the water, for one reason or another.

[Zitchas]

This has been a long time coming. Looks good. I would like the option for an "And" in there too, but that's fine for a follow up PR.

Anyway, thanks for working on this. Looking forward to having it in-game.

[petervdmeer]

I will note that we are VERY limited in what we can put in this UI at the moment.

Agreed, let's keep the texts as-is for now. This can go with an UI overhaul of the boarding panel in some future PR.

Ships can't have "enablers" right now, and they can't be allowed to while the keywords are the same.

Agreed, that's why I suggested different keywords for the "lock" and for the "key" (as you nicely called them). "capture key" and "capture lock" would also be fine keywords, maybe even better than "capture enabler" and "capture blocker" because they describe the mechanism better.

How would a ship's built-in tool break?
Would it be unbreakable?

The ship would be destroyed, so using your ship as a (not 100% safe) capture-tool is a risky business. If the capture itself succeeds when the ship breaks, then in a future PR we could also have the player transferred to the captured ship. (But for now it just results in the player dying, as transferring players to other ships is currently not merged yet.)

I can imagine that we even get "speciality capture ships" which only exist to act as capturing ships. (But that is likely going to be plugin stuff.)

Would the desire to have a built-in capture tool not be met by just having an uninstallable outfit?

If an uninstallable outfit gets destroyed, then I would also expect the ship to be destroyed. (But this would also be for a future PR, don't include it here.)

Outfits can only ever be tools for capturing at the moment, never for preventing hijacking. "capture class" on the ship itself is always the defense, and "capture class" on an outfit is always the offense. Having distinct keywords for what is offense and what is defense could allow us to have outfits add to a ship's defense, but how would that behave? What if a ship has multiple security stations? I did not design this in such a way as to have multiple defenses stack on top of one another, or multiple offenses stack either.

I designed this with locks and keys in mind. A ship can have one or many doors to enter. These doors come built into the ship, and you cannot add or remove doors (just as there are various attributes which we can't change on our ships). These doors are locked (the "capture class" on the ship), and each requires a certain key to open (the "capture class" on your outfits). Although opening a single door is enough to capture the ship (there are no doors behind doors), and no door has multiple locks

I understand the ideas, and I was thinking of an alternative design:

• The player needs the "keys" to all of the "lock types". But if a "lock type" exists multiple times (multiple security stations), then the player only needs one key for that type. (there are doors behind doors, but we only count the unique doors.)
• The complete set of "unlocking all doors" succeeds as one, or fails as one.
  • Individual keys can be lost in case of failure to unlock (the loss of keys is per key-outfit).
  • Individual keys can also be lost in case of success (the loss of keys is per key-outfit.)

• Can we change the "capture blockers" from "OR" to "AND", so that one needs the "enablers" for all the "blockers"?
• With this ships with more "blockers" would be harder to capture, instead of easier to capture.

I'd rather there be a future enhancement to provide both OR and AND behavior (or some equivalent mechanics that causes multiple outfits to be required), instead of replacing OR with AND.

I feel that we don't really need the OR behavior if we make some other changes as well:

• Locks on the ships don't have any of the success, self destruct, lock down, success break or failure break properties.
  • They key is the only item that specifies those properties.

Note that although a ship with multiple capture classes will be easier to capture with certain outfits, those outfits will also be harder to get your hands on. The purpose of the OR behavior is to provide a progression with capturing ships of the same type as well as ships of varying types. (That is, with better gear you can capture A better than you used to be able to, but you can also capture B when you used to be unable to.)

We can already have this progression with the AND behavior and only properties on the the keys; the player will get access to better keys over time. The "scriptkiddie keycard" typically breaks before it is even inserted into the card-reader of a cruiser, while the "admirals keycard" will have a 100% success rate against a cruiser, but gets used up when used once. (I would imagine the "admirals keycard" not to be for purchase in generic outfitters, but be given to the player in a specific capture mission.)

Switching to AND behavior would only allow us to have progression of capturing ships of varying types. (That is, you either can or you can't capture A. Once you can capture A, it never gets easier.)

If we encode the success factors only in the keys, then we can also have both; Outfits can have multiple "capture keys", and newer outfits can provide better keys, so getting better outfits will give the player access to more keys, as well as access to better keys than before.

• Can a "locked down" ship still be repaired by friendly ships?
• If yes, can we then try to capture again?

Yes and no. Although note that a ship can only become locked down after hand to hand combat has ceased, which means that the ship will have zero crew. I'm unaware of whether ships will try to repair friendlies that are empty husks, but if they do, it's not like the ship is suddenly functional now. It's still dead in the water, for one reason or another.

Agreed. Not an issue at this moment.

[Amazinite]

• Locks on the ships don't have any of the success, self destruct, lock down, success break or failure break properties.
  • They key is the only item that specifies those properties.

The reason that the locks have all the same attributes as the keys is because although the same tool might be able to work on multiple ships, those ships might not all have the exact same lock model, and so different lock models might be more or less resistant against the same tool.

Stepping away from the lock-and-key discussion, another goal with this PR was to create some method where we can tweak roughly how much money a player needs to put into a ship to capture it. If a ship has a 50% capture chance with a specific tool that costs 25k, then it'll take (I think) on average about 1.44 outfits to capture the ship. So using those metrics, we could say that the capture cost of this ship is effectively 36k.

Now the capture cost of a ship should increase with the ship's base cost, so say we have another ship that costs twice as much as the first one, meaning the capture cost should be (at least about) twice as much. There's two things we could do to make that happen.

1. Have the second ship use a different tool that costs twice as much as the tool for the first ship (50k) with the same capture chance, and therefore the same average number of uses to capture the ship.
2. Reduce the ship's capture chance with the first tool, therefore increasing the average number of tools you need to use. (In this case, we'd reduce the capture chance to about 30% so that it takes on average 2.80 outfits to capture the ship.)

When you're talking about only two ships, neither approach really becomes the "obvious" approach to take. But we don't only have two ships in the game, we have over 200, with about 60 in human space alone (not counting Marauders). If we needed to have one tool for each ship in order to balance their capture costs, even if we made some ships require no tool, then that wouldn't just be cumbersome from a development perspective, but also a gameplay perspective in getting the right tool for the specific job.

Therefore, I don't think it'd be the best to only limit success rates to the keys, as even if that does open us up in some areas, I think it also closes us off in other, more important ones.

I guess to get to the heart of the matter, what actual benefit would we see from having AND behavior, or from having outfits act as locks, or ships with integral locks, compared to what this PR already provides?

• AND behavior means you'd need two or more separate outfits to capture certain ships, which does have a bit of gameplay flavor to it, but if we wanted some ship to be more difficult to capture (which requiring multiple outfits does), then could we not just have a third outfit, or reduce the effectiveness of either of the existing two outfits?
  • Not to say that I don't think that AND behavior should ever become possible, just that I don't think that it gives us a massive gameplay benefit over the existing mechanics in this PR, and therefore isn't necessary to have right out the gate. (Although if we're certain that we want to support it eventually, I think we might want to change the syntax now as to make supporting it easier, because with this PR being built entirely around OR behavior, I'm not sure how I'd get AND behavior to fit without significant changes.)
• Outfits being locks would mean that we could have the same ship have varying levels of difficulty to capture depending on its loadout, but how much of a benefit would that actually be to the gameplay experience? Security stations don't appear in the boarding panel, so if they were to act as locks, the player wouldn't know that a ship is more or less difficult to capture without using an outfit scanner.
  • As an aside, I feel like at least in the case of defensive H2H outfits like security stations and Pug biodefenses, part of the H2H combat probably involves destroying/disabling/overtaking these defenses. The hijacking phase is then when your crew has successfully cleared the ship and is currently in the cockpit of the ship trying to take control of it. That is to say, it doesn't really make sense for such outfits to act as locks then you've already beaten them.
• Ships having integral locks could introduce some of the gameplay aspects you've mentioned, but I also think we could just as easily have those aspects by having keys and locks be capable of self destructing the boarding ship, in addition to how they can self destruct the boarded ship. That, in addition to uninstallable keys on certain ships, would then make your ideas possible without much extra work on top of what is already here.

[petervdmeer]

We are discussing on different topics:

• one keyword for keys and locks, or different keywords for keys and locks.
• key-only (properties only on keys) vs key+lock (properties both on keys and on locks)
• AND vs OR vs AND+OR (both supported)
• details on which outfits provide locks

On the "one keyword" vs "different keywords":
I feel we should just use different keywords. The investment seems small (just use different keywords for different things), and it allows Outfits to add additional locks (and with some follow-up work also allows ships to have built-in keys).
Those additional locks will in the "OR"-case provide additional access ways, while in the "AND"-case will provide additional blocks on the single access way. There is an inconsistency in that adding a new lock to a ship with no locks would actually decrease vulnerability to capturing (while it shouldn't in the "OR" case), but I would expect most ships to have at least 1 type of lock, so that shouldn't be an issue when we actually use the mechanism.

I see no downsides to not using different keywords (except maybe some rework on this PR).

On "key-only" vs "key+lock":
Having a single tool that works on "multiple ship-models in different value-ranges" will work much better than having a capture tool per ship-model; We don't want players to carry around 60 different outfits to be able to capture 60 different ship models. Supporting a single tool for different value-ranges is however not unique to the "(key+lock)" approach, because we can also set multiple "keys (capture classes)" on a single "key Outfit" in the "(key-only)" approach (with the keys(capture classes) for the more expensive ships having a lower success rate).

Some arguments in favor of "key+lock":

• Key-Outfits will typically have only 1 key (capture class), making them easier to display, although with less detail.
• A single key+lock combination can work for many combinations of ships, because locks of the same type-name can have different models depending on the ship where it is used.
• We can prevent plugins from defining some "master key" that allows capturing as-is today.
• The code seems more flexible, because key effectiveness can be defined in keys and locks (which is not always a good thing if we want to keep things simple).

Just after posting I realized that there is another variant "lock-only", so I also added some arguments in favor of "lock-only":

• Key-Outfits will typically have only 1 key (capture class), making them easier to display, although with less detail.
• A single key+lock combination can work for many combinations of ships, because the keys effectiveness is always described in the lock.
• We by default prevent plugins from defining some "master key" that allows capturing as-is today.
• The code is simpler, because key effectiveness is only stored in the lock.

Some arguments in favor of "key-only":

• The "key-only" stats makes it easier to display the effectiveness (against certain locks) in the Outfitter, although key-Outfits will typically contain multiple keys.
• We can add new (more effective) keys for ships later, without needing to add new locks.
• Plugins can define some "master key" that allows capturing as-is today.
• The code is simpler, because key effectiveness is only stored in the key.

I still have a small preference for "key-only".

On AND vs OR vs AND+OR:

I feel that we should chose to implement either "AND" or "OR" behaviour in keys/locks, but not both. Keeping the system simple also has value.

The "OR" and "AND" approaches are fundamentally very similar when it comes to ships having only 1 lock. The difference begins with ships with multiple locks; does each lock need to be opened, or is opening any lock sufficient?

Some unique benefits that I see for the "OR" approach:

• Capturing code is simpler, since it typically involves just finding 1 matching key.
• New outfits can make ships more vulnerable to capture. (E.g. a weapon outfit that opens up some doors.) This could be a nice story tool. (Go capture a ship with an "ION cannon", because such ships are more easy to enter.)
• We can have some master-capture-key-Outfit during some missions (which just works on its own unique lock)

Some unique benefits that I see for the "AND" approach:

• The additional gameplay flavor of needing 2 keys for capturing certain ships.
• The same shipmodel can have varying levels of difficulty to capture (due to extra locks). I actually like the idea that a player can be surprised that some ship just cannot be captured; it makes capturing a little bit more unpredictable. In the current game a player already knows that capturing is likely to succeed or not before even touching the ship.
• We can have some master-capture-key-Outfit during some missions (with a 100% success rate against all the locks in the target ship), and this can also include unique locks.
• AND allows to define which ships can capture if we add built-in keys to the ships that we want to be able to capture on top of the mechanisms mentioned earlier. (Thus allowing world-ships with huge amounts of bunks, while those ships not being able to capture.)

I still have a preference for "AND".

On "which outfits provide locks":

I agree that H2H outfits should not provide locks. It should probably be some new outfit like "computer security upgrade" or "reinforced bridge doors" that provides additional locks.

[Hurleveur]

I like the idea, especially how it would potentially combine with capture override to do say a plugin disabling this mechanic, for instance but also meaningfull exceptions, probably (shouldnt we make this a gamerule tho?)

Looks like it would work as advertised from what I could see of the code (but I'm on phone), I just noticed some things I think we should discuss.

[Hurleveur]

Suggested change

	// Sort capture tools be decreasing success chance, so that the best tool
	// Sort capture tools by decreasing success chance, so that the best tool

[Hurleveur]

Since all elements are % between 1 and 0 shouldnt we have a check that the given value is in that range at the start, and a warning that it will default to 0/1 if it isnt between the two boundaries, if we dont completely disregard it?

Otherwise someone may write 50, imagining its % and get 100% applied instead (+ we're doing the same code at every line)

[Hurleveur]

Usually I dont approve of putting comments in both the cpp and h but in this case since its done for other functions and can be a bit of a complex return type (especially for the second function) I'd add it here too?

[Hurleveur]

These two feel a bit huge and use a pair + vector and map so we probably should make a small class combining it?
I thought we were discouraging the usage of pair to begin with given it contains unnamed data

We also have to explain a lot when a good + functions class name would do that everywhere we use it, I see that there are some differences for sure though so maybe its not easy because of that, but maybe logic could be moved to such a class, too?

Maybe its fine because the pair contains the name of the thing that is stored with it?

[Hurleveur]

We dont seem to account for the case where the player has tools but none that work for this ship? Or do they all work on all ships?

[Hurleveur]

So you can have a tool with 0% succes chance?
I assume that all attributes will be displayed, right? (Meaning we cant do pirates doing a sneaky one by selling it to you?)
It seems a bit weird because the boarding will happen as if you could do smth but you wont at the end?
Same thing for the ship having 0% cap chance itself, it's kind of weirdly uncapable in that case.
Do we just accept mis-use or should we put safegards/warnings?

[mike-f1]

C++17 introduce std::clamp

[petervdmeer]

I've removed myself as a reviewer:
Customizable capture requirements is a nice improvement to the game, and I agree to the general ideas.
I will not have a lot of time to review in the near future, but I also don't want this PR to be blocked on minor details or on my availability.
If this PR is still open when I have more time available, then I will re-join as reviewer. Just don't wait for me unless you really feel a strong need to do so.

[Amazinite]

I'm thinking of redesigning this to a system which can be a bit more flexible, but not planning on getting to this any time soon. Not considering this PR orphaned, but I am closing it since it's not moving any time soon and what's here will likely be redone.