Add migration guide

docs/.vitepress/config.js

@@ -86,6 +86,13 @@ module.exports = {
             { text: "Dynamic Layers", link: "/guide/advanced-concepts/dynamic-layers" },
             { text: "Nodes", link: "/guide/advanced-concepts/nodes" }
           ]
+        },
+        {
+          text: "Migrations",
+          collapsed: true,
+          items: [
+            { text: "0.5.X to 0.6.0", link: "/guide/migrations/0-6" }
+          ]
         }
       ],
     "/api/": generateAPISidebar()

docs/guide/getting-started/setup.md

@@ -12,14 +12,14 @@ For local development, you will need the following tools:
 Create a new project from the [Profectus repository](https://github.com/profectus-engine/Profectus) by clicking the "Use this template" button. Then, clone the repository locally using the provided link.
 
 ::: info
-The template repository allows easy creation of multiple projects from one repository. However, updating an existing project to a newer version of Profectus can be challenging. Consider [updating Profectus](https://chat.openai.com/updating.md) _before_ starting development to avoid issues with unrelated histories.
+The template repository allows easy creation of multiple projects from one repository. However, updating an existing project to a newer version of Profectus can be challenging. Consider [updating Profectus](./updating.md) _before_ starting development to avoid issues with unrelated histories.
 :::
 
 It's recommended to create a new Git branch for development, allowing you to push changes without affecting the live build. The GitHub workflow will automatically rebuild the page when you push to the `main` branch.
 
 Next, install Profectus' dependencies by running `npm install`. Run `npm run serve` to start a local server hosting your project. The site will automatically reload as you modify files.
 
-Also, follow the steps to [update Profectus](https://chat.openai.com/updating.md) before starting to make future updates easier without worrying about unrelated histories.
+Also, follow the steps to [update Profectus](./updating.md) before starting to make future updates easier without worrying about unrelated histories.
 
 ### Deploying
 

docs/guide/getting-started/updating.md

@@ -2,7 +2,7 @@
 
 ## Github
 
-Due to Profectus being a template repository, your projects do not share a git history with Profectus. In order to update changes, you will need to run the following:
+Due to Profectus being a template repository, your projects do not share a git history with Profectus. To update changes, you will need to run the following:
 
 ```bash
 git remote add template https://github.com/profectus-engine/Profectus
@@ -14,8 +14,8 @@ The first command only has to be performed once. The third command may require y
 
 ## Replit
 
-The sidebar has a tab labelled "Version Control", which you can use to merge all changes made to Profectus into your project. Unfortunately, replit does not have a merge tool so this process may irrecoverably erase changes you've made - I'd recommend making a backup first.
+The sidebar has a tab labeled "Version Control", which you can use to merge all changes made to Profectus into your project. Unfortunately, Replit does not have a merge tool so this process may irrecoverably erase changes you've made - I'd recommend making a backup first.
 
 ## Glitch
 
-Unfortunately glitch does not provide any method by which to update a project from a github repository. If you've only changed things in the data folder you may consider creating a new project, importing the current version of Profectus, and then placing your data folder in the new project.
+Unfortunately, Glitch does not provide any method by which to update a project from a Github repository. If you've only changed things in the data folder you may consider creating a new project, importing the current version of Profectus, and then placing your data folder in the new project.

docs/guide/migrations/0-6.md

@@ -0,0 +1,124 @@
+# Migrating to Profectus 0.6
+
+In addition to the usual steps for [Updating Profectus](../getting-started/updating), this update has many large or breaking changes. This guide will go over the additional steps you'll want to do after updating Profectus.
+
+## Fixing save data
+
+This update includes a major change to how save data is collected and stored. The change makes save data smaller and fixes issues that can arise, causing persistent values to be reset to their default values. Unfortunately, this change will require the developer to effectively mark which uses of persistent values are supposed to be included in the save data, and which uses are just a reference. Let's walk through an example:
+
+```ts
+const flowers = createResource<DecimalSource>(0, "moly");
+const job = createJob(name, () => ({
+	/** snip **/
+    resource: flowers
+}));
+/** snip **/
+return {
+	/** snip **/
+	flowers,
+	job
+}
+```
+
+This would store the same persistent data in two locations - `flowers.flowers` and `flowers.job.resource`. We can mark the latter usage as a reference by wrapping it in the [noPersist](../../api/modules/game/persistence#nopersist) utility, so it'd look like `resource: noPersist(flowers)`. Otherwise, you'll get an error in the console when the layer is loaded:
+
+![Persistence Error](./persistence-error.png)
+
+You can use these errors in the console to determine where you have save data redundancy that needs to be corrected. It's recommended to just run the app and use those errors as a guide, rather than trying to determine any redundancies by hand.
+
+In addition to getting non-persistent refs from your persistent refs, you may also need to wrap entire features that contain persistent refs within them. For example, in Kronos there are 7 layers with "Job" features, and they're collected into a dictionary in the main layer. That would make the persistent state appear in both layers, but you can wrap that dictionary into a `noPersist` call to skip it during serialization, thus making it so that it'll only use the jobs inside their respective layers. Here's what that looks like in Kronos:
+
+```ts
+const jobs = noPersist({
+    flowers: flowers.job,
+    distill: distill.job,
+    study: study.job,
+    experiments: experiments.job,
+    generators: generators.job,
+    breeding: breeding.job,
+    rituals: rituals.job
+}) as Record<JobKeys, GenericJob>;
+```
+
+This step will take longer depending on how you've structured your project. You can use [this commit](https://github.com/thepaperpilot/Kronos/commit/6e8bfc1a78df0a7957de06bacdabf87c688b917c) to see all the changes it took for Kronos, which is structured so that similar features all used a utility function that made it so only a few places needed to be changed.
+
+## Breaking feature changes
+
+Several features had some breaking changes this update. Here are a couple more minor fixes:
+
+- Buyables have been renamed to repeatables. This should be fixable by just replacing every instance of `Buyable` with `Repeatable`.
+- Achievements and Milestones have been merged. Any existing achievements should have `small: true` added to their options, and any `createMilestone` calls replaced with `createAchievement`.
+
+In addition, there are a couple changes which have a more significant impact on your code: Requirements, Formulas, and Modifiers.
+
+### Requirements
+
+Many features no longer take a `cost` and `resource` property, but instead take a `requirements` property, which can be one or more `Requirement` objects. This'll make it easier to support features requiring multiple currencies or having other conditions. To update an existing cost requirement, you can simply wrap your existing cost function and resource property like so:
+
+```ts
+requirements: createCostRequirement(() => ({
+    cost: () => Decimal.pow(priceRatio, unref(machines.amount)),
+    resource: generators.energeia,
+}))
+```
+
+You can read more about requirements and their capabilities in [this guide page](../important-concepts/requirements).
+
+### Formulas
+
+Formulas are a new feature that allow for scaling cost or effect functions to be inverted or integrated without the developer needing to code anything besides the original formula. They can make it much easier to support things like "buy max" functionalities, and make conversions much easier to read and write.
+
+Any cost requirements can now accept a formula instead of a cost function. The formula system can then handle finding how many purchases can be made at once. To continue the example above, here's how it'd be rewritten:
+
+```ts
+requirements: createCostRequirement(() => ({
+    cost: Formula.variable(machines.amount).pow_base(priceRatio),
+    resource: generators.energeia,
+}))
+```
+
+Conversions work slightly differently. Their scaling function system has been replaced with a `formula` property that takes a lambda - it'll give you the input formula variable, representing the base resource, as a parameter, and you then return a formula that represents the amount of the gain resource you could convert for. For example, if previously you had code like this:
+
+```ts
+scaling: addSoftcap(createPolynomialScaling(10, 0.5), 1e100, 0.5)
+```
+
+then you can now write this:
+
+```ts
+formula: x => x.div(10).sqrt().step(1e100, f => f.sqrt())
+```
+
+You can read more about formulas and their capabilities in [this guide page](../important-concepts/formulas).
+
+### Modifiers
+
+Modifiers now display negative effects in red. It currently assumes any value that reduces the result is negative, and the output being less than the base means is a negative outcome. However, for some modifiers this may be the opposite of what you want - for example, a cool down being reduced below it's base is a positive effect. You should set the `smallerIsBetter` property to `true` for those modifiers. This property also exists when making collapsible modifier sections.
+
+Modifiers have renamed their `revert` property to `invert` so they match the terms formulas use. If you've created a custom modifier you'll need to update that.
+
+## Fixing visibility changes
+
+Visibility properties now work with booleans, which has had a lot of implications.
+
+The `showIf` util is no longer useful and has been removed - you can now simply return the boolean value itself. In fact, if you were previously passing a computer boolean into showIf, then now you can just use the computed ref directly, lowering overhead. Here's an example:
+
+```ts
+visibility() {
+    return showIf(spellExpMilestone.earned.value);
+}
+```
+
+This code can now be simplified to this:
+
+```ts
+visibility: spellExpMilestone.earned
+```
+
+Be aware that using the computed ref directly instead of a function can cause a circular dependency issue. If you experience one while simplifying a visibility property, you'll need to resolve those or continue to use a function, returning the value of the computed ref.
+
+### Custom Components
+
+If you made any custom features with their own Vue component, you'll need to update it to support booleans for visibility values. That means replacing **ALL** equality checks for specific visibilities with calls to [isVisible](../../api/modules/features/feature#isvisible) and [isHidden](../../api/modules/features/feature#ishidden).
+
+While updating your component, you may also need to cast the component to [GenericComponent](../../api/modules/features/feature#genericcomponent).