New Content - Implemented Rethinking Candy

[Veracity]

Revision 17613 does some of Phase 2 and the rest of Phase 3. It also corrects the candy types for a couple of candies; I was wondering why my generated candy pairings were not identical to those shown by Ezandora's tool, and it turns out we had a candy1 listed as a candy2 and a candy2 listed as a candy1. There might be other data errors.

1) ASH function:

effect sweet_synthesis_result( item candy1, item candy2 )

[color=green]> ash sweet_synthesis_result( $item[ Yummy tummy bean], $item[ Yummy tummy bean ] )[/color]

Returned: Synthesis: Hot
default =>
note =>
all => aggregate boolean [string]
image => https://s3.amazonaws.com/images.kingdomofloathing.com/itemimages/molecule1.gif
descid => 70c1f50c4b1f77c7a6b2770d368a8392
candy_tier => 1

2) ASH function:

item [int] sweet_synthesis_pairing( effect result, item candy1 )

[color=green]> ash sweet_synthesis_pairing( $effect[ Synthesis: Hot ], $item[ Yummy Tummy bean ] )[/color]

Returned: aggregate item [11]
0 => pink candy heart
1 => Piddles
2 => Yummy Tummy bean
3 => delicious candy
4 => cotton candy pinch
5 => fudgecule
6 => Tasty Fun Good rice candy
7 => jabañero-flavored chewing gum
8 => Comet Pop
9 => green gummi ingot
10 => cotton candy bale

3) ASH function:

boolean sweet_synthesis( item candy1, item candy2 )

[color=green]> ash sweet_synthesis( $item[ Yummy tummy bean], $item[ Yummy tummy bean ] )[/color]

Encounter: Sweet Sythesis
synthesize Yummy Tummy bean, Yummy Tummy bean
You acquire an effect: Synthesis: Hot (30)
Returned: true

Here's what the session log shows for that last one:

cast 1 Sweet Synthesis
Encounter: Sweet Sythesis
synthesize Yummy Tummy bean, Yummy Tummy bean
You acquire an effect: Synthesis: Hot (30)

Yes, KoL's name for that choice page is "Sweet Sythesis".

It successfully deducted the two candies from inventory and added one to spleen. Of course, considering it immediately followed up with a call to api.php to get status, it would have gotten that anyway.

Work remaining:

Data:

None known

ASH:

None, modulo suggestions, etc. Perhaps we will want "boolean sweet_synthesis( effect result )", as part of Phase 5, to obviate "cli_execute( "synthesize EFFECT" )".

GUI:

Synthesize pane in the Item Manager as previously described

CLI:

synthesize CANDY1, CANDY2
synthesize? CANDY1, CANDY2
synthesize EFFECT
synthesize? EFFECT

I'll probably do the GUI next.

 

[Veracity]

Revision 17614 adds the GUI. The Synthesize! is not hooked up yet, but I wanted to get this out so that people could try out and comment on the User Interface. You can find it on the "Tools" menu.

You select a desired effect and are given a list of Candy A candidates.
You select one and are given a set of Candy B candidates.
You select one and the Synthesize! button is enabled.

Sorting rule for the candy lists:

In Ronin or Hardcore, from most to least available to acquire.
Otherwise, from cheapest to most expensive mall price, most to least available, if equal, alphabetical otherwise.

Some candy is not mallsellable. Some is not autosellable. For now, I just sort all those to the end.

Comments welcome & desired.

 

[Xande1]

I really like the proposed synthesis UI, Veracity. I'd love to give constructive feedback, but I can't yet think of anything I'd want done differently. It looks great.

EDIT: OK, one tiny thing: Muscle memory says the Modifier Maximizer is the last thing in the Tools menu. I could get used to the change, but I'd have less adjusting to do if Sweet Synthesis was moved up a spot or two.

 

[AlbinoRhino]

I like it ! Well done, as usual !

 

[Bale]

Revision 17614 adds the GUI. The Synthesize! is not hooked up yet, but I wanted to get this out so that people could try out and comment on the User Interface. You can find it on the "Tools" menu.

Nice! Friendly!

The only thing I could suggest is to add an "automatic" button to automatically find a cheapest combination of candy.

 

[Boesbert]

Minor display bug: Selecting a candy from the Sweet Synthesis UI in the left pane and then trying to sort by either "have" or "price" makes both panes blank. Right pane works normally.

 

[fronobulax]

I like it. Trying to sort resulted in blank columns for me as well. I'm trying to make a case that I want some filters but if I actually learn the criteria used to include something in either list then I suspect that I can accomplish the same things with a good sort. I'm not completely sure I understand the new candy mechanics but to the extent that they generate effects that last a variable number of turns some kind of cost per turn display would be useful.

Thank you.

 

[heeheehee]

Looks neat / potentially useful, at a glance. I especially like how the sort order for each candy panel is preserved as you move around (although I'd guess without having looked closely at the code that's an artifact of how you're reusing the same Swing panels). Couple of display bugs I noticed:

- If you click around on the sections up top that determine the target effect, buttons remain depressed -- you change focus, but that's it. I'm not sure if this is some quirk with my display manager, or if other people are also seeing this.

- To elaborate on Boesbert's comment -- it's actually any header, including the candy name. Sorting the left column before selecting a candy works fine.

No DEBUG logs were generated for either of these.

In-run, I imagine I'd like to filter based on items in inventory, as opposed to all items, although I'm not sure if there's room in the UI for checkboxes (or however else you might want to implement it). Quantity sort is probably a decent proxy, but here's an edge case for you: suppose I have 30 different items that have ID % 5 == 0 and two of one item with ID % 5 == 2 (let's say... angry farmer candy), and I'd like to see how I can get the sleaze resistance effect (i.e. (A + B) % 5 == 4). It'd be great if only the relevant item showed up, so I wouldn't have to click through each of the items until I found the one I wanted.

Follow-on to that: would be nice if effects I can't currently obtain were greyed out (maybe if the suggested "only use available" checkbox were checked).

I noticed that non-mallsellable (which includes gift) items show up as Integer.MAX_INT.

 

[ckb]

EDIT: OK, one tiny thing: Muscle memory says the Modifier Maximizer is the last thing in the Tools menu. I could get used to the change, but I'd have less adjusting to do if Sweet Synthesis was moved up a spot or two.

I thought this was a weird request, until I did the same thing three times today. So +1 for moving it up a spot.

 

[Veracity]

1) The problem with clearing windows clearing when you sorted a column in Candy A was a result of two issues:

- I got multiple ListSelectionEvents, one of which was "no selection" - and I erroneously cleared Candy A and Candy B.
- All but the first event were getValueIsAdjusting() == true, and I only should process on the final event.

Apparently, sorting clears the selection, sorts, and then reselects the same item in its new spot. This is fixed by only looking at events where the value is no longer adjusting. And clearing Candy A when deselecting an item in it is not correct, anyway.

2) I am happy to move the Sweet Synthesis tool up one in the tools menu.

3) The intended behavior of the top buttons was this:

- If you press one, the background goes dark as an indication that the button is pressed.
- If you then press another one, the first one is restored and the second one is pressed.
- If you press the same button again, the background is restored and none is pressed.

Ideally, I wanted the button color and text color to reverse when the button was pressed, but on a Mac, apparently, only the part outside the border will be colored. Googling revealed a solution, but it was not clear if it works on Windows. I have attempted an implementation which might work for both.

Here is how my frame looks with no effect selected:



And here is how it looks with an effect selected:



Revision 17615 has all of those.

I'm going to go hook up the Synthesize! button and then come back to respond to your other comments.

 

[Veracity]

P.S. Somebody with Windows and/or Linux please tell me how the effect buttons look for you now.

 

[heeheehee]

Appearance is now consistent with your posted image (as opposed to the old behavior).

 

[heeheehee]

Actually, it looks like you have a fixed height for the candy panels, which ends up creating a lot of unused space if the frame is taller than the default (as my tiling window manager will often cause to be the case).

 

[Veracity]

Revision 17616 hooks up the Synthesize! button. It also fixes a bug in the SweetSynthesisRequest: we were always combining candy1 and candy1, rather than candy1 and candy2. Oops.

When you successfully synthesize, the Frame now updates the Candy 1 and Candy 2 panels on the right with the current "count" and "cost" fields. It does not update the candies in the candy lists - which presumably might require resorting.

Regarding the fixed height - yeah. The issue was that if I didn't give them a height, when you opened the frame initially (with no candies in the lists), it made the frame really short - the candy lists were big enough to show zero lines.

I need to find a better solution.

I realize there are unanswered comments from several of you. I also need to have dinner. More later.

 

[fronobulax]

17621

Sweet Synthesis does not appear as thing that can be added to a tab on startup.

The effect button changes to black on a Windows 10 box when pressed. Text is no longer readable.

Before and After pressing a button.

 

[Veracity]

The only thing I could suggest is to add an "automatic" button to automatically find a cheapest combination of candy.

I suppose. I think that's sort of a "Phase 5" thing. I'll add it to that list.

I'm trying to make a case that I want some filters but if I actually learn the criteria used to include something in either list then I suspect that I can accomplish the same things with a good sort.

I see two possible filters:

- Inventory only
- Standard-compliant only

Both would be useful only in-run.

The first can be obtained by sorting on -count (the default in-run) and choosing to not look at anything with a count of 0. However, showing others would help you understand which you might adventure for or pull - not that either is necessarily that useful.

The second should be the default; if you are in a Standard-compliant run, it should simply not include restricted items in the lists. That applies for the ASH interfaces, too; unless you are running a script - in run - which will analyze aftercore possibilities, all you want/need is things you can use right now.

Given that, I think we don't need filters.

I'm not completely sure I understand the new candy mechanics but to the extent that they generate effects that last a variable number of turns some kind of cost per turn display would be useful.

The effects last 30 turns.

I considered a "Total" box beneath Candy A and Candy B in the right column which would have the total cost/value. I suppose a "per turn" figure would go there too.

In-run, I imagine I'd like to filter based on items in inventory, as opposed to all items, although I'm not sure if there's room in the UI for checkboxes (or however else you might want to implement it). Quantity sort is probably a decent proxy, but here's an edge case for you: suppose I have 30 different items that have ID % 5 == 0 and two of one item with ID % 5 == 2 (let's say... angry farmer candy), and I'd like to see how I can get the sleaze resistance effect (i.e. (A + B) % 5 == 4). It'd be great if only the relevant item showed up, so I wouldn't have to click through each of the items until I found the one I wanted.

Yeah, OK. There is room for a row of checkboxes between the effect buttons and the Candy tables.

We're in the realm of pre-analyzing candy combos here, rather than letting the user manually choose one from column A and one from column B. Guided help in making that decision.

Follow-on to that: would be nice if effects I can't currently obtain were greyed out (maybe if the suggested "only use available" checkbox were checked).

Ditto.

I'd put both of those into "Phase 5".

I noticed that non-mallsellable (which includes gift) items show up as Integer.MAX_INT.

This was a conscious decision, which we can discuss.

Those are all items that you either have to farm/create on your own or happen to already have. I don't know how to value them in comparison to items that you can just buy in the mall. My initial thought was to use autosell price in that case - and a Candy object as seen in the table has an "autosell" field, should we care to use it - but there are some no-trade no-discard items which would sort to the top of the cost column.

I initially made my Comparator sort no-trade items to the bottom, but if you then sorted on a column, they would pop back up again. My "solution" to that was to cost them at MAX_INT, as you noticed so they stay at the bottom.

I think I'm OK with that, until somebody comes up with a reason you'd want to prefer a sugar chapeau over some random other candy you also have in inventory.

Actually, it looks like you have a fixed height for the candy panels, which ends up creating a lot of unused space if the frame is taller than the default (as my tiling window manager will often cause to be the case).

Right. I need to figure this out. I'd like the candy tables to have some (suggested) minimum height - in table rows, ideally - which would be used to initially size the window, but if you make the window taller, they will go all the way down to the bottom. I don't know how to do that yet, but, how hard can it be? (Famous last words from somebody who's never done any sort of GUI work except on this program.)

-----------

Given all of the above

1) Make the Candy panels variable height with a minimum
2) Add a Total box in the right showing total cost and cost/30 (i.e., cost per turn of effect.
3) Don't show restricted candies when in a standard-compliant run.

Phase 5:

1) "Automatic" button to load and select a minimum cost pairing for a particular effect.

In-run filtering:

2) Pre-analyze candy combos and filter out candies which will not combine with things you have to get the selected effect
3) The above and grey-out effects you can't currently get at all

 

[Veracity]

Sweet Synthesis does not appear as thing that can be added to a tab on startup.

It's really wide. As a tab, it makes everything else wide. However, I added it to the list of windows you can either put in a tab or startup as a window.

The effect button changes to black on a Windows 10 box when pressed. Text is no longer readable.

Not that I can test this, but I have a fix. I hope.

Revision 17622 should fix those and also allow the Candy lists to shrink and grow to fill entire available height of frame.

 

[fronobulax]

r17622

Synthesis showed up as an option to start up in a tab but when I did so, shut down and restarted mafia, the tab did not appear. I will retry later tweaking existing sizes - maybe the space left to render was too small to have it actually appear for my settings?

Sadly, the button, when selected remains black with no visible text. Not sure I will get a chance to look at code and debug on a Windows box today.

 

[Veracity]

I'm reconsidering filters (checkboxes).

If we have an "available" checkbox, which will show only candies you have,

- The Candy A lists will be much smaller
- The Candy B list will be empty if you can't get the desired effect with the selected Candy A

That would make it a lot easier to simply click through Candy A until SOMETHING appears in Candy B.

This checkbox would be checked in-run, but you could uncheck it if you wanted to see options which you could farm or pull.

A single checkbox is sort of dumb. I might want a "unrestricted" checkbox, checked by default if you are in a Standard-style run. But it would be more useful to not even have unusable candies in the list, if you are in such a run. The only use would be for me to look, in aftercore, what the lists look like if restricted candies are filtered out.

I might make primitives to return candy sets with one or the other of those flags set, which would make it possible to enable/disable individual effect buttons. Once I do that, I'll also need to set up a listener to detect candy entering/leaving inventory so I can enable/disable effect buttons as needed.

 

[Veracity]

Revision 17623 adds two checkboxes to filter candy lists.

available - only items for which "have" is greater than 0
unrestricted - only items which are currently allowed in Standard.

The former defaults to true in-run.
The latter defaults to true if in a run with Standard restrictions.

This was fairly complicated - and it is still not quite right. I use the LockableListModel's ability to filter and hide or show items based on a isVisible method. And if you do it on a list with nothing selected, it works well. But if you have an item selected and it removes items in front of it, it may lose the selection. Or it may keep it. Or it may move it to a different item.

Obviously, that is unacceptable. I will look at it tomorrow. In the meantime, check your desired filters before selecting candies.