"use" command as generalization of "drill"

[kostmo]

Issue formerly titled: "Recipes with custom drills do not work in creative mode"

Creating this bug for visibility/findability later, as I've mostly figured out the problem and a workaround.

In word-search.yaml, for example, I define a custom entity "highlighter" that has drill capability. I also define recipes that require this "highlighter". However if I try to play this scenario in creative mode, it will say "no way to make [...]" or something to that effect.

This is because in creative mode, the player is granted a "drill" entity automatically, and in fact it defaults to that drill when computing recipe inputs/outputs for the drill command, ignoring the user-defined highlighter recipe.

One workaround is, of course, to avoid Creative mode. Another workaround is to eschew custom entities with drill capability, and instead incorporate the standard "drill" entity into one's recipe.

[xsebek]

The drill is overall a bit hacky for which I am sorry. 😄 I don't think "highlighting with drill" makes much sense, but maybe we could solve that and the input/output problem simultaneously.

I would propose adding a use command (or apply?) that uses a given installed device on a nearby location:

use :: entity -> direction -> cmd unit

@byorgey would it have to be a syntax form to work with requirement analysis? Or could we make it work as long as the entity parameter is known at definition? 🤔

Maybe it's too cumbersome to use (pun intended), but I think it would work better with custom recipes and entities.

[byorgey]

I like the idea of use. Yes, it would have to be a special form (or we could make it a normal constant and just add a special checking rule to make sure it's applied to a text literal - that would give better error messages).

[kostmo]

Would the use command only work with an equipped device? Let's say I need a "key" to open a "locked door" (where a recipe converts the "locked door" to an "unlocked door"). Shall we require the player to execute this sequence of commands?

equip "key";
use "key" forward;

On the bikeshedding front, I'm not necessarily opposed to use as the command name, but may I also submit operate for consideration?

[byorgey]

I think having it only work with an equipped device makes sense. However, note that getting something your example to work (doing an equip immediately followed by a use) would require a more careful job of requirements analysis than we currently do (see #921 (comment)).

I don't have a strong personal preference between use and operate.

[xsebek]

@byorgey I think a normal Const command is the way to go here - if the requirements analysis finds a App (TConst Use) (TText "highlighter") then it can use that information, but it would be too constraining to forbid dynamic usage.

This will subsume the drill command and should require almost no changes... in fact let me assign myself.