TODO

Add externalPluginLoaderEarly before metadata, and externalPluginLoaderLate
at the very end.

Consider renaming startupEmitter to startupChecklist.

Create issue for controller support.

Create issue for API structure that has everything nicely separated into namespaced.

Make ship movable with physics using keyboard controls.
Implement physics in a universally easy to use way.

Fix bug where switching to mouse steering uses old now-invalid analog numbers.

Move cam[0] logic into ship loader.
 - Create notion of a standard arrow.
 - Ship orientation cam.
 - Initial cam.
 - Bridge cam.
 - Ship outside cam.

Make the ship loader load gltf lights.

Make planets respect local star light.
 * Implement a mechanism to differentiate between stars, light emitting
   planets, and regular planets.
 * Make stars light emitters.
 * Give celestial bodies the materials needed to facilitate lighting.

Create a linter setup to enforce project code consistency.

Implement ultra low quality mode.

shipPilot.onShipLoaded:
Many changes have been made since this was implemented; check if the cam
rotation code in that function even does anything. Remove if not.

Cam controllers currently have the option to be notified when they are loaded.
They do however not have a direct mechanism to be notified if a different
controller is being loaded, making checking verbose copy-pasta. Implement
something in core to facilitate this.

Put first load mode in index.js.

Test bridge cam attach in both local and world transform.

Test switching between hyperdrive and regular.

Implement world position reset when switching to/form hyperdrive.

Implement a ramp based speedometer and make sure distances measured with m/s check out.

Fix bug where the game can sometimes grab the mouse pointer while the game is
inactive.
This seems to happen exclusively while the game is loading. We can probably fix
this by preventing a lock during boot if it's found that the window is not
focussed.

Move all UI elements that do not need updates every frame (such as the control page)
to React. Future menus need to be moved to React as well.

Ensure React-based menus work in VR.

-- Set up a spacecube field and make the ship travel through it (just via brute
force, no need for physics right now). Then ensure the player stays on the ship
and doesn't get left behind, in all modes. Maybe give to option to let one
detach from ship in free cam mode.

Implement an analog logarithmic speedometer (or at least a relative one).
Show all speeds underneath, but make the font smallers as the numbers grow.
Move position and rotation to left bottom.

Implement dynamic gravity.
Address the walking through wall problem.
Consider implementing invisible floors to make walking smoother.

Create indicator that shows "Press [] to interact." or "[] Interact."
Make the border be in the direction of the switch highlighted.
Maybe place an actual arrow next the border closer the the interactable, but
this last one is optional.

spaceshipLoader.modelPostSetup:
Implement mechanism to load player ship at specific world position.

Implement a queueable toast system.
Current toast system only supports one message at a time. Requesting a second
message causes existing text to be replaced while the toast message is still
showing.

Add on camControllerReady to core.startupEvent.

Some technical problems to consider:
Moving at 3000c causes the camera to jump around *slightly*. \[Note that this was
*after* render order optimisations which fixed glitches showing at 100km/h
already.] This get worse until the game is eventually unplayable. Some tests I
did suggest that the problem gets far worse as distance to the world coords
0,0,0 goes into the multimillions. A solution was found: don't move the space
ship at all - move the entire universe in opposite direction instead. This
completely solves not only the jumpiness, but means the skybox is now stable
too. The results were good even at 3 billion times the speed of
light (I stopped there because we'll never need nearly that much). The
glitchiness vanished, but there is one last problem. At exactly 2 specific
distances from 0,0,0, the camera first jumps about around 3 meters forward
from where is should be, and then jumps 3 meters back from where it should be.
I don't have exact values, happens at around 75,000ly and 150,000ly. Note
however it isn't glitchy and stays stable despite the bad cam positions,
meaning we can hopefully code around it when the time comes.
At the time of writing, I have no clue if you can make physics system
(cannon.js) account for this. Even if you could, it's likely unnecessary.
Instead, I propose a solution where the player movement vs universe movement
is done dynamically based on certain conditions, which disables physics as needed.
* [Ship movement] Player can accelerate infinitely using normal engines, but make
this infeasible. Basically, accelerate about as fast as the Parker Solar Probe,
which would take about 3.5 years to travel 1AU. Also limit ship speed to 400m/s
by default using safety mechanisms, but allow the player to unlock acceleration
via ship hack. Maybe have the ship automatically engage hyperdrive past a
certain speed (if equipped).
* [Universe movement] To travel as reasonable speeds, jump into hyperdrive.
When doing this, disable all physics. This allows us to transform the world
instead of the ship. We'll need to ensure the entire game is compatible with
the change in ref calculations.
* Hyperspace (IID) of course just instantly teleports you, so it does what
hyperdrive does.
* When the player exits hyper\[*], parent it to a new group and transform it to
world 0,0,0. Then transform the universe such that the player is the center of
the universe just like my ex. Reactivate physics at the new center of
universe.
* Profit.

Detail a standard for mesh creation. Maybe with a json file that describes how
the mesh is the be loaded, example:
{
  "main": { "label": "hull" },
  "captainSeat": { "label": "cube.002" },
  "navMonitor": ...
  "combatMonitor": ...
  "statusMonitor": ...
  "shipMonitor": ...
  "generic_seats": [
    { "label": "rear_observation_seat"  }
  ],
  "doors": [
    { "label": "loading_bay", "switch": "loading_bay_switch" }
  ]
}
Check if GLTF supports collections. If so place internal ship lights into those
collections, like "cockpitLights" etc and see if other lights like individual
crew quarters can be tagged somehow. This would allow for highly dynamic ship
function with zero additional coding needed for new ships. Maybe tagged via
specially named materials (which 100% would fail in engines like godot, because
material names are global and therefore need to be unique).

Implement mode switches correctly WRT ship controls, then follow that with menu
controls.

Implement switching between body cam and free cam. Make body cam the default.

either of these first: [
    - Implement ship modular power systems.
    - Create in-ship computer interface:
        * Navigation
        * Combat
        * Status
        * Ship
]

create weapon modules.

implement firing groups.

create some environments:
    - saturn, to scale. hexagon storm demo.
    - something akin to ME citadel, to scale, with some landing spots.
    - implement orbital station, orbiting star.

implement hyper relays (star gate).

implement hyper drive.

implement multiplayer.

implement ai.

make procedural universe.

make galaxy map.



--------------------------------------------------------------------

Technical debt
==============

ammo.js was copied from node_modules to hackedlibs to fix a crash. See its
readme for more details.

--------------------------------------------------------------------