Item handling may become very difficult when fully automating a run. Deciding what to equip, buy, sell, create, smash, save, etc. will need to be handled some way.
Yes. I can see three equipment needs: 1) optimizing equipment in a general way as you acquire better items. 2) optimizing equipment for a specific purpose, such as item/meat farming. 3) equipping specific items to enable/unlock specific zones (i.e. putting on the correct outfit for a zone). This is not something we can just call "maximize" on, although that would make a decent temporary solution. Equipment changes seem like something best suited for a betweenBattleScript -- it would use a) goals and b) your current location to determine what to equip between battles:
- Equip the proper outfit / accessories for the specified zone and lock those slots.
- Try to ensure that you have a valid attack for killing monsters in the zone given your equipment. This would be iffy for spellcasters and should probably be toggle-able.
- If you are trying to get items that drop in the zone at a less than 100% rate, it would boost item drop.
- If you are trying to get an item that drops specifically from a choiceadv, try to decrease combat frequency.
- With remaining slots, maximize +stats / attack stat / meat / regen / whatever.
Unfortunately, there is no way to know in ASH if you have meat or choiceadvs as a goal, so before trying to get meat the script would have to call "maximize meat".
This betweenBattleScript could be expanded to include familiar/buff management as well. It would be friggin' awesome.
Either way, all of the forms of item handling that you mentioned, since they need to be adaptive, must be either a separate function in the script or a separate script entirely (betweenBattle would be best). However, there should be an "outfit" keyword to specify an equipping action since it might be necessary to equip an outfit before performing a non-adventuring action (where the bBB script is not called).
I've actually started work on an EatDrink spinoff that calculates adventures needed to create a given consumable in HC, and if it's efficient it will farm for ingredients as part of the feast-queueing process (before using any consumption helpers). Some of the logic here may be useful for the consumption section of this bytewise ascent script.
Speaking of a name -- I propose a naming contest. The contest for BatMan was great fun!
Play Style?
We all haive our own play style so with a collaboration of script writers our objectives may clash making the script difficult to optimize. You may want to think about a way to police this without upsetting people.
Yes -- but, arguably, if your goal is low turncount there is actually ONE optimal way to play the game at all times -- since it's all just numbers when you break it down. The optimal method will morph as the RNG injects its changes into your play and new content/items/familiars are introduced, but there's still only one way. So far, we've abstracted these numbers a great deal by giving them fantasy-world names like "eat food" and "adventure for an item" -- and we must maintain this not only because ASH does but also because it's useful. We've also mostly not designed algorithms capable of overlapping goals to maximize the numbers. I don't see this script doing that either -- but it looks like the closest thing I've seen yet to bare numbers. We've arrived at a middle ground by breaking the game first into quest chains and then from there into individual little actions. The logic of prioritizing the available actions is where the script will shine because it can calculate drop percentages, etc, between each adventure and change tactics as it goes. My recommended logic for that was described in the thread Doodle linked above.
My short answer: this will be far more optimal than anything yet existing, so playstyle is really a non-factor. Individual chains can be defined for just about everything, and users will be able to include / exclude any chain they choose from consideration. I think that's pretty dang user-friendly.
Structure?
Are you proposing that there will be a main script that calls other individual scripts based off of a list of data entries that act as pointers?
No. I have proposed a three-file arrangement:
1) The data file of actions, which will be pretty dang big and doesn't need to be sorted since every action can have its own ID number, which means it can be handily arranged by chain. Each action (which I'm envisioning as being a
very small piece of a quest, such as checking for text on a page, making sure you have X meat, or acquiring a single item) will include enough information that the script will have everything it needs to make the sorting decisions.
2) The script itself, which will interpret the data file, then sort and perform the available actions one by one, with a rebuild/resort after every action.
3) The betweenBattleScript -- which you have led me to believe is necessary -- which maintains moods / items / buffs contingent upon adventuring location / goals, and performs other item management.
Of course, you'll want a good CCS as well, but that's not specific to this script.
I would suggest that each contributing author should only submit one script with everything that they want to add to the project arranged by predefined ID numbers. This will keep this project from swelling to 100 files or more.
Something like this is a good idea. We should arrange the data file similarly to the way KoL defines skills in class-related ranges: all level 1 mandatory actions will be 1XXX (starting at 1000), level 2 mandatory actions will start at 2000 (achieving level 2 would itself be 2000), etc. Non-level-specific mandatory actions (such as unlocking the guild) could start at 20000. The LEW quest could start at 30000, with the 20XXX guild unlocks as prerequisites. The annoying gnomish moxie-sign quest could start at 60000 -- whatever, so long as there's a system for it.
