Full transcript
0:04In this video, I'll be discussing the
0:06relatively unknown impact that your hot
0:08bar layout can have on your performance,
0:10as well as detailing optimal layouts for
0:13performing certain techniques. This
0:14video will get technical, but I can
0:16assure you that the information covered
0:18today will be valuable if you play any
0:20game mode that requires regularly
0:21switching between hot bar slots. This is
0:24my first time making my educational
0:26content in this manner, so please let me
0:28know if you enjoy it.
0:31In order to start off, I first need to
0:33go over how exactly hot bar inputs are
0:35handled. As many of you already know,
0:38Minecraft runs at a steady 20 ticks per
0:40second. When using hotkeys to switch hot
0:43bar slots, you can only switch to one
0:45slot each tick, meaning that if you
0:47happen to input multiple in the same
0:49tick, you'd only end up switching to one
0:51of them. This is a common mistake that's
0:54unsurprisingly prevalent in its effect
0:56on combat and is actually one of the
0:58main entry barriers when it comes to
1:00learning complex techniques. What a lot
1:02of people don't realize, however, is
1:04that you can actually optimize your hot
1:05bar layout in a manner that achieves
1:07maximum benefit from the way in which it
1:09inputs are prioritized. In some
1:12scenarios, doing this can be so
1:13beneficial that it can allow you to
1:15consistently execute difficult
1:17techniques without error, which is the
1:19driving force behind my stun smashing
1:21method. In order to illustrate this
1:23clearly, I need to go over the concept
1:25of slot priority. Every tick, Minecraft
1:28executes a loop that checks every slot
1:30for a selection input. This loop starts
1:33its input check from slot one and ends
1:35at slot 9. Ultimately, regardless of the
1:38timing of your inputs, it will always
1:40prioritize the later slot. Now that I've
1:44explained this though, I need to
1:45demonstrate why knowing it can be
1:47useful. Depending on your objective, you
1:49can benefit from deliberately assigning
1:51an item's priority. For the sake of this
1:54video, I've decided to select a few
1:56techniques that serve as good examples
1:58of the benefit from both low priority
2:00and high priority arrangements. I'll be
2:02starting with the most straightforward
2:04of these examples, which is shield
2:05disabling. I first want to clarify how
2:08priority in this context is more about
2:10relativity rather than purely putting an
2:12item in an earlier slot or a later slot.
2:15For example, if you're only going to be
2:17switching between a couple items to
2:19perform a technique, the exact order of
2:21these items relative to the rest of your
2:23hot bar doesn't exactly matter much.
2:25What does matter, however, is the order
2:27of the items that will be used for the
2:29input sequence. When performing a shield
2:31disable, it's extremely common to start
2:33by disabling the shield using the
2:35properties of the axe, then immediately
2:37swapping back to sword to prepare your
2:38next hit. The speed at which you perform
2:41this sequence is important. Since the
2:43faster you do it, the more damage and
2:45knockback output you'll have from your
2:46increased sword charge. The issue is if
2:49your sword is in a higher priority sloth
2:51than your axe, you might end up
2:53switching back to it too quickly, which
2:55would skip ever swapping to the axe and
2:57performing the shield disable
2:58altogether. In situations like this, you
3:01can benefit from intentionally putting
3:02the last item of the sequence, which in
3:04this case is the sword, in a lower
3:06priority slot than the previously used
3:08item, which in this case is the axe. The
3:11result of doing this in the
3:12affformentioned scenario would mean
3:14dropping the sword swap back input
3:16rather than the ax's shield disable,
3:18which is the substantially lesser of the
3:19two negative outcomes. Now that you have
3:22a better idea of how hot bar priority
3:24can affect the execution of techniques,
3:26we can apply the same logic you just
3:28learned from shield disabling onto other
3:30strategies. For instance, it's better to
3:32put crystals in a lower priority slot
3:34and obsidian since if you attempt to
3:36swap too quickly to them when inputting
3:37the combo, the obsidian will still be
3:39placed. While there are numerous other
3:41situations like this that can benefit
3:43from the same logic, some of these are
3:45definitely much more important than
3:46others. The best example of this is stun
3:49smashing, which many players find
3:50difficulty performing for various
3:52reasons. The truth is stun smashing as
3:55well as every other previous example I
3:57gave has an arbitrary timing window that
3:59will be different every time you perform
4:01the technique. What this means is that
4:03regardless of whether or not you perform
4:04the same technique with identical
4:06timing, sometimes it will work and
4:08sometimes it won't. I'll explain why
4:10this is the case. As we discussed
4:13previously, Minecraft runs at a rate of
4:1520 ticks per second. This means one tick
4:18is equivalent to 50 milliseconds. While
4:20this might not sound like much on the
4:22surface, it's actually very noticeable
4:24in gameplay. Most competitive games, for
4:26instance, handle inputs at a rate of at
4:28least 60 times per second. So, you can
4:30imagine how 20 actually feels quite
4:32clunky. Part of the problem here is that
4:35whenever you input an action, you could
4:37be anywhere between your current tick.
4:39For example, if you input a shield
4:41disable on the last millisecond of your
4:43current tick, you will immediately be
4:44able to input a smash attack one
4:46millisecond later. If you were to do
4:48this same exact thing when your client
4:50is at the start of the tick, however, in
4:52order to avoid an input being dropped,
4:54you would be forced to wait 50
4:56milliseconds before you could perform
4:57the smash attack. Your client is
4:59constantly in this loop and could be
5:01anywhere in between it each moment you
5:03take action. Undoubtedly, this is one of
5:06the main reasons people have so much
5:07trouble with stun smashing and is
5:09ultimately what led me to seek out a
5:11more reliable method to perform the
5:12technique. The overarching premise
5:15behind my stun smashing method is to
5:17deliberately create a tick lockout that
5:19prevents you from preemptively switching
5:21to the mace before the tick ends. The
5:23way in which I do this is by attacking
5:25and swapping to my axe in the same tick
5:27to perform a shield disable while
5:28ensuring my axe is at a higher priority
5:30than my mace. A lot of you may have
5:33noticed that I initiate this with my
5:34sword. However, this is merely out of
5:36habit, and I would recommend starting
5:38from your current item in order to
5:40reduce an extra input. It's also worth
5:42knowing that you can still perform this
5:44technique without starting from another
5:45item, since even if you already have the
5:47axe selected, pressing its hotkey as if
5:50you were swapping to it will still
5:51create a tick lockout. Not only does
5:54creating a tick lockout prevent the
5:56error of switching slots too soon and
5:57fumbling your shield disable, but it
6:00also means you can reliably land a mace
6:02mash on the earliest possible tick by
6:04repeatedly pressing the input. It's
6:06worth noting that this same logic can be
6:08applied to all of the examples I
6:09mentioned earlier, such as swapping back
6:11to your sword on the earliest possible
6:13tick after a shield disable. Well, that
6:16wraps up about everything I wanted to go
6:18over in this video. So, hopefully you
6:20were able to learn something useful from
6:21it. With that being said, thanks for
6:24watching.