Alongside the standard steps for Updating Profectus, this update contains numerous large or breaking changes. This guide will cover additional steps to follow after updating Profectus.
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:
const flowers = createResource<DecimalSource>(0, "moly");
const job = createJob(name, () => ({
/** snip **/
resource: flowers
}));
/** snip **/
return {
/** snip **/
flowers,
job
}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 utility, so it'd look like resource: noPersist(flowers). Otherwise, you will encounter an error in the console when the layer is loaded:
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 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:
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>;The time required for this step depends on your project structure. You can use this commit to see all the changes made for Kronos, which used a utility function for similar features that limited the number of required changes.
This update includes several breaking feature changes. Here are a few minor fixes:
Buyable with Repeatable.small: true to the options for existing achievements, and replace createMilestone calls with createAchievement.Additionally, there are changes with more significant impact on your code: Requirements, Formulas, and Modifiers.
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:
requirements: createCostRequirement(() => ({
cost: () => Decimal.pow(priceRatio, unref(machines.amount)),
resource: generators.energeia,
}))Learn more about requirements and their capabilities in this guide page.
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 determining how many purchases can be made at once. To continue the example above, here's how it would be rewritten:
requirements: createCostRequirement(() => ({
cost: Formula.variable(machines.amount).pow_base(priceRatio),
resource: generators.energeia,
}))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:
scaling: addSoftcap(createPolynomialScaling(10, 0.5), 1e100, 0.5)you can now write this:
formula: x => x.div(10).sqrt().step(1e100, f => f.sqrt())Learn more about formulas and their capabilities in this guide page.
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 to match the terms used by formulas. Update any custom modifiers you've created accordingly.
Visibility properties now work with booleans, which has several implications.
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:
visibility() {
return showIf(spellExpMilestone.earned.value);
}This code can now be simplified to:
visibility: spellExpMilestone.earnedBe 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.
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 and isHidden.
While updating your component, you may need to cast the component to GenericComponent.
`,41),p=[l];function r(c,i,y,d,u,D){return a(),e("div",null,p)}const A=s(t,[["render",r]]);export{C as __pageData,A as default};