Feature - Implemented Clip Art summons should be Creations

[Veracity]

We now have a summoning skill in which you can specify exactly what you want to get. In the Browser, it takes two steps to do that:

campground.php?preaction=summoncliparts (or via Skill menu, which redirects to that)

displays the screen of clip arts you can select from, the section of previous successful combos for quickly selecting three appropriate clips, and, once three clips have been selected, a "Say BALUNGO BALUÑO" button. Pressing that button will submit the following URL:

campground.php?action=bookshelf&preaction=combinecliparts&clip1=05&clip2=05&clip3=03&pwd

where clip1, clip2, and clip3 are (non-uniquely) selected from the following list:

01 = DONUT
02 = BOMB
03 = KITTEN
04 = WINE
05 = CHEESE
06 = LIGHT BULB
07 = SNOWFLAKE
08 = SKULL
09 = CLOCK
10 = HAMMER

The "action=bookshelf" results in the bookshelf being shown again after the summon.

I have not tried this, yet, but I suspect that for KoLmafia to use this internally, we can omit the initial call to campground.php?preaction=summoncliparts (since we don't need to look at the browser page to select clips) and can omit the action=bookshelf from the second call, making the whole action of summoning an item be:

campground.php?preaction=combinecliparts&clip1=05&clip2=05&clip3=03&pwd

We should implement the summonable items as creations, so that they appear on the Create/Food/Booze tabs of the Item Manager, are gettable via "acquire" or "retrieve_item()", and are automatically created, as needed, by "eat" and "drink" and such. This is how I think it could be done

- Add KoLConstants.CLIP_ART as a creation method.
- Create ClipArtRequest as a CreateItemRequest that uses campground.php?preaction=combinecliparts
- CampgroundRequest.registerRequest delegates to ClipArtRequest.registerRequest to log the creation, for preaction=combinecliparts
- CreateItem.createInstance generates a ClipArtRequest for the CLIP_ART mixing method
- ConcoctionDatabase recognizes CLIP_ART as a permitted method if you know the skill (KoLCharacter.canSummonClipArt) and the tomeSummons setting is < 3.
- concoctions.txt contains all clip art items with the CLIP_ART mixing method and NO ingredients (since the clips are not real items).
- ClipArtRequest internally maps each item to clip1, clip2, and clip3
- The concoctions for clip art items, although they have no ingredients, have a dynamically changing "creatable" amount which is the number of tome summons remaining today. Therefore, every time you summon from a Tome, if you canSummonClipArt, we need to update all clip art concoctions and refresh concoctions so that all the lists of creatables (Food, Booze, etc.) update

That's all that comes to mind, for the moment. The "fun" code is the new ClipArtRequest which converts a request to create an item into the appropriate URL, and which recognizes such a URL and logs it as a creation of the appropriate item. The rest is just hooking the class into the appropriate places such that scripts and the GUI can seamlessly use the clip art tome to create/summon the desired items.

 

[Veracity]

One additional twist: you get 3 Tome summons, period, per day, one of which is consumed for each CLIP_ART creation. If you queue up such a creation, the creatable amount of every other recipe that uses that mixing method needs to go down.

Fortunately, this is the exact situation that we have with using Nash Crosby's Still, and it can be handled in the same way. Take a look at ConcoctionDatabase.stillsLimit and ConcoctionDatabase.queuedStillsUsed to see how it's handled...

 

[jasonharper]

r9801 adds most of the infrastructure for this, although not the actual ClipArtRequest which makes it kind of useless at this point...

In particular, I've added a way to put numeric parameters in concoctions.txt, so there won't be any need to hard-code the clip patterns for each summonable item.

 

[lostcalpolydude]

That looks good. I was thinking that specifying them in ClipArtRequest would first require listing them all in ItemPool, and that seemed like the wrong way to approach it. Not that I had any hope of putting together a useful patch, I was just trying to see how much I could understand for the process.

 

[slyz]

I don't know anything about bitwise operations, so I'd rather make sure I understood the way clipart parameters are coded:

// Treat all-numeric element as parameter instead of item.
// Up to 4 such parameters can be given if each fits in a byte.
param = (param << 8) | StringUtilities.parseInt( data[ i ] )

To get the parameters back, I need to create four "masks" like this:

mask1 = 11111111000000000000000000000000 = 0xFF000000
mask2 = 00000000111111110000000000000000 = 0x00FF0000
mask3 = 00000000000000001111111100000000 = 0x0000FF00
mask4 = 00000000000000000000000011111111 = 0x000000FF

and I can get the separate parameters back simply by doing:

clip1 = param & mask1
clip2 = param & mask2
clip3 = param & mask3

Is this about right?

EDIT: I guess I'm missing a step, maybe the relevant bits should be shifted back to the right?

 

[slyz]

Another thought - shouldn't UseSkillRequest handle the actual casting? Something like

UseSkillRequest( final String skillName, Concoction conc )

would allow it to pull the parameters need to summon a Clip Art.

 

[jasonharper]

Two problems with your understanding:
* The three individual parameters end up in the areas specified by your mask2 thru mask4, not 1-3. Nothing gets shifted left far enough to be in the mask1 area.
* Everything other than the mask4 value has to be shifted to the right, to get the bits of the value back in the right place.

I'd personally do the shifting before the masking, which makes the mask always 0xFF, but that's really a matter of preference:

clip1 = (param >> 16) & 0xFF
clip2 = (param >> 8) & 0xFF
clip3 = param & 0xFF

 

[slyz]

Thanks!

 

[Veracity]

// Treat all-numeric element as parameter instead of item.
// Up to 4 such parameters can be given if each fits in a byte.
param = (param << 8) | StringUtilities.parseInt( data[ i ] )

You can invert it like this:

byte4 = (param >> 24 ) & 0xFF;
byte3 = (param >> 16 ) & 0xFF;
byte2 = (param >>  8 ) & 0xFF;
byte1 = (param >>  0 ) & 0xFF;

For these concoctions, exactly three bytes are stored, so you'd have:

clip1 = (param >> 16 ) & 0xFF;
clip2 = (param >>  8 ) & 0xFF;
clip3 = param & 0xFF;

...although order doesn't matter in the URL you submit.

Another thought - shouldn't UseSkillRequest handle the actual casting? Something like

UseSkillRequest( final String skillName, Concoction conc )

would allow it to pull the parameters need to summon a Clip Art.

I proposed a separate class when I thought there would be a big data table mapping item to parameters. Jason obviated that with his numeric parameter bitmask "concoction.param" feature. It could be in (or a subclass of) UseSkillRequest, I guess. But, the thing is, with the exception that it uses MP like a skill, it has a lot more in common with CreateItemRequest - which already has a CreateItemRequest( url, conc ) constructor.

Edit: Wow! Ninja'd big time. I like Jason's proposed code, though.

 

[Veracity]

I've added a way to put numeric parameters in concoctions.txt, so there won't be any need to hard-code the clip patterns for each summonable item.

Yes, but... in order for ClipArtRequest.registerRequest to recognize which item is being created from a given campground.php?preaction=combinecliparts URL so it can log "create Ur-donut", say, it will have to take to clip1, clip2, and clip3 codes, make a bit mask, and compare it to the "params" field of each clip art concoction. It has to find those concoctions.

Just so happens that, for now, the clip art concoctions are itemId #5224 - #5283. We can look up concoction by itemId.

Another wrinkle is that clip1, clip2, and clip3 are unordered; you can ask for donut, clock, kitten or clock, donut, kitten, or ... potentially 6 different permutations to get the same result. Either we have to generate all six bit masks and look for any match for each concoction or we normalize the concoctions such that, for example, the clips go in increasing order, from 1 to 10, and order the clip1, clip2, and clip3 fields from the URL to generate a similarly normalized bit mask, allowing a single comparison per concoction.

Or I suppose we could generate a hash table mapping all valid permutations to concoction or item name, but that seems like a lot of memory overhead at the expense of execution time for something which will done at most 3 times per character per day.

 

[jasonharper]

Why would it need to recognize the item being created? The successful cast of Summon Clip Art gets logged, the acquisition of the item gets logged on the next or previous line. This isn't like most creation methods, where the item HAS to be recognized in order to deduct the right ingredients from inventory.

 

[Veracity]

That's a good point.

I guess my sense of aesthetic tidiness would like to see it logged as "create xxx" - the command you could have typed into the CLI to do the summon - but, as you say, it's not necessary for keeping inventory correct.

Never mind. Let's go for the simplest and most expedient implementation, at this point.

 

[slyz]

Here is my current patch for this. I'm not submitting yet because I'm limited to 3 tests per day, and I want to make sure everything works first.

I ended up adding

UseSkillRequest getInstance( final String skillName, final Concoction conc )

so the proper URL is created by UseSkillRequest, and ClipArtRequest simply calls UseSkillRequest the correct number of times.

Registering, parsing and logging is done in CampgroundRequest and UseSkillRequest.

In the gCLI, we see

> acquire 1 bucket of wine

Creating 1 bucket of wine...
Casting Summon Clip Art 1 times...
You acquire an item: bucket of wine
Summon Clip Art was successfully cast.
Successfully created bucket of wine (1)

and in the session log, we simply see:

cast 1 Summon Clip Art
You acquire an item: bucket of wine

When casting via the Relay Browser, this is what we see in the gCLI:

You acquire an item: forbidden danish

and in the session log:

cast 1 Summon Clip Art
You acquire an item: forbidden danish

I still need to test the creation of several items at once.

 

[slyz]

I'm going to go ahead and submit the patch as it is. If anything comes up, I'll try to fix it quickly

EDIT: r9812

 

[Winterbay]

Works perfectly (for the one summon I've done today)

Can this be expanded to also work for sugar-items? "acquire 1 sugar shield" fails unless you precast to acquire 1 sugar sheet.

 

[slyz]

It seems to work as intended, even though I still haven't tested creating 2 of an item (but no-one has complained yet!).

The only drawback I see is the clutter of Clip Art food/booze in the Usable panels. Thoughts?

 

[Winterbay]

Well... You can realistically create 3 of them to eat/drink, but since it is probably not what most people want to do I guess it could be an idea to hide them. But OTOH it is also nice to be able to make my nightcap bucket of wine from there instead of having to create it from the CLI first...

 

[roippi]

The "no create" filter works, I guess.

I don't see a really good way of cleaning it up. Maybe it could be considered Not Free if a "require free crafting" filter gets implemented with Inigo's protection. I've made a few false starts at that code myself, but CreateItemRequest is complicated.

 

[Veracity]

The only drawback I see is the clutter of Clip Art food/booze in the Useable panels. Thoughts?

I see no drawback. It is working exactly the way I hoped: it shows me clipart food/drink, sorted into the appropriate place in the panel, complete with expected stats and status effect - and as soon as you have no more clip art summons left, the method is not available and the "clutter" is gone. You get precisely the same sort of "clutter" if you happen to have lunar isotopes and a transponder. Or, for that matter, Meat and NPC purchasing enabled, which shows mugcakes and fortune cookies from the gift shop and oranges from the hippy store and so on.

Do you consider all the new potions and equipment showing up on the Creatble tab to be "clutter"?

This patch shows you what your available consumption options are and lets you choose.

Well done.

 

[fronobulax]

It is working exactly the way I hoped:

+1 The presence in the various tabs helps me decide the best way for me to spend the summons at the moment. The strategy of summoning the most expensive item, mall selling it and then using the meat to buy something cheaper (rather than summoning it) is obviously of limited utility in Ronin or HC.

Well done.

+1 again. Thank you.