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
OpenPeripheral, Plethora and the future #452
Comments
Yes, I realise there's nothing really actionable right now. I got halfway through writing this issue, and then realised that everything else was just going to be a list of problems with Plethora and me not having a clue on how to fix them. That can probably wait 'til later. |
I agree with moving some of Plethora's basic features to CC:T. It always seemed to make sense to me that inventory interaction should be a native CC feature, given the sheer amount of things made possible by it. One thing that comes to mind, though, is the introspection module - I'm imagining you don't plan on bringing that or any of the other modules over, but it provides some basic functionality for turtles that wouldn't be available otherwise. |
I think the only the introspection module can do that turtles can't is getting complete item metadata? Ideally |
Yeah that sounds about right. The only other thing that makes sense to me is adding another method |
could the extra metadata be fetched with an extra arg to |
That does sound a lot better |
This exposes a basic peripheral for any tile entity which does not have methods already registered. We currently provide the following methods: - Inventories: size, list, getItemMeta, pushItems, pullItems. - Energy storage: getEnergy, getEnergyCapacity - Fluid tanks: tanks(), pushFluid, pullFluid. These methods are currently experimental - it must be enabled through `experimental.generic_peripherals`. While this is an initial step towards implementing #452, but is by no means complete.
- Refer to this as "data" rather than "metadata". I'm still not sure where the meta came from - blame OpenPeripheral I guess. - Likewise, use getItemDetail within inventory methods, rather than getItemMeta. - Refactor common data-getting code into one class. This means that turtle.getItemDetail, turtle.inspect and commands.getBlockInfo all use the same code. - turtle.getItemDetail now accepts a second "detailed" parameter which will include the full metadata (#471, #452). - Tags are now only included in the detailed list. This is a breaking change, however should only affect one version (1.89.x) and I'm not convinced that the previous behaviour was safe.
This is a great feature idea! In the past, I've ran a modpack for myself and some friends that's a "computercraft/opencomputers" focused world. We have some tech mods (Integrated Dynamics, is probably the most advanced) but not a lot of advanced stuff can be done without programming! (It's super fun) I can't recall which of the cc interface apis did this - the old open blocks one and the newer plethora one - but one of the gave us quite a lot more meta data than the other. (maybe not the full NBT but close in some cases!) Now, this is our little sandbox, we REALLY want the ability to get full meta data on stuff in chests, or blocks - But we also know this could be a bit cheaty in some modpack/ or normal gameplay. I'd love for there to at least be an option to get "deep" meta data - regardless of how slow it may be, we can code around that just fine. But for game balance, pack authors - I'd like to say that a blacklist/whitelist be available for blocking meta data other than bare minimum for some items, for pack authors to decide if knowing the exact amount of mana in a botania mana pool is cheating (A comparator output could always be used) |
Background
Historically, CC has never had much integration with other mods. That has changed more recently, with support for JEI, MCMultipart, CraftTweaker and Charset.
However, what hasn't changed is that CC:T does not provide peripheral methods for external mods (or even Vanilla!). This has instead been provided by other mods, such as OpenPeripheral and Plethora. This is fine, but not without its problems:
This is, in short, a Problem.
Proposal
I think the "best" solution for now is to merge the vanilla (and Forge) integration into CC: Tweaked. This means we don't add any additional dependencies (which make updating the mod harder), but should provide enough functionality for most users.
Effectively, this means the following changes:
There's a lot of stuff about how the API should look which really needs to be hashed out before doing any work on this. Plethora has a lot of nice functionality, but it ends up being stupidly complex and somewhat broken (I'm looking at you converters).
The text was updated successfully, but these errors were encountered: