"Transfer failed" error when closeting stuff

[Wrongfellow]

I'm trying to put a WA in my closet from an ash script and getting an error:

> ash put_closet(1, $item[WA]);

Placing items into closet...
Transfer failed for 100-Watt bulb
Returned: false

It looks like something's doing a fuzzy match where I want a strict one. At first I thought I had the wrong syntax for the item lookup, but that part seems to be fine:

> ash print($item[WA]);

WA
Returned: void

Am I doing something wrong or is this a bug?

(I'm using the latest SVN version of Mafia.)

 

[jasonharper]

Mafia bug. Your request is being turned into the CLI command closet put 1 WA, and "1 WA" is successfully matching "100-Watt bulb". (It's the same matching rule that allows "334 scroll" to match a singular item, rather than 334 of some arbitrary scroll).

Short-term fix: if you know you will always be dealing with exactly one WA, you can do so via
cli_execute("closet put WA");
If the quantity varies, I don't see anything you could do, since the problem would be unavoidable with a quantity of 10 or 100.

 

[Wrongfellow]

Quotes seem to help:

> closet put 1 WA

Placing items into closet...
Transfer failed for 100-Watt bulb

> closet put 1 "WA"

Placing items into closet...
Requests complete.

So I changed line 1709 of RuntimeLibrary.java to add them:

KoLmafiaCLI.DEFAULT_SHELL.executeCommand( "closet", "put " + count + " \"" + item + "\"" );

Now my script works fine.

Could this problem occur with any of the other ASH->CLI wrappers?

 

[jasonharper]

Good thinking - I didn't realize that this special handling of quotes would apply to the CLI.

Yes, the problem will occur with any of the wrappers for CLI item-related commands - it's happening in the low-level routines for parsing item names, not anything specific to the "closet" command. Actually, there's another problem I see with the CLI wrappers - items with commas in their name are going to cause problems when passed to a command that accepts an item list. Currently, these are:
* Happy Birthday, Claude! cake
* "I Love Me, Vol. I"
* Staff of Ed, almost
* Maxing, Relaxing
Such items are going to need to have the commas stripped out, and quotes NOT added, when passed to the CLI. I'll work on this once I get some more urgent problems out of the way...

 

[Wrongfellow]

Yuck.

Here's another idea - this diff adds the ability to refer to items by their item-ID (eg "closet put #623") and updates (some of) the ASH wrappers to use it. This avoids the need for the second bit of string matching completely.

(Of course it'll break if Jick ever adds an object whose name starts with a '#'. Jick, if you're reading this, that's not meant as a challenge!)

 

[jasonharper]

I'm going to have to vote against that - some future item like a "#2 pencil" seems far too likely to me (and "#1" thru "#4" are currently reasonable abbreviations for the Hodgman journals). It would be safer to use some obscure Unicode character; it doesn't really have to be anything the user is capable of typing themselves.

 

[Wrongfellow]

Good points - though to be honest I can imagine myself wanting to use this syntax occasionally - I'm strange like that

Of course it doesn't have to be a single character. What about "$item$" ?

 

[jasonharper]

Fixed in r7422.

I ended up using a paragraph mark ¶ (which is apparently properly called a "pilcrow"), as a reasonable compromise between "typeable by humans" and "unlikely to ever be the first character of an item name". It's Option-7 on a Mac; it's not so easy on Windows (Alt+0182), but there don't seem to be any easily typeable special characters on Windows.

 

[Wrongfellow]

Thanks very much!

I can't test my original script now because I'm in Ronin but I'm sure it'll work fine.