aqualectrix
Member
You may want to see my implementation of quantities, but I'm not quite there yet.
I present for discussion a beginning of a refactor for PA, in the hopes that those who are scripting with it can tell me if this is the sort of thing they are looking for... or if I'm completely off base. I'm not rewriting advice for concoctions without knowing the base representations are better this time!
Looking at the to_executable_string() or to_readable_string() methods are probably good indications of how I am using the data in a pa_advice to construct everything that used to just be its action member. Having all that information broken out instead of stuck in a string makes a few things more complicated, but I hope it will make most others much easier since it gets rid of string parsing.
PARefactor deals only with autosell, mallsell, and smashing (not malusing, or concoctions, or using, or anything else). Quantity does not yet come into play, but since smashing does include expected results style output you can see what that will look like.
This will also give you a heads-up on many nomenclature changes. I don't actually delight in breaking scripts that use PA, but since I was changing the basic data structure anyway I decided to change a bunch of other stuff that I'd thought better of.
An easy way to visualize the executable-style output is to change print(pa_advice a) (line 284) to call to_executable_string() rather than to_readable_string().
Suggested alias for testing things:
alias par => ashq import <PARefactor.ash> print(all_advice($items[%%], true))
Re: quantities:
I propose that a basic pa_advice does not have a quantity -- i.e. has a quantity of 1 -- although it does store the quantity of its results. This is actually fairly necessary, as it enables caching... and as I discussed in my post about 1.6, PA really really needs its cache. (Okay, this early PARefactor doesn't, because it can't recurse very deeply, but eventually...)
I agree, however, that as much as possible of the mallbot-like silly behavior should be dealt with. Towards this aim, the functions that construct strings from pa_advice accept a quantity argument (although you'll notice they don't have any anti-mallbot-like behavior in them yet). Thus, the pa_advice will be constructed as an abstract, and when it is put into implementable form it will become smarter depending on the quantity it now knows about.
(Notify and version checking have been commented out in PARefactor. Anyone is welcome to download this and tell me what they think of it, but it is not a new version of PA yet!)
I present for discussion a beginning of a refactor for PA, in the hopes that those who are scripting with it can tell me if this is the sort of thing they are looking for... or if I'm completely off base. I'm not rewriting advice for concoctions without knowing the base representations are better this time!
Looking at the to_executable_string() or to_readable_string() methods are probably good indications of how I am using the data in a pa_advice to construct everything that used to just be its action member. Having all that information broken out instead of stuck in a string makes a few things more complicated, but I hope it will make most others much easier since it gets rid of string parsing.
PARefactor deals only with autosell, mallsell, and smashing (not malusing, or concoctions, or using, or anything else). Quantity does not yet come into play, but since smashing does include expected results style output you can see what that will look like.
This will also give you a heads-up on many nomenclature changes. I don't actually delight in breaking scripts that use PA, but since I was changing the basic data structure anyway I decided to change a bunch of other stuff that I'd thought better of.
An easy way to visualize the executable-style output is to change print(pa_advice a) (line 284) to call to_executable_string() rather than to_readable_string().
Suggested alias for testing things:
alias par => ashq import <PARefactor.ash> print(all_advice($items[%%], true))
Re: quantities:
I propose that a basic pa_advice does not have a quantity -- i.e. has a quantity of 1 -- although it does store the quantity of its results. This is actually fairly necessary, as it enables caching... and as I discussed in my post about 1.6, PA really really needs its cache. (Okay, this early PARefactor doesn't, because it can't recurse very deeply, but eventually...)
I agree, however, that as much as possible of the mallbot-like silly behavior should be dealt with. Towards this aim, the functions that construct strings from pa_advice accept a quantity argument (although you'll notice they don't have any anti-mallbot-like behavior in them yet). Thus, the pa_advice will be constructed as an abstract, and when it is put into implementable form it will become smarter depending on the quantity it now knows about.
(Notify and version checking have been commented out in PARefactor. Anyone is welcome to download this and tell me what they think of it, but it is not a new version of PA yet!)