[Free] Bria KitPvP core base [Open-Source]

[Scifi]

Made this for fun while live streaming on and off and decided to release it to the public with that being said it is far from completed but it will be maintained. Feedback / Contributions to the project would be very appreciated and I hope to improve my portfolio by increasing the amount of things I have open-sourced.

Features:

Credits System, Eatable Soup, Started Kits (May add abilities aswell), Scoreboard added.

Requirements: MongoDB (Most likely will make a flat-file option aswell)

ToDO: Finish kits, implement kit selector, implement tablist, killstreaks and add other suggested features.


Link: https://github.com/Scifi9902/Bria

Credits: NV6 - Tablist API (Not yet implemented), ThatKawaiiSam - Scoreboard API

 

[ChrisDZN]

Vouch for this anime fan!

 

[Scifi]

Vouch for this anime fan!

Thank you

 

[NV6]

A few suggestions -

• Add a .gitignore file to remove the unnecessary files.
• Remove the credit handler, you have profiles for a reason.
• Use finals.
• Move the soup listener outside of the KitListener class - this is not supposed to be in here.
• Use a Map<UUID, Profile> instead of a List<Profile> for (approximately) O(1) lookup times whenever finding the profile.
• Use Bukkit's built in statistics tracker for kills/deaths, this is just unnecessary data since you can already retrieve it in a different way.
• The 2 if statements inside of the scoreboard class don't really make sense to me - especially the if statement to check if the lines aren't empty.
• Remove the Pair<K, V> class, I see no point in using this, and if you need to use anything similar for some weird reason, you could always use a Map.Entry<K, V>.
• Remove the Config object for the default config.yml. Spigot has built in functionality inside of JavaPlugin for this, you don't need this class unless you're doing any configuration caching inside of this class (which you currently aren't).
• A few more things, can't be arsed to look through the code right now.

Also, besides that, I'd recommend looking into saving flatfile instead of using a database - the data you're saving is only required on the KitPvP server itself - not on any other server (unless you're planning to use this on multiple proxies), so I'd at least add support for flatfile saving instead of MongoDB or any other database.

Other than that, as long as it's just a fun project, it looks fine. I'd suggest looking into the suggestions I provided above.

 

[Scifi]

A few suggestions -

• Add a .gitignore file to remove the unnecessary files.
• Remove the credit handler, you have profiles for a reason.
• Use finals.
• Move the soup listener outside of the KitListener class - this is not supposed to be in here.
• Use a Map<UUID, Profile> instead of a List<Profile> for (approximately) O(1) lookup times whenever finding the profile.
• Use Bukkit's built in statistics tracker for kills/deaths, this is just unnecessary data since you can already retrieve it in a different way.
• The 2 if statements don't really make sense to me - especially the if statement to check if the lines aren't empty.
• Remove the Pair<K, V> class, I see no point in using this, and if you need to use anything similar for some weird reason, you could always use a Map.Entry<K, V>.
• Remove the Config object for the default config.yml. Spigot has built in functionality inside of JavaPlugin for this, you don't need this class unless you're doing any configuration caching inside of this class (which you currently aren't).
• A few more things, can't be arsed to look through the code right now.

Also, besides that, I'd recommend looking into saving flatfile instead of using a database - the data you're saving is only required on the KitPvP server itself - not on any other server (unless you're planning to use this on multiple proxies), so I'd at least add support for flatfile saving instead of MongoDB or any other database.

Other than that, as long as it's just a fun project, it looks fine. I'd suggest looking into the suggestions I provided above.

Will do, thanks for the suggestions.

 

[Morals]

• Use Bukkit's built in statistics tracker for kills/deaths, this is just unnecessary data since you can already retrieve it in a different way.

You don't want to track stats that way, you want to make your own handler for deaths/kills, especially for a kitpvp server.

 

[NV6]

You don't want to track stats that way, you want to make your own handler for deaths/kills, especially for a kitpvp server.

And why would you not?

 

[sores]

https://github.com/Scifi9902/Bria/b...github/scifi9902/bria/kit/KitHandler.java#L12
I'm assuming this is intended to be used to track players and their selected kits. You could instead store a kit object in their profile and set that when a kit is applied, and track it that way instead.

In the pay command you should make sure they're not paying themselves.

Other than that and the above mentioned stuff it's not a bad little project, keep it up!

 

[NV6]

https://github.com/Scifi9902/Bria/b...github/scifi9902/bria/kit/KitHandler.java#L12
I'm assuming this is intended to be used to track players and their selected kits. You could instead store a kit object in their profile and set that when a kit is applied, and track it that way instead.

In the pay command you should make sure they're not paying themselves.

Other than that and the above mentioned stuff it's not a bad little project, keep it up!

I think having a hash map inside of the kit handler isn't a bad idea - if you'd store it inside of the Profile object, you'd need the Profile object to retrieve the player's current selected Kit - but now you can just get the kit through the KitHandler.

And about the pay command, there are a few changes needing changes,

• The payment will proceed even if the target's profile doesn't exist - this means:
  • The player who paid the money will lose the money.
  • The target who should receive the money will not receive any money.

Also, a small thing for the CreditHandler class (which I previously already mentioned, should perhaps be completely removed since you already have a Profile class for this), you should perhaps change the Optional#isPresent checks with a Optional#ifPresent(Consumer<Profile>).

I can also tell parts of this plugin are inspired from the KitPvP base I released a few days ago (https://github.com/NoSequel/KitPvP/), things such as mentioned by sores (the equipped kit map), the methods to get the health type and sword inside of the abstract kit class, the Kit#applyKit method, and potentially more. Not saying this is a bad idea, just mentioning this.

 

[LillianA]

Use finals

What's the point of spamming final everywhere?

 

[NV6]

What's the point of spamming final everywhere?

For global variables - compiler optimizations, less bytecode.
For local variables - although technically unnecessary, consistency with the global variables, and readability in case other developers work on the project (showing which variables should be changed - and which not).

 

[LillianA]

For global variables - compiler optimizations, less bytecode.
For local variables - although technically unnecessary, consistency with the global variables, and readability in case other developers work on the project (showing which variables should be changed - and which not).

I agree with global variables, Local variables is where I disagree though. I feel like it just adds more clutter to everything making it harder to read for some people with no real benefit IMO but it's down preferences at this point. I more or less thought you meant literally everywhere including function signatures which is definitely where I hard disagree with its usage.

 

[NV6]

I agree with global variables, Local variables is where I disagree though. I feel like it just adds more clutter to everything making it harder to read for some people with no real benefit IMO but it's down preferences at this point. I more or less thought you meant literally everywhere including function signatures which is definitely where I hard disagree with its usage.

That's completely fair, and I completely agree it comes down to personal preference. The main thing I meant in my original post was global variables, which I should've specified, or at least made more clear. Also thanks for giving your own opinion.

 

[Scifi]

I think having a hash map inside of the kit handler isn't a bad idea - if you'd store it inside of the Profile object, you'd need the Profile object to retrieve the player's current selected Kit - but now you can just get the kit through the KitHandler.

And about the pay command, there are a few changes needing changes,

• The payment will proceed even if the target's profile doesn't exist - this means:
  • The player who paid the money will lose the money.
  • The target who should receive the money will not receive any money.

Also, a small thing for the CreditHandler class (which I previously already mentioned, should perhaps be completely removed since you already have a Profile class for this), you should perhaps change the Optional#isPresent checks with a Optional#ifPresent(Consumer<Profile>).

I can also tell parts of this plugin are inspired from the KitPvP base I released a few days ago (https://github.com/NoSequel/KitPvP/), things such as mentioned by sores (the equipped kit map), the methods to get the health type and sword inside of the abstract kit class, the Kit#applyKit method, and potentially more. Not saying this is a bad idea, just mentioning this.

Indeed, this is due to kits currently being statically coded though they will be created in game soon. as for the kit map thats because I was gonna add classes.

 

[Morals]

And why would you not?

If you handle all deaths and kills yourself, you can control what counts as a death or a kill. Using bukkit's system, I don't think you can, and if you can, it requires more work.

 

[Scifi]

If you handle all deaths and kills yourself, you can control what counts as a death or a kill. Using bukkit's system, I don't think you can, and if you can, it requires more work.

All deaths are handled the same way I believe because no matter what they trigger the PlayerDeathEvent, with that being said I believe theirs an Event#getCause method with the PlayerDeathEvent so you could go based off of the cause (Could be wrong)

 

[IrishTheGod]

Great idea!