I'll copy them here directly and add my own notes:
x - X coordinate for the search center. Note, this cannot be a decimal value. If this value exists, 'y', 'z' and 'r' must also exist.
y - Y coordinate for the search center. Note, this cannot be a decimal value. If this value exists, 'x', 'z' and 'r' must also exist.
z - Z coordinate for the search center. Note, this cannot be a decimal value. If this value exists, 'x', 'y' and 'r' must also exist.
r - Maximum search radius. Minimum of 1. If this value exists, 'x', 'y' and 'z' do NOT need to. If 'x', 'y' and 'z' do not exist, the center of the radius becomes the location of the command block. 'rm' does not need to exist.
rm - Minimum search radius. If this value exists, 'x', 'y' and 'z' do NOT need to. If 'x', 'y' and 'z' do not exist, the center of the radius becomes the location of the command block. 'r' does not need to exist.
m - A players game mode. -1=All, 0=Survival, 1=Creative, 2=Adventure
c - Number of players. If negative, uses players from the end of the list first. For player selectors such as @p, which normally only selects one player, adding a "c=2" will instead select the two closest players that also match other arguments.
l - Maximum experience level of players. 'lm' does not need to exist.
lm - Minimum experience level of players. 'l' does not need to exist.
score_name - For the objective "name", the maximum score this player has. 'score_name_min' does not need to exist.
score_name_min - For the objective "name", the minimum score this player has. 'score_name' does not need to exist.
team - Checks if player is in the specified team. Inserting an '!' before the team name checks only for players not on this team. Providing no team name allows for checking for all players without a team. Checking for only '!' will check for players that are on a team.
name - Checks for players with this name. Using =! instead of = checks only for players who do not have this name. (Example: name=!Notch)
You can only have one of each parameter, and don't necessarily need them all unless explicitly stated (which at the time of writing this, only concerns 'xyzr').
So as I've included above, if you have any of the x, y, or z parameters, you must include them all. If you do not include a radius, the command block will always return true. If you include a radius of 0, the command block will also return true no matter what. So the minimum radius is 1.
You do not need to include xyz parameters and can use radius alone. You cannot use decimals, and you cannot use the tilde (~) to indicate relative coordinates.
If you have a radius ( r ) alone of 100, that checks all players within 100 blocks of the command. If you only have a radius minimum (rm) of 100, that will check all players that are 100 blocks away from the command block and infinitely outward. If you include a radius ( r ) of 100 and a minimum radius (rm) of 50, all players between 50 and 100 blocks away from the command block will be checked.
You do not need the xyzr parameters at all, in which case every player can be checked no matter where they are. Just know that if you have one coordinate, you need all 3 other parameters. You can use radius and radius minimum alone, without the usage of coordinates. In which case, the command block becomes the center of the radius.
"c" is maximum players to check. The command block will still output a signal if you have a "c=2" and only one player is found. It boosts the number of possible players that can be selected at a time, regardless of player selector (@p, @r), and can decrease the total number of players that can be selected from @a. It will not select the same player twice. "c=0" does not function, as can be expected.
level (l) and level minimum (lm) function in the same way as radius ( r ) and radius minimum (rm). If you have a level max (l) of 10, players between levels 0-10 will be selected. If you have a level minimum (lm) of 10, all players 10 levels or infinitely higher will be selected. If you have both level and level minimum of 10, only players at level 10 will be selected.
Gamemode (m) is pretty self-explanatory. You cannot check for two different gamemodes at a time though, as you are restricted to one of each parameter.
Maximum score (score_<name>) and minimum score (score_<name>_min) are also similar to radius and levels. A max score of 5 will select all players that have that selected objective score of 0-5. Having just minimum score of 5 would be a score of 5 and infinitely higher. And having both set to 5 would select players only at a score of 5.
For teams (team), searching for "team=BLUE" selects all players on team blue. If no players are found, then no players are selected. If there is no BLUE team, then no players will be selected (because technically there are no players on team BLUE since it doesn't exist). Including an exclamation point before the team name will search for players who are not on the listed team. You cannot search for players on two different teams in one player selector because you can only have one of each parameter.
If the team parameter reads "team=!", that will select all players who are on a team. Having a blank team name with no exclamation point "team=" will select all players that are not a team.
And finally, the name (name) parameter selects players of specific names. You cannot use a player selector (@p) in place of this.
Scoreboards allow you to track "fake" players by specifying a player name when incrementing a score instead of using player selectors. However, all parameters are checking for online players. This means you cannot use any player selectors to grab a hold of a fake player, and can only manipulate their score through the /scoreboard command. So there is no way to detect what score a fake player has.
If you include the xyzr parameters, you can completely remove the "x=", "y=", "z=", and "r=" from the player selector only if they appear in that exact order. For example:
/testfor @a[x=0,y=4,z=0,r=5,score_test_min=1]
Could become:
/testfor @a[0,4,0,5,score_test_min=1]
This is optional.
When a player selector runs, it will cycle through EVERY player, even if they don't match the parameters. The player must match all parameters to be successfully selected. For example, if you use:
/testfor @p[score_test_min=5]
It will check the closest player regardless of their score. If the player matches all parameters, they will be selected and the check ends. If they do not match the parameters, the next closest player will be checked. This will continue until either all players have been checked or the command has received the number of players it needs.
The @a selector will do the same, except it will not stop once it finds its first player closest to the command block. You can force it to end early by adding a count ( c ) parameter.
If two players are standing in the exact same location and you are using @p to select one of them, it will select the player with the lowest entity ID. This means that the player who logged in first will always be selected in this event.
I think that about covers it. If you have further questions concerning them, I will be happy to answer. If I have forgotten something, I will make sure to post.
Thanks a lot for the information. It's going to be much easier to implement it with this.
Though, I'm just curious as to know why you're giving me so much information. If you have this much knowledge, shouldn't you be programming your own tool? (I'm implying you know how to code)
Thanks a lot for the information. It's going to be much easier to implement it with this.
Though, I'm just curious as to know why you're giving me so much information. If you have this much knowledge, shouldn't you be programming your own tool? (I'm implying you know how to code)
I don't have the knowledge base to create a tool like this. So it's best to give out as much information to people who can :P.
x) Unfortunately I don't have Microsoft Access to be able to try it out, though I'm interested in doing so. I myself don't use any tools; I hand-code commands as it helps me to understand the structure better in order to help out others that are having issues.
Do you reckon you have a solution for an error I constantly encounter?
Thanks in advance.
That's about the message asking if you want to retrieve records from older versions.... hmmmmm. I don't get this so I don't know why you would get it... Are you using the 32-bit or 64-bit version?
That aside, I've been developing a VB.net version of the tool that will be accessible to everyone and without bugs different for everyone! I've done a lot already, so expect it in the next week!
Here is a very premature version of the executable version of the tool. It doesn't work properly for any computer settings right now, but I hope it can help some of you.
I'm already having a hard time between two Windows versions... until this doesn't work properly, I won't port it to mac. But yeah, that was in my plan.
[0.9.1]:
- Improved the range of PC configuration the application can launch on. I know it's Windows 64-bit compatible, but I don't know about 32-bit. Need to test it. If anyone is able to test it, please report! I need to get my hands on a 32-bit version of Windows.
[0.9.2]:
- Finished the template management feature. (Except for retrieving from older versions. Need to find a way around this.)
- Fixed the color feature. Working like a charm!
- Finished the player management feature. (Except for retrieving from older versions. Need to find a way around this.)
- Fixed some bugs.
How to install:
Download the file, extract the folder to any location, click on the setup and the program should install what it needs to launch on its own. A shortcut will be created on your desktop. (Might need to run the setup twice for some reason)
If you are updating your version to a newer one, you will need to unistall the application from the "Uninstall or change a program" panel. Currently working on a way around this.
[0.9.3]:
- Revamped the way to retrieve players and templates. You can now export and import each of them.
- Fixed the tab order (still a bit glitchy but way better)
- Fixed the sizable issue. The main window will open with scroll bars if you have less than 1920x1080 as resolution and you can re-size any window.
- Fixed some bugs.
Now that the biggest part of remaking the tool executable is done, here is a little list of things that are coming:
- Testing on different OS
- Adding more items and their icons
- Adding pictures on buttons such as arrows
- Implementing the different arguments
I suppose you are using it and it's working perfectly? I am not getting a lot of feedback and so I never know if what I'm doing is actually working for the actual users.
If you have anything to report, please do so. I also would like to know which OS you're running.
I suppose you are using it and it's working perfectly? I am not getting a lot of feedback and so I never know if what I'm doing is actually working for the actual users.
If you have anything to report, please do so. I also would like to know which OS you're running.
I have not been using it lately, but I do read all the posts on here, so I always love to see those changelogs and what progress you're making.
As far as Operating System goes, I am running 64-bit Windows 7. I read your previous posts about needing to test 32-bit.
What IDE are you using to develop the executable? If you're using Microsoft Visual Studio, then I do recall there being an option in there somewhere to compile 32/64-bit into one executable so it would run appropriately on any system.
Give me a list of all the arguments that you know and how they work if it's not obvious and I will add it to my tool.
The wiki has a good supply: http://minecraft.gamepedia.com/Command_block#Arguments
I'll copy them here directly and add my own notes:
You can only have one of each parameter, and don't necessarily need them all unless explicitly stated (which at the time of writing this, only concerns 'xyzr').
So as I've included above, if you have any of the x, y, or z parameters, you must include them all. If you do not include a radius, the command block will always return true. If you include a radius of 0, the command block will also return true no matter what. So the minimum radius is 1.
You do not need to include xyz parameters and can use radius alone. You cannot use decimals, and you cannot use the tilde (~) to indicate relative coordinates.
If you have a radius ( r ) alone of 100, that checks all players within 100 blocks of the command. If you only have a radius minimum (rm) of 100, that will check all players that are 100 blocks away from the command block and infinitely outward. If you include a radius ( r ) of 100 and a minimum radius (rm) of 50, all players between 50 and 100 blocks away from the command block will be checked.
You do not need the xyzr parameters at all, in which case every player can be checked no matter where they are. Just know that if you have one coordinate, you need all 3 other parameters. You can use radius and radius minimum alone, without the usage of coordinates. In which case, the command block becomes the center of the radius.
"c" is maximum players to check. The command block will still output a signal if you have a "c=2" and only one player is found. It boosts the number of possible players that can be selected at a time, regardless of player selector (@p, @r), and can decrease the total number of players that can be selected from @a. It will not select the same player twice. "c=0" does not function, as can be expected.
level (l) and level minimum (lm) function in the same way as radius ( r ) and radius minimum (rm). If you have a level max (l) of 10, players between levels 0-10 will be selected. If you have a level minimum (lm) of 10, all players 10 levels or infinitely higher will be selected. If you have both level and level minimum of 10, only players at level 10 will be selected.
Gamemode (m) is pretty self-explanatory. You cannot check for two different gamemodes at a time though, as you are restricted to one of each parameter.
Maximum score (score_<name>) and minimum score (score_<name>_min) are also similar to radius and levels. A max score of 5 will select all players that have that selected objective score of 0-5. Having just minimum score of 5 would be a score of 5 and infinitely higher. And having both set to 5 would select players only at a score of 5.
For teams (team), searching for "team=BLUE" selects all players on team blue. If no players are found, then no players are selected. If there is no BLUE team, then no players will be selected (because technically there are no players on team BLUE since it doesn't exist). Including an exclamation point before the team name will search for players who are not on the listed team. You cannot search for players on two different teams in one player selector because you can only have one of each parameter.
If the team parameter reads "team=!", that will select all players who are on a team. Having a blank team name with no exclamation point "team=" will select all players that are not a team.
And finally, the name (name) parameter selects players of specific names. You cannot use a player selector (@p) in place of this.
Scoreboards allow you to track "fake" players by specifying a player name when incrementing a score instead of using player selectors. However, all parameters are checking for online players. This means you cannot use any player selectors to grab a hold of a fake player, and can only manipulate their score through the /scoreboard command. So there is no way to detect what score a fake player has.
If you include the xyzr parameters, you can completely remove the "x=", "y=", "z=", and "r=" from the player selector only if they appear in that exact order. For example:
Could become:
This is optional.
When a player selector runs, it will cycle through EVERY player, even if they don't match the parameters. The player must match all parameters to be successfully selected. For example, if you use:
It will check the closest player regardless of their score. If the player matches all parameters, they will be selected and the check ends. If they do not match the parameters, the next closest player will be checked. This will continue until either all players have been checked or the command has received the number of players it needs.
The @a selector will do the same, except it will not stop once it finds its first player closest to the command block. You can force it to end early by adding a count ( c ) parameter.
If two players are standing in the exact same location and you are using @p to select one of them, it will select the player with the lowest entity ID. This means that the player who logged in first will always be selected in this event.
I think that about covers it. If you have further questions concerning them, I will be happy to answer. If I have forgotten something, I will make sure to post.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
Though, I'm just curious as to know why you're giving me so much information. If you have this much knowledge, shouldn't you be programming your own tool? (I'm implying you know how to code)
I don't have the knowledge base to create a tool like this. So it's best to give out as much information to people who can :P.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
x) Unfortunately I don't have Microsoft Access to be able to try it out, though I'm interested in doing so. I myself don't use any tools; I hand-code commands as it helps me to understand the structure better in order to help out others that are having issues.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
That's about the message asking if you want to retrieve records from older versions.... hmmmmm. I don't get this so I don't know why you would get it... Are you using the 32-bit or 64-bit version?
That aside, I've been developing a VB.net version of the tool that will be accessible to everyone and without bugs different for everyone! I've done a lot already, so expect it in the next week!
Here's a sneak peek!
http://www.mediafire...0/GCG 0.9.0.zip
I will be working on it a lot during the holidays to make a reliable version. Sorry everyone!
[0.9.1]:
- Improved the range of PC configuration the application can launch on. I know it's Windows 64-bit compatible, but I don't know about 32-bit. Need to test it. If anyone is able to test it, please report! I need to get my hands on a 32-bit version of Windows.
[0.9.2]:
- Finished the template management feature. (Except for retrieving from older versions. Need to find a way around this.)
- Fixed the color feature. Working like a charm!
- Finished the player management feature. (Except for retrieving from older versions. Need to find a way around this.)
- Fixed some bugs.
How to install:
Download the file, extract the folder to any location, click on the setup and the program should install what it needs to launch on its own. A shortcut will be created on your desktop. (Might need to run the setup twice for some reason)
If you are updating your version to a newer one, you will need to unistall the application from the "Uninstall or change a program" panel. Currently working on a way around this.
Please report any bug/error!
[0.9.3]:
- Revamped the way to retrieve players and templates. You can now export and import each of them.
- Fixed the tab order (still a bit glitchy but way better)
- Fixed the sizable issue. The main window will open with scroll bars if you have less than 1920x1080 as resolution and you can re-size any window.
- Fixed some bugs.
Now that the biggest part of remaking the tool executable is done, here is a little list of things that are coming:
- Testing on different OS
- Adding more items and their icons
- Adding pictures on buttons such as arrows
- Implementing the different arguments
Feel free to give me your ideas and comments!
I am happy to see that work on an executable version is coming along nicely.
Keep up the work. ( ^.^)b
I suppose you are using it and it's working perfectly? I am not getting a lot of feedback and so I never know if what I'm doing is actually working for the actual users.
If you have anything to report, please do so. I also would like to know which OS you're running.
I have not been using it lately, but I do read all the posts on here, so I always love to see those changelogs and what progress you're making.
As far as Operating System goes, I am running 64-bit Windows 7. I read your previous posts about needing to test 32-bit.
What IDE are you using to develop the executable? If you're using Microsoft Visual Studio, then I do recall there being an option in there somewhere to compile 32/64-bit into one executable so it would run appropriately on any system.