profectus/profectus-docs
1
0
Fork 0
Code Issues 12 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Wording changes

Browse source
This commit is contained in:
thepaperpilot 2023-04-17 23:27:58 -05:00
parent 4261cdface
commit fd037c3474
1 changed files with 25 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
docs/guide/migrations/0-6.md
View file

@ -1,10 +1,10 @@
# 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.
Alongside the standard steps for [Updating Profectus](../getting-started/updating), this update contains numerous large or breaking changes. This guide will cover additional steps to follow 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:
This update introduces a major change in save data collection and storage. The change reduces save data size and fixes issues that can cause persistent values to reset to default values. Unfortunately, developers will need to mark which persistent value uses should be included in the save data and which are merely references. Let's go through an example:
```ts
const flowers = createResource<DecimalSource>(0, "moly");
@ -20,13 +20,13 @@ return {
}
```
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:
This example stores 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 will encounter 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.
Use these console errors to identify save data redundancy that needs correction. It is recommended to run the app and use the errors as a guide rather than trying to identify redundancies manually.
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:
In addition to obtaining non-persistent refs from your persistent refs, you may need to wrap entire features containing persistent refs. For example, in Kronos, there are seven layers with "Job" features, which are combined into a dictionary in the main layer. This would cause the persistent state to appear in both layers, but you can wrap the dictionary in a noPersist call to bypass serialization, ensuring it only uses the jobs within their respective layers. Here's an example from Kronos:
```ts
const jobs = noPersist({
@ -40,20 +40,20 @@ const jobs = noPersist({
}) 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.
The time required for this step depends on your project structure. You can use [this commit](https://github.com/thepaperpilot/Kronos/commit/6e8bfc1a78df0a7957de06bacdabf87c688b917c) to see all the changes made for Kronos, which used a utility function for similar features that limited the number of required changes.
## Breaking feature changes
Several features had some breaking changes this update. Here are a couple more minor fixes:
This update includes several breaking feature changes. Here are a few 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`.
- Buyables have been renamed to repeatables. Simply replace all instances of `Buyable` with `Repeatable`.
- Achievements and Milestones have been merged. Add `small: true` to the options for existing achievements, and replace `createMilestone` calls with `createAchievement`.
In addition, there are a couple changes which have a more significant impact on your code: Requirements, Formulas, and Modifiers.
Additionally, there are changes with 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:
Many features no longer use `cost` and `resource` properties but instead utilize a `requirements` property, which can consist of one or more `Requirement` objects. This makes it easier to support features requiring multiple currencies or other conditions. To update an existing cost requirement, wrap your current cost function and resource property as follows:
```ts
requirements: createCostRequirement(() => ({
@ -62,13 +62,13 @@ requirements: createCostRequirement(() => ({
}))
```
You can read more about requirements and their capabilities in [this guide page](../important-concepts/requirements).
Learn 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.
Formulas are a new feature that allows for scaling cost or effect functions to be inverted or integrated without requiring the developer to code anything beyond the original formula. They can simplify support for "buy max" functionalities and make conversions 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:
Any cost requirements can now accept a formula instead of a cost function. The formula system can then handle determining how many purchases can be made at once. To continue the example above, here's how it would be rewritten:
```ts
requirements: createCostRequirement(() => ({
@ -77,31 +77,31 @@ requirements: createCostRequirement(() => ({
}))
```
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:
Conversions work a bit differently. Their scaling function system has been replaced with a `formula` property that takes a lambda - it provides the input formula variable, representing the base resource, as a parameter, and you return a formula representing the amount of the gain resource that could be converted. For example, if you previously had code like this:
```ts
scaling: addSoftcap(createPolynomialScaling(10, 0.5), 1e100, 0.5)
```
then you can now write this:
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).
Learn 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 now display negative effects in red. The current implementation assumes any value that reduces the result is negative, and the output being less than the base value is a negative outcome. However, for some modifiers, this may be the opposite of what you want - for example, a cooldown being reduced below its base value is a positive effect. For those modifiers, set the `smallerIsBetter` property to `true`. This property also exists when creating 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.
Modifiers have renamed their `revert` property to `invert` to match the terms used by formulas. Update any custom modifiers you've created accordingly.
## Fixing visibility changes
Visibility properties now work with booleans, which has had a lot of implications.
Visibility properties now work with booleans, which has several 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:
The `showIf` util is no longer necessary and has been removed - simply return the boolean value itself. In fact, if you were previously passing a computed boolean into `showIf`, you can now use the computed ref directly, reducing overhead. Here's an example:
```ts
visibility() {
@ -109,16 +109,16 @@ visibility() {
}
```
This code can now be simplified to this:
This code can now be simplified to:
```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.
Be aware that using the computed ref directly instead of a function can cause circular dependency issues. If you encounter one while simplifying a visibility property, resolve the issue or continue using a function, returning the computed ref value.
### 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).
If you created any custom features with their own Vue components, you'll need to update them to support booleans for visibility values. This 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).
While updating your component, you may need to cast the component to [GenericComponent](../../api/modules/features/feature#genericcomponent).