Closed ttk2 closed 9 years ago
How often does this happen?
every 5-10 seconds
On Mon, Nov 3, 2014 at 9:34 PM, rourke750 notifications@github.com wrote:
How often does this happen?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61588873.
Is it constant throughout the entire day or just for periods. If its peorids I'm sure its a null group issue. On Nov 4, 2014 4:17 PM, "ttk2" notifications@github.com wrote:
every 5-10 seconds
On Mon, Nov 3, 2014 at 9:34 PM, rourke750 notifications@github.com wrote:
How often does this happen?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61588873.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61716077.
just periods
On Tue, Nov 4, 2014 at 5:44 PM, rourke750 notifications@github.com wrote:
Is it constant throughout the entire day or just for periods. If its peorids I'm sure its a null group issue. On Nov 4, 2014 4:17 PM, "ttk2" notifications@github.com wrote:
every 5-10 seconds
On Mon, Nov 3, 2014 at 9:34 PM, rourke750 notifications@github.com wrote:
How often does this happen?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61588873.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61716077.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61736127.
this is happening continuously.
https://github.com/Civcraft/JukeAlert/blob/master/src/com/untamedears/JukeAlert/util/OnlineGroupMembers.java#L146 is a bug. It needs to convert the member name to a UUID object before calling Bukkit.getPlayer().
Same thing at https://github.com/Civcraft/JukeAlert/blob/master/src/com/untamedears/JukeAlert/util/OnlineGroupMembers.java#L134 and https://github.com/Civcraft/JukeAlert/blob/master/src/com/untamedears/JukeAlert/util/OnlineGroupMembers.java#L162 .
On Wed, Nov 5, 2014 at 9:41 PM, ttk2 notifications@github.com wrote:
this is happening continuously.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-61930084.
what new jars do I need to pull?
On Thu, Nov 6, 2014 at 6:06 PM, rourke750 notifications@github.com wrote:
2074354 https://github.com/Civcraft/JukeAlert/commit/2074354edd5b5aa88a704c4bf3d1c1183ee653c6
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62074825.
I grabbed the new JukeAlert jar still getting the stack.
yay. Same stack or different?
On Mon, Nov 10, 2014 at 10:32 AM, ttk2 notifications@github.com wrote:
I grabbed the new JukeAlert jar still getting the stack.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62400782.
looks identical to me.
On Mon, Nov 10, 2014 at 9:38 AM, rourke750 notifications@github.com wrote:
yay. Same stack or different?
On Mon, Nov 10, 2014 at 10:32 AM, ttk2 notifications@github.com wrote:
I grabbed the new JukeAlert jar still getting the stack.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62400782.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62401689.
The stack shouldn't be different. Can you past it so we can be double sure.
2014-11-10 10:47:05 [ERROR] Could not pass event PlayerMoveEvent to JukeAlert v1.2.4 org.bukkit.event.EventException at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:302) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:502) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:487) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.PlayerConnection.a(PlayerConnection.java:249) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.PacketPlayInFlying.a(SourceFile:137) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.PacketPlayInPosition.handle(SourceFile:63) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.NetworkManager.a(NetworkManager.java:184) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.ServerConnection.c(ServerConnection.java:81) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.MinecraftServer.v(MinecraftServer.java:734) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.DedicatedServer.v(DedicatedServer.java:289) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.MinecraftServer.u(MinecraftServer.java:584) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.MinecraftServer.run(MinecraftServer.java:490) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.ThreadServerApplication.run(SourceFile:628) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] Caused by: java.lang.IllegalArgumentException: Name cannot be null at org.apache.commons.lang.Validate.notNull(Validate.java:192) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.craftbukkit.v1_7_R4.CraftServer.getPlayerExact(CraftServer.java:543) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.Bukkit.getPlayerExact(Bukkit.java:450) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at com.untamedears.citadel.entity.FactionMember.getPlayer(FactionMember.java:48) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.getNextMember(OnlineGroupMembers.java:162) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.getPlayerByState(OnlineGroupMembers.java:182) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.getNextPlayer(OnlineGroupMembers.java:228) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.startIterating(OnlineGroupMembers.java:125) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.iterator(OnlineGroupMembers.java:118) ~[?:?] at com.untamedears.JukeAlert.util.Utility.notifyGroup(Utility.java:47) ~[?:?] at com.untamedears.JukeAlert.listener.JukeAlertListener.enterSnitchProximity(JukeAlertListener.java:353) ~[?:?] at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_65] at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_65] at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:298) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] ... 13 more
On Mon, Nov 10, 2014 at 9:45 AM, rourke750 notifications@github.com wrote:
The stack shouldn't be different. Can you past it so we can be double sure.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62402868.
This is a new stack. I assume that there's a non-existent member in some group which doesn't map back via the Citadel lookup table.
Wasn't this going to be migrated to use NameLayer?
No its the same bug just with citadel. The bukkit.getplayerexact throws an error if it tries getting a player that isn't online. On Nov 11, 2014 5:02 PM, "erocs" notifications@github.com wrote:
This is a new stack. I assume that there's a non-existent member in some group which doesn't map back via the Citadel lookup table.
Wasn't this going to be migrated to use NameLayer?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62630186.
Do we have a fix in the works?
Was just about to change something and noticed the error was being caused because getPlayerName was returning null. The only time that happens is when nothing is found in namelayer or there is an error looking it up. Maybe the name even in the db is set to null. Can you search?
I don't see any nulls in the namelayer tables.
On Wed, Nov 12, 2014 at 4:53 PM, rourke750 notifications@github.com wrote:
Was just about to change something and noticed the error was being caused because getPlayerName was returning null. The only time that happens is when nothing is found in namelayer or there is an error looking it up. Maybe the name even in the db is set to null. Can you search?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62823331.
What happens if a player associated with a Citadel group hasn't logged in since before NameLayer and/or UUIDs?
There isn't a case. All those names were pulled from mojang. On Nov 13, 2014 11:45 AM, "Travis Christian" notifications@github.com wrote:
What happens if a player associated with a Citadel group hasn't logged in since before NameLayer and/or UUIDs?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62923627.
then who was NULL??? #2spooky4me
sounds like you need some debug logging to see what's getting passed into util and bukkit
No one was null. It was just a derp. Ignore it. On Nov 13, 2014 5:17 PM, "Travis Christian" notifications@github.com wrote:
then who was NULL??? #2spooky4me
sounds like you need some debug logging to see what's getting passed into util and bukkit
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-62976828.
Per comment today from erocs, these are still occurring.
Is the new citadel on. On Nov 18, 2014 2:15 PM, "Pentom" notifications@github.com wrote:
Per comment today from erocs, these are still occurring.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63527508.
I was able to reproduce this by adding something to rurke75's Name_player table - which controls the 'have we seen this user and can we add them to groups' and not adding them to the 'citadel_account_id_map' table. Once I've added a player to the Name_player table and not the citadel version of such, hijinx ensue the moment these users are added to groups as members/founders/moderators. I do not consider this a defect in juke alert.
SQL that is needed to test this (these are the items causing you issues): SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map);
Fun SQL that may help to indicate a problem with your migration script: SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map) AND founder IN (SELECT UUID FROM Name_player); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player);
Also - cases where there is data missing from Name_player tables that exist in the faction tables are cases of bad data. Those need to be scrubbed. This issue appears to be a pure data integrity issue - the data is inconsistent.
Just let's make sure we are using the right citadel. On Nov 18, 2014 6:49 PM, "Pentom" notifications@github.com wrote:
I was able to reproduce this by adding something to rurke75's Name_player table - which controls the 'have we seen this user and can we add them to groups' and not adding them to the 'citadel_account_id_map' table. Once I've added a player to the Name_player table and not the citadel version of such, hijinx ensue the moment these users are added to groups as members/founders/moderators. I do not consider this a defect in juke alert.
SQL that is needed to test this (these are the items causing you issues): SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map);
Fun SQL that may help to indicate a problem with your migration script: SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map) AND founder IN (SELECT UUID FROM Name_player); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player);
Also - cases where there is data missing from Name_player tables that exist in the faction tables are cases of bad data. Those need to be scrubbed. This issue appears to be a pure data integrity issue - the data is inconsistent.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63567962.
This would have helped the situation. https://github.com/Civcraft/Citadel/issues/19
Back to educational accounts which were deleted by Mojang, then re-bought by the owners, thus properly receiving a different UUID, and NameLayer properly improperly renamed them. They had to be manually fixed to get the accounts back to the owners. I know I fixed one in particular but now Name_player and citadel_account_id_map are disagreeing about the correct UUID for the account. I'll fix it again but I'm not sure why the tables have diverged since the last fix.
On Tue, Nov 18, 2014 at 3:48 PM, Pentom notifications@github.com wrote:
I was able to reproduce this by adding something to rurke75's Name_player table - which controls the 'have we seen this user and can we add them to groups' and not adding them to the 'citadel_account_id_map' table. Once I've added a player to the Name_player table and not the citadel version of such, hijinx ensue the moment these users are added to groups as members/founders/moderators. I do not consider this a defect in juke alert.
SQL that is needed to test this (these are the items causing you issues): SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map);
Fun SQL that may help to indicate a problem with your migration script: SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map) AND founder IN (SELECT UUID FROM Name_player); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player);
Also - cases where there is data missing from Name_player tables that exist in the faction tables are cases of bad data. Those need to be scrubbed. This issue appears to be a pure data integrity issue - the data is inconsistent.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63567962.
we are using the latest version of Citadel as of a few days ago, you push changes a lot and don't tell me to update, what version number should we be on?
On Tue, Nov 18, 2014 at 5:54 PM, erocs notifications@github.com wrote:
This would have helped the situation. https://github.com/Civcraft/Citadel/issues/19
Back to educational accounts which were deleted by Mojang, then re-bought by the owners, thus properly receiving a different UUID, and NameLayer properly improperly renamed them. They had to be manually fixed to get the accounts back to the owners. I know I fixed one in particular but now Name_player and citadel_account_id_map are disagreeing about the correct UUID for the account. I'll fix it again but I'm not sure why the tables have diverged since the last fix.
N
On Tue, Nov 18, 2014 at 3:48 PM, Pentom notifications@github.com wrote:
I was able to reproduce this by adding something to rurke75's Name_player table - which controls the 'have we seen this user and can we add them to groups' and not adding them to the 'citadel_account_id_map' table. Once I've added a player to the Name_player table and not the citadel version of such, hijinx ensue the moment these users are added to groups as members/founders/moderators. I do not consider this a defect in juke alert.
SQL that is needed to test this (these are the items causing you issues): SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map);
Fun SQL that may help to indicate a problem with your migration script: SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map) AND founder IN (SELECT UUID FROM Name_player); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player);
Also - cases where there is data missing from Name_player tables that exist in the faction tables are cases of bad data. Those need to be scrubbed. This issue appears to be a pure data integrity issue - the data is inconsistent.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63567962.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63568560.
sorry, yea we are on the latest.
On Tue, Nov 18, 2014 at 9:34 PM, ttk2 notifications@github.com wrote:
we are using the latest version of Citadel as of a few days ago, you push changes a lot and don't tell me to update, what version number should we be on?
On Tue, Nov 18, 2014 at 5:54 PM, erocs notifications@github.com wrote:
This would have helped the situation. https://github.com/Civcraft/Citadel/issues/19
Back to educational accounts which were deleted by Mojang, then re-bought by the owners, thus properly receiving a different UUID, and NameLayer properly improperly renamed them. They had to be manually fixed to get the accounts back to the owners. I know I fixed one in particular but now Name_player and citadel_account_id_map are disagreeing about the correct UUID for the account. I'll fix it again but I'm not sure why the tables have diverged since the last fix.
N
On Tue, Nov 18, 2014 at 3:48 PM, Pentom notifications@github.com wrote:
I was able to reproduce this by adding something to rurke75's Name_player table - which controls the 'have we seen this user and can we add them to groups' and not adding them to the 'citadel_account_id_map' table. Once I've added a player to the Name_player table and not the citadel version of such, hijinx ensue the moment these users are added to groups as members/founders/moderators. I do not consider this a defect in juke alert.
SQL that is needed to test this (these are the items causing you issues): SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map);
Fun SQL that may help to indicate a problem with your migration script: SELECT * FROM faction WHERE founder NOT IN (SELECT account FROM citadel_account_id_map) AND founder IN (SELECT UUID FROM Name_player); SELECT * FROM faction_member WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player); SELECT * FROM moderator WHERE member_name NOT IN (SELECT account FROM citadel_account_id_map) AND member_name IN (SELECT UUID FROM Name_player);
Also - cases where there is data missing from Name_player tables that exist in the faction tables are cases of bad data. Those need to be scrubbed. This issue appears to be a pure data integrity issue - the data is inconsistent.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63567962.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63568560.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63583167.
@ttk2 do you want Jenkins to send you an email or something whenever a build succeeds?
no, I want devs to let me know when they are just patching stuff that can go online whenever and when I should pull a jar for a specific issue.
On Tue, Nov 18, 2014 at 9:21 PM, Travis Christian notifications@github.com wrote:
@ttk2 https://github.com/ttk2 do you want Jenkins to send you an email or something whenever a build succeeds?
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63586620.
Clarification: As this appears to be a data integrity issue, can I assume that either erocs/ttk/arieh are reviewing and fixing? I can provide scripts if truly desired, but these things are best handled by the db operators who actually have access - so one of you three.
If you can validate that someone above is owning this fix, I will ignore this ticket and move on.
Yes, I own the DB maintenance. On Nov 19, 2014 12:12 PM, "Pentom" notifications@github.com wrote:
Clarification: As this appears to be a data integrity issue, can I assume that either erocs/ttk/arieh are reviewing and fixing? I can provide scripts if truly desired, but these things are best handled by the db operators who actually have access - so one of you three.
If you can validate that someone above is owning this fix, I will ignore this ticket and move on.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#issuecomment-63705369.
Ticket ignored as pending fix and I am moving on. Thanks.
@erocs @ttk2 Is this still occurring or should we close the issue?
meh
still occuring.
On Mon, Nov 24, 2014 at 1:13 PM, rourke750 notifications@github.com wrote:
Closed #5 https://github.com/Civcraft/JukeAlert/issues/5.
— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/5#event-197801969.
2014-11-03 09:02:25 [ERROR] Could not pass event PlayerMoveEvent to JukeAlert v1.2.3 org.bukkit.event.EventException at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:302) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:502) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:487) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.PlayerConnection.a(PlayerConnection.java:249) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.PacketPlayInFlying.a(SourceFile:137) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.PacketPlayInLook.handle(SourceFile:98) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.NetworkManager.a(NetworkManager.java:184) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.ServerConnection.c(ServerConnection.java:81) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.MinecraftServer.v(MinecraftServer.java:734) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.DedicatedServer.v(DedicatedServer.java:289) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.MinecraftServer.u(MinecraftServer.java:584) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.MinecraftServer.run(MinecraftServer.java:490) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at net.minecraft.server.v1_7_R4.ThreadServerApplication.run(SourceFile:628) [spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] Caused by: java.lang.IllegalArgumentException: Name cannot be null at org.apache.commons.lang.Validate.notNull(Validate.java:192) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.craftbukkit.v1_7_R4.CraftServer.getPlayerExact(CraftServer.java:543) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at org.bukkit.Bukkit.getPlayerExact(Bukkit.java:450) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] at com.untamedears.JukeAlert.util.OnlineGroupMembers.getNextModerator(OnlineGroupMembers.java:146) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.getPlayerByState(OnlineGroupMembers.java:177) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.getNextPlayer(OnlineGroupMembers.java:228) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.startIterating(OnlineGroupMembers.java:127) ~[?:?] at com.untamedears.JukeAlert.util.OnlineGroupMembers.iterator(OnlineGroupMembers.java:120) ~[?:?] at com.untamedears.JukeAlert.util.Utility.notifyGroup(Utility.java:47) ~[?:?] at com.untamedears.JukeAlert.listener.JukeAlertListener.enterSnitchProximity(JukeAlertListener.java:349) ~[?:?] at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_65] at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_65] at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:298) ~[spigot.jar:git-Spigot-1.7.9-R0.2-203-g02dec9b] ... 13 more