Details:
Browserify is unable to deal with external libraries that have not been transpiled to lower versions. Replace with webpack, which is known to do this well.

Details:
Implement warp drives.

Requirements:

• We need warp drives types that can accelerate either linearly or exponentially. Note that, regardless of type, max speed should be the same for both.
• We need to take into account gravity; essentially, gravity introduces spacetime drag. Spacetime drag reduces warp drive max speed.
• Create a scaling mechanism where increasing engine output power causes explosive increase in speed. For example, a 206 engine might have a max speed of 3c (3x speed of light), while a 209 engine would have a max speed of 4c.
• Physics should be disabled while in warp. There is no reverse, and no moving vertically.

Details:
Implement keyboard controls.

Requirements:

• We need mode contexts priorities - for example, if up arrow is 'move forward', but up arrow is also 'interact with menu item', then up arrow should be used for the menu while the game is running. On the other hand, if the menu is open but another key (such as analog forward) is not mapped to a menu action, then it should be sent to the game while the menu is open. These modes should work generically across the entire application.
• We need to be able to map more than one key to an action.
• We need to be able to hide some keys for dev and debugging reasons.

Details:
Make it possible to use two (or more) buttons for a single key binding. This is important with controllers where the ~16 buttons available are not enough for all available actions (at the time of writing we already have 16 actions in shipPilot mode alone, and that list is incomplete).

This needs to be implemented in ContextualInput. Unless someone has an alternative suggestion, this should be implemented by intentionally introducing a tiny bit of lag to allow for keys to pile up.

Not everyone will appreciate this tiny additional lag, so this needs to be an option disabled by default. The user should also be allowed to choose the amount delay time in milliseconds, with a suggested default.

Details:
The way input modes are currently implemented in core has a design mistake that needs to be addressed before the UI can be implemented. If correctly implemented, different modes may sometimes, but not always, be mutually exclusive. You can have more than one active at a time, with input preference based on some predefined [hardcoded] priority.

Using Dark Souls as an example: you can run around while in ANY menu, but arrow keys and interaction keys are now snatched by the menu and don't make their way to the game. Some flight have similar features.

Needed result:
For each action mode, send the current key(s) pressed.

By default, all active mode controllers¹ should receive key input simultaneously. A controller is allowed to request priority or exclusive access.

Bonus points:
Don't allow the key controllers to actually receive keys; rather, have them receive actions. This makes control bindings completely transparent, and allows abstracting between, say, keyboard and mouse events.

Completion of this task does not require implementing all possible peripherals; rather, it requires setting up the basic framework to facilitate any peripherals.

¹ Controller in this case refers to a logical piece of software controlling what happens to actions generated by input from any source, including keyboard / mouse / gamepad. It does not mean 'hardware device'.

Describe the bug
Interacting with door switches no longer cause doors to open.

Steps to reproduce
Steps to reproduce the behavior:

1. Load the game with the devFlyer space ship.
2. Enter free cam and fly to rear of ship.
3. Interact with door switch - nothing happens.

Expected behavior
Door should slide open when interacting with switch, and close again if interacting with switch a second time.

Screenshots
https://imgur.com/a/ftIxXdc

Desktop (please complete the following information):

• OS: Windows
• Build 72

Additional context
This appears to have started happening after the ship was parented in warp bubble logic.

Door switch no longer light up green like it used to, either.

Details:
Implement level logic by making player space ships load as levels. Add logic to interact with switches. Make switches trigger reversible door animations.

Details:
Add initial mode switching, initial draco mesh loading, FPS meter, and some demo assets.

Details:
Once the game nears the end of pre-alpha stage, ensure that all UI components are VR compatible.

Details

Implement the in-game menu (including options, quit, inventory, etc) using React. The menu needs to be implemented as a mode controller.

Brief description

A menu system should be implement using React. Should use Semantic UI React as the base.

Definition of done

• Debug tools menu implemented.
• Options menu implemented.
• Graphics menu implemented.
• Customisation menu implemented.
• Credits menu implemented.
• Profile menu implemented.
• A ship interface menu should, at the very least, be prototyped.

Subtasks

• #48

Details:
Create control mappings that allow controlling the space ship while in warp.

Details:
Add visual speed indicator to godCam and freeCam.

All issues are currently managed on my own machine.

Task: migrate to them to GitHub.

Details:
Add free cam functionality.

Details:
Changes the user makes in the menu need to be persisted to their profile. These changes include:

• Control bindings
• Graphics settings
• Starting space ship (until a better mechanism is implemented)
• Customisations

Profile needs to be saved in a standard location that makes sense given its host OS. Examples:

Windows | C:\Users\[user]\AppData\Roaming
Linux   | /home/[user]/.local/share
Apple   | /Users/[user]/Library/Preferences
Android | /storage/emulated/0/Android/media

Please make the profile multi-user (i.e. allow for multiple save files). Perhaps limit the names a profile can have, example [a-zA-Z0-9_] so that we may give each profile its own directory. Create a default profile with name default during boot if it does not exist.

We also need to provide the option to have no saves in case saving is impossible (i.e. permission denied, out of space, cannot determine OS profile location, etc).

Overview:

• When game starts, check if the profile dir exists. if not, create it.
• Check if default profile exists. If not then create it, and fill it with default values from controls, graphics, customisation, etc.
  • This probably means section like controls menu, graphics menu, etc need to register their own default templates before profile init functions start.
  • A profile is a directory. Each profile contains a manifest.json (maybe?).
• No profile-related actions should take place until its emitter has fired, and should be queued instead. - This will now be done as part of preboot instead of using the emitter system.
• Things that work with profile state should, after saving stuff to disk, immediately replace running game state with what's on the disk. This is to ensure we immediate see profile-related bugs as they're introduced, and gives the user a sense of consistency of running state when they restart.
• Create backups of the profile before it's written. If writing the backup fails, abort. This allows us to 1) restore to a working save on catastrophic failure and 2) means we can pre-emptively check for write issues that might corrupt the profile in use. - We've run out of time and this is currently non-essential. This will instead be done as a separate task.

Details:
There are currently UI elements (such as the speedometer and thrust indicators) that update very frequently, but is written as plain HTML. Rewrite this as pure Three.js code.

Note that the Three.js code does not have to look the same visually; the items currently in place were created in a rush for debugging purposes.

Details:
We need something to stream in images and height data for celestial bodies. This would be akin to something like tile servers used by OpenStreetMap and Google Maps.

Example use case:

• When far away, planet is a sprite mimicking relative luminosity.
• Stream in higher quality images as you get closer to a planet, eventually getting very detailed.
• Once close enough, start streaming in heightmap info to give the planet terrain as as well.

This might might take form as a separate application service spawned by the main application.

Details:
The application doesn't really work out-of-the-box at the moment. Adjust npm scripts and the like to 'just work' so that we may do our first release.

Details:
Ship loading process currently ignores any lights defined in the 3D editing software (such as Blender).

Implement a clear process on how lights made in 3D editing software interact with the engine, then document it.

Describe the bug
Under certain conditions, the ship steering will get flung in some direction when entering locked mouse steering.

Steps to reproduce
Steps to reproduce the behavior:

1. Ensure hyperdrive is active.
2. Middle click to enter mouse steering.
3. Move in some direction.
4. Middle click to deactivate mouse steering.
5. Middle click again.
6. Ship is flung in the last direction you were steering.

Expected behavior
Steering should be centered when entering mouse steering.

Desktop (please complete the following information):

• OS: Windows
• Build 72

The contributing page is currently a braindump, and is missing some details. Please complete it.

Details:
Create unit and integration tests.

We will not be using any test frameworks for this. Instead, we'll be using in-application tests to make certain tasks a bit easier.

What needs to be documented?
How we create a fully working install for Windows.

Details:
I tried electron for fun, but I'm not quite what I'm used to and its quirks are interfering with development. Switching to nwjs, something I've worked with a long time.

Details:
Add visual collision bounds for debugging purposes in physics code.

Details:
Implement HMR. For now just make it reload the entire application. Eventually we may open a new task to have HMR reload pieces of the application as needed.

Details:
Implement feature that allows looking around inside the ship.

Details:
Moving very fast causes camera glitches. Research done showed that this is caused by the ship moving very (VERY) far from the game's true zero origin point.

When accelerating in regular space, move the space ship through space as per normal. However, when in warp, make the space ship the 'center' of the universe, and make the universe move instead of the space ship.

Details:
Add a CONTRIBUTING.md file. Does not need to be complete just yet; just need something basic going.

Details:
API function should be smart functions. I.e. they should work when appropriate, or wait for an appropriate time to execute before executing.

Details:
User profile backups were initially meant to be implemented in #48, however profile backups are not really essential so early in pre-alpha and time constraints for the task were exceed. This ticket should continue that work.

Original task:
Create backups of the profile before it's written. If writing the backup fails, abort. This allows us to 1) restore to a working save on catastrophic failure and 2) means we can pre-emptively check for write issues that might corrupt the profile in use.

It should be noted that this task will only be consider low priority as long as the game isn't yet a proper (fun/playable) game. The moment we have real players doing real things, this task becomes top priority if not yet implemented.

Details:
First release was potentially a little confusing to new users because it doesn't have menus, tutorials, hints, etc.

Requirements:

• Add a nice little loading indicator that shows the build number. Maybe a spinning space ship.
• Add a common controls box in the top left.
• Add a feature to press F1 to show all controls (the 'all controls' window should be dynamically generated).
• Start the game in hyperdrive because we do not yet have working engines in normal space, which makes it look like the game isn't working.

Details:
Implement a mechanism that allows different parts of the application to, asynchronously and retroactively, know the boot state and progress of the application.

Details:
Webpack is currently spitting out warning which are invalid. Silence them.

Details:
Add modding support. We want to add as many functions to these as possible. All mod functions need to employ checklist loading signals and attempt to do as much error checking and error logging as possible, even at the potential expense of performance.

Functions should be groups in major categories, example:

• camControl
• shipControl
• keyAction
• userProfile

Technical details:

• Create a modding directory in /apps.
• The modding dir needs to have a v1 dir, in which the mod API js files will reside. This is so that we may create breaking changes in future if needed without actually breaking existing mods. This should ideally never happen, but it's good practice, anyway.
• Create a directory called mods in the root directory, and create these directories in it:
  • community
  • official

Mods need to have exactly two files: name.js and name.json5. The JSON5 file will be used to feed the user info before they enable it. Once enabled, the game should md5 sum the js file and store that in the user profile. If the md5 changes, the application should complain and give the user the option to force-enable the new file if they so choose.

JSON5 file requirements:
The JSON5 file should contain a series of values. They are as follows:

name | Unique name of the mod.

modApiVersion | The mod API version that the mod uses. We'll start at v1 and hopefully never have the need for a v2.

minimumApplicationVersion | The minimum version of the game the mods requires to work. This is important because the modder may be targeting functionality that does not yet exist on the user's machine, in which case the application should warn the player. They will still have the option to force enable the mod.

Logging:
No mod functions should console.log any debug information. Warnings should be avoided, but may be added. Errors should always be logged.

Implement space ship physics using Canon.js.

Note: this task is purely related to space ship physics while not in a warp bubble.

Details:
Implement a HUD item that allows you to track, perhaps on some sort of compass, where nearby bodies are relative to you yourself.

Details:
We need an ultra low quality mode that causes the game to:

• Disable all lighting, shadows etc.
• Cause all materials to be loaded as basic materials (i.e. cpu cheap materials).
• Use very basic shaders.

Details:
All UI code not currently tied to per-frame updates are currently written as tacked-on HTML. Move this into a proper React JS mechanism.

Future menus should also use this new mechanism.

Describe the bug
The direction in which you point the ship in 3D design software (such as Blender) will determine what forward is. This is not only unintentional, but was supposed to be fixed with 300652f. It seems something was either improperly tested or we have a regression.

Steps to reproduce
Steps to reproduce the behavior:

1. Start with the devFlyer space ship.
2. Try to fly forward. Suffer the disappointment.
3. Load either the DS69F or Scorpion-D space ships.
4. Try fly forward - it works.

Expected behavior
With the current implementation, direction should be based on the direction the first camera in the scene is pointing.

Desktop (please complete the following information):

• OS: Windows
• Build 72

Additional context
This bug is a weird one because the DS69F and Scorpion-D space ships actually point in two very different directions already (also I'm 100% sure I tested the devFlyer... regression, maybe?).

[Parent issue: #74]

Details:
We need to make planets and the space ship interiors respect local star light.

Task:

• 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.
• Ensure the space ship itself has realistic shadows.

Note that this task refers to lighting from the local star and does not include stars that are light years away.

Investigation to be followed in comments below.

Describe the bug
Seems an accidental dependency on frame rate was introduced while creating warp drives.

Steps to reproduce
Steps to reproduce the behavior:

1. Set frame limiter to 60.
2. Start a timer, go full warp, run for a minute. Measure distance and max location.
3. Set frame limiter to 20. Repeat step 2.
4. Max speed is lower at 20 frames, and we do not travel as far.

Expected behavior
Speed should be consistent. Changes in frame rate should not affect speed.

Desktop (please complete the following information):

• OS: Windows

Additional context
This also manifests as the speedometer rapidly changing speed.

Details:
Implement file resource loader. It should automatically default to productions assets, but fall back to dev assets when prod assets are unavailable.

Details:
We need build scripts. The purpose of these is to easily publish distributables to the releases page.

The current steps are detailed at the bottom of the CONTRIBUTING.md page, but note that the instructions are currently windows-only; we likely need to include other platforms.

Once the build scripts are working, CONTRIBUTING.md needs to be updated as part of this task.

Optional extra credits:

• Make scripts CI/CD friendly.
• Allow building for other platforms (i.e. allow building for a platform you're not actually running the script from).

Details:
We need a standard linter setup to ensure we have consistent code across various files.

Details:
Move away from react-three-fiber to plain three.js.

We'll still be using React itself for some UI items, but unfortunately we will no longer be using react-three-fiber within this project.

Reasoning:
Whilst react-three-fiber is undoubtedly a very powerful tool, react-three-fiber is a bit lacking in documentation right now. My understanding of three.js is simply too little to use educated guesses to perform tasks (this is my first three.js project, and I'm currently the only contributor). Simple tasks are simply taking me way too long. By contrast, vanilla three.js is quick to learn.

Details:
The asset loader mechanism is somewhat incorrectly named at the moment. Additionally, the constructor should be capitalised.

Rename assetLoader to AssetFinder, because that's what it does: it searches for assets based on certain conditions.

Then, create a new AssetLoader constructor to manage assets at the high level.

Details:
Implement full screen. User should be able to press F11 to enter and exit full screen.

Details:
Move cam[0] logic into ship loader.

• Create notion of a standard arrow.
• Ship orientation cam.
• Initial cam.
• Bridge cam.
• Ship outside cam.

Explanation:
Currently, the engine expects any imported space ship to have at least one camera. This camera is used as the 'forward' direction of the ship. This same camera is also used as the captain's bridge seat location. Logic needs to be updated such that:

1. The 3D designer decides what forward is,
2. Seats and cameras are not treated as the same thing.

Details:
The current toast implementation was thrown together in a quick/dirty fashion (in literally 10 minutes) and has multiple issues (the most important one being that queuing messages does not work, and likely never will).

Task:
Implement a new toast system utilising the newly implemented React core. Delete the old toast mechanism.

We need multiple toast types:

• System messages (messages floating in the center of the screen for a bit),
• Quest messages (larger messages with headers briefly floating at the top, indicating game status change).
• Interaction messages (such as 'Press [E] to activate door.').
• Notifications (messages in top right; they have exit buttons and may have headers).

Not all of them will be made equally - for example, system messages may recur for things like "Maintenance at 18:00." Interaction messages have no time limit, and are instead killed by a deletion event. Quest messages will have no option to be displayed indefinitely, and will have 'long' or 'short' time limits.

Toast messages should have the option to grab input priority for potential interaction. For example, a quest message might be displayed for 5 seconds, and have a little 'Press [Tab] to open journal' note that takes one to that particular entry in the journal. A 'Press [E] to interact' should have appropriate callback mechanisms.