POB Change Suggestions

[Grumblesaur]

---

Suggestion
Type: POB Plugin
Title: Placement Constraints

Specifics

• Plugin code would be changed to detect distances from certain objects in system.
  
• A minimum distance constraint from mining zones, dockable solars, and lootable wrecks will be introduced into base placement.
  
• Placement of a base will fail unless the constraints are met.
  
• Failed placement will not consume resources, and will notify the player of the nearest object whose constraint they are violating in a chat message.
  

Potential Problems

• Building in systems with many NPC bases may require base construction off-plane or off the map, which may introduce some navigational difficulties for first-time base visitors.
  
• Scanning all objects in a system, filtering them by the relevant properties, and calculating distances may be non-trivial, and CPU time-intensive; however, POB placement is not a frequent operation.
  
• POBs which predate this change will need to either be grandfathered in (and thus potentially have an advantage from proximity to other bases, NPC or player-owned), or manually relocated by a GM (which takes time away from other duties).
  

Example of Effect
By programmatically constraining the placement of POBs, less GM time will be devoted to moving bases which foul trade lane junctions, obstruct jump holes, or merely sit in illogical or impossible places.

Additionally, it prevents POBs from deforming the intended designs of systems by the development team. NPC bases, dockable objects, mining zones, and loot caches are all placed with certain intentions of creating player interaction, respecting the lore, producing aesthetics, and progressing the story. POBs can be used to subvert these designs, by shrinking the gap between a resource (wreck or mining field) and a safe haven. Nefariously-placed POBs can also create choke points or induce area denial (particularly through their weapon platforms) not intended by the systems developers. Sometimes they're simply ugly and unbefitting of their location.

With POBs constrained to a minimum distance from interactive objects in space, they are less likely to form redundancies and hazards, and more likely to populate frontier regions of systems.

Further Discussion
This would have a further effect of preventing the construction of "planetary defense grids", where POBs are constructed around a major solar in a system, with weapon platforms strategically arranged to create a protective bubble. As POBs are themselves dockable objects, the construction of adjacent POBs would not be possible.

During sieges, attacking players would find themselves at a disadvantage, as the enforced remoteness of the target will make changing ships or resupplying consumables difficult or time-consuming. For defenders, this would not change much, except for perhaps adding a few extra minutes to the cruise time toward the base.

Note that while it's possible to build a base in a remote location at present, many bases are simply built adjacent to NPC bases or other notable areas on or near the system's central plane. Requiring a certain amount of effort to place bases may enhance their security. The off-plane or off-map volumes of space are ultimately much larger than the plane plus-or-minus 10K volume that most systems' objects lie within.

---

Pseudocode describing the constraint-checking procedure:

Spoiler

Code:

# POB Placement Constraint Pseudocode

# Trivial, well-known function listed for completeness of this example.
function distance3D(position1, position2):
  return square_root(
      squared(position2.x - position1.x)
    + squared(position2.y - position1.y)
    + squared(position2.z - position1.z)
  );


# When a player attempts to create a base, before the plugin checks that the
# player has the appropriate goods in their hold, this check occurs. The return
# value is a pair (or tuple) of values, where the first is a boolean indicating
# success or failure, and the second is a string, which will be the name of the
# first object which raises a conflict if the procedure fails, but an empty
# string on success.

function is_valid_location(player, system, minimum_distance):
  foreach object in get_objects_in(system):
    let is_constraining = is_mining_zone_marker(object)
                       or is_lootable(object)
                       or is_dockable(object);
    
    if not is_constraining:
      continue;
    else:
      if distance3D(player.position, object.position) < minimum_distance:
        return pair(false, object.name);
  return pair(true, "");

# What the procedures is_mining_zone_marker(), is_lootable(), is_dockable(),
# and get_objects_in() look like is dependent on the structure of objects in
# FLHook, which I am not familiar with.

---

A way a lone a last a loved a long the riverrun, past Eve and Adam's, from swerve of shore to bend of bay,
brings us by a commodius vicus of recirculation back to Howth Castle and Environs.