Hi there!

 

I just returned to forge after about three years of C# coding and realized that there have been some huge changes.

Right now I am trying to create a block that can store a large amount of one specific item by right clicking. (no gui or anything else fancy) My original plan was to use a TE with read/write NBT to save the content of my block and then use blockstates to change the blocks appearance depending on how full it is. While reading through the new docs however I discovered the new(?) Capabilities System, which apparently can also be applied to TileEntites.

 

 

So in which cases should I use the Capabilities System? As far as I can tell the simple read/write functions inside the TE class are not part of the EEPs, and therefore also not deprecated.

To be honest I would rather not use the CS without a good reason. I am still unsure how exactly I want to structure my project now that even the most basic stuff has changed and would rather not have to add additional classes for something so minor.

And is there a more specific documentation or example project for CS?

 

Edited July 18, 20178 yr by Jacky2611

2 hours ago, Jacky2611 said:

So in which cases should I use the Capabilities System?

It should be used when attaching data to Entities, TileEntities, ItemStacks, and the World if you so wish (WorldSavedData is still in use). This includes saving Items to TileEntities Forge provides a Capability: CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.

2 hours ago, Jacky2611 said:

While reading through the new docs however I discovered the new(?) Capabilities System, which apparently can also be applied to TileEntites.

Yes they can be applied in two ways. If the TileEntity is yours apply it through the getCapability and hasCapability methods in your TileEntities class. If it is not yours then you must subscribe to the AttachCapabilityEvent and attach it to the TileEntity.

2 hours ago, Jacky2611 said:

And is there a more specific documentation or example project for CS?

What you read is the official documentation, I know Choonster has some Capability examples on his github.

Thx for the reply.

All I really need to save is an Integer and maybe a Boolean.

 

If I wanted to create something more complicated like a real inventory I wouldn't have asked and would already be trying to implement the CS. But writing my own Capability class just to save these two vars feels a bit like overkill. And it would make my project needlessly complicated.

The way I understood it, and please correct me if I am wrong, the Capabilities System is meant primarily to be used on LivingEntities and Players. In addition I would have to manually save/load the CS content to/from disk and come up with my own way to sync it over network.

 

So is there any advantage it has in my use case? Unless the TE's read and write to NBT are deprecated they are a perfect fit for what I plan to do.

 

And thanks for the GitHub link, I will definitely have a look at that.

2 minutes ago, Jacky2611 said:

So is there any advantage it has in my use case?

No as long as you are doing it to your own TileEntity.

3 minutes ago, Jacky2611 said:

In addition I would have to manually save/load the CS content to/from disk and come up with my own way to sync it over network.

You are gonna have to do this anyways if the display changes based on the item.

4 minutes ago, Jacky2611 said:

All I really need to save is an Integer and maybe a Boolean.

I am assuming that the Integer is an Item/Block ID. I do not suggest that you use the numerical ID do load it take a look at ItemStack#writeToNBT and ItemStack#readFromNBT.

6 minutes ago, Jacky2611 said:

The way I understood it, and please correct me if I am wrong, the Capabilities System is meant primarily to be used on LivingEntities and Players.

It isn't that it was "meant primarily to be used on LivingEntities and Players", but that it seems that it is more useful to save stuff to players and Entities than it is to TileEntities and ItemStacks.

By God, no! I am not insane enough to save anything by using the item id!

I know exactly what item will be put into my container. (It's a special barrel made to store a custom item.) All I really need to know is the stack size and a Boolean so that I can open/close the lid.

I'd use an IItemStackHandler (the capability) in order to provide the capability to "handle items" with a single slot containing a 1-size stack of whatever's stored.

 

Then you store an integer normally that actually tracks how many are stored.

But why would I want to do that? The only reason I add these barrels is to store one specific single item that will evaporate in other containers. I already know the item, I only need the stack size.

 

And why would you combine a capability with normal NBT data? Wouldn't it make more sense to simply store everything inside the TE should I want to store the item-type too? I am still feeling like Capabilities have a huge advantage I am missing. ?

2 minutes ago, Jacky2611 said:

But why would I want to do that?

To be compatible with things like hoppers?

Quote

normal NBT data?

NBT has nothing to do with anything. IItemStackHandler is also saved to NBT.

TileEntities do not operate on NBT at runtime, NBT is for serialization and serialization only.

Yeah, meant keeping everything inside my TE class the way we did it before Capabilities came around when I used "NBT" In my reply above. I am a bit busy decorating a ? right now. And don't TEs use NBT to sync their content during run time?

 

And no, I definitely don't want to be compatible with hopers. The item I plan to add doesn't even really exist as an actual item, there will only be special containers that can store and transfer a certain amount of it for a certain amount of time. Allowing low tech hopers or pipes to pump it out of my containment units would be ridiculous.

And wasn't there a special function that determined what items would be mapped to different sides of my block should someone try to extract something from it?

 

I really only need to save and sync an Integer. If I can do that the same way I did it a couple of years ago without the possibility of having to rewrite it in the near future that's perfect.

Edited July 18, 20178 yr by Jacky2611

43 minutes ago, Jacky2611 said:

NBT

NBT is not relevant, but yes, you will need to save and synchronize just as you always have.

Yeah, I know that NBT is not relevant. I meant the old TE system I used back in 1.7 when I used "NBT" in my reply. Sry, I was tired and my cakes dressing wasn't working the way I planned it. "NBT" was the first thing that came to my mind when I tried to somehow describe the old system.

Edited July 18, 20178 yr by Jacky2611

The main benefit of capabilities is compatibility, with vanilla things and with other mods which might connect to or extend your functionality. If you don't want compatibility at all, then you can just not bother to use a capability.

Aaannnddd...The "old"system still exists. Capabilities are the replacements for the massive interface list, implements IPowerUser, IMechanicalPower, IRedPowerConsumer, IInventory, ISidedInventory, IButterworthPillbox, IForestryFishnet, IRotaryBanana....

 

It isn't a replacement for data storage. 

Already figured out that part. But I am happy if I can just use good ol' TEs for the basic stuff. Just needed something fast and easy that won't be outdated in a few versions.

Really like it btw that we now have a built in power/energy interface.

Using capabilities is using TEs, it's just using them in a particular way that's a bit more effort to set up, but more tailored for compatibility. A TE is just a class, and instances can store fields like anything else. Using capabilities doesn't mean not using TEs, it means storing the information in your TEs in a particular form that makes it easy to be accessed and used in certain ways.

Yeah yeah, I got it. Kinda hard to describe not using Capablities. All I really wanted is a confirmation that I don't have to use them for something really small.

Size isn't important. Capabilities is about compatibility and accessibility.