Farm-hand v2

[SyfSchydea]

The farm-hand script in particular has just so much spaghetti. There's code duplication. There's way too much complexity in the page interface. There's nonsensical inheritance hierarchies. And there's lots of inefficiencies which are very hard to improve with the current systems in place.

So, I think that actually completely rewriting the thing with better design goals in mind would be really beneficial.

So what are those design goals?

• No behaviour by default until activated specifically from the console
• Plot unlocks should be prioritised (as long as that behaviour is activated), and should use a system like this one to do so efficiently.

And some more back-end goals:

• Better separation of action and expiration policies in tasks (I had started to do this in some more recent changes to v1)
• Task expiration should be split into task eligibility and completion
• Mutation tasks should be created ahead of time, and activated or discarded later.
• Page interface should avoid complex tasks, eg. getEligibleFlavourEvolveMutation

[SyfSchydea]

Functions like getEligibleFlavourEvolveMutation should roughly correspond with functions in the main script of v2, which will spit out a list or generator of all mutations of this type. These new functions should not take eligibility or necessity into account like the v1 ones do. This could also include multiple mutations/tasks for each berry. Eg. Custap may be mutated using either Watmel or Pinkan berries, so two mutation objects should be generated, one for each of these possibilities. All of these mutation factory functions should be called when the script starts running properly after the game first loads, and a big long list of all mutations should be generated. If any tasks are found to be already complete, they may be deleted from the list. If any incomplete tasks are found to be eligible, they may be picked off the list, and made the current active task. That eligibility function should continue to be called regularly on the active task too, just in case anything happens. Some effort should be made to prioritise this list of mutations in an intelligent way. Berries with lower ids should be prioritised. Where a berry has multiple possible mutations it may use, other factors may be used to prioritise them, eg. preferring parent berries which are faster to grow, or which do not spread.