-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prototype of a way to get the name of inventories #1114
base: mc-1.19.x
Are you sure you want to change the base?
Conversation
Hey, this looks familiar! I messed around with this feature in CC: Restitched and thought it worked very well in the small, vanilla-ish mod pack I was playing. I was concerned there might be spottiness in anvil renaming support with larger mod packs, but it sounds like you're on a big tech pack and that hasn't been a problem? |
I haven't yet tested it in my current playthough, went ahead and made the pr on 1.19 whilst the modpack is on 1.16 😅 Your way looks a lot cleaner (i have no idea which method arguments can magically appear when requested) 👍 |
1.16 is the main version of CC:T, Squid usually ports everything when releases are made. (Which may not happen anymore or happen less often as he's retired from CC dev now.) |
I see this has a merge conflict now, is it worth fixing? (aka: does this (or toad's version) stand any chance @SquidDev?) |
What I've done for my Create Above and Beyond virtual pipe network is make a table called So something like local peripheralAlias = {
treeFarmHopper = "minecraft:hopper_1",
loggingDrawer = "storagedrawers:standard_drawers_4_4",
} Under the hood my virtual pipes library is basically doing this This might be what you mean by manually maintaining a list, but I've been finding this not too bad for maintenance. I've rearranged my base (changing nearly all of the peripheral ids) and only having to change them in one place has been quite good compared to having string literals everywhere. |
Sorry, meant to reply to this, but entirely forgot! I've been umming and ahhing about this, and I think it's a feature we want. However, I'm not quite sure how it the implementation should look: while the current implementation does work, it ends up putting the This is one of those times we kinda hit the limits of the generic peripheral system. Ugghr. TLDR: I definitely want this, just in a bit of a limbo right now. |
Hey @toad-dev, sorry to resurrect this thread on the forge version and not the restitched fabric version i find myself playing and finally having a chance to play around with it, but its no longer there? I've tried searching through the git history for a few dozen minutes at this point and i just cannot seem to find the commit/reason why it was removed? Kinda narrowed it down to these 2 commits, if i press "view file at " on the bottom commit it shows the I would be most grateful if someone could point me to the commit and/or reason restitched pulled that feature. 🙂 |
It looks like this came in from cc-tweaked/cc-restitched@f880396#diff-96744b9a57d72c125614de97f777c3e98a2ba257f86c23ec044c56e48a41939b. This effectively "reset" CC:R to be based on the latest CC:T code. |
Dead thread I know, BUT! I was trying to create a system that could generically transfer items from one inventory to another and the biggest hurdle is trying to find what an inventory is called so that I can transfer items to it. |
This is just a proof of concept, i do not expect this code to be merged as-is, or even inside this peripheral or this way:
During my most recent enigmatica 6 expert playthough me and my basemate opted for a basewide wired network, this of course meant lots of chests/barrels on the same network, which can get tricky to tell apart.
There are of course solutions to that, like having a disk drive with a floppy that contains a map of addresses, like:
ip.storage = 'minecraft:barrel_3'
(for a barrel that imports into refined storage)ip.foundry = 'tconstruct:drain_0'
(for tinkers construct based fluid storage)Of course those would still need to be manually maintained in case something gets moved, and all computers that imported it should be rebooted. (though that can be remedied with pulling peripheral change events and whatnot)
Another concept on the same wired network was using a special item in the 1st slot, for the output of several create contraptions we had a purple
active logistic provider frame
from pneumaticcraft signaling that thatinventory
should be emptied, and theip.storage
mentioned above had a yellowstorage logistic frame
in it to signal the destination, as well as a dedicated computer to orchestrate the bunch.For recipe inputs this was a little more tricky since the "item in slot 1" should not be pulled into the machine, this of course was fixable by just blacklisting the item used for filtering from being pulled into the machine.
But in order for the computer(s) on the network to know which chest belonged to which machine's input we had to rename the slot 1 items in an anvil and then compare the
displayName
, here is a snippet that accomplished that goal:This was stored on the networked floppy, the logistics core from pneumaticcraft was chosen because no recipes used it.
However, it would be easier if the names of chests (& other inventories) renamed in an anvil were accessible, then the input/output/storage chests could simply be named accordingly and there would be no more need for hardcoded
_#
's or items inside inventories in order to tell them apart.Some food for thought:
Nameable
exists on multiple things (including fluid/energy storage), so inventory methods might not be the best spot.Nameable
supportshasCustomName, getDisplayName & getCustomName
, maybe players would want access to all 3, or only custom names? perhaps its best made into its own generic peripheral, but those seem to demand capabilities.This pull request is thus just a proof of concept, see it more as a suggestion/idea than code intended to merge as-is.
(ps, the docblock has not been generated/tested, it received minimal love 💔)