Typical greetings! I had a long weekend, so I decided to spend about my entire weekend working on this project of mine. I have not worked with command blocks much ever since 1.9, but with the help of lots of online tutorials I managed to actually recreate the entire Assassin Class in Vanilla MC 1.12! Yes you hear me right. I recreated Spin Attack, Vanish, Multihit and Smoke Bomb in three days! I also played around with Loot Tables, Item Attributes, and lots, lots of frustrating Motion NBT tags. I am proud to say I am finally done with this so far. I can gurantee it works well in Singleplayer, and although I have tried my best to make it multiplayer friendly, I don't have a server / buddy to test it out with. #feelsbadman I might work on a video for an explanation with commentary, but no promises. (I do too much "uh"s, "well"s,"so"s and hideously long pauses) For those who wants an explanation, here's how it works: Spoiler: Explanation The first thing is the actual click combo system. Right Click detection is by using a carrot on a stick and then a scoreboard value of stat.useItem.carrot_on_a_stick. The carrot on a stick appears on the player's offhand when they hold the weapon in their hand. Left Click detection is by constantly tping an invisible rabbit to the player's head so that when they start to cast a spell (initiated by the player clicking on the carrot). Why rabbits? It is actually accurate to how Wynncraft detects left clicks. We are just too oblivious to know that a rabbit is killed every time a spell is casted. I set the rabbits to have one health, and thus when the player attacks the rabbit dies in one hit, which is also stored as a scoreboard value. Spoiler: Additional Notes about Rabbits I am sorry I killed rabbits. I basically hard coded the inputs of the clicks into 3 separate scoreboard values, called ClickA, ClickB, and ClickC. How I did this, is that if ClickA is not 0 @a[score_ClickA_min=1], then store the value in ClickB. If ClickB is not 0 @a[score_ClickA_min=1,score_ClickB_min=1], then store the value into ClickC. The reason? You guessed it, they store the order of the clicks! Then I made some ifs statements with these values. An example, if ClickA is 2 (Right click), ClickB is 1 (Left click), and ClickC is 2 (Right click), you will cast Spell 1, which is Spin Attack. Another note is that there is a spellCasting timer, just so that if the player does not cast a spell fast enough, the spell cast cancels, just like how it is in Wynncraft! Damaging mobs is a bit tricky. Because damaging mobs would mean using instant damage for non undeads, and instant health for undeads, we need to find a way to label them as a single group. Luckily, it is possible with modern day Minecraft to do this. Here is a list of systems that are used to construct the spells: Spoiler: Differentiating Undead and Non Undeads In 1.12, scoreboard tags are introduced. This allows you to tag a certain type of mob to be an undead. Thus, I made a list of mobs there are considered as undead, and the rest would be non-undeads. This is run on a 20 hertz clock (runs 20 times per second). This means when I deliver damage with the /effect command, I can do this: /effect @e[tag=Undead] instant_health 1 0 /effect @e[tag=!Undead] instant_damage 1 0 Note, Undead means every entity tagged as Undead, !Undead means every entity that are not tagged as Undead. Spoiler: Hunger System - How it works Hunger in vanilla minecraft is tricky, especially without plugins. There is the normal hunger, and there is also a "hidden hunger bar" which is called saturation points. There isn't a way to find the saturation levels of the player, even with scoreboards, but the hunger levels can be recorded down by having 21 command blocks noting the food level of the player from 20 hunger to 0 hunger. There goes 10 minutes of work. But by doing this, we can then use the scoreboard value to accurately know how much hunger the player has. Thus, if the player does not have enough hunger, they cannot cast the spell. The hunger and saturation effect comes very useful. Saturation effect works where every tick of saturation would increase hunger levels by 1 point and saturation levels by 2 points. That's kind of annoying, but I learnt to accept it and move on. For every 40 levels, Hunger effect depletes one point per second. That means Level 240 hunger depletes 6 hunger points. This allows us to accurately take off hunger points when the player uses spells. They can spam click spells, but usually they are unable to click that fast. Spoiler: 8-direction system For some spells, such as Multihit and Smoke Bomb, where players look at would be where the spell is used at. In Wynncraft, it is very smooth because it uses plugins. Since we are only using Command blocks, we need to sacrifice a bit on "smoothness" and be a bit more "realistic". The 8 direction system stores the player's movements into the scoreboard. For example, when the player is looking North, their direction score will be 1. Northeast gives a score of 2, and so on. This allows us to make spells that are actually plausible to use and don't feel limited to only one direction, it also saves us time since we don't have to code for 360 directions. Woohoo! Moving on to the individual spells! Spoiler: Spin Attack This one is one of the easier ones to make. We just have like a straightforward one hit (damage), some slowness / blindness effects and then an animation. Damaging mobs is explained earlier, but to prevent the player themselves from getting damaged, there is a range in which mobs are affected by Spin Attack. @e[r=6,rm=1] This means all the entities that are at least 1 block radius to at most 6 blocks radius of the place the command is used. When mobs are within the Spin Attack radius, they will have a Timer (scoreboard timer) to show how long they have their effects for. The timer lasts for only about 2 seconds, in which when they are inflicted by it, their followrange is decreased to 0, effectively, this means they are "stunned"! Blindness does not work on mobs, so that's what I need to do. But I also included blindness just in case since it would be good for multiplayer. The particle animation is based on the intersection points of this graph. The origin is the player, and the particles are the intersection points. https://www.desmos.com/calculator/pyjgbnpztl That's right, I did some trigonometry. Math is important everyone! I did not include the Vampire feature of Spin Attack. Basically the spin attack is just a Tier 2 Spin attack. Spoiler: Vanish This one is a buggy one. If you had a look at the video, the skeleton actually killed me while I was vanished. The tricky part is that invisibility does not reset mob aggro, they would and will shoot your face off if you vanished when they already noticed you. Basically, invisibility is just extremely inconsistent. An example is that zombie pigman would chase you down no matter if you are invisible or not. Somewhat makes vanish useless in some situations. To make it a bit more useful, I made it so that in the first 2 ticks of vanish, mobs in a 50 block radius have a follow range of 0. This way, they lose track of the player, and now that the player is invisible, normal mobs like zombies, skeletons, creepers etc won't know where the player is! God damn Zombie Pigman still never gives up on the player though. I basically gave up and called it a "feature". Other than the vanish timer running out, vanish also runs out when the player attacks, takes damage, uses a spell or just switch hands. I made sure to included those in. The rest are easy. Jump boost, speed, the status effects aren't that bad to make. Vanish "charge" effect isn't coded in since Player Motions cannot be edited with command blocks. Spoiler: Multihit Multihit is the hardest one. Seriously, it has 4 layers of command blocks. That is saying something. The reason why is because I needed it to work in all directions. However, I can't make it 360 degrees, reason is because every direction takes more than 10 command blocks of hard coding. Too much lag and too much effort. As mentioned earlier, I am using the 8 direction system. This means I can use much less command blocks, while the spells still be "usable" or "playable" (imagine if in Wynncraft you can only multihit or uppercut in one direction!). For every direction, it needs to be mobs needs to be registered for being hit. That takes one command blocks. Each direction also requires 11 command blocks since multihit has 11 hits in total. Also you need to make that purple block particles. Multihit basically took 104 command blocks just for the animation alone, and this is for only 8 directions. Thank goodness Smoke Bomb is not like that. Funny thing is that the motion does not even register on players since player NBT tags cannot be changed. So sorry to break the dreams for all who wanted to throw your friends around with multihit. For damage, instead of using poison or wither, I only used 3 instant health / damage hits. 2 of them happens during the combo, which thus means they have the same damage, and the last one is the fatal hit that deals the most damage. The first 2 and the last hit is different in damage because I made sure to time the resistance effect at the right moment. Multihit takes away about 8 hearts of damage. I debated against using wither and poison since they aren't really as easily customized. They are more DoT rather than DPS. Spoiler: Smoke Bomb Also quite difficult, this one requires lots of motion animations as well, although it isn't that much. I debated against using eggs since in my first three test trials, baby chicks actually spawned out of the eggs, which is quite funny since the chance should only be 1 out of 8. So, I used snowballs. Motion NBT Tags are used for the snowballs, and each snowball has to be summoned individually. Since I am also using the 8 direction system, and it is 3 snowballs per direction, we only needed 24 command blocks to code the animations for all 8 directions. Additionally, I wanted to make it so that the smoke arrives only when the snowball hits something, such as a block or a entity. That is difficult until I found a solution. Said solution is a bit complicated, also quite genius. By using a timer, yet again, when the snowball is first summoned, it summons an invisible armor stand affected by gravity with a timer as well, and it is teleported two blocks above the snowball constantly, just to make sure it does not interfere with the snowball's motion, but so that it can keep track of the snowball's movements. This means, when the snowball hits something, the armor stand would drop down due to gravity, and thus the smoke is deployed where the snowball was at! The timer on the armor stand is the lifetime of the armor stand. Once it hits about 100 ticks (5 seconds), the armor stand is killed and thus the smoke is gone. However, the smoke is disabled when the snowball is around, as the snowball would execute the timer to be constantly set to 1. The timer is stuck like so, thus I was able to set it so that no smoke is deployed when the smoke bomb is still just a projectile. Since there is three snowballs, I made sure that each snowball would only execute and effect only its own armor stand using the target selector [c=1,r=3]. When the snowball hits something, the timer on the Armor stand is off and between ticks 2 to 100 it would give off smoke particles and also harm and slow mobs nearby. Since this includes the caster, I needed to make an exception for the caster and tagged them as "unaffected". And thus, the Full Smoke Bomb Spell is finished! However, it is impossible to aim up or down with the spell, since I did not include y-directions. I would die if that is the case. The explanation is mostly for people who really want to dive into how it works. Hopefully that would come as helpful for people who wants to try and make their own wynncraft spells! A downloadable map is attached for people who want to try and kill as many mobs as they want with the spells. Also for people who wants to look into the Command Blocks. If anyone wants to build an adventure map out of this system, be my guest! I will be really eager to see how it looks!