Change command: create_pickup

[SChinchi]

• Add autocomplete support, fix equipment not found without the 'equip' search. Fixes #109
• Add void coin support; useful for the Released From The Void mod.
• Explicit arg strings should be prioritised before partial search terms to avoid ambiguity.
  • The same applies to give_equip {equip|'random'}, so I fixed that too.

[harbingerofme]

Great work!

I'm worried we might break workflows, any chance we can add backwards compatibility for "both" instead of "all". I don't think adding it for coins is sensible with potential for conflicts on that one.

[SChinchi]

I think I see your point. "all" is actually "both" as in only "equip" and "item" for a search term. I used "all" because we already had that keyword, but I now see the confusion it creates. The reason why I added an encompassing term to begin with is so that a user can have the option to use the default value either with "" or an explicit arg. I will change it back.

I assume that also addresses your worry about the coins and that you aren't actually against the command creating coins.

[harbingerofme]

I think I see your point. "all" is actually "both" as in only "equip" and "item" for a search term. I used "all" because we already had that keyword, but I now see the confusion it creates. The reason why I added an encompassing term to begin with is so that a user can have the option to use the default value either with "" or an explicit arg. I will change it back.

I agree with the change to "all", I just want to maintain the backwards compatibility for using "both".

I assume that also addresses your worry about the coins and that you aren't actually against the command creating coins.

There's no concern with coins. The term is outdated since sotv.

[SChinchi]

The signature of the command had always been {object} [search ('item'|'equip'):<both>] [target]. "both" had never been a valid input for the user according to the docs. However, in the past it technically worked, as "b0th"/"zxcv"/"whatever" also worked because they silently defaulted to the default behaviour. But after adding more explicit argument parsing errors, it reported anything not "item" or "equip" as invalid. With proposing [search ('item'|'equip'|'both'):'both'] the functionality is enhanced by making "both" a valid option and it doesn't break any backwards compabitilty. I initially chose "all" for that purpose, but "both" seems to be better.

I hope I haven't misunderstood you.