Only ops are able to program command blocks, so that should narrow the list of suspects. Some (virtual) face time with your ops should reveal the guilty party.
In the meantime, if your map doesn't rely heavily on command blocks, they can be disabled by setting enable-command-block=false
in the server.properties
file and restarting the server.
To locate the offending block you can render the world map showing just command blocks and redstone, using one of the many 3rd-party cartography tools. (I quite like Minecraft Overviewer for this use, and though it's not technically 1.4.6-up-to-date, it can handle Anvil and custom block IDs so it's still compatible.) This will give you a high-level view of the problem and let you zero in on the possible culprits. Compare it to a regular overworld render to find a recognisable landmark nearby, then fly/tp there, unearth it, and render it inoperable.
Fixing your command
Your problem here is that you are mixing up target selector arguments with data tags, and then some minor mistakes.
Target selector arguments, such as team=Moderators
(lowercase!) are placed in square brackets ([]
) directly with the target selector, such as @a
or @p
. They come in the form key=value
, with a predefined set of valid keys.
Data tag matching on the other hand is looking directly at the NBT data of an entity, such as ActiveEffects
. They are placed within curly brackets ({}
) and come in the form of key:value
. Only a fairly small subset of commands are capable of using data tags at all.
Your command in this case should be
/testfor @a[team=Moderators] {ActiveEffects:[{Id:21b,Amplifier:20b}]}
Fixing your setup
However, your whole idea is rubbish, if I may be so blunt. It looks like you are testing if there are moderators with Health Boost 20, then invert the signal and re-apply health boost. The first problem is that no moderator gets health boost unless none of the moderators currently have health boost. Actually negating data tag matching requires assigning scoreboard values based on the data tag.
For most effects, reapplying the effect all the time works just fine, e.g. run
/effect @a[team=Moderators] <effect> 1 <amplifier> true
on a fast clock (setblock/fill clock!) works just fine, and is actually way less resource-intensive than a redstone lag-machine with torches, comparators and whatnot.
However, there is an issue with reapplying Health Boost since it will reset your current health to 10 hearts all the time. If you want to reapply the effect only when needed, using /testfor
, comparators and redstone is still not a good idea. Instead, you should translate the data tag into a scoreboard value which can be used in a target selector. To do that, start by creating a scoreboard objective:
/scoreboard objectives add hasEffect dummy
Create a fill/setblock clock and put the following commands in order:
/scoreboard players set @a[team=Moderators] hasEffect 0
/scoreboard players set @a[team=Moderators] hasEffect 1 {ActiveEffects:[{Id:21b,Amplifier:20b}]}
/effect @a[team=Moderators,score_hasEffects=0] minecraft:health_boost 9999 20 true
Best Answer
I have my server running inside a screen session. I can then use cron (or anything else, for that matter) to send commands to that screen session.
As an example, here's how i broadcast that i'm about to shut down the server. Adjust the command to your taste
look here for more info on the screen command if you need it
Hopefully that'll let you do what you need.
edit:foolishly, i assumed you were using linux...simply because i am.