Add ItemExchange Tokens and TokenModifier - #956
Conversation
The primary use case in mind for these are bank deposits: the bank can set up a bunch of premade tokens, put them in a shop chest, then people can trade diamonds (or whatever) for these tokens, then redeem the token via the bank's bot (or whatever) for that amount of diamonds.
This helps indicate that a specific token is required.
|
This is fully possible. Name a piece of paper. Make a shop for just paper no name or anything. Problem solved. |
|
Untrue. Yes, you can name a button in an anvil to put a token on it, but ItemExchange's support for this is very minimal. Supporting "any token" means just removing the display name modifier, which looks to any shopper like you're just trading expensive stuff for stone buttons. Similarly, what if you want to accept a particular token as an input: how do you do that without revealing the token? |
|
Isn't this all already solved via secure notes? |
|
You still have the same problem of how to define, in ItemExchange, of wanting a particular token from the customer without also revealing that token to the player. |
|
Wordbank recipes technically could do that I believe |
|
Could you elaborate, and show a screenshot of what the exchange would look like printed in-chat for the customer? |
|
iirc you can take wordbanked items as inputs. say you have 5 different trades in the same chest each for a different wordbank each a secure note lored "100 diamonds" but word banked something different. The user can buy or take a secure note, do the withdrawal online, get a wordbank recipe back. Apply that and do the trade. Little complex but also I don't think civ needs this feature. It feels awfully close to supporting non-item economies |
|
That doesn't answer my question: how do you set up an exchange that accepts a token as an input that must have a particular value on it without exposing that value to the customer? |
|
If your using secure notes, made in the printing press, the uuid is shown in the item exchange as the lore |
|
Ditto with Anvil names: ExchangeRules that require a specific value in the Anvil name or the lore will be revealed to anyone who browses the shop, thus undermining the concept of redeemable tokens. Similarly, the burden of creating an token-item through traditional means (eg: Anvil names) is annoying/prohibitive enough to similarly undermine the concept of redeemable tokens. |
|
This is entirely untrue, you can name a piece of paper "abc" then sell "1 Paper" for 100d and it will give you the "abc" paper. Any shop with a generic named item would not work then? Like my head shop uses "1 Player Head" as the output for most of them. The burden of naming an item in anvil is not very high. This is specifically for what I imagine would be "deposits" |
|
Just to be clear, the ability to Anvil-name an item as a form of generic input was already known about: This idea was also discussed when we originally created the Bank of Icenia back in 2024. This doesn't mean the PR is destined to be merged or anything, but we are aware that there's pre-existing means to do some of what this PR would allow. However, those pre-existing means are prohibitively annoying: it's similar, in my mind, to how you could technically sell potions prior to official support by using a dropper contraption that takes advantage of the successful-transaction redstone signal. Just because a pre-existing solution exists doesn't mean it's a good one or that an official solution is a bad one: while I may be biased, I don't foresee this being a negative addition or one that undermine's someone's niche in an economy. |
|
I felt some of your representations were somewhat disingenuous and comparing it to potion droppers reinforces that belief, apples and oranges. My main goal was to express I don't believe this is needed. |
|
Oh boy, here we go 🙄 Back in the day, potions were not officially supported by ItemExchange. I can't quite remember the exact reason why since it's been seven years since I fixed it, but it was typical to have a dropper system to sell potions (more details). But selling potions was relatively rare because of this issue. Why is this relevant? I believe it to be so because tokens are not officially supported by ItemExchange. You can approximate selling tokens by editing the output rule to remove any Anvil-name condition. But again, this isn't helpful when you want to buy tokens, ie, spending a token for a commodity, because by definition any condition you set will be disclosed to the customer. This is what allows paper currencies to work, because people can't arbitrarily set that particular lore which the secure note has. The whole point of tokens is to be arbitrary. There's also the UX argument: with the current system, someone who's new or otherwise unaware of tokens sees your shop chest that takes 8 diamonds and outputs 1 button. That's all the information that'll be displayed. So unless you put a bunch of signage everywhere, no one will know the purpose of that button. Whereas, with this PR, that button will be clearly marked as a token, thus indicating its purpose. |
|
You can literally make a printing plate with a custom name and formatting, which will also give the plate a visible uuid. You can then use the same factory to print secure notes, which are also given the same uuid, so cannot be forged. I don't see why this is needed compared to this tbh. The uuid, is exposed through the lore, however is not cloneable as this uuid is random when the printing plate is made. This is a security feature too allowing users to spot counterfeits too. |
This is irrelevant to the subject of tokens. The XY of this PR is allowing banks (like Monument Bank) to create single-use redeemable tokens. This would allow them to set up shop chests that exchange diamonds for tokens. You'd trade in, say, 32 diamonds, and get a token that when given to Bertha (or whatever they're calling their bot now), will transfer 32 diamonds into your account. What you're talking about wrt secure notes only matters with paper currencies. You wouldn't use secure notes for tokens because the uuid is moot: you can just put the token value in the display name, which you can do by signing the book you'd spend on the secure note, or by naming any arbitrary item in an Anvil. Genuinely, secure notes are irrelevant to this discussion. Think about tokens like Steam keys: them having all the same value defeats the point of the key. |
Could be wrong, but I don't believe it's possible to wrap NBT as PDC without delving into forbidden internals. And even then, I'm personally against using PDCs given their relative inefficiency and hostility to pattern matching. As you may be able to see from the PR, NBT (like JSON) is extremely amenable to pattern matching. |
|
Yes, but you're using NBT to store the token string. That should be PDC. NBT usage should be kept to an absolute minimum as it is less maintainable |
|
Adding an entirely new and purely idiosyncratic method of serialisation to ItemExchange is well outside the scope of this PR. |
|
I'm not asking you to do that, but half this PR's LoC is adding utilities to handle custom data for the token. This could be greatly simplified by using PDC and would not be idiosyncratic to the rest of the code. |
|
Those utilities are conveniences, not necessities: they're more there to provide documentation and an even-more efficient option when you're only reading NBT. The original intention was to switch the |
5 participants
The primary use case in mind for these are bank deposits: the bank can set up a bunch of premade tokens, put them in a shop chest, then people can trade diamonds (or whatever) for these tokens, then redeem the token via the bank's bot (or whatever) for that amount of diamonds.