"take" action does not show an output

[saraht45]

When taking an item, it returns a blank line rather than outputting the action. This has been tested locally and in vRWOT.

[ChristopherA]

Is built in take verb being overridden by a merry-based take?

Is a take-* signal being sent to the environment?

[shentino]

Is built in take verb being overridden by a merry-based take?

Is a take-* signal being sent to the environment?

For more general context, what do you mean by "built in"? Is it like hard coded inside ~TextIF somewhere as a default implementation by the parser that can be intercepted by Merry?

[noahgibbs]

I don't see an obvious Merry-based "take". So that's going to be something implemented in DGD.

[shentino]

I don't see an obvious Merry-based "take". So that's going to be something implemented in DGD.

That's impossible. DGD itself doesn't even have a concept of a verb, that is entirely in the LPC layer.

Not even the kernel library defines verbs as such, just commands you can use in the wiztool shell.

[shentino]

I don't see an obvious Merry-based "take". So that's going to be something implemented in DGD.

DGD is the bottom of multiple layers of software, ironically related to the layering document you accidentally deleted.

DGD defines the context of objects, callouts, and so on, and provides the baseline kfun api.
The kernel library is next, and provides basic security regime
Next is the LPC layer that is the bulk of skotoslib
Up from here is either merry or bilbo, (merry being hooked specially and compiled into a hash-named LPC file which itself is then compiled as a master object by DGD)

Any verbs that are implemented, but not present in merry, would therefore have to be in the skotoslib LPC layer somewhere.

[noahgibbs]

I'm assuming the object of the "take" command is getting taken or Sarah wouldn't have said "no message" but rather "no effect" or "it doesn't work." That would strongly imply that the "take" action is happening, which strongly implies that the signal is being sent.

I'm not sure what should normally catch the (post?) signal and output the "Noah takes a pair of black socks"-type message.

I'm seeing the same thing on gables_game, so this isn't related to RWOT changes.

[noahgibbs]

Also: yes, "take" is definitely happening, it's just not showing a message.

[shentino]

Sorry btw noah if I got snippy, I thought you were literally saying that the take command was part of DGD itself.

[noahgibbs]

Sorry, yeah, I just meant it's written in LPC rather than Merry.

[noahgibbs]

So here's something interesting. There's an LPC-based "OutputDB" that seems to have default messages for when things happen around you (e.g. you take or drop an object, or somebody around you does the same.) The message from OutputDB is turned into something you can see in /usr/TextIF/cmd/desc.c, in the function desc_output.

That function is getting called when I "get" or "take" my pipe, though I'm not seeing output in the game client. It is not getting called when I drop my pipe, suggesting that "drop" (which works) might not get its message from OutputDB.

(Edit: sorry, desc.c NOT basic.c)

[noahgibbs]

Hm. And the message it's querying from OutputDB is coming out as nil, which is probably getting ignored when we say "emit this as SAM."

[noahgibbs]

Hm. Maybe the XML file TextIF:OutputDB isn't getting loaded, and so we're only getting output messages for verbs with Merry code to emit the message? That might be.

[noahgibbs]

To be clear, I'm really not sure why "drop" is properly showing a message - but it does not seem to be using this low-level LPC code to query the message from OutputDB since my debug log messages aren't being printed for "drop", but they are for "get" and "take".

[noahgibbs]

Huh. There's two OutputDB.xml files. The one under data/vault/SID is empty. I don't think that should prevent the other one from loading, though. And because of the way the other one uses SID to call methods, I don't think loading an empty one too should cause trouble.

[noahgibbs]

Huh. Oddly, it looks like the outputdb object does think it has a bunch of stuff loaded, including Output:Take. So why is it returning nil?

[noahgibbs]

Ah. Okay, OutputDB does this weird thing where it accepts queries as a string which it downcases, then converts the downcased version back to case-sensitive, then returns the result. And only the patch() code ever populates its internal downcased-to-case-sensitive mapping. So this was code that was unsafe for cold-boot that was never updated to be cold-bootable, since it assumes the patch() method will fix this.

[noahgibbs]

Okay. If I manually call "/usr/TextIF/sys/outputdb"->patch() from the wiztool, it fixes the problem. I'm going to make the smallest change that will fix this - when we add an entry to OutputDB I will update its internal lc2cs array that lets it look it up, which it currently doesn't ever update.

The right answer is to remove lc2cs and look up everything lowercase. It already has the down-sides of doing that without the up-sides, probably to avoid doing an annoying-but-entirely-possible remapping in the patch() method to maintain compatibility with pre-cold-boot SkotOS games.

Still not sure why the "drop" verb didn't have the same problem. It didn't have an entry in lc2cs either. So the drop output is presumably coming from somewhere else.

[noahgibbs]

PR: #76

[saraht45]

Tested the PR locally and it now works as it should. Thanks, Noah! :)