endless-sky icon indicating copy to clipboard operation
endless-sky copied to clipboard

Add a "ship payload" NPC attribute that determines the payload weight of ships in a mission

Open Amazinite opened this issue 1 year ago • 3 comments

Feature

This PR addresses the feature described in issue #2569.

Summary

Adds a new attribute to mission NPCs:

  • "ship payload": Causes ships in an NPC to count toward the mission's "payload", which is used to determine the total pay for the mission. Mission payload is normally cargo + 10 * passengers. With this is becomes cargo + 10 * passengers + (ship payload * number of NPCs) for each NPC. Note that the payload is multiplied by the payment multiplier (typically 150), which is then multiplied by jumps to destination + 1.
    • By default, NPCs still won't add any payment per jump.

Note that we don't know how many ships are present until after all NPCs are instantiated in a mission, but the instantiation of NPCs uses the mission payload to determine the payments of actions within those NPCs. As such, each NPC action will take the base payload of the mission with only cargo and passengers accounted for and add the NPC's own ship payload. The mission will take into account the payload added by all NPCs, though. For example, if you have two NPC blocks where one has 2 ships, the other has 3, and both have a ship payload of 100, then actions from the mission will add 5 * 100 to the normal mission payload, but each NPC will only add 2 * 100 and 3 * 100 to the payloads that they use respectively.

This also fixes a bug where the <npc> text replacement wouldn't work in NPC action text, as actions were being instantiated before the NPC's ships were.

Usage examples

The payload for the following mission would be 20 + 10 * 4 + 50 * 1 = 110. That results in 110 * 150 = 16,500 per jump to the destination.

mission "Overbooked"
	job
	description "This captain has booked more cargo and passengers than he can fit in his Shuttle. He would like for you to escort him to <destination> while taking care of his overbooked <tons> of cargo and <bunks> passengers. Payment is <payment>."
	destination "Earth"
	passengers 4
	cargo 20
	npc save accompany
		government "Merchant"
		personality escort
		"ship payload" 50
		ship "Shuttle" "Dim Light Bulb"
	on complete
		payment 20000 150

Testing Done

Created a job to escort one ship to Earth with a ship payload of 50 and an on complete payment of payment 10000 150. Landed on planets at various distances to Sol with and without the ship payload active and observed that the job payment was higher when the ship payload was active. Also observed that changing the number of ships changed the final payment for the same distance.

Amazinite avatar Feb 16 '24 00:02 Amazinite

Might make sense to rename this to "escort payload" since the actual payment you receive is determined by the payment multiplier and the total number of jumps to the destination.

Amazinite avatar Feb 16 '24 00:02 Amazinite

I think this should be defined on a per-NPC basis. "escort payload" as a child of "npc". All ships in that NPC count for the payload. So, for example, ships that aren't actually being escorted can contribute to the payment (bounties, scanning, for example.) You could even have the hostile ships in an escort mission contribute to the payment, and in different amounts to the ships you are actually escorting. Though, it wouldn't make sense for that to be called "escort payload", though.

Basically, I think the current implementation is very specific, unnecessarily so.

I see two uses for this:

  • missions with NPC related objectives can vary payments based on how many NPC ships are present, without knowing how many there will be at the time of writing the mission;
  • missions with NPCs but no cargo or passengers can vary payments based on distance;
  • or some combination of the two.

I think the second part could also be solved by having a separate payment multiplier that doesn't depend on cargo and passenger count. (It might make sense to have that regardless of the feature in this PR.

warp-core avatar Apr 19 '24 12:04 warp-core

@Amazinite Can you fix the merge conflicts?

tibetiroka avatar Jul 15 '24 21:07 tibetiroka