Courier ships: Remotely purchasing from Trade Stations

Hiya! First and foremost, I'd like to apologize for the wall of text. The suggestion grew slightly out of proportion compared to what I expected, and while I formatted it to the best of my ability, it's still a somewhat bulky reading. Also, please forgive my somewhat awkward manner of expressing myself; English is not my native language.

Anyway! The suggestion:

If two or more grids with store blocks on them are within the antenna reach of each other, the store blocks can remotely connect to others. Then players could use remote store blocks to peruse all the wares of the station's store block and add the desired ones into a "shipping bin". Once the player is satisfied with their choices and finalize the purchase, a courier ship is dispatched from the station to the point designated by the player as a landing pad with a connector.

NPC stations would spawn their own courier ships, while player-made stations can designate their own couriers.

For this purpose, I also want to suggest for a Laser Antenna to be included into all existing NPC station designs. Stations have a low radio reach (10-20km) by default, and being able to connect to them from literally any distance would really make this system shine. As an interesting side effect, this also further encourages building satellites and relay stations on the planets.

More detailed notes:

When purchasing via a courier ship, a collateral is paid that is at least equal in value of the courier ship itself. The collateral is refunded to the player's account once the ship has safely made it back to the station. This encourages the players to build valid landing pads and ensure a clear route exists, as opposed to simply commandeering the courier ships.

There is also an additional fee proportional to the mass of the cargo, defined in credits/kg, to cover the fuel costs.

To prevent malicious players from trapping courier ships instead of attacking/destroying them outright, each delivery comes with a time limit. If the courier exceeds it without returning to the station, it is considered lost and the collateral is kept by the station. If the courier ship is owned by a player, they can predefine what will happen with its ownership if that happens - the ship can either remain theirs, get transferred to the client or get unclaimed and transferred to Nobody. This helps to prevent the PCU and other block limitations.

The courier ships are controlled by Remote blocks in Autopilot mode with Collision Avoidance on. Each time a Courier ship is dispatched, the trading AI defines its route and sets the waypoints. Pathfinding in the world of Space Engineers is a complex task, and, in my opinion, this is the weakest link of the entire suggestion; however, it is definitely solvable.

• When designating a Courier ship, the owner of the player-controlled station gives it a docking routine. More on it below.
• When designating a landing pad, a connector on it must be referenced - its location and the direction it's facing are then inferred, and each courier dispatch then individually calculates the approach point, trying to find the shortest route between it and the boundary sphere of the destination station. The owner of the pad can also assign additional waypoints for the courier ship to follow when approaching.
• When planning a route to the station within an atmosphere, the courier will either try to orbit the planet or approach from space depending on its thrust power. More on it below.

In order to designate a player-owned ship connected to a player-made station as a courier, it must be outfitted with a remote block which can then be "slaved" to the trade station in its GUI. When planning a delivery route, the entries already present in the Remote block are put in the beginning of the waypoint list, and AI will assume the Precision mode when executing the first waypoint after those. This allows the custom courier ships to execute player-defined docking procedures.

The "slaving" mechanism allows to reference additional courier ship blocks for the dispatch mechanism to manage, such as:

• Timer blocks - if the delivery routine implies the ship must stay connected for a period of time (and it most likely does), timer blocks are used in conjunction with remote block waypoint actions to turn the autopilot back on, and must be included as well.
• Timer blocks (again) and warheads - for deliveries with a set time limit, a dispatch can configure a designated timer block to execute a series of actions once the time limit has passed - i.e. when the ship is most likely have been trapped or crippled. These are optional, but allow for such things as turning on an emergency beacon/antenna, telling an onboard laser antenna to connect with the home station, detonating self-destruction warheads, turning on an emergency fuel supply, et cetera. Having a timing mechanism themselves, the self-destruction warheads can be designated on their own without the need for a separate timer block. Of course, if the courier makes it back in time, the timers are stopped.
• Any blocks with actions - while the exact waypoints are generated anew for each dispatch route, it is possible to hook some generic location events to certain block actions to be executed when - or, rather, where - needed.
  • Possible events include: entering/leaving a certain atmospheric/gravity/height threshold, switching between generally horizontal and purely vertical movement inside a gravity well (when the trade station and the landing pad are not on the same planet), crossing a percentage% threshold of the path en route to the client/station, entering/leaving proximity threshold to a predefined GPS point.
  • Possible applications include: turning on additional defences when getting close to a known large player base, toggling ion engines in favour of hydrogen thrusters when in atmosphere, disarming warheads when approaching the landing pad - we wouldn't want the client to worry of an accidental mishandling destroying his valuable property, after all? - and rearming them on the way back to discourage pirates, enabling the emergency chutes after the ship rises well above the autodeploying height for it to land safely in case of a midair accident, setting a different forward direction to ensure more favorable thrusters are used for the situation (for instance, while on many ships the strongest thrusters are the forward ones, for some heavy cargo ships it might be upwards ones instead - to combat gravity; hence, when trying to leave the atmosphere, it might be a better idea to remain vertical when flying directly into the sky, while by default the autopilot would try to align it forwards), and so on.

Do note that the "slaved" block configuration happens at the moment of dispatching the courier ship - once it's in flight, it's a simple ship and treated just as any other regular grid, there is no magic or hidden variables involved. However, it might be worth considering a monitoring feature - explained away, for instance, as a courier ship being tracked from a distance by a stealthy scout, or having a planted bug, or relaying its status via quick directional radio bursts - that could tell the buyer (and the courier owner, if the station is player-controlled) the generic status of the courier ship: is it flying towards the landing pad? Back to the station? Trying to dock? Was it attacked, and by whom? Did it depower or suffer critical damage? It would work as an anti-frustration feature, to help debug routing algorithms and to further disincentivize piracy (but not prevent it completely, of course). The exact locations of the ship and attacks are intentionally not tracked, though - a beacon or other means could always be used for this.

The buyer can choose among several fitting courier ships, if the station provides more than one option. Each Courier ship has limitations such as maximum distance it is allowed to travel, maximum carry weight, maximum cargo volume, atmosphere/gravity ranges it can operate within, the collateral cost and the fuel fee (credits per cargo kg), as well as the directions its connectors are facing. These values can be easily automatically inferred from the ship's stats (for example, see the online thrust calculator at https://se-speed.ga/en/ - by using a similar mechanism, it is easy to calculate in real time whether a particular ship with given cargo mass will be able to provide the necessary lift given specific planetary conditions), but can also be tweaked manually for the player-owned ships.

Q&A:

Q: How is the cargo actually loaded onto the courier?

A: The items are moved directly into the courier ship's cargo system via the connectors, same as when trading into a player-owned ship.

Q: How is the cargo actually unloaded from the courier?

A: The items are "pushed out" from the courier's connector into the landing pad's, which are then distributed per usual rules of conveyor systems.

Q: What possible avenues are here for the abuse of the system, and how to prevent it?

A: First and foremost, no automated system can truly match an ingenuity of a creative and resourceful engineer seeking to exploit it. Some matters have to be left in hands of the server administration staff or on players' conscience; as any engineer knows, no system design can be expected to be completely failproof. That being said, it doesn't need to be so - only to be good enough to work well!

• Q: Player-owned pirate ships attacking the couriers?
  A: That's the whole point of piracy! Rather than having it perceived as a blocking obstacle for the courier system, I suggest simply letting it fly as is and adding immersive features to combat piracy as the development progresses.
  
  • Some servers may prohibit the NPC Courier piracy on a ruling basis - and, since logging attacks on Courier ships is simple, it is quite easy to enforce such a rule.
  • Then the stations may provide a choice of heavily armed and/or armoured couriers; naturally, the collateral will tend to be larger for these ships, and part of it may be withheld even upon safe return to cover the spent ammo costs.
  • Then there's the whole field of escorting military drones, not to mention Escort contracts that are basically designed for this sort of thing - but that is a complex system on its own, and would deserve a separate suggestion if and after the couriers themselves are implemented.
  • Then there's the faction reputation penalty to consider. Attacking a courier ship hurts a relationship with both the seller and the buyer, and the players known for robbing others of their supplies are unlikely to be treated as truthworthy. Is an occasional stolen supply drop worthy being treated as a pirate by other players? That's the question each player/faction must answer for themselves, and it's a great roleplaying kindle.
  • And finally, there're so many stations and the orders happen so occasionally that it becomes physically hard to catch a courier ship when they are dispatched, unless the pirate player deploys some automatic drones to monitor the space around the station, attack the couriers and deliver the loot to their base - which is a worthy engineering challenge in and on itself, and can be exploited in so many wonderful ways by others as well.



• Q: Players getting too many orders from an NPC station at once and clogging up the performance?
  A: Again, such acts of malice towards the server are easy to log and are up to the admins to handle. However, some hard limits should be configurable [included in square brackets are the suggested reasonably restrictive values]:
  • Simultaneous orders per player, per trade station [2];
  • Simultaneous orders per player, globally [2-4];
  • Simultaneous orders per NPC station [5];
  • Simultaneous orders per server [server maxpop * 2].

  If the player is already at the limit, the NPC station will politely refuse a courier's dispatch and explain why.

Miscellaneous notes and relevant ideas:

• Slightly generalizing the concept: a store block could be used to remotely access another store block - on the same grid, on the grid directly connected to its own or on a completely separate grid with an established remote connection. The first two options do not make use of the Courier system, instead simply allowing the player to purchase the station's goods from the comfort of their own ship (this would also go great with hardcore options, such as No Helmets). The last one works as described above.
• The same system can be used for contracts - a contracts block can remotely connect to another contracts block. And if a contract involves items, the courier system *might* also be expanded to transfer the said items between the player's pad and the station - with additional fees, of course.
• If a player has its ship connected to the station, but is not present physically - i.e. if it's a cargo drone that was remotely piloted there - the remote store block connection can be used to load items into the said ship with no additional fees (as well as handle contract items - see above).
• I'm not sure yet how this should be handled, but there's a certain appeal in having an option to use an external cargo unit instead of loading items inside the ship: in the simplest case, a single crate carried with landing gears. Connectors, batteries and/or beacons are all reasonable first choices when expanding on the idea. This enables ships to carry much above their internal cargo allowance, simplifies the deliveries within gravity wells and offers a great deal of variability and decorum - remember those grated double crates laying around in snow in Frostbite? Imagine one getting delivered to your doorstep! However, this would also require a great deal of tweaking in the delivery algorithms, adding a greater variety of premade ships, making sure the garbage collection does not erase them prematurely - and, while an NPC courier ship may instaspawn with a cargo unit already attached, things get much more complicated at the player-controlled stations, where both the ship and the unit have to be provided separately and successfully connect to each other. While definitely possible, I suggest this idea is held on to until after the regular courier system is implemented and polished out.
  

Please share and subscribe feel free to comment and ask further questions; I think I have a pretty solid concept in my mind, but I'm not sure if I've managed to fully convey it, and if there are any blank unexplained spots left, I must be skipping over those without even realising. So, again, I'd like to encourage all constructive criticism and miscellaneous feedback.

Thank you for reading! :3