New Content - Implemented Folder Holder: August's back to school IotM!

lostcalpolydude said:
I haven't figured out how to work with that code yet, and mafia certainly has no idea how to change folders.
Click to expand...
Basically, EquipmentRequest needs to know what to do with pseudo-slots FOLDER1 - FOLDER5. It will be an "inv_use.php" request on the folder holder, which will redirect to choice.php, followed up by submitting choice.php with appropriate parameters to add or remove a particular folder. So, in other words, when the response (to the "inv_use.php" request) comes back to EquipmentRequest, for a FOLDER request, look at the response, make sure it is the expected choice.php (given automatic redirection; otherwise, do the redirection yourself), and submit the request to actually do the work.

It's new territory for EquipmentRequest, but I suspect it is not difficult.

I'm going to do The Sea (as a SA) today and ascend. I'll do it again (as a PM) on Sunday and then again (as a DB) on Wednesday, at which point I will try out KOLHS for the first time and will be able to look at this myself, if you haven't gotten to it yourself by then.
 
Revision 12861 should take folders in your folder holder into account when we calculate modifiers. I am in (non-KOLHS) HC, so this is untested, although I used the same technique for the card sleeve and tested it with my multi, and that works correctly. If someone can test folders, I'd be appreciative. "modtrace" should show the effect of individual folders, as appropriate.

We detect folders via api.php and also when you add or remove them via the Relay Browser. Soon we will be able to add and remove them via the Gear Changer. And with that, we might be sufficiently done supporting this item; the only thing lacking I can think of would be teaching the modifier maximizer about folders, and I'm not sure whether that's necessary or even desirable. I'm pretty sure that I'm not interested in tearing out and reinstalling folders as I maximize this or that; how would it decide which one to discard?

I do think that I can guarantee that somebody will ask for it, if we don't provide it. I propose that we don't provide it and just wait for the inevitable Feature Request to be posted, and we can discuss it there. :)
 
We don't suggest changing familiars in the CoT, or stickers, so I think it's okay to not suggest changing folders.

I just restarted to test 12861 and it looks good.

I have the URLs for changing folders, and I can probably get that implemented before I go on vacation starting Sunday (I need to do something with this extended furlough). One thing I'll have to figure out is how to not hit inventory.php?action=useholder twice when removing a folder to replace it with another one.
 
KoLmafia doesn't apply +500% item drops when using an owl folder in Dreadsylvania.

Other than that, awesome!
 
It appears that the +500% of the owl folder in Dreadsylvania is not taken into account for modtrace.
Code: 
[COLOR=olive]> ash my_location()[/COLOR]

Returned:      Dreadsylvanian Village
nocombats => false
zone => Dreadsylvania
parent      => Clan Basement
parentdesc => Clan Basement
environment =>      indoor
bounty => none
combat_queue => hot ghost; spooky ghost;      stench ghost; stench ghost; hot ghost
noncombat_queue => The Even More      Dreadful Part of Town; The Old Duke's Estate; Dreadsylvanian Village      Square; The Florist Friar's Cottage; You're About to Fight City Hall
kisses      => 1

[COLOR=olive]> modtrace item[/COLOR]

    [TABLE]
[TR]
[TD]           source[/TD]
[TD="colspan: 2"]           Item Drop Penalty[/TD]
[TD="colspan: 2"]           Item Drop[/TD]
[TD="colspan: 2"]           Sporadic Item Drop[/TD]
[/TR]
[TR]
[TD]           octopus's spade[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +5.00[/TD]
[TD]           = 5.0[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           camp scout backpack[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +15.00[/TD]
[TD]           = 20.0[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           bounty-hunting pants[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +15.00[/TD]
[TD]           = 35.0[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           hodgman's metal detector[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +37.50[/TD]
[TD]           = 72.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           mad looting skillz[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +20.00[/TD]
[TD]           = 92.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           powers of observatiogn[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +10.00[/TD]
[TD]           = 102.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           natural born scrabbler[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +5.00[/TD]
[TD]           = 107.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           florist:rutabeggar[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +25.00[/TD]
[TD]           = 132.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           withered heart[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +3.00[/TD]
[TD]           = 135.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           fat leon's phat loot lyric[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +20.00[/TD]
[TD]           = 155.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           heart of lavender[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +10.00[/TD]
[TD]           = 165.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           object detection[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +5.00[/TD]
[TD]           = 170.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           joyful resolve[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +15.00[/TD]
[TD]           = 185.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[TR]
[TD]           hustlin'[/TD]
[TD][/TD]
[TD][/TD]
[TD]           +10.00[/TD]
[TD]           = 195.5[/TD]
[TD][/TD]
[TD][/TD]
[/TR]
[/TABLE]

[COLOR=olive]> ash equipped_item($slot[folder1])[/COLOR]

Returned:      folder (owl)

[COLOR=olive]> ash equipped_item($slot[acc2])[/COLOR]

Returned:      over-the-shoulder Folder Holder
 
r12863 adds most maximiser support for folder holder (it will not suggest changing folders, and this is not currently planned)/

It doesn't support the +5 combat rate, as the current system for supporting changeable items, and seeing if they are worth including checks that the results is positive for the current aim. It can currently therefore support either +5 combat or -5 combat, but not both. I suspect -5 combat rate is the more popular, so patch supports that one. I don't really want to have to hard code an exception for folder holder in evaluator logic, but it might be needed.
 
Here's a thing: I understand that when you graduate from KOLHS, it ejects folder #4 and #5 from your folder holder to inventory. We should move whatever is in the FOLDER4 and FOLDER5 equipment slots to inventory and replace them with EquipmentManager.UNEQUIP.
 
Adding folders will be a little weird. You can only add a folder to the first empty slot, so with multiple empty slots someone using the GUI might not end up with folders where they expect. The only type of fix I can think of for that is making some slots unselectable sometimes, but that seems weird to implement (not even thinking about the code for it yet).
 
If KoL tells us to refresh status after adding a folder, we will do an api.php call and will update folders to where they actually ended up.
 
There's no way to add a folder without ending up on the manage folders page, and mafia will parse it from there. It's more that someone might select the third folder slot to add a folder and be confused when they see it show up in the first slot. Mafia gives the illusion of getting to pick a slot, something that clearly isn't the case with KoL's interface (you get buttons to add folders, independent of slots).
 
Would it be possible to have all but the next one greyed out so that it obvious which slot the folder will go into? I assume you can't equip more than one folder per server hit anyway, even though it would mean slightly more clicking for the user.
 
I see no reason to do that. You could have 3 folders equipped, change the 3rd one to something else, and add a 4th one (assuming you are in KOLHS), and they may not end up in exactly the spots you think you are specifying, but when we refresh the folders, the equipment lists in the Gear Changer will update and you'll see where they went. Unlike dual-wielding weapons, where it matters which weapon goes where, if I recall correctly, where accessories go, where folders go, and so on doesn't really matter.
 
I think the issue is the loop in GearChangeFrame.customizeItems:

Code: 
		// Start with first pseudo-slot
		for ( int i = EquipmentManager.SLOTS; i < EquipmentManager.ALL_SLOTS; ++i )
		{
			if ( i == EquipmentManager.CROWN_OF_THRONES )
			{
				continue;
			}

			AdventureResult item = (AdventureResult) this.equipment[ i ].getSelectedItem();
			if ( EquipmentManager.getEquipment( i ).equals( item ) )
			{
				continue;
			}

			RequestThread.postRequest( new EquipmentRequest( item, i, true ) );
		}
After each EquipmentRequest is called, if KoL tells us to refresh status, we will call api.php, which will reset the equipment lists to the current stickers & folders - and will set the selection in each list to whatever it currently is. Next time through the loop, it finds the current selection, not whatever you'd changed it to.

Same problem with stickers and folders.

Try replacing that loop with this:

Code: 
		// Card Sleeve
		AdventureResult card = (AdventureResult) this.equipment[ EquipmentManager.CARD_SLEEVE ].getSelectedItem();
		if ( !EquipmentManager.getEquipment( EquipmentManager.CARD_SLEEVE ).equals( card ) )
		{
			RequestThread.postRequest( new EquipmentRequest( card, EquipmentManager.CARD_SLEEVE, true ) );
		}

		// Stickers
		AdventureResult[] stickers = new AdventureResult[] {
			EquipmentManager.getEquipment( EquipmentManager.STICKER1 ),
			EquipmentManager.getEquipment( EquipmentManager.STICKER2 ),
			EquipmentManager.getEquipment( EquipmentManager.STICKER3 ),
		};

		for ( int i = 0; i < stickers.length; ++i )
		{
			AdventureResult sticker = stickers[ i ];
			int slot = EquipmentManager.STICKER1 + i;
			if ( !EquipmentManager.getEquipment( slot ).equals( sticker ) )
			{
				RequestThread.postRequest( new EquipmentRequest( sticker, slot, true ) );
			}
		}

		// Folders
		AdventureResult[] folders = new AdventureResult[] {
			EquipmentManager.getEquipment( EquipmentManager.FOLDER1 ),
			EquipmentManager.getEquipment( EquipmentManager.FOLDER2 ),
			EquipmentManager.getEquipment( EquipmentManager.FOLDER3 ),
			EquipmentManager.getEquipment( EquipmentManager.FOLDER4 ),
			EquipmentManager.getEquipment( EquipmentManager.FOLDER5 ),
		};

		for ( int i = 0; i < folders.length; ++i )
		{
			AdventureResult folder = folders[ i ];
			int slot = EquipmentManager.FOLDER1 + i;
			if ( !EquipmentManager.getEquipment( slot ).equals( folder ) )
			{
				RequestThread.postRequest( new EquipmentRequest( folder, slot, true ) );
			}
		}
 
OK, I looked over your patch. It is not api.php which is changing the equipment slots. It is your call to parseFolders in EquipmentRequest.processResults. I think that's fine, but the GearChanger needs the change I suggested.

I submitted your patch + my change in revision 12883.

I won't be able to test it myself until Thursday; I'm freeing the king on Wednesday and will do The Sea for the last time, but I have enough aftercore things to do that I figure I'll linger to the next day before ascending to my first KOLHS run. Perhaps others will test it before then and give us feedback. I'm hopeful that we can mark this Implemented.
 
I expect that inventory updating is not handled properly in all cases still. At the very least, there's using a folder with no empty slots to check.
 
I also had bugs in my suggested change to the Gear Changer. Revision 12885 fixes them.

By "using a folder with no empty slots", do you mean "removing a folder and then putting the new one in its place"?
 
You must log in or register to reply here.
Back
Top