Bug - Not A Bug create() does not work with all sushis

[Winterbay]

I am currently working on a suhi-handling script which appears to be working just fine. The problem I have is that at the moment it has decided that "salty slick maki" is the way to go (i.e. 1 slick fish meat, 1 white rice, 1 seaweed and 1 sea salt crystal).

Trying to create it the following happens:

> ash create(1, to_item("salty slick maki"))

[¶-1] has no matches.

Which, incidentally, is the same as supplying create with a blank space (" ").

If I buy the ingredients and go to the item manager my "salty slick maki" shows up just fine and I can eat it as well.

ETA: The CLI-command "create" works just fine as well. I find this inconistency annoying

 

[Veracity]

"salty slick maki" is not an item. It has no item number or description. Therefore, you cannot do $item[ salty slick maki ] or to_item( "salty slick maki" ). That should be true of ALL sushi.

I don't anticipate that changing.

 

[Theraze]

Is there a workaround for this to create the sushi from the CLI?

 

[Winterbay]

Ok. Fair enough. So the only way to do this would then be to use "cli_excecute("create 1 salty slick maki"); instead then?

 

[Veracity]

Yes.

 

[Theraze]

Is there a $recipe[salty slick maki] or anything like that? Should there be?

Also, when looking at concoctions data file, grimacite hammer doesn't have the grimacite tag... should it?

 

[heeheehee]

Grimacite tag means that you need a grimacite hammer to make it. If it did indeed require a hammer, then you'd run into the self-inclusive question raised in the item description, if I'm remembering this correctly.

 

[Theraze]

Heh. That would make sense. I don't have any of the grimacite stuffs, I just saw that it said it takes plans to craft...

So, no $recipe?

 

[StDoodle]

IMO, adding a datatype to deal with this one, specific situation seems like overkill. Especially as the situation in question is a very special, non-ascension-relevant one. If, at some point down the line, we start seeing a similar mechanic of adjectives + items used (say, the Pizza Oven that comes up once in a while), it may be worth reconsidering. But it just seems like a major change for a niche use. Again, my opinion.

 

[Theraze]

I wasn't asking for a change... I just know there's the concoctions datafile, and was wondering if there was some internal map that had this in a player-callable way. If $recipe or $conconction or something similar worked, it could be called for all sorts of things... for that matter, it'd be similar to a reversed get_ingredients...

On looking, the issue is that textui/DataTypes specifically invalidates -1 for item id, which is used by all of the sushis (at the same time), as well as the "untypeable item names" (which might be aliases, from the name used around it).

Okay... put together a patch that fake-numbers the sushis as below negative... this shouldn't cause problems, but should have each of them with a unique identifier. It looks sort of like this currently:

> to_item slick maki

Returned: -7

> to_item salty slick maki

Returned: -41

> debugcreate salty slick maki

salty slick maki.canMake(1) => 0

Basically should make sushis act 'normal' despite their not ever being in your inventory... I left untypeable names as -1 for their item id, and -1 is still disallowed as a lookup type...

The one potential issue is that the reversed lookup by id number isn't finding them, though that makes sense as they aren't really an item. to_item does (obviously, as above) find them... There's some other parts where, likely because it doesn't have a complete record, it's a bit odd. Here's one example I noticed.

> ash print($item[asbestos crossbow])

asbestos crossbow
Returned: void

> ash print($item[slick maki])

-7
Returned: void

So the question is... would this be a patch that other people would find useful and should be examined for possible main inclusion, or should I sit on it for now and wonder why people complain about command-line crafting?

As I said above, I wasn't looking for a change... I got bored though and made a change for myself.

 

[Veracity]

Okay... put together a patch that fake-numbers the sushis as below negative... this shouldn't cause problems, but should have each of them with a unique identifier.

Let's not do this and pretend we did.

...should I sit on it for now and wonder why people complain about command-line crafting?

Command line crafting works just fine; the CLI "create" command has no problems making any kind of sushi.

 

[Theraze]

Ah, I see now what the

> ash create(1, to_item(" "))

[¶-1] has no matches.
Returned: false

is... it's the item number. Failed lookups return -1. With the partial lookup it's doing now, it returns the following:

> ash create(1, to_item("salty slick maki"))

[¶-41] has no matches.
Returned: false

I won't bother anyone with it until it's fully working as it should. If I even decide to care enough.

Is this a project you'd like me to quit, or just shut up on for now until it works?

Edit: Think I've got it figured out...

> ash create(1, to_item("salty slick maki"))

You cannot make sushi without a sushi-rolling mat.
Returned: false

Problem was that itemIdByName was being generated, but not dataNameById or nameById. Once that was added, the lookup is working fine...

Also put the other 2 name-by-id bits for punchcards, since they were missing (on purpose?) as well... Should make things work a bit better for people who don't want to use the "attack wall" automation.