"That is not correct. It checks the command block physically behind it during the tick of its execution" I get that skylinerw, but what I'm saying is that once the conditional command block has successfully detected that the command block behind it has executed successfully based on the condition wrote in it, the said conditional command block will then execute it's command one tick later, it DOES NOT execute it's command within the same tick that it has detected that the command block behind it has executed successfully. If you don't believe me let me know and I can show you proof, because that's one thing that a lot of command blockers don't know about the conditional functionality and often disagree that a 1 tick delay exists, when in reality it does. Since 1 tick is 0.01 seconds, it's very hard to notice the delay at all, except through scoreboards.
That is absolutely incorrect, especially when looking at the source code directly. All you need to do is have a 20t/s incremental score, use /tellraw to state the score before a conditional command block, and then use the same /tellraw command in a conditional command block in the same chain of activation (preferably with an Impulse block as the host). It will be the same numbers because they execute within the same tick.
If you are not using Chain blocks then you're using the conditional setting incorrectly, because at that point it's relying on an update order that is not guaranteed. For example, if you have a conditional Repeating block relying on a Repeating block behind it, then you're relying on block update and scheduled tick order.
That is, your conditional command block may be activating first before the command block it's relying on activates (which isn't an issue with chains), and is then relying on what occurred a tick prior since the command block behind it hasn't activated yet. Swapping the queue order fixes that.
But that does NOT mean it activates in the next tick, it's just activating before the other Repeating block, giving the illusion that it's activating in the next tick. You should be using Chain blocks when requiring a guaranteed activation order.
EDIT: Here is a video that first shows that conditional blocks activate in the same tick as detection, and also shows the illusion of activating next tick (when really it's just relying on old information) and how it forms: https://youtu.be/I9fsXk5_AW4
There only appers to be 5 [] on the page for reference material. yet there area about 8 references sited down below to profiles or mod/map pages.
possible spam additions?
If you click the up-arrow on the reference, you can see what the citation is referring to. For references 6–9, those are within the 'milestones' table, which is keeping track of particular users and posts within the forum.
"That is not correct. It checks the command block physically behind it during the tick of its execution" I get that skylinerw, but what I'm saying is that once the conditional command block has successfully detected that the command block behind it has executed successfully based on the condition wrote in it, the said conditional command block will then execute it's command one tick later, it DOES NOT execute it's command within the same tick that it has detected that the command block behind it has executed successfully. If you don't believe me let me know and I can show you proof, because that's one thing that a lot of command blockers don't know about the conditional functionality and often disagree that a 1 tick delay exists, when in reality it does. Since 1 tick is 0.01 seconds, it's very hard to notice the delay at all, except through scoreboards.
That is absolutely incorrect, especially when looking at the source code directly. All you need to do is have a 20t/s incremental score, use /tellraw to state the score before a conditional command block, and then use the same /tellraw command in a conditional command block in the same chain of activation (preferably with an Impulse block as the host). It will be the same numbers because they execute within the same tick.
If you are not using Chain blocks then you're using the conditional setting incorrectly, because at that point it's relying on an update order that is not guaranteed. For example, if you have a conditional Repeating block relying on a Repeating block behind it, then you're relying on block update and scheduled tick order.
That is, your conditional command block may be activating first before the command block it's relying on activates (which isn't an issue with chains), and is then relying on what occurred a tick prior since the command block behind it hasn't activated yet. Swapping the queue order fixes that.
But that does NOT mean it activates in the next tick, it's just activating before the other Repeating block, giving the illusion that it's activating in the next tick. You should be using Chain blocks when requiring a guaranteed activation order.
EDIT: Here is a video that first shows that conditional blocks activate in the same tick as detection, and also shows the illusion of activating next tick (when really it's just relying on old information) and how it forms: https://youtu.be/I9fsXk5_AW4
u rock \m/
I noticed you've reverted some things I did today on the MC Wiki. Sorry if I was causing trouble. I'm new to this.
Can we please talk about the rules/policies of editing articles? I think we can use my Talk page. ;l
Why is this sited as a reference?
There only appers to be 5 [] on the page for reference material. yet there area about 8 references sited down below to profiles or mod/map pages. possible spam additions?
on this page: http://minecraft.gamepedia.com/Minecraft_Forums
If you click the up-arrow on the reference, you can see what the citation is referring to. For references 6–9, those are within the 'milestones' table, which is keeping track of particular users and posts within the forum.
nice profile! :D