In an adventure map setting, with massive amounts of redstone operations, what are the main sources of lag, and how do they compare?
Specifically, how does the lag produced by these mechanisms compare:
Simple inverted clocks,
Hopper clocks,
Comparator clocks,
And command blocks?
Would a single simple redstone clock hooked up to multiple command blocks produce less lag than if each of those command blocks were hooked up to their own hopper clocks, and by how much?
Additionally, do command blocks of different natures produce different amounts of lag?
Do testfor commands significantly differ from commands with selectors?
Does the number of selectors in a single of command matter, or only the number of command blocks?
Complete answers to any of these questions would be greatly appreciated; however, as this is an advanced topic, low-level answers will probably not be helpful. Please remember that this question is derived from a scenario with dozens (up to a hundred) of distinct operations occurring concurrently, so small singular differences can create large differences in outcomes.
In an adventure map setting, with massive amounts of redstone operations, what are the main sources of lag, and how do they compare?
Specifically, how does the lag produced by these mechanisms compare:
Simple inverted clocks,
Hopper clocks,
Comparator clocks,
And command blocks?
Would a single simple redstone clock hooked up to multiple command blocks produce less lag than if each of those command blocks were hooked up to their own hopper clocks, and by how much?
Additionally, do command blocks of different natures produce different amounts of lag?
Do testfor commands significantly differ from commands with selectors?
Does the number of selectors in a single of command matter, or only the number of command blocks?
Complete answers to any of these questions would be greatly appreciated; however, as this is an advanced topic, low-level answers will probably not be helpful. Please remember that this question is derived from a scenario with dozens (up to a hundred) of distinct operations occurring concurrently, so small singular differences can create large differences in outcomes.
Don't take my word for any of this; I don't know the official code behind this. This is from personal experience and observation.
A single redstone clock would produce more lag than multiple hopper clocks. Though the more hopper clocks there are, the more noticeable their lag is. This is including the comparators of course; they wouldn't be too useful without them. For whatever reason, hoppers were coded nicely to not have to deal with the lag redstone clocks produce.
Comparator clocks appear similar to redstone clocks, if not slightly worse. I'd guess they have more information to handle than a piece of dust or torch at a quick pace, which would explain that. Command block clocks I've had no lag with, but I haven't tried using them in bulk.
But with command blocks, they themselves aren't going to cause lag. It's the result of the command they issue; for example, the /setblock command forces the client to render the new blocks and do re-lighting calculations. I assume that, because of this, command block clocks in bulk would start to lag in this manner.
As far as selectors/parameters, that's just being parsed by the server. There shouldn't be any fps lag from that. Depending on the number of command blocks simultaneously going off, each with their own multitude of selectors, you may see some server lag, but not framerate lag. Unless you've gone completely mad scientist here, that shouldn't be an issue.
The main thing you want to be careful about are light updates. Repeaters, torches, and dust change light levels around them. If they're in a dark area, changing their state will cause client lag. Personally, I build any redstone components under sunlight to help deal with that, but supposedly you'll have to light it with block sources (glowstone) to reduce lag further. If any components are under a certain light level, I do stick some glowstone nearby, which has proved helpful.
I'd very much like to know the deep technical bits about this as well. Perhaps somebody with that knowledge would be of better help than I, as the above is merely my own in-game observations.
Don't take my word for any of this; I don't know the official code behind this. This is from personal experience and observation.
A single redstone clock would produce more lag than multiple hopper clocks. Though the more hopper clocks there are, the more noticeable their lag is. This is including the comparators of course; they wouldn't be too useful without them. For whatever reason, hoppers were coded nicely to not have to deal with the lag redstone clocks produce.
Comparator clocks appear similar to redstone clocks, if not slightly worse. I'd guess they have more information to handle than a piece of dust or torch at a quick pace, which would explain that. Command block clocks I've had no lag with, but I haven't tried using them in bulk.
But with command blocks, they themselves aren't going to cause lag. It's the result of the command they issue; for example, the /setblock command forces the client to render the new blocks and do re-lighting calculations. I assume that, because of this, command block clocks in bulk would start to lag in this manner.
As far as selectors/parameters, that's just being parsed by the server. There shouldn't be any fps lag from that. Depending on the number of command blocks simultaneously going off, each with their own multitude of selectors, you may see some server lag, but not framerate lag. But unless you've gone completely mad scientist here, that shouldn't be an issue.
The main thing you want to be careful about are light updates. Repeaters, torches, and dust change light levels around them. If they're in a dark area, changing their state will cause client lag. Personally, I build any redstone components under sunlight to help deal with that, but supposedly you'll have to light it with block sources (glowstone) to reduce lag further. If any components are under a certain light level, I do stick some glowstone nearby, which has proved helpful.
I'd very much like to know the deep technical bits about this as well. Perhaps somebody with that knowledge would be of better help than I, as the above is merely my own in-game observations.
This is mostly in line with my own experience, and the relighting load is definitely a good thing to keep in mind. One issue with that is keeping spawn chunks separate, and I can't seem to find a straight answer on where the spawn chunks are stored. If you happen to know, are spawn chunks stored with the spawn point (meaning that changing the spawn point changes the spawn chunks which stay loaded), or are they stored in the level.dat file or some other NBT accessible resource?
This is mostly in line with my own experience, and the relighting load is definitely a good thing to keep in mind. One issue with that is keeping spawn chunks separate, and I can't seem to find a straight answer on where the spawn chunks are stored. If you happen to know, are spawn chunks stored with the spawn point (meaning that changing the spawn point changes the spawn chunks which stay loaded), or are they stored in the level.dat file or some other NBT accessible resource?
In NBT Explorer:
Those 3 indicate where the default spawn location is. It's an exact XYZ, rather than chunk number. The number of chunks is 16x16 with the default spawn chunk location in the north-west corner of the center (thus the chunks are offset in the south-east direction):
The black square is where your default spawn is, while the gray indicates all forever-loaded chunks. Changing those numbers DOES change the chunks that are loaded, so you can set them where you need them to be.
Those 3 indicate where the default spawn location is. It's an exact XYZ, rather than chunk number. The number of chunks is 16x16 with the default spawn chunk location in the north-west corner of the center (thus the chunks are offset in the south-east direction):
The black square is where your default spawn is, while the gray indicates all forever-loaded chunks. Changing those numbers DOES change the chunks that are loaded, so you can set them where you need them to be.
That's very helpful. Is it a built-in function of MC Edit, to view that area, or is that picture an edited one?
When inserting, you want to align the lapis underneath the spawn point, and tick "chunk align":
EDIT:
The schematic is pre-"doDaylightCycle" and comes with an always-day mechanism; forgot about that.
Hmm, the southeast orientation that you mentioned doesn't line up with some of the other , which seem to indicate that the spawn location (and the coordinates stored in the level.dat file?) are the central location of the permaloaded area. A citation would be good.
1.7 makes wireless redstone much simpler (and thus smaller), eliminating most need for clocks in general (other than player searching, item clearing, etc), so this post was mostly just a bit of optimization for my curiosity.
Hmm, the southeast orientation that you mentioned doesn't line up with some of the other , which seem to indicate that the spawn location (and the coordinates stored in the level.dat file?) are the central location of the permaloaded area. A citation would be good.
1.7 makes wireless redstone much simpler (and thus smaller), eliminating most need for clocks in general (other than player searching, item clearing, etc), so this post was mostly just a bit of optimization for my curiosity.
Not sure I'm following; the perma-loaded chunks encircle the spawn chunk, that's correct. Because there's an even number of chunks (16x16) but only 1 spawn chunk, the area in the image is offset in the south-east direction, while the spawn chunk is still relatively in the center of that.
Not sure I'm following; the perma-loaded chunks encircle the spawn chunk, that's correct. Because there's an even number of chunks (16x16) but only 1 spawn chunk, the area in the image is offset in the south-east direction, while the spawn chunk is still relatively in the center of that.
Hmmm... Is the XYZ tag set the Northwest corner of the NxN permanently loaded area, and is not the coordinate of the spawn chunk?
EDIT: Nevermind, I reread the post which confused me and figured it out.
Hmmm... Is the XYZ tag set the Northwest corner of the NxN permanently loaded area, and is not the coordinate of the spawn chunk?
Ah I may have worded things oddly. Within the center of the 16x16 area will be a 2x2 area. Within that 2x2 area, the spawn chunk is in the north-west corner. This is necessary to know for when you're determining how far you plan on expanding out from the spawn chunk; there are fewer chunks available going north than there are south.
The XYZ determines the spawn chunk, which determines the center of the pre-loaded area.
EDIT:
Ah, sorry for the confusion! Hopefully I haven't just made it worse.
Specifically, how does the lag produced by these mechanisms compare:
Simple inverted clocks,
Hopper clocks,
Comparator clocks,
And command blocks?
Would a single simple redstone clock hooked up to multiple command blocks produce less lag than if each of those command blocks were hooked up to their own hopper clocks, and by how much?
Additionally, do command blocks of different natures produce different amounts of lag?
Do testfor commands significantly differ from commands with selectors?
Does the number of selectors in a single of command matter, or only the number of command blocks?
Complete answers to any of these questions would be greatly appreciated; however, as this is an advanced topic, low-level answers will probably not be helpful. Please remember that this question is derived from a scenario with dozens (up to a hundred) of distinct operations occurring concurrently, so small singular differences can create large differences in outcomes.
Don't take my word for any of this; I don't know the official code behind this. This is from personal experience and observation.
A single redstone clock would produce more lag than multiple hopper clocks. Though the more hopper clocks there are, the more noticeable their lag is. This is including the comparators of course; they wouldn't be too useful without them. For whatever reason, hoppers were coded nicely to not have to deal with the lag redstone clocks produce.
Comparator clocks appear similar to redstone clocks, if not slightly worse. I'd guess they have more information to handle than a piece of dust or torch at a quick pace, which would explain that. Command block clocks I've had no lag with, but I haven't tried using them in bulk.
But with command blocks, they themselves aren't going to cause lag. It's the result of the command they issue; for example, the /setblock command forces the client to render the new blocks and do re-lighting calculations. I assume that, because of this, command block clocks in bulk would start to lag in this manner.
As far as selectors/parameters, that's just being parsed by the server. There shouldn't be any fps lag from that. Depending on the number of command blocks simultaneously going off, each with their own multitude of selectors, you may see some server lag, but not framerate lag. Unless you've gone completely mad scientist here, that shouldn't be an issue.
The main thing you want to be careful about are light updates. Repeaters, torches, and dust change light levels around them. If they're in a dark area, changing their state will cause client lag. Personally, I build any redstone components under sunlight to help deal with that, but supposedly you'll have to light it with block sources (glowstone) to reduce lag further. If any components are under a certain light level, I do stick some glowstone nearby, which has proved helpful.
I'd very much like to know the deep technical bits about this as well. Perhaps somebody with that knowledge would be of better help than I, as the above is merely my own in-game observations.
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/
This is mostly in line with my own experience, and the relighting load is definitely a good thing to keep in mind. One issue with that is keeping spawn chunks separate, and I can't seem to find a straight answer on where the spawn chunks are stored. If you happen to know, are spawn chunks stored with the spawn point (meaning that changing the spawn point changes the spawn chunks which stay loaded), or are they stored in the level.dat file or some other NBT accessible resource?
In NBT Explorer:
Those 3 indicate where the default spawn location is. It's an exact XYZ, rather than chunk number. The number of chunks is 16x16 with the default spawn chunk location in the north-west corner of the center (thus the chunks are offset in the south-east direction):
The black square is where your default spawn is, while the gray indicates all forever-loaded chunks. Changing those numbers DOES change the chunks that are loaded, so you can set them where you need them to be.
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 very helpful. Is it a built-in function of MC Edit, to view that area, or is that picture an edited one?
It's an edited one. I do have a schematic for the area though:
http://www.mediafire.com/?0gb2onawra5s28y
When inserting, you want to align the lapis underneath the spawn point, and tick "chunk align":
EDIT:
The schematic is pre-"doDaylightCycle" and comes with an always-day mechanism; forgot about that.
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/
Hmm, the southeast orientation that you mentioned doesn't line up with some of the other , which seem to indicate that the spawn location (and the coordinates stored in the level.dat file?) are the central location of the permaloaded area. A citation would be good.
1.7 makes wireless redstone much simpler (and thus smaller), eliminating most need for clocks in general (other than player searching, item clearing, etc), so this post was mostly just a bit of optimization for my curiosity.
Not sure I'm following; the perma-loaded chunks encircle the spawn chunk, that's correct. Because there's an even number of chunks (16x16) but only 1 spawn chunk, the area in the image is offset in the south-east direction, while the spawn chunk is still relatively in the center of that.
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/
Hmmm... Is the XYZ tag set the Northwest corner of the NxN permanently loaded area, and is not the coordinate of the spawn chunk?EDIT: Nevermind, I reread the post which confused me and figured it out.
Ah I may have worded things oddly. Within the center of the 16x16 area will be a 2x2 area. Within that 2x2 area, the spawn chunk is in the north-west corner. This is necessary to know for when you're determining how far you plan on expanding out from the spawn chunk; there are fewer chunks available going north than there are south.
The XYZ determines the spawn chunk, which determines the center of the pre-loaded area.
EDIT:
Ah, sorry for the confusion! Hopefully I haven't just made it worse.
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/
Simply typing in "/setworldspawn" will set it to where you're standing.
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/
Poker v2
Follow me here as I build Poker!
Yes, there is only one hard-wired world spawn after all.
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/