New Content - Implemented September IotM - bagged Cargo Cultist Shorts
- Thread starter Landamus
- Start date
Revision 20419 adds all the "cargo effect XXX" to statuseffects.txt as alternate ways to gain an effect.
This makes them show up in the maximizer. For example, when I tell it to maximize Monster Level, I see:
cast 1 Ur-Kel's Aria of Annoyance (30 mp, +52)
... or cargo effect 164 (+52)
The maximizer needs to be taught more about the "cargo" command - once per day, perhaps you've already picked all the pockets that provide the effect, etc.
That's also making me regret using the effect number, since - especially for effect that have no other source - it'd be nice to see what effect you are getting without having to look it up.
I guess I'll fix that.
This makes them show up in the maximizer. For example, when I tell it to maximize Monster Level, I see:
cast 1 Ur-Kel's Aria of Annoyance (30 mp, +52)
... or cargo effect 164 (+52)
The maximizer needs to be taught more about the "cargo" command - once per day, perhaps you've already picked all the pockets that provide the effect, etc.
That's also making me regret using the effect number, since - especially for effect that have no other source - it'd be nice to see what effect you are getting without having to look it up.
I guess I'll fix that.
Malibu Stacey
Active member
Maximizer is still listing cargo effects when you've already opened a pocket that day.
Also
It would be appreciated if that was updated with all these new parameters for the cargo command.
Also
Code:
> help cargo
cargo inspect | [pocket] - get status of Cargo Cult Shorts, or pick a pocket.It would be appreciated if that was updated with all these new parameters for the cargo command.
Last edited:
OK, I have refined and implemented the ASH functions - EXCEPT for pick_pocket(), which goes to KoL and manipulates the shorts.
I'd like to get some feedback on what I have - which gives full access to the Pocket Database, as well as sorting and selecting the "best" pocket for a desired goal - is what people need.
Here is the updated doc.
I did not add those typedefs to ASH, but use them in the doc to, hopefully, make it easier to understand.
I'd like to get some feedback on what I have - which gives full access to the Pocket Database, as well as sorting and selecting the "best" pocket for a desired goal - is what people need.
Here is the updated doc.
Code:
// Pocket types we support in ASH
// Pocket Data types
typedef int [ effect ] pocket_effects; // One or two effect => duration
typedef int [ item ] pocket_items; // One or two items => count
typedef int [ stat ] pocket_stats; // One, two, or three stats => substats
typedef string [ int ] indexed_text; // index => text
typedef int pocket; // Pocket number
typedef boolean [ pocket ] pocket_set; // Unordered set of pocket numbers
typedef pocket [ int ] pocket_list; // Ordered list of pocket numbers
// Functions to query pockets
pocket_set picked_pockets(); // Pockets picked this ascension
pocket_set picked_scraps(); // Demon name syallables found this ascension
pocket_set monster_pockets(); // All pockets with monsters
pocket_set effect_pockets(); // All pockets with effects
pocket_set item_pockets(); // All pockets with items
pocket_set stats_pockets(); // All pockets with stats
pocket_list meat_pockets(); // All pockets with meat, ordered by Meat
pocket_list poem_pockets(); // All pockets with poems, ordered by half-line
pocket_list scrap_pockets(); // All pockets with demon name syllables, ordered by number
monster pocket_monster( pocket p ); // The monster in the specified pocket
pocket_effects pocket_effects( pocket p ); // The set of effects in specified pocket
pocket_items pocket_items( pocket p ); // The set of items in specified pocket
pocket_stats pocket_stats( pocket p ); // The set of stats in specified pocket
indexed_text pocket_scrap( pocket p ); // The scrap => syllable in specified pocket
indexed_text pocket_poem( pocket p ); // The index => poem half-line in specified pocket
indexed_text pocket_meat( pocket p ); // The Meat => clue in specified pocket
pocket_list potential_pockets( monster m ); // List containing single pocket containg the specified monster
pocket_list potential_pockets( effect e ); // List of pockets containg effect; inverse ordered by effect duration
pocket_list potential_pockets( item e ); // List of pockets containg item; inverse ordered by item count
pocket_list potential_pockets( stat s ); // List of pockets granting stats; inverse ordered by substats
// Functions to speculate about pockets. Return 0 if no unpicked pocket
// provides desired result. Equivalent to "cargo?" command
pocket available_pocket( monster m ); // Unpicked pocket containing monster
pocket available_pocket( effect e ); // Unpicked pocket containing effect
pocket available_pocket( item i ); // Unpicked pocket containing item
pocket available_pocket( stat s ); // Unpicked pocket containing stat
// Functions to pick pockets
boolean pick_pocket( pocket p ); // Pick specified pocket number
boolean pick_pocket( monster m ); // Pick pocket containing monster.
boolean pick_pocket( effect e ); // Pick pocket containing effect
boolean pick_pocket( item i ); // Pick pocket containing item.
boolean pick_pocket( stat s ); // Pick pocket containing stats.
I'm not sure what this is - a feature request, opportunity to manage my expectations, something already on the ToDo list or what.
I ran the Maximizer on a character in HC who does not have the shorts. I was surprised to see effects listed and they were black, not gray'd out. Since I had not checked "Show all, effects with no direct source, skills you don't have, etc'" and was willing to include "items you don' have access to" in the "etc." this was a surprise.
Thinking about it, I do use Maximizer settings to be reminded of things I could buy (or pull from my DC if I remember they are there) so I am OK with seeing shorts effects. But I can maximize for Adv and not get told about the Nuge's Crossbow so I feel like there is an opportunity for consistency. In general if an effect comes from an item that I do not have and cannot be reasonably expected to obtain I would like not to know about it with my usual Maximizer settings.
Thanks.
I ran the Maximizer on a character in HC who does not have the shorts. I was surprised to see effects listed and they were black, not gray'd out. Since I had not checked "Show all, effects with no direct source, skills you don't have, etc'" and was willing to include "items you don' have access to" in the "etc." this was a surprise.
Thinking about it, I do use Maximizer settings to be reminded of things I could buy (or pull from my DC if I remember they are there) so I am OK with seeing shorts effects. But I can maximize for Adv and not get told about the Nuge's Crossbow so I feel like there is an opportunity for consistency. In general if an effect comes from an item that I do not have and cannot be reasonably expected to obtain I would like not to know about it with my usual Maximizer settings.
Thanks.
Revision 20425 implements the following:
The jokes are for completeness; that is the only pocket content from PocketDatabase not previously exposed to ASH.
I will be surprised if any script uses them.
pick_pocket() attempts to pick either the specified pocket or the "best" pocket that delivers the desired monster, effect, item, or stat.
I haven't tested what happens with a monster - either from "cargo monster MONSTER" or "pick_pocket( $monster MONSTER ] )".
I believe it should do between battle checks - restore, moods, etc. - and then pick the pocket and automate the fight.
Assuming that works as intended, I think the only thing left is to teach the Maximizer about the "cargo" command; I haven't touched the Maximizer yet for this feature and cargo commands showing up there is simply a side effect of adding said commands to statuseffects.txt as a way to generate the effect.
Code:
pocket_set joke_pockets(); // All pockets which contain a joke
string pocket_joke( pocket p ); // The joke in the specified pocket
boolean pick_pocket( pocket p ); // Pick specified pocket number
boolean pick_pocket( monster m ); // Pick pocket containing monster.
boolean pick_pocket( effect e ); // Pick pocket containing effect
boolean pick_pocket( item i ); // Pick pocket containing item.
boolean pick_pocket( stat s ); // Pick pocket containing stats.I will be surprised if any script uses them.
pick_pocket() attempts to pick either the specified pocket or the "best" pocket that delivers the desired monster, effect, item, or stat.
I haven't tested what happens with a monster - either from "cargo monster MONSTER" or "pick_pocket( $monster MONSTER ] )".
I believe it should do between battle checks - restore, moods, etc. - and then pick the pocket and automate the fight.
Assuming that works as intended, I think the only thing left is to teach the Maximizer about the "cargo" command; I haven't touched the Maximizer yet for this feature and cargo commands showing up there is simply a side effect of adding said commands to statuseffects.txt as a way to generate the effect.
Thanks. I'm just ahead of you.
Revision 20427 improves the help message for the cargo command:
This might be the first multi-line help message I've seen for a command.
I also added a new (final?) ASH function:
So, although the pocket database has a whole mess of categories, the full set of objectively different pocket types are these:
"joke" and "restoration" pockets are also "effect" pockets - and therefore appear in the list of such - with an extra feature.
All the other internal categories - Yeg, Bell, Candy2, whatever - could be useful if you wanted to look at a subset of items or effects iusing the "cargo" command, but in an ASH program, you can categorize (or not) as you choose. You don't have to use my (internal) design choices.
This might really be the end of stuff to do before I grit my teeth and dive into the Maximizer.
Code:
[color=green]> help cargo[/color]
cargo[?] # | monster MONSTER | effect EFFECT | item ITEM | stat STAT - pick pocket from your shorts
cargo pocket # - describe contents of specified pocket
cargo count ( type TYPE | monster MONSTER | effect EFFECT | item ITEM | stat STAT ) - count matching pockets
cargo list ( type TYPE | monster MONSTER | effect EFFECT | item ITEM | stat STAT ) - list matching pockets
cargo inspect - check which pockets you've picked
cargo demon - check which demon name syllables you've collected
cargo - list which pockets you've picked so far during this ascensionI also added a new (final?) ASH function:
Code:
pocket_set restoration_pockets(); // All pockets which contain grant full HP/MP restore
Code:
pocket_set monster_pockets(); // All pockets with monsters
pocket_set effect_pockets(); // All pockets with effects
pocket_set item_pockets(); // All pockets with items
pocket_set stats_pockets(); // All pockets with stats
pocket_list meat_pockets(); // All pockets with meat, ordered by Meat
pocket_list poem_pockets(); // All pockets with poems, ordered by half-line
pocket_list scrap_pockets(); // All pockets with demon name syllables, ordered by number
pocket_set joke_pockets(); // All pockets which contain a joke
pocket_set restoration_pockets(); // All pockets which grant full HP/MP restoreAll the other internal categories - Yeg, Bell, Candy2, whatever - could be useful if you wanted to look at a subset of items or effects iusing the "cargo" command, but in an ASH program, you can categorize (or not) as you choose. You don't have to use my (internal) design choices.
This might really be the end of stuff to do before I grit my teeth and dive into the Maximizer.
Rinn
Developer
Are these return types for pick_pocket() intentional for effect item & stat? Your last post where you mentioned them stated they all return boolean values:
Code:
> ashref pick_pocket
boolean pick_pocket( monster )
int [effect] pick_pocket( effect )
int [item] pick_pocket( item )
int [stat] pick_pocket( stat )
boolean pick_pocket( int )Yeah, I decided that they all return a "continue value" - true if it succeeded, and false - and an error condition which you must "capture" - if it failed.
We can discuss that, but if you want the original versions, you can do something like this:
If you don't care about the specifics, just that it gets the "best" pocket with the effect, item, or stat you specified, you can use pick_pocket() directly.
I originally was going to parse the results on success to get the effect, item, or stats map, but that seemed a lot of work.
On the other hand, stats can vary, based on experience and experience percent modifiers, so just looking at the base stats for the pocket is not accurate; you'd have to save the original substats for each stat and compare to what they are after opening the stats pocket.
I'm open to suggestions. How ere you intending to use this? And how are others intending to use it?
We can discuss that, but if you want the original versions, you can do something like this:
Code:
int ep = available_pocket( $effect[ The Halls of Muscularity ] );
if ( pick_pocket( ep ) ) {
int [effect] items = pocket_effects( ep );
}
int ip = available_pocket( $item[ star ] );
if ( pick_pocket( ip ) ) {
int [item] items = pocket_items( ip );
}
int sp = available_pocket( $stat[ muscle ] );
if ( pick_pocket( sp ) ) {
int [stat] stats = pocket_stats( sp );
}I originally was going to parse the results on success to get the effect, item, or stats map, but that seemed a lot of work.
On the other hand, stats can vary, based on experience and experience percent modifiers, so just looking at the base stats for the pocket is not accurate; you'd have to save the original substats for each stat and compare to what they are after opening the stats pocket.
I'm open to suggestions. How ere you intending to use this? And how are others intending to use it?
Something like this:
Code:
int [stat] my_pick_pocket( stat s )
{
int muscle = my_basestat( $stat[ SubMuscle ] );
int mysticality = my_basestat( $stat[ SubMysticality ] );
int moxie = my_basestat( $stat[ SubMoxie ] );
int stat[] result;
if ( pick_pocket( s ) ) {
result[ $stat[ muscle ] ] = my_basestat( $stat[ SubMuscle ] ) - muscle;
result[ $stat[ mysticality ] ] = my_basestat( $stat[ SubMysticality ] ) - mysticality;
result[ $stat[ moxie ] ] = my_basestat( $stat[ SubMoxie ] ) - moxie;
}
return result;
}Well, good news and bad news for automating monster pockets.
I shrugged the buff which was in my mood.
I asked to pick a monster pocket.
It perfomed my between battle checks - moods, restoration (if needed), etc. - before visiting the cargo shorts and pulling out a monster. That's good.
It logged the "location" - Cargo Cultist Shorts - with a turn number - which is good, since one likes to know which turn fights happen on.
It did NOT automate the fight. That's not good; this should be a typical choice redirects to a fight.
Code:
[color=green]> shrug Phat Loot[/color]
Shrugging off your buff...
Fat Leon's Phat Loot Lyric removed.
[color=green]> cargo monster smut orc pervert[/color]
Pockets loaded: 666
Pockets categorized: 666
Casting Fat Leon's Phat Loot Lyric 1 times...
You acquire an effect: Fat Leon's Phat Loot Lyric (20)
Fat Leon's Phat Loot Lyric was successfully cast.
Inspecting Cargo Cultist Shorts
picking pocket 666
[8763] Cargo Cultist Shorts
Encounter: smut orc pervert
Round 0: Veracity wins initiative!
[color=green]> ashq run_combat()[/color]
Round 1: Veracity executes a macro!
Round 1: Veracity attacks!
Round 2: smut orc pervert takes 1954 damage.
Round 2: Veracity wins the fight!
After Battle: The little orphan girl frisks your fallen opponent for candy, and weirdly enough she finds some. Her dance of joy brings a smile to your face.
After Battle: You gain 37 hit points
After Battle: You gain 31 Mojo Points
You acquire an item: smut orc keepsake box
After Battle: You gain 10 Strengthliness
After Battle: You gain 6 Enchantedness
After Battle: You gain 24 Smarm
This combat did not cost a turnI asked to pick a monster pocket.
It perfomed my between battle checks - moods, restoration (if needed), etc. - before visiting the cargo shorts and pulling out a monster. That's good.
It logged the "location" - Cargo Cultist Shorts - with a turn number - which is good, since one likes to know which turn fights happen on.
It did NOT automate the fight. That's not good; this should be a typical choice redirects to a fight.