todo

Code review notes

[x] Switch “distance” field on nodes to a “position” vector; this will
let us calculate distance in 3d space and stop worrying about system
membership for battles
[x] Use volume-units for all resource calculations, then divide by
cargovol right before showing the numbers to the player (shipinstances
make this problematic; discuss)
[x] Keep json file up-to-date
[x] Run program as part of regular testing
[ ] Have minimal and maximal test cases for various entities in json
[x] Remove obsolete features promptly to prevent confusion
[x] Use highly explicit variable names

GENERAL:
[x] Have a "bitmap" field on Nodes, which sets the bitmap to be used in other nodes' backgrounds to depict this node
[x] We can have suns as orphaned, linkless nodes for environment-bitmap purposes; this should be cheap -- have an "exclude from system" field on json nodes, so that a sun can be in a system but not linked to the other nodes. Also probably useful for other purposes. (Need to figure out the orphan checking)
[ ] Figure out the whole issue of whether and how we check for supply from input stockpiles (and demand from output stockpiles?).
[ ] Test whether stockpiles set to not propagate work the way they're supposed to.
[x] Replace the threat field on Node with the factions field on Global Salience.
[x] Figure out issues surrounding engine mechanics -- the relationship between once-per-turn events and once-per-move events
[x] A list of ship keys is stored in hangar.contents, but ships in a hangar have their location data set to the carrier holding them. This is redundant. We should probably abandon the notion of the contents field and stick to ship.location, but given that ships can have multiple hangars, we'll need a way to specify, which probably means unique hangar keys and hangars being stored in a table in root...
[x] When entities are stored in a table, we don't (AFAIK) have a way to get the key associated with an entity if all we have is the entity itself. This means that any time we need the entity's key for a method on an entity, it can't actually be a method -- it has to be an associated function. This seems non-ideal. (Associated functions are fine, per Amaryllis.) (Later mostly resolved by switch to Arcs.)
[x] We'll need to make a "get ideal strength" method on fleetclass, which likewise references a "get ideal strength" method on shipclass, so that we can do disbandthreshold checking properly without the modder having to calculate it manually. Or maybe keep the idealstrength field on fleetclass, but compute it at hydration.
[x] Add nodeflavor enterability checks
[x] Figure out how to handle some edges being traversable and not others by certain ships. Edgeflavors, probably.
[x] Battlescalars struct
[x] Engine health
[x] Battle check method (on root)
[x] maybe also make internal_battle a method on root?
[x] Add hangarclass as a field to hangarinstance, and id as a field to hangarclass, maybe same for repairers, etc.
[x] Have visibility defined in the class of things
[x] Maybe add visibility to more entity types (nodes? systems? factions?)
[x] If we implement disband checking the easy way, more experienced fleets will effectively have lower disband thresholds than less experienced fleets. Is this fine?
[x] Split out force-gathering from internal_battle into a separate function that parcels out all the data needed by FSO (will this be viable in terms of expense?)
[x] Add per-turn/per-engagement toggle on repairers
[x] Have repairers check for damage before running
[x] Build navigation/traversal methods for fleets
[x] Add id field to entity instances; use this where relevant
[x] Base battle duration on strength calc with avg duration instead of shipcount
[x] Experience should probably work differently (it should be a feature of characters, not ships; basically dummy it out for now)
[x] Defectchance as from-faction and to-faction
[x] Build defection logic
[x] Implement shipflavors (and maybe fleetflavors?)
[ ] Implement variants for ships
[ ] Implement resourceflavors, factionflavors
[x] Toughnessmod field on squadrons, maybe similar for interdiction, etc? Think about it (No.)
[x] Config struct on root with settings for salience propagation iters
[x] Replace current implementation of entity locations with entity-component system or similar
[x] Build hangar entry and exit methods
[x] Build balance_stockpiles
[x] Build balance_hangars
[ ] Build operation logic
[x] Implement faction demand, and incorporate faction salience into navigation logic
    [x] Add scalars on faction and on config for resource/unitclass salience relative to strength of forces
[x] Think about how unitclass supply is calculated -- by volume, or strength? (Pretty much has to be by volume. Value mults will work fine to modify it.)
[x] Make sure value mults are properly applied for relevant calculations
[x] Clean up salience propagation logic
[x] Think about whether demand from ship stockpiles should be treated differently from demand from shipboard shipyards or factories during navigation
[x] Sort out the issue of which supply/demand gathering methods on units should be recursive, and how
[ ] Determine how to handle problem of output stockpile targets -- we need the resources to generate supply, but target is also used for factory state calculations
[x] Think about whether and how to take target into account when calculating unitclass supply
[x] Make sure all get supply/demand methods check for propagation flag
[ ] Figure out the situation with generic unitclass demand.
[x] Figure out the whole thing with whether demand from a pluripotent stockpile should be divided by the number of relevant resources or whatever
[x] Think about whether there should be a check so that hangars don't generate demand for/seek out units that can't currently fit in them. (Not needed; demand is calculated based on ideal configurations)
[x] Create check in transfer to make sure units can't be inside themselves
[ ] Build out process_turn
[x] Gigantic refactor! Switch everything in root over to Arcs.
    [x] Convert nodeflavors.
    [x] Convert nodes.
    [x] Convert systems.
    [x] Convert edgeflavors.
    [x] Convert factions.
    [x] Convert resources.
    [x] Convert hangarclasses.
    [x] Convert engineclasses.
    [x] Convert repairerclasses.
    [x] Convert factoryclasses.
    [x] Convert shipyardclasses.
    [x] Convert shipais.
    [x] Convert shipclasses.
    [x] Convert shipinstances.
    [x] Convert fleetclasses.
    [x] Convert fleetinstances.
    [x] Convert engagements.
    [x] Deal with hangarinstances.
[x] Put certain methods in "mobility" trait on Arc-Ship/FleetInstance
[x] Put certain methods in "locality" trait on Arc-Node
[x] Make "mobility" fully generic -- allow fleets and hangars to hold fleets
[x] "Propagates" bool on factions, resources, shipclasses, fleetclasses; check for this and don't do salience prop calcs for things that don't have it as true
[x] Replace root's shipinstances and fleetinstances with units (decided not to do this for now)
[x] Build "unitclass"; replace shipclass salience with unitclass salience
[x] Refactor internal_battle and related to clean it up, take advantage of unit genericity, and allow multi-coalition engagements
[x] Make try_defect fully generic?
[x] Change squadron supply so that it gets the volume of the squadron as it actually exists, rather than ideal volume
[x] Interdictor stat on ships
[x] Rename "fleets" to "squadrons"
[ ] Squadron leader, scalar for how much extra influence its AI gets
[ ] Build edge-length system
    [x] Add check_for_battles, balance_hangars, and balance_stockpiles bools on node
    [x] Build node templating system
[ ] Figure out mechanics for ground assaults/ship or station capture
    [ ] Build system for ship capture
    [ ] Invulnerability flag so that ships can be used as planets or similar
[x] Add inter-node weapons
    [x] Add system for checking influence of weapons when navigating
        [x] Weapon map creation
        [x] Add parameters to AI
    [x] Add damage-by-factor
[x] Add navigation threshold on ships and fleets, and check for it in navigate
[x] Excursions!
    [x] Build method for determining how many moves left a ship has
    [x] Build deploy_daughters method, and use it in maneuver
[x] Make movement_left propagate to daughter ships
[x] Clean up hydration logic -- which things do or don't return just the internal struct vs. internal struct plus stringid.
[x] Dessication logic
    [x] Move dessication methods to connection
[x] Rehydration logic
[ ] Test to make sure that dessication-rehydration loop does not alter contents of root
[ ] Optimize salience propagation logic
    [x] Exclude all-to-all system edges from propagation (figure out why this doesn't actually help and whether it's fixable)
    [ ] Figure out where the shipbuilding indeterminacy is coming from
    [ ] Store salience source node data so we can prune the logic for unit movement
    [ ] Move propagation logic to GPU
[x] Optimize rng creation
[x] Make sure units can't enter hangars they won't fit in by entering a squadron within a hangar -- make the fit check recurse upward
[x] Fix the thing where ordering of lists in root gets scrambled by the hashmaps during hydration
[x] Remove fields that can be stored in classes from their respective instances
[x] Clean up struct field names -- switch to snake case, remove unnecessary qualifiers
[x] Stop calling everything an instance?
[ ] Build fleet creation logic
[ ] Build system for determining how many reinforcements will be sent into an engagement in progress
[ ] Take hostile threat into account for faction demand
[x] Make hangar allowed an option, with none meaning no restrictions, as with pluripotent stockpiles
[x] Create method that recurses up unit tree and tries to transfer unit into the nearest available place, finishing at the node if necessary, for use while disbanding squadrons (it turns out to be better to just dump disbanded ships into the node, and transact units afterward)
[x] Allowed list for squadrons
[x] Make sure remove_dead and disband_squadrons are read-write-safe, and that they destroy all arcs including hangar parent arcs
[x] Think about taking average instead of product in cases like getting AI for squadrons
[x] Build mother loyalty system
[x] Deal with case where there are too many units and hangar or squadron can't accept ideal units (Volkswagen Beetle problem)
[ ] Move relevant parameters from unitclasses into AIs
[x] Figure out weirdness about squadrons not immediately schlurping up the units that spawned them
[x] Add system for de-ghosting relevant squadrons at the end of transact_units
[ ] Figure out why empty squadrons aren't getting destroyed
[ ] Clean up processor demand in navigation

LONGER-TERM:
[ ] Build system for transmitting data to frontend
[ ] Build display system for Spiderweb data
[ ] Hook Spiderweb into frontend

LOW-PRIORITY:
[ ] Have relations between factions in a coalition fighting together affect strength score
[ ] Allow factions that have no presence in the node where a battle is taking place to send reinforcements in if they want
[ ] Build system for ships deciding to leave squadron, and add squadron-misalignment-tolerance scalar to shipclass
[ ] Build high-level nonlocal fleet system
[ ] Add randomization to various calculations
[ ] Add node position rotation logic
[ ] Use distance between nodes as a parameter for determining engine performance
[ ] Build morale system
[ ] Build pilot system
    [ ] Build characterais
[ ] Build intel system
[ ] Replace shipbuilding system with a more simulationistic one
[ ] Build parser to convert .blend file to Spiderweb nodemap

QUESTIONS:
[x] process_engines short-circuiting
[x] retain for remove_dead and disband_fleets
[x] orphan checking/how does the all-to-all edge generation even work currently?
[x] figure out what objective data structure should be
[ ] What's the best way to get the objective data for Engagement?
[x] What's the tradeoff between storing data in the classes table and having to look it up/storing the data in the instance and having it be redundant? (Copy cheap integers, etc., into instances, leave strings in classes.)
[x] Is there a more efficient way to handle the per-engine nodeflavor/edgeflavor checking than cloning the engine data and passing it up to traverse?
[x] Can we get rid of the clones in various places?
[x] Is the usize::MAX technique good design?
[x] Is there a better way to handle figuring out what ship a hangar belongs to while avoiding data duplication?
[x] Make sure table-index/key creation is adequately safe
[x] What the fuck do we do about the mutability/ownership bullshit w/r/t ship creation if we can't clone???
[x] How do we make an unwrap make the check fail instead of crashing when checking for forbidden edgeflavors between two nodes that don't have an edge (or if the thing is given two of the same node)?
[x] Doing "adding a specific thing to a collection we're getting from somewhere else" in a sane fashion
[x] Making the get_ai thing work correctly without creating overlapping ids
[x] Look over The System-Edge-Building Situation(TM)
[x] Figure out what to do about fleet ideal volume
[x] Probably there's a cleaner way to do the coalition wars gathering? (There isn't. Or at least Amaryllis didn't immediately come up with one.)
[x] How do we handle making sure the arcs get cleaned up properly when a dynamic entity is destroyed? (Just go clean up the arcs; weaks aren't necessary.)
[x] What's the best way to get the data about how many resources there are for get_resource_demand? (It probably works better to not even divide by number of resources the stockpile can hold.)
[ ] Look at the set_movement_recursive shitshow.
[ ] Consult re: magic numbers in navigation calcs.
[x] Make sure the option option thing for deploys_daughters will work in json.
[x] Weirdness with faction demand being multiplied by relations.
[ ] Faction demand get_value performance.
[ ] Best way to prune navigation logic by scalar = 0?
[x] Hangarinstances not being in root
[ ] Will the duplicated sequential application of damage in fn-fire work correctly, and is there a better way?
[ ] Will read locks on shipmuts in fn-transfer reliably live long enough to lock out writes until the transfer is finished?

SHIPYARD REWORK NOTES:
- ships under construction are their own struct which implements Mobility
- ShipUnderConstruction fields: class, input stockpiles, completion fraction
- ShipClass has a hashmap of resource costs, and a number of turns for completion
- when laying down a new ship, hashmap gets converted into stockpiles
- a shipyard has a UnitContainer which holds its ships under construction
- if all the ship's stockpiles have enough resources to be processed, the ship's construction advances by one turn
- construction stockpiles in the same shipyard have their demand weighted according to the desirability of the ship they're constructing
- (...except maybe in special cases for things like stations or unique one-offs? This kind of gets back to the question of what ultimately drives production)
- ships under construction count as supply for salience propagation, but it's multiplied by the completion fraction