[Solved]ICapabilityProvider Help

[jredfox]

Edit: use this:
https://www.planetminecraft.com/blog/forge-tutorial-capability-system/

 

How to use the interface? Do I need to register it constantly in a certain event for tile entities or just use the AttachCapabilitiesEvent<TileEntity> event?

What is Capability do I need to make yet another class? How am I suppose to return get capability the list shouldn't have it already yet it's there? What is capability<?> it extends what and is it an array? So confused on what to do here

 

I am trying to store a boolean or (byte if no boolean option) into nbt of all tile entities to retrieve it later
 

public class TileCapabilities implements ICapabilityProvider{

	@Override
	public boolean hasCapability(Capability<?> capability, EnumFacing facing) {
		return capability.;
	}

	@Override
	public <T> T getCapability(Capability<T> capability, EnumFacing facing) {
		return capability.getName().;
	}

}

 

Edited March 2, 2018 by jredfox

[Draco18s]

TileEntity already Implements ICapabilityProvider. You don't need to do anything but override those methods.

[jredfox]

3 minutes ago, Draco18s said:

TileEntity already Implements ICapabilityProvider. You don't need to do anything but override those methods.

right and I was asking how those methods work. I plan on this for all tile entities

 

like an example very basic example of storing a single variable object would help

Edited March 1, 2018 by jredfox

[Draco18s]

27 minutes ago, jredfox said:

What is Capability do I need to make yet another class?

If you want to create a new capability, then yes, you do. You need an interface that describes your capability, then you need to implement it:

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/interfaces/IMechanicalPower.java

https://github.com/Draco18s/ReasonableRealism/tree/1.12.1/src/main/java/com/draco18s/hardlib/api/capability

Quote

How am I suppose to return get capability the list shouldn't have it already yet it's there? What is capability<?> it extends what and is it an array?

What you are looking at is a Generic.

https://en.wikipedia.org/wiki/Generics_in_Java

Capability<T> means "This is an object of type Capability of some subtype." It is not an array, an array is just another type of Generic.

In order to provide a return from getCapability you need to cast to Type T:

return (T)someObject;

Quote

So confused on what to do here

 

All of this is described in the docs:

https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

Edited March 1, 2018 by Draco18s

[jredfox]

30 minutes ago, Draco18s said:

 

return super.hasCapability(capability, facing); doesn't exist in class object error message but, forge said to do it this is confusing me. I need to know steps since every time I read this then look at an actual class there is 10 more then I find out no such thing can't use it? like say you have to: 1: create interface, 2: how to use interface methods 3: capability<?> how that works can be retrieved and set the object inside

 

@Override
	public boolean hasCapability(Capability<?> capability, EnumFacing facing) {
		if(capability == hasScaned)
			return true;
		else
			return super.getCapability(capability, facing);
	}

 

Yeah forge docs says 3 different things are capabilities they need to simplfy it doesn't tell me what is what and how to do anything for me I am guessing everything read it like 5 times. I need steps and explain what to actually do in order.

Edited March 1, 2018 by jredfox

[jredfox]

21 minutes ago, diesieben07 said:

There is a difference between adding a capability to your own tile entity and adding one to someone else's tile entity. You want the latter, so some of what Draco said is not correct.

 

You implement ICapabilityProvider, to provide whatever capabilities you want. This provider also ensures that and defines how these capabilities get to save data. You can then attach this provider to an existing tile entity using AttachCapabilitiesEvent<TileEntity> and that tile entity will also provide the capabilities provided by your provider and the data will be saved with the tile entity.

 

For how to make your own capability (not the provider!), see the link to the documentation posted by Draco.

So I need a provider and the other object please explain the steps simplified on what to do. Forge docs is confusing and doesn't explain everything. Then after explaining that explain how to retrieve and store the object in Capability<Object>

Edited March 1, 2018 by jredfox

[Draco18s]

36 minutes ago, diesieben07 said:

There is a difference between adding a capability to your own tile entity and adding one to someone else's tile entity. You want the latter, so some of what Draco said is not correct.

This is true, I did skip over that possibility.

[jredfox]

1 hour ago, diesieben07 said:

 

I think I figured it out but, this is really a piece of utter crap of confusion
https://www.planetminecraft.com/blog/forge-tutorial-capability-system/

How I think it should be
Register class object that implements an interface that extends the base provider{readNBT(),writeToNBT()}

the 2d parameter being the base resource location for your mods tags to go into {  }

 

CapabilityManager.INSTANCE.register(new CapObject(),new ResourceLocation("modlib:tileSyncing"));

IBaseCapability cap = CapabilityManager.INSTANCE.get(new ResourceLocation("modlib:tileSyncing"));// from here you could either cast it to the right object to get said stuff

Nothing more if you have the variables/objects you need written and reading that's all you need maybe do something else for Object support but, I don't even think it supports writing full blown objects to nbt anyways. They populate vars from readFromNBT() and save by writing to disk. Modify vars from other forge events and have the static instanceof the capabilities container for further use since it's their own interface they create they can get the objects as well but, no need can use regular methods at this point

 

Edited March 2, 2018 by jredfox

[Draco18s]

The definition of the capability and its implementation need to be separate objects.

 

Your proposed idea misses the fact that there may be multiple instances of the implementation, e.g. a chest inventory is a Capability<IItemHandler> and there may be hundreds of chests each with their own copy of an IItemHandler implementation. You can't just say CapabilityManager.INSTANCE.get(new ResourceLocation("forge:inventory")); and get anything sensible back. What would it give you? the Capability<T> or the T?

 

It can't give you the T because of the aforementioned issue. Which means it must return the Capability<T> (which is a wholly separate object!), which, surprise, is already available, CapabilityItemHandler.ITEM_HANDLER_CAPABILITY. For other mods' capabilities, there's already the @ObjectHolder annotation.

Edited March 2, 2018 by Draco18s

[jredfox]

1 minute ago, Draco18s said:

The definition of the capability and its implementation need to be separate objects.

 

Your proposed idea misses the fact that there may be multiple instances of the implementation, e.g. a chest inventory is a Capability<IItemHandler> and there may be hundreds of chests each with their own copy of an IItemHandler implementation. You can't just say CapabilityManager.INSTANCE.get(new ResourceLocation("forge:inventory")); and get anything sensible back. What would it give you? the Capability<T> or the T?

 

It can't give you the T because of the aforementioned issue. Which means it must return the Capability<T> (which is a wholly separate object!), which, surprise, is already available, CapabilityItemHandler.ITEM_HANDLER_CAPABILITY. For other mods' capabilities, there's already the @ObjectHolder annotation.

well maybe they could do new ResourceLoaction("minecraft:chest:enderchest"); ? The point is they are making it waaaaaaaaaaaaaay more complictated then it needs to be take IRecipe for example 3 simple methods one register parameter and it's more complex then this needs to be 

[jredfox]

I also made an nbt path api they could implement into forge so the path could be chest/enderchest from default nbt rather then resource location. It decompiles nbt without recursion since I didn't know how to use recusrion and I hear it literally takes seconds compared to something non recursive that takes miliseconds yes I tried 400 branches randomly it decompiled the nbt properly

[Draco18s]

2 minutes ago, jredfox said:

well maybe they could do new ResourceLoaction("minecraft:chest:enderchest"); ? The point is they are making it waaaaaaaaaaaaaay more complictated then it needs to be take IRecipe for example 3 simple methods one register parameter and it's more complex then this needs to be 

Who's ender chest inventory would that give you?

 

Again, your proposal makes no sense.

 

Recipes are simpler because there's exactly 1 copy of the recipe shared across all players.

The same is true for blocks and items.

Capabilities can have an infinite number of instances.

Just now, jredfox said:

I also made an nbt path api they could implement into forge so the path could be chest/enderchest from default nbt rather then resource location. It decompiles nbt without recursion since I didn't know how to use recusrion and I hear it literally takes seconds compared to something non recursive that takes miliseconds yes I tried 400 branches randomly it decompiled the nbt properly

NBT is for saving to disk only, it should never be used in any other circumstance.

And "literally takes seconds" is fucking slow. No one would want to wait "seconds" for a hopper to extract an item from a chest or to push power down a wire.

[jredfox]

1 minute ago, Draco18s said:

Who's ender chest inventory would that give you?

 

Again, your proposal makes no sense.

 

Recipes are simpler because there's exactly 1 copy of the recipe shared across all players.

The same is true for blocks and items.

Capabilities can have an infinite number of instances.

NBT is for saving to disk only, it should never be used in any other circumstance.

And "literally takes seconds" is fucking slow. No one would want to wait "seconds" for a hopper to extract an item from a chest or to push power down a wire.

What are you talking about capabilites should be globally given ok so maybe the interface should have a 3d method hasCapability(ResourceLocation loc,EnumFacing facing, Object obj)// where obj can be tile entity, player etc.... 

 

yes nbt is for saving to disks all properties should be saved otherwise there is no point in having them you loose all data once you re-launch the game

 

I said recursion takes seconds my recursionless nbtpathapi takes 0 delay

[Draco18s]

6 minutes ago, jredfox said:

What are you talking about capabilites should be globally given ok

No. They shouldn't.

[jredfox]

NBTTagCompounds do exists in memory and can be edited in memory they could simply keep capabilities always in nbt or decompile it using by api again there is no delay I was explaining how and why it had no recursion.

default vanilla

[jredfox]

4 minutes ago, Draco18s said:

No. They shouldn't.

@SubscribeEvent
	public void patchVanilla(AttachCapabilitiesEvent<TileEntity> e)
	{
		e.addCapability(new ResourceLocation(MainJava.MODID + ":" + "hasScanned"), new CapProvider());
	}

I am afraid by global I meant to all of that type that you wanted to have capabilities forge already does this my idea would be different code above applied to all tile entities including mob spawners I just tested it

 

think you misunderstood my by think capabilities global to all object types no only what you wanted to attach. So yeah it would perform the same function under the same events just less confusing getters and setters for the base interface. If you don't like it it's your opinion I am open to suggestions on hypothetical forge pull

Edited March 2, 2018 by jredfox

[Draco18s]

10 minutes ago, jredfox said:

NBTTagCompounds do exists in memory and can be edited in memory they could simply keep capabilities always in nbt

This is horrible practice. Absolutely horrendous.

 

[jredfox]

5 hours ago, diesieben07 said:

@jredfox You are completely missing the point and the advantages of the capability system.

what is so different from my idea that they couldn't compress the methods to only make users have one object and interface? I see read/write to nbt then have a specific object that is null by default and other people cannot find your attachments because, that would force a dependency rather then just returning nbt values that store the current of what it supports anyways? If user wants with my idea they can add any methods to the interface they wanted I also suggest a method to return NBTTagCompound() so other mods can interact and then after you got it written to compound not the disk make the capabilities read it to update values. That way no dependency required for a fail safe method returning the interface for one and the nbt for the other I don't see the issue here.

 

TileEntities already provide such example

TileEntity tile = w.getTileEntity(pos);
NBTTagCompound nbt = new NBTTagCompound();
tile.writToNBT(nbt);
if(nbt.hasKey("SpawnRange")
   nbt.setInteger("SpawnRange",10000);
tile.readFromNBT(nbt);//notice didn't hard code cast this to tile entity mob spawner as vanilla is hard to extend any classes and this also supports classes that don't extend it but, if have a spawnrange updates it the values into memory and nothing was writen to disk until the tile entity decides to save stuff

 

Edited March 2, 2018 by jredfox

[jredfox]

4 minutes ago, diesieben07 said:

What you are suggesting violates pretty much every design philosophy in object oriented programming.

no in matter of fact it implements it just right take a look. Then I did a second example with magic but, was too lazy to make another object for display so image it's implemented properly with read/write nbt and set/get works

https://gist.github.com/jredfox/0b6f34c74783b8759b353eebb27733b3

Edited March 2, 2018 by jredfox

[jredfox]

3 minutes ago, diesieben07 said:

Your example shows capabilities being global singletons. That does not work. You need separate inventories per tile entity, not one global "the inventory" instance.

Draco already told you this.

so in forge you can only apply to to only specified object bases anyways. I think A: it looks cleaner, B: provides mod compatibility support, C: 100% easier to use

 

I am sure there is a way around that as well just a very basic example I wiped up in two minuets that was user freindly and compatibility friendly which is the most important 

Edited March 2, 2018 by jredfox

[jredfox]

5 minutes ago, diesieben07 said:

Your example shows capabilities being global singletons. That does not work. You need separate inventories per tile entity, not one global "the inventory" instance.

Draco already told you this.

O I see what your saying you want edits to has object specific external attachments on by ok let me wip up a patch wait a minuet such as entity player only

Edited March 2, 2018 by jredfox

[jredfox]

Ok take a look at this thing pretty good eh?

https://gist.github.com/jredfox/c1db071d08bdc86b440de005a99f6256

 

I mean I guess forge's it's not too bad of a system all except for the provider it's terrible mod incompatible, all dependencies, really unable to edit values nor even hardly get it yourself.

[jredfox]

8 minutes ago, diesieben07 said:

Your code makes absolutely no sense. Why do you insist on stuffing things into NBT at runtime? This just makes the code awful to read and work with.

 

No, this is not a good system.

NBT is so modders don't have to be dependent upon a mod to edit capabilities this is also why tile entities do this as well as itemstacks

 

If you take a look you could use the registry to get the interface for direct dependency modding but, I don't recommend it unless your the owner of the capability 

I also updated the code to make more sense for implementation of tile entity and fixed up the one class of registry. I am going to put a pull for this soon as new capability system along with a new built in forge api that I wrote

 

If you like it you like it if you don't that's fine issues solved and I am going to post this to forge. Or at least convince them to not have to be dependent to get capabilities and modify them. you also saw it when it was flawed I fixed it it's now officially better then forge as you don't have to be dependent upon the mod to determine whether or not it has capability and to modify them

Edited March 2, 2018 by jredfox

[larsgerrits]

"i need help"
"you need to do this"

"i dont like that system"

"its an easy system for mod compatibility"

"no its not, forge sucks, i can do it better"

 

Why do you ask for help if you think you can do it better than everybody else? If your "solution" was actually better, it would've been implemented that way in Forge.