Jump to content

[1.10.2] How to handle multiple player capabilities


Daeruin

Recommended Posts

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.

Link to comment
Share on other sites

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.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.