Over on this thread I wrote:
GValko wanted to sell stuff, to which I responded, "My suggestion: have a developer write a cli or ash command to interface with it. How about a Feature Request?"
Bale suggested:
I already added (without notice) a "boolean is_coinmaster_item( item )" function to ASH, like the existing "boolean is_npc_item( item )" function. Presumably, there should be a corresponding "int coinmaster_price( item )", like the existing "int npc_price( item )", where the returned int is the number of tokens.
The issue with tokens is that although some are items - and we look at inventory to see how many are available, on the coinmaster frame, or in "accessible" places, when using "acquire" - some are pseudo-items: dimes, quarters, game shoppe credits. For the latter, we have properties to keep the number available.
Perhaps we need a new type: $coinmaster[ big brother ], for example. Add "coinmaster item_coinmaster( item )" to get the (single) coinmaster that buys or sells the item. Add proxy fields to the $coinmaster: string token, boolean is_item, int available_tokens, and so on.
Alternatively, item_coinmaster returns a string(the coinmaster name), and we have a plethora of new functions: string coinmaster_token( string ), and so on.
I want to know how people would use this and design the API to fit the expected usage.
What about an API - a way to trade tokens for items via the various Coin Masters in CLI and/or ASH scripts without having to hardcode visit_url() calls.
- We need a way to visit specific stores
- We need a way to trade - buy or sell - specific items.
- Do we care about specifying which store to get specific items from? They are unambiguous, so far.
GValko wanted to sell stuff, to which I responded, "My suggestion: have a developer write a cli or ash command to interface with it. How about a Feature Request?"
Bale suggested:
It would be good to be able to query token types so that I could check to see if I have enough of them to acquire an item. It might be best if the token type returned was a string so it could be "store credit" or "meat".
string purchase_type(item)
I already added (without notice) a "boolean is_coinmaster_item( item )" function to ASH, like the existing "boolean is_npc_item( item )" function. Presumably, there should be a corresponding "int coinmaster_price( item )", like the existing "int npc_price( item )", where the returned int is the number of tokens.
The issue with tokens is that although some are items - and we look at inventory to see how many are available, on the coinmaster frame, or in "accessible" places, when using "acquire" - some are pseudo-items: dimes, quarters, game shoppe credits. For the latter, we have properties to keep the number available.
Perhaps we need a new type: $coinmaster[ big brother ], for example. Add "coinmaster item_coinmaster( item )" to get the (single) coinmaster that buys or sells the item. Add proxy fields to the $coinmaster: string token, boolean is_item, int available_tokens, and so on.
Alternatively, item_coinmaster returns a string(the coinmaster name), and we have a plethora of new functions: string coinmaster_token( string ), and so on.
I want to know how people would use this and design the API to fit the expected usage.