In 1.8, the /time query [day/night/whatever] command allowed for the commands to be triggered at specific times or ticks or (in 1.9) days by scoreboard.
Applying a feature like this to the /weather command would be just as helpful, allowing player to trigger events based on weather, or triggering events based on duration of the weather, or maybe other things.
For example, you could make a devise that accurately creates events while rain occurs, instead of relying on unreliable mobs or cauldrons.
It is on the Minecraft Suggestion Reddit if you want to support it as well!
There could be one that is set to 0, 1, or 2 for the weather types and one for tracking the time the weather has been going on for?
Creating arbitrary IDs as a return integer value is probably not the best way to go about it, especially since Mojang is trying to avoid using numerical IDs.
Depending on how exact the return values are to be, a boolean for each type would be necessary due to how weather states are saved. For example, the weather is marked as thundering even when it's not raining.
When "rainTime" depletes, "raining" is set to 0 and then "rainTime" is set to another number that represents how long until the next rainfall. "thundering" remains at 1 for 100 ticks after that point, though will not actually affect the game. And then once "thunderTime" depletes, "thundering" is set to 0 and "thunderTime" is set to another number, just like "rainTime" does. As long as "raining" is 0, the weather is currently clear.
The "clearWeatherTime" is only used when the "/weather clear" command is run. As long as "clearWeatherTime" is 1 or higher, "raining" and "thundering" are forcibly set to 0 while "rainTime" and "thunderTime" are set to 1.
As a result, there are technically two types of clear weather: natural and enforced. But since "raining" is set to 0 anyway, it would still represent the clear weather state. Perhaps another query for enforced clear weather would be implemented, though is not necessary.
Example command syntax to obtain certain return values:
If the return value for "/weather query rain" is 0, then the weather is clear. If, at the same time, "/weather query clearTime" returns 0, that means the weather is naturally clear. If it instead returned 1 or higher, the weather is forcibly cleared. "clearTime" querying is not particularly necessary since the weather is going to be clear, which would already be detected with querying "rain".
If "thunder" returns 1, that won't necessarily mean it's thundering. Both "rain" and "thunder" would have to be checked at the same time. But it does allow weather "prediction". If "rain" is 0 and "thunder" is 1, with "rainTime" being lower than "thunderTime", then it will begin to thunder after "rainTime" (which would be a displayable value) depletes. Scoreboard operations can very easily be used in combination with these values for advanced weather "analysis".
Creating arbitrary IDs as a return integer value is probably not the best way to go about it, especially since Mojang is trying to avoid using numerical IDs.
Depending on how exact the return values are to be, a boolean for each type would be necessary due to how weather states are saved. For example, the weather is marked as thundering even when it's not raining.
When "rainTime" depletes, "raining" is set to 0 and then "rainTime" is set to another number that represents how long until the next rainfall. "thundering" remains at 1 for 100 ticks after that point, though will not actually affect the game. And then once "thunderTime" depletes, "thundering" is set to 0 and "thunderTime" is set to another number, just like "rainTime" does. As long as "raining" is 0, the weather is currently clear.
The "clearWeatherTime" is only used when the "/weather clear" command is run. As long as "clearWeatherTime" is 1 or higher, "raining" and "thundering" are forcibly set to 0 while "rainTime" and "thunderTime" are set to 1.
As a result, there are technically two types of clear weather: natural and enforced. But since "raining" is set to 0 anyway, it would still represent the clear weather state. Perhaps another query for enforced clear weather would be implemented, though is not necessary.
Example command syntax to obtain certain return values:
If the return value for "/weather query rain" is 0, then the weather is clear. If, at the same time, "/weather query clearTime" returns 0, that means the weather is naturally clear. If it instead returned 1 or higher, the weather is forcibly cleared. "clearTime" querying is not particularly necessary since the weather is going to be clear, which would already be detected with querying "rain".
If "thunder" returns 1, that won't necessarily mean it's thundering. Both "rain" and "thunder" would have to be checked at the same time. But it does allow weather "prediction". If "rain" is 0 and "thunder" is 1, with "rainTime" being lower than "thunderTime", then it will begin to thunder after "rainTime" (which would be a displayable value) depletes. Scoreboard operations can very easily be used in combination with these values for advanced weather "analysis".
OK, so you would need a combination of blocks to analyse the environment and tell if it is raining. Could the command do that internally and tell you how many times it has rained or thundered?
While what your talking about might have slightly more uses, it is not really user friendly. So I really don't know which one to trade off...
OK, so you would need a combination of blocks to analyse the environment and tell if it is raining. Could the command do that internally and tell you how many times it has rained or thundered?
While what your talking about might have slightly more uses, it is not really user friendly. So I really don't know which one to trade off...
If you wanted a simplified version, you could just query for "rainTime" and "thunderTime" and have no other options available. If "raining" or "thundering" is 0, "rainTime" and "thunderTime" would return 0 as well. Otherwise it would be the remaining duration. However, that would knock out the entire other half of the weather cycle, which would be the waiting duration between events. Querying data through CommandStats is meant to be technical and already an advanced topic, so more options would be better as the user is expected to know these tiny details if they are to use them.
My examples however would allow you to detect if it's raining by just using "/weather query rain" and nothing more. The other options available just allow for more usage, and is providing what's already stored by the game.
In either case, you would have to have an external command mechanism to store the number of times it's rained (such as whenever "rainTime" reaches 0). The game does not store how many times it has rained or thundered.
If you wanted a simplified version, you could just query for "rainTime" and "thunderTime" and have no other options available. If "raining" or "thundering" is 0, "rainTime" and "thunderTime" would return 0 as well. Otherwise it would be the remaining duration. However, that would knock out the entire other half of the weather cycle, which would be the waiting duration between events. Querying data through CommandStats is meant to be technical and already an advanced topic, so more options would be better as the user is expected to know these tiny details if they are to use them.
My examples however would allow you to detect if it's raining by just using "/weather query rain" and nothing more. The other options available just allow for more usage, and is providing what's already stored by the game.
In either case, you would have to have an external command mechanism to store the number of times it's rained (such as whenever "rainTime" reaches 0). The game does not store how many times it has rained or thundered.
aahhh, ok. Well, since I don't really have the technical knowledge to be able to include this whole thing into the post, maybe I could just leave it as an implied sort of thing? That way the less technical people will know what is going on, and the more technically skilled can infer what is going on. Plus, people wouldn't then do the whole "tl;dr" sorta thing.
In 1.8, the /time query [day/night/whatever] command allowed for the commands to be triggered at specific times or ticks or (in 1.9) days by scoreboard.
Applying a feature like this to the /weather command would be just as helpful, allowing player to trigger events based on weather, or triggering events based on duration of the weather, or maybe other things.
For example, you could make a devise that accurately creates events while rain occurs, instead of relying on unreliable mobs or cauldrons.
It is on the Minecraft Suggestion Reddit if you want to support it as well!
https://www.reddit.com/r/minecraftsuggestions/comments/45784c/add_query_to_weather_command/
Cool! Thanks! .....
.....
.....
Guess there is not that much to discuss though. Do you have any thoughts you would like to elaborate? This isn't gonna get very far without it.
Yeah, that sounds good. I'll definitely try and add that and be much clearer with what should happen.
Creating arbitrary IDs as a return integer value is probably not the best way to go about it, especially since Mojang is trying to avoid using numerical IDs.
Depending on how exact the return values are to be, a boolean for each type would be necessary due to how weather states are saved. For example, the weather is marked as thundering even when it's not raining.
Weather states example:
When "rainTime" depletes, "raining" is set to 0 and then "rainTime" is set to another number that represents how long until the next rainfall. "thundering" remains at 1 for 100 ticks after that point, though will not actually affect the game. And then once "thunderTime" depletes, "thundering" is set to 0 and "thunderTime" is set to another number, just like "rainTime" does. As long as "raining" is 0, the weather is currently clear.
The "clearWeatherTime" is only used when the "/weather clear" command is run. As long as "clearWeatherTime" is 1 or higher, "raining" and "thundering" are forcibly set to 0 while "rainTime" and "thunderTime" are set to 1.
As a result, there are technically two types of clear weather: natural and enforced. But since "raining" is set to 0 anyway, it would still represent the clear weather state. Perhaps another query for enforced clear weather would be implemented, though is not necessary.
Example command syntax to obtain certain return values:
If the return value for "/weather query rain" is 0, then the weather is clear. If, at the same time, "/weather query clearTime" returns 0, that means the weather is naturally clear. If it instead returned 1 or higher, the weather is forcibly cleared. "clearTime" querying is not particularly necessary since the weather is going to be clear, which would already be detected with querying "rain".
If "thunder" returns 1, that won't necessarily mean it's thundering. Both "rain" and "thunder" would have to be checked at the same time. But it does allow weather "prediction". If "rain" is 0 and "thunder" is 1, with "rainTime" being lower than "thunderTime", then it will begin to thunder after "rainTime" (which would be a displayable value) depletes. Scoreboard operations can very easily be used in combination with these values for advanced weather "analysis".
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/
OK, so you would need a combination of blocks to analyse the environment and tell if it is raining. Could the command do that internally and tell you how many times it has rained or thundered?
While what your talking about might have slightly more uses, it is not really user friendly. So I really don't know which one to trade off...
If you wanted a simplified version, you could just query for "rainTime" and "thunderTime" and have no other options available. If "raining" or "thundering" is 0, "rainTime" and "thunderTime" would return 0 as well. Otherwise it would be the remaining duration. However, that would knock out the entire other half of the weather cycle, which would be the waiting duration between events. Querying data through CommandStats is meant to be technical and already an advanced topic, so more options would be better as the user is expected to know these tiny details if they are to use them.
My examples however would allow you to detect if it's raining by just using "/weather query rain" and nothing more. The other options available just allow for more usage, and is providing what's already stored by the game.
In either case, you would have to have an external command mechanism to store the number of times it's rained (such as whenever "rainTime" reaches 0). The game does not store how many times it has rained or thundered.
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/
aahhh, ok. Well, since I don't really have the technical knowledge to be able to include this whole thing into the post, maybe I could just leave it as an implied sort of thing? That way the less technical people will know what is going on, and the more technically skilled can infer what is going on. Plus, people wouldn't then do the whole "tl;dr" sorta thing.