Added unstable support for CTP1

.eslintrc.cjs

@@ -178,9 +178,11 @@ module.exports = {
                 'functional/no-return-void': 'off',
                 'functional/no-throw-statements': 'off',
 
+                'jsdoc/check-tag-names': 'off',
                 'no-undef': 'off',
                 'no-unused-vars': 'off',
                 'vitest/max-expects': 'off',
+
                 'vitest/no-hooks': 'off',
             },
         },

.github/copilot-instructions.md

@@ -0,0 +1,27 @@
+**CRITICAL: Always output the results of any commands you run to temp.log (in the root directory), then read that to get the results of the previous command. This ensures that you can read it - there is a bug at the moment that will prevent you from reading commands directly. Use tee when doing this so I can see the command running without having to open temp.log. You should NOT have to run "echo "Starting header test creation" | tee temp.log" or similar - only do it for test runs and other important commands. Echo should almost never be present.**
+
+STEPS TO FOLLOW:
+
+Try your best to follow the linting rules the first time, that way you will not have to come back to change the code later (see .eslintrc.cjs in the root).
+
+Before starting ANY new features or editing existing features, create tests for the feature, run the tests you created (they should fail) and use test-driven development (red-green testing) to ensure the feature works according to the spec you filled out. Mock and stub anything that needs to be mocked / stubbed, but don't overdo it.
+
+Instead of writing the whole files at once, write the files in incremental steps - writing a function at a time (so you don't corrupt it).
+
+Once each step is completed, run "npm run lint" and fix any issues (warnings OR errors) that pop up. Additionally, run the tests with "npm test -- run" and fix any test failures that remain. You are not allowed to change any linting rules, styling rules or any testing rules.
+
+If a single React component has more than 5 useState / state management calls, convert it to use a React reducer as a part of your task.
+
+TOOLS TO USE:
+
+A pre-install hook will prevent you from ever using npm. Use npm, not pnpm (pnpm has issues with Electron).
+
+Use Vitest and Playwright for tests.
+
+Use eslint for linting. You can use the ESLint MCP server to check the current ESLint status.
+
+You can add packages (especially if they make the job significantly easier). Make sure that if you want to add a package, you tell me the reasoning first.
+
+ALWAYS run tests without watch mode so I don't have to cancel / quit the runs for you.
+
+The "diffing" portion of the repository (applyModsToInstallWithMerge, etc.) are legacy and must be kept intact, but should not be considered for refactoring or actual use.

.gitignore

@@ -8,4 +8,7 @@ out/
 
 .vite/*
 
-debug
+debug
+examples
+
+temp.log

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 There are a few different steps to get started with this repo. To get started, you will need:
 
--   `Node` and `npm` installed (nvm is highly recommended - the repo is set up so that you can simply run `nvm use` in the root to install the correct versions automatically)
+- `Node` and `npm` installed (nvm is highly recommended - the repo is set up so that you can simply run `nvm use` in the root to install the correct versions automatically)
 
 From here, you can start the dev server with:
 
@@ -18,6 +18,6 @@ Code should be formatted with [Prettier](https://prettier.io/). The recommended
 
 Relevant unit or integration tests are always appreciated, but not necessarily required (yet). Eventually, the plan is 80% test coverage, but this project has ballooned quite a lot.
 
-Submit all code via a pull-request on GitHub. I understand it may be a bit hypocritical (given I have just pushed to main since the beginning), but I was the sole contributor for the two years before this project was open-sourced, so there was no need to use PRs. That said, I am going to use PRs for all future contributions as that is the expectation going forward. 
+Submit all code via a pull-request on GitHub. I understand it may be a bit hypocritical (given I have just pushed to main since the beginning), but I was the sole contributor for the two years before this project was open-sourced, so there was no need to use PRs. That said, I am going to use PRs for all future contributions as that is the expectation going forward.
 
-Before you submit your PR, ensure that there are NO warnings or errors with ESLint by running `npm run lint`. After that, make sure all tests pass with `npm test`. If both of these work, feel free to submit the PR!
+Before you submit your PR, ensure that there are NO warnings or errors with ESLint by running `npm run lint`. After that, make sure all tests pass with `npm test`. If both of these work, feel free to submit the PR!

README.md

@@ -31,18 +31,20 @@ Most mods can just be applied in a single click, including scenario mods. Incomp
 
 ![image](https://github.com/user-attachments/assets/dfe0ecf7-fd5d-48a5-aa7a-739cfc19fc50)
 
-
 ## Change Your Theme
 
 You can change your themes with a click of a button to any of DaisyUI's wonderful themes. These include light modes, dark modes and most modes in-between!
 
 ### Light:
+
 ![image](https://github.com/user-attachments/assets/438322aa-7ed9-4efd-bd12-6aaf365d9ebb)
 
 ### Dark:
+
 ![image](https://github.com/user-attachments/assets/64e5ad90-541a-46ef-beae-2830bd1a568d)
 
-### Halloween: 
+### Halloween:
+
 ![image](https://github.com/user-attachments/assets/8befd4a6-c3ad-44a3-a752-4afcb2717006)
 
 ... and many more!

index.html

@@ -8,7 +8,7 @@
     <meta name="A mod manager created for the 1999 game Call to Power, as well as the 2000 sequel Call to Power II."
         content="Call to Power Mod Manager" />
     <meta http-equiv="Content-Security-Policy" content="script-src 'self';" />
-    <title>Call to Power Mod Manager (Alpha)</title>
+    <title>Call to Power Mod Manager (Beta)</title>
     <link rel="stylesheet" href="src/css/tailwind.css" />
 </head>
 

nguid.ctp

@@ -0,0 +1 @@
+ͱ�]G�A�*7_��