I am still trying to learn how to best use the new Capabilities features in Forge. I have set up two completely separate capabilities, one that adds a thirst attribute to players and one that adds a set of booleans to players to keep track of hints I give out as they play. Each of these two capabilities has their own interface, provider, and storage classes. I have a single capability handler that attaches the capabilities to the player.

 

I think I could mash both of them together into a single Capability. But would that be wise? It seems cleaner as is. I'm not sure what the pros and cons would really be. I'm planning to add more capabilities soon, like a custom player inventory, and I want to go forward in a good way.

Think of it this way. You have two drawers filled with information and they have nothing to do with each other except that they are for about the same person. Do you put the two drawers into one and make it less organized and take longer to find what you need, or do you keep them separate and easier to find what you need? Also if you keep them separate then there is less data to get when you call the getCapability method.

I think I could mash both of them together into a single Capability. But would that be wise? It seems cleaner as is. I'm not sure what the pros and cons would really be. I'm planning to add more capabilities soon, like a custom player inventory, and I want to go forward in a good way.

 

The question is more along the lines of software design and best practice than something relate to Capabilities.  Your "it seems cleaner as is" is a pretty good indication of what you should do.  I personally would keep them separate because that is the way I think and it fits within most OOP practices.  Main benefits that I would see in keeping them separate:

 

• Organization.  If you see an something labeled "Utensil Drawer" you know you can find your utensils there.
  
• Maintenance.  Overtime your mod will grow and if you have a single Capability you pack things into its going to get unwieldy.
  
• Public API.  Not sure if this is a requirement for you, but keeping things separate would help facilitate making an API.  You may want "thrist" available to other mods, but not the "tracking" data.
  

That's the way I was leaning. I started to get a little worried about the sheer number of files that will be in my capabilities package, considering all the capabilities I want to add in the future. But I can definitely see how it would get unwieldy to mash all the capabilities together.

 

I don't have an API in my sights yet. If I get requests for it, I might try to learn how to do it, but things are going slowly enough that I'm not sure I'll even finish the dang mod to begin with.