OnDeath Event not working

Hey bukkit forums, I'm having a bit of trouble!
And I hope you guys can help!

Well, my first problem is, I have two kits that when you use them, and then you go in water, you get potioneffects BUT, when you die, it doesn't remove the kit. Idk why
My onDeath event

Code:

@EventHandler
public void onKit(PlayerDeathEvent e) {
Player p = (Player) e.getEntity();
if(poseidon.contains(p.getName())){
poseidon.remove(p.getName());
if(shark.contains(p.getName())){
shark.remove(p.getName());
}
}
}

 

I'm guessing shark and poseidon are hashmaps? Do you check if the player is in the hashmap before applying the potion effects?

Add some println()'s to see what's going on when a player dies.

 

Code:java

@EventHandler
public void onKit(PlayerDeathEvent e) {
Player p = (Player) e.getEntity();
 
if(poseidon.contains(p.getUniqueId())){
   poseidon.remove(p.getUniqueId());
}
 
if(shark.contains(p.getUniqueId())){
shark.remove(p.getUniqueId());
}
}
 
 

I think this is what you want (change String to UUID in HashMaps, storing information is being changed to this format to get ready for the ability to change your Minecraft names.) You also don't want the second if statement inside the first.

 

NerdsWBNerds kennethbgoodin
Actually, if it's only being used for the duration of when the player is online it is safe to use their names. No need to hassle for UUID implementations if they are just going to be required to be online to use kits and such. What you should be using with UUIDs is for stroing information tied to the player to a form of a database or file for later use.

All deprecation is to raise awareness of UUIDs and [the deprecation warning] will be removed in 1.8 if not already.

 

Gater12 @NerdsWBNerd

So you guys want me to use a hashmap not an arraylist to store the player in the two kits?

 

Arraylists would probably work, I recommend UUID because getting used to storing it with that is nice, and you can get into trouble with .contains and case sensitivity of names, where UUID doesn't have that problem.

 

NerdsWBNerds Properly knowing when to use UUID vs the Player's name is also nice, which if the lists are only used for the duration that the Player is online, then UUID is not needed.
Fhbgsdhkfbl Can we see where you declare/initialize the ArrayLists?

 

It can be nice, but I find it easier to use it all the time, don't have to .toLowerCase() all the time. If I'm storing a name that will be accessed and displayed later, I'll store by the name, but I still prefer the UUID because from it I can easily get the player and their full, styled name.

 

NerdsWBNerds You shouldn't have to manipulate the Player's name when storing it in anyway, as it will never change in the session that they are online. And, I believe using a UUID vs a String may be more resource intensive (might be such a small ammount that the difference doesn't matter, but its still a difference)
From the String you can also get the player and their full, styled name (as long as its same-session), as the methods for getting it by-string are only temporarily deprecated, and still work.

 

To remove a players inventory contents then you simply do

Code:java

p.getInventory().clear();
p.updateInventory();

 

Gater12
I didn't say anything about UUID usage, I was asking about his actual HashMap usage.

But I can't see any reason for not using UUIDs; it's either use them, or remove a player from HashMaps when they disconnect. I'm not sure what hassle you're talking about regarding UUIDs.

 

kennethbgoodin
I'd do not mean to Tahg you.

 

xTigerRebornx

Code:

public List<String> poseidon = new ArrayList<String>();
public List<String> shark = new ArrayList<String>();

 

If you are going to have players parsing an arraylist with a command (/stats <name>) the case sensitivity does matter because .contains is case sensitive, and players don't always type names out case correctly.

 

NerdsWBNerds If you had a stats command, then you'd need some sort of way of changing that name to a UUID, since you would be storing those stats.
Fhbgsdhkfbl Are those in the same class as the command/event that adds them to the other Lists? If not, then you need to be using the same instance of the list across all classes, and refer to the same one every time you want to manipulate them.

 

xTigerRebornx

It's in the same class as the PlayerDeathEvent, but not the kits. they're in seperate classes.

 

Fhbgsdhkfbl Like I said, you need to make sure you are referencing the same List<> when you both add them and remove them, I'd recommend keeping them both in your class that extends JavaPlugin, then pass an instance of that class through each class' constructor that requires access to the Lists

 

xTigerRebornx

My main class extends JavaPlugin.
Should I have my kit classes extend JavaPlugin also? It does Commandexecutor

 

Fhbgsdhkfbl
Only have one class extends JavaPlugin if you make a new instance of a class that also extends JavaPlugin other than your main class in your plugin, it will throw an error saying the plugin is already initialized.

 

Fhbgsdhkfbl No, have the 2 List<String> in your main class. Then pass the main class into the classes that need to access those lists through the constructor
I.E.

Code:

private MainClass plugin;
 
public YourCommandListener(MainClass p){
  this.plugin = p;
}

Where MainClass is your main class, and YourCommandListener is the class that implements CommandExecutor.
Then, you can simply use the variable plugin to access the List<String> and properly use it.

 

xTigerRebornx
I have that, I just don't know why it's not removing the kit when the player dies.

Code:

private Main plugin;
public PoseidonKit(Main plugin) {
this.plugin = plugin;
}

 

Fhbgsdhkfbl You have that, but are you using the same thing for everytime you give someone a kit or remove their kit?

 

xTigerRebornx

Im not sure, do you have skype? it would make this so much easier.

if not:

I don't know if I'm doing that.

 

Hello there!

First what you want to do is make sure your event has been registered:

Code:java

 
getServer().getPluginManager().registerEvents(new EventClass(), this);
// OR if the even is in your main class, do this:
getServer().getPluginManager().registerEvents(this, this);
 

Next, make sure your event class looks something like this:

Code:java

 
package com.mrgreen33gamer.c;
 
import java.util.ArrayList;
 
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.PlayerDeathEvent;
 
public class YourEventClass implements Listener{
 
public Main plugin;
 
public static ArrayList<String> poseidon = new ArrayList<String>();
public static ArrayList<String> shark = new ArrayList<String>();
 
public YourEventClass(Main instance){
plugin = instance;
instance = plugin;
}
 
@EventHandler
public void onKit(PlayerDeathEvent e) {
Player p = e.getEntity().getPlayer();
 
if(poseidon.contains(p.getUniqueId())){
poseidon.remove(p.getUniqueId());
}
 
if(shark.contains(p.getUniqueId())){
shark.remove(p.getUniqueId());
}
}
 
}
 

Or if you want your main class to contain the event, do here it is:

Code:java

 
package com.mrgreen33gamer.c;
 
import java.util.ArrayList;
 
import org.bukkit.entity.Player;
import org.bukkit.event.EventHandler;
import org.bukkit.event.Listener;
import org.bukkit.event.entity.PlayerDeathEvent;
import org.bukkit.plugin.java.JavaPlugin;
 
public class YourEventClass extends JavaPlugin implements Listener{
 
public static YourEventClass plugin;
 
Logger logger = Logger.getLogger("Minecraft");
public static ArrayList<String> poseidon = new ArrayList<String>();
public static ArrayList<String> shark = new ArrayList<String>();
 
public YourEventClass(YourEventClass instance){
plugin = instance;
instance = plugin;
}
 
@Override
public void onEnable(){
plugin = this;
getServer().getPluginManager().registerEvents(this, this);
}
 
@Override
public void onDisable(){
//Nothing in here
}
 
@EventHandler
public void onKit(PlayerDeathEvent e) {
Player p = e.getEntity().getPlayer();
 
if(poseidon.contains(p.getUniqueId())){
poseidon.remove(p.getUniqueId());
}
 
if(shark.contains(p.getUniqueId())){
shark.remove(p.getUniqueId());
}
}
 
}
 

And yes, I like to spoon-feed because it helps the poster get help fast.

 

mrgreen33gamer Spoon-feeding hurts way more then it helps. You are simply tossing code at the person saying "Here, this code works, use this" instead of actually helping them and getting them to understand what their problem is and how to fix it. We don't spoon-feed code around here because, most of the time, it will just have people come back with more problems because the that they were given doesn't work, or it causes problems, and then they can't fix the problems because all they've learned from people spoon-feeding is that they (think) they can come here and just ask for help, then expect code to be handed to them, or they try and get help, and people tell them the generic responses such as "Learn Java".

td;lr Don't spoon-feed. It doesn't help as much as you think it does.

 

Well if these people want them help, I give them the help. Besides, why are you all up in my business? And I thought you were smart

 

Fhbgsdhkfbl Reading through all the posts, I'm still not sure what "remove the kit" actually means exactly. Is it just from the list, or is it (as I suspect) something more than that? It would be easier if you show us the full code.

mrgreen33gamer The point xTigerRebornx is making is that you're not "helping" you're "doing it for them". If they want a plugin made, they should go to Plugin Requests. Do you really think that everybody you "help" is going to read the code you give them and try to understand it? Because I don't. Whereas, the people that have to try and work it out themselves, because we don't five them another option? They're much more likely to have to learn it, because it doesn't just magically appear on their screen for them.

xTigerRebornx Are you against the "Learn Java" response? Because sometimes it really is necessary, if they don't know it. If someone came to me asking me to help them to ride a bike and they didn't know how to walk, I'd say "Learn to walk first, then I'll help you".

NerdsWBNerds Sure, contains() is case sensitive, and sure that can cause problems when taking input from a user. But the simple fact here is that he's (I assume) using getName() to temporarily store the player's kit. No persistence or user input required. It's not like getName() has a random chance of changing some capitals about for the fun of it. As xTigerRebornx (3rd tag for you in this post... I'm not targetting you deliberately, honest ) was saying - it's easy to always use UUID because they work for different cases too. It's easy to always use .equals() instead of == for enums because equals() works for different cases too. It's easy to make fields public and static as you can always access them in different situations. But that's not the point. There always has been and always will be more than one way of doing certain things in programming. But the real beauty in it is knowing the difference of when to use each way.

 

AdamQpzm I am not against the 'learn Java' response, I am simply saying that people who go and copy-paste code instead of learning and building their code on their own will get that response because they don't know Java (or the person who posted the responses judged that they don't know Java from the code provided).
Fhbgsdhkfbl I do have Skype, feel free to PM me yours if you want me to add you.
mrgreen33gamer When you post huge chunks of code, saying "this is the code you want", that is no help. They learn nothing, and if they are new to the forums, they might expect that is how it always works when they post here, and the next time they come, they'll simply try to get people to post code. Spoon-feeding doesn't help anyone, which is why it is highly discouraged here, and it is even more discouraged when you go and hand out code that is improper (Your improper use of statics, other things) or the code just might not work at all (You don't provide a blank constructor for your class that extends JavaPlugin, which I believe causes an error)
AdamQpzm Agreed on that last sentence