Suggestion: Mote Nexus as a peripheral

[beholderface]

Some methods for it:

• readMotes() - Returns a table containing all the motes (in the same format as reading a mote via focal port) in the nexus
• checkMote() - Takes a wrapped nexus and a mote as arguments, returns a bool based on whether the passed mote is in the passed nexus.

Methods that don't specifically interact with a nexus, but with motes in general:

• getMoteCount() - get the number of items contained within a mote.
• getMoteName() - gets the name of the item contained within the mote.
• getMoteType() - gets the itemtype of the mote.
• canMotesStack() - takes two motes, returns a bool based on whether they could be stacked, similar to Stacking Distillation II.
• readMoteIota() - if the item within a mote could be read via Scribe's Reflection, returns that iota (or, for spellsbooks, a table of tables containing iotas and page names), otherwise returns nil. Not sure if this one would be suitable, since if all you need is reading, it would be way better than a focal port.

I don't like the idea of it being able to do something like Depot Purification (returns the coordinates of the nexus that the passed mote is in) because at least in my head, that involves following the mote's media back to the nexus, as opposed to the methods I've listed here which would just involve analyzing the mote data the computer already has. Probably also shouldn't let you manipulate, create, or return motes directly, since then it would be too close to being usable as "generic digital storage mod #69", in addition to the issue of some of those patterns requiring media, which a computer does not have.

[SamsTheNerd]

so y'know cc gets the "block that does everything" accusations a lot, so one of the main things i try to think about with new peripherals is "does this actually allow you to do something new that you otherwise wouldn't be able to", and if not how does it balance with the existing method of doing it. (with the exception that if it's flashy enough some of that can be ignored like with keyboards)

so for a lot of these i'm not sure that it really adds anything new. you can get all of this info in hex with a wisp or circle or whatever else, which you can then dump into cc with the focal port or focal link.

The mote iota -> lua already gives the itemtype, I could maybe add count too, but it does feel odd to let you query the count from an arbitrary computer + focal port just from having the mote. The name bit is tricky, since to my knowledge, unless the item has a custom name, the actual item name is based on the translation key and then the lang file which is client side, so cc wouldn't be able to actually get the human readable item name.

For the checkMote(), I'd rather just add a method to return the nexus uuid, then let you do the checking yourself, since motes already have that info.

For canMotesStack(), I think it'd make more sense to have something attached to the mote, maybe an nbt hash ? and then let you handle the checking if they can stack (idk if there are other factors to it or not), rather than having some arbitrary cc function that Just Does It.

readMotes, is maybe, but I think it would be a more shallow reading, so it wouldn't give you the mote uuid that you would need to turn it into an actual iota with the focal port. Few reasons for this: main one is that I think that would make it too easy to just use cc for managing the nexus, a shallow read could be nice for making some sort of cc based ui though. Other reason is that the mote uuid you get from the focal port is only created when you read in that mote, so having a method that will make all those uuids from just reading the nexus could maybe pollute that table and maybe on a large enough server add some loading time, but like idk if that's a real concern or not.

Also this made me realize that the itemtype iota <-> lua is not documented on the wiki oops.