New Content - Implemented Tome of Clip Art

[lostcalpolydude]

That is not true, never has been true, and can't be true. Otherwise you couldn't search for "sword" or "Pok" or whatever and see the prices for all swords or all Pokemann cards, for example.

That only works because mafia knows about 2 or more items with that in the name. I tried searching for "time halo" and mafia ignored the request even though it worked in the relay browser. A search for "halo" forced a search for "snow halo" (unrelated to the new IotM). Once I made a frosty halo and mafia knew there were 2 items with "halo" in the name, I could search for "halo" and get mafia to discover all of them.

 

[Veracity]

I tried searching for "time halo" and mafia ignored the request even though it worked in the relay browser.

So, file a bug report.

Revision 9789 adds all the clip art items. I found them with three mall searches: "a", "e", and "o".

 

[Bale]

Overrides data was totally not happening when I did mall searches! (Override data totally did apear when an item was in my inventory.) I'm not about to get worked up about why it did not happen for me though since all the items are now in the data.

 

[fronobulax]

Since it is distressing to see lost and Bale contradicting veracity, is there any chance there is not a shared definition of "overrides"?

My understanding is that mafia finds out something new, logs "Unknown item found" and some other data to the gCLI and then retains that data internally for use until mafia is shut down. I call this "overrides". This is different from older behavior where the discovered data was written to a file and persisted when mafia was shutdown and restarted.

r9788 behaves as I described so if there is not a definitional problem then there is probably something in common with veracity's and my environment that is not in lost's or Bale's?

 

[lostcalpolydude]

I'm not talking about creating overrides, I'm talking about mafia not doing the mall search in the first place (so it didn't see the items to generate overrides). Once I was able to do the mall search I wanted (by making mafia aware of a second halo item through other means), overrides were generated as expected.

A more broad mall search like veracity suggests would have worked also.

 

[Bale]

My understanding is that mafia finds out something new, logs "Unknown item found" and some other data to the gCLI and then retains that data internally for use until mafia is shut down. I call this "overrides". This is different from older behavior where the discovered data was written to a file and persisted when mafia was shutdown and restarted.

This. There was no info printed in the CLI about the item seen. The info was printed when teh item was in my inventory.

 

[Winterbay]

FWIW I can reproduce lost's problem. I have a time halo in my inventory and can search for halo and it generates overrides for the other halos. If I however search for "unbearable" (as in "unbearable light") I don't even get an attempt at a search (or for that matter if I do a search for the entire name).

Doing a search in the relay browser works, but no override is generated from that.

Edit: This with version 9788.

 

[fronobulax]

OK.

A successful mall search is generating data about unkowns since I do not have any ToCA items in inventory but I am seeing the CLI info with r9788.

Following winterbay's lead, I did search for unbearable from Purchases. I tried unbearable, unbearabl, unbeara and so on with no results until I got down to unb at which point it found unbearable light and generated an override. I won't speculate as to what mafia was doing without looking at the code but it does seem as if there is something worthy of investigation here.

 

[Veracity]

I'm not talking about creating overrides, I'm talking about mafia not doing the mall search in the first place (so it didn't see the items to generate overrides).

I never doubted you. I did a search for "lostcalpolydude", no search was submitted, and I said:

So, file a bug report.

It's nice that so many people later tried to reproduce it, but, considering that I had already done so and requested a bug report, that was fairly redundant.

 

[roippi]

It looks like unb is the first nonspecific match of items known by mafia at the time:

> acquire? unb

uncle jick's brownie mix
unstable laser battery

[unb] has too many matches.

> acquire? unbe

[unbe] has no matches.

I suspect the issue is that in order to perform a mall search that matches a new item, the input must be a string that ambiguously matches more than one item already known by mafia. I believe (without looking at the code) behavior goes: if it is a unique match to a known item, it does an exact search for that item; if it is an inexact match to items, it does the search as entered; if it is not a match for any known items it does not perform the search.

I'm not sure that issue needs a fix, since it is a feature to cull unnecessary server hits from mistyped searches.

 

[fronobulax]

I skimmed the code and roippi seems pretty close to my understanding. I'm trying to figure out what the bug report or feature request should be.

Mafia should allow mall searches for arbitrary strings, whether they are likely to match a known item or not.

If that is the FR then I'm not sure there is any benefit to implementing it. It allows mall searches for "undiscovered" items but at the cost of unnecessary server hits if there are no undiscovered items.

 

[Veracity]

With revision 9795, I'm close to having the "easy" stuff taken care of. Here's a comment from CampgroundRequest.registerRequest that gives the necessary info for someone to implement ClipArtRequest as a creation method:

		// campground.php?pwd&action=bookshelf&preaction=combinecliparts&clip1=05&clip2=05&clip3=03
		// 01 = DONUT
		// 02 = BOMB
		// 03 = KITTEN
		// 04 = WINE
		// 05 = CHEESE
		// 06 = LIGHT BULB
		// 07 = SNOWFLAKE
		// 08 = SKULL
		// 09 = CLOCK
		// 10 = HAMMER

		if ( action.equals( "combinecliparts" ) )
		{
			// Eventually somebody will claim and parse this
			RequestLogger.updateSessionLog( urlString );
			return true;
		}

I'd like to finish the following and pass the baton:

- Add the status effects that you get from consuming clip art food and booze
- Pay the mana cost for combining when you actually submit the "preaction=combinecliparts".

I added completely wild consumption data - taken from the Wiki and modified to my taste - for the food or booze. Obviously, that will need refinement, by and by.

And the "clip art as a create method" project remains. I added KoLCharacter.canSummonClipArt(), which will be useful to determine if it's an allowed method. The other half of that will be whether you have any tome summons left today - and the "creatable amount" for any clip art concoction will be the number of tome summons left today.

I'm tempted to finish the two things I mentioned and roll a new release. Things seem relatively stable right now and I'd like to capture that in a point release.

And then, when somebody does the clip art creation method and the new KoLCon donation item is supported, we could even roll another release, mere weeks later.

 

[mstieler]

Not sure if this should go here or as a feature request, since this is currently being worked on:

Can we get the created Clip Art summons (in the Relay Browser at least, not sure how it would function in the main Mafia interface though you guys seem to be working on that) to be either sortable or auto-sorted by some parameter, whether "most summoned", alphabetically, grouped by type, or something else?

 

[roippi]

Not sure if this should go here or as a feature request, since this is currently being worked on:

Can we get the created Clip Art summons (in the Relay Browser at least, not sure how it would function in the main Mafia interface though you guys seem to be working on that) to be either sortable or auto-sorted by some parameter, whether "most summoned", alphabetically, grouped by type, or something else?

That sounds like work for a relay override. It's also pretty likely that enough people will clamor for KoL to do this natively that it will get fixed.

 

[Veracity]

In my opinion, as of 9799, we have completed the minimum necessary for this new content:

- we have all the new items and status effects
- we have (most likely bogus) consumption data for the new food and drink, so they show up on the Food and Booze tabs, at least.
- we recognize the presence of the tome on the bookshelf
- we recognize casting the skill from the Relay Browser: both the initial "cast skill" from the bookshelf or skills menu, and the actual summoning of the item after selecting three clips. We only deduct MP in the latter case and only on a successful summon.
- we increment daily Tome uses for successful summons.

And that is probably enough of "have to have sooner rather than later" for this IOTM.

This thread has gotten sidetracked into discussion of mall searches (now their own Feature Request). Additionally, my ideas for how to make summoning easier by turining it into a creation method have gotten buried. Therefore, I have moved - and expanded upon - those ideas and placed them in their own feature request. Hopefully they can be discussed there - and somebody other than me can implement them.

Since I think we are otherwise done with this New Content, I am marking this Implemented.
Bugs in what we have implemented can be logged as - gasp - Bugs. Exception: we know the consumption data has to be wrong. There has just not been sufficient spading, yet. Please hold off on saying "Ur-donut is wrong" and "such-and-such a wine is wrong" and so forth. Perhaps we need another New Content thread to track that - with the expectation that they will all be fixed at once, eventually.
Suggestions on how we can do things better can be logged as Feature Requests - or can use the existing Feature Request for summons-as-creations, if appropriate.