Welcome back! I’m happy to be back to working on ReLife and CodingCloud, but unfortunately with school I don’t have tons of time to code. As I’ve said, I’m also trying to be very careful to avoid burnout, so I’m not pushing myself super hard. My plan for the upcoming week is that I will code for 30-60 minutes per day, homework permitting, and hopefully that should be a good pace. 30 minutes of focused work can actually be quite productive. Anyway, as I said I don’t have a ton to talk about, but I did finish up a quick, mostly visual, thing on shovels with Lightning Aspect from last time, and started working on the Augmented Armor set.
The alert box makes it's return! I just feel like I should mention this at the top to make sure everyone sees it. I'm simply re-iterating that if you have any suggestions for the blog, requests for a coding project, or quesitons about anything, please contact me! Especially suggestions, if you think of anything that would make it a more enjoyable reading experience, you can either email me at mtroalson@gmail.com, or any of the other methods listed on the about page. Enjoy the post!
Touch Up
Alright, I’m going to start by talking about the shovel. Essentially, if you don’t remember from last time, a shovel with Lightning Aspect will break blocks in a 3 by 3 area. For anyone who hasn’t played Minecraft, you can usually only mine one block at a time, so mining 9 at a time (3x3) is very valuable. Last time, I did get it to work… except for one thing. It didn’t show the breaking animation. Usually when you mine blocks it goes thorugh a 9-stage breaking animation, however that seemed too complicated for such a small thing. Well, my brother convinced me to work on it, and here we are.
Essentially, the issue I was having is that block animations cannot be dealt with using the API. I have to delve into NMS, and the world of packets. Some of you probably don’t know what that means so I’ll try to explain. Minecraft servers work by having server-side code and client-side code. The client renders everything (i.e. GUIs), which means that server-side code can’t modify that stuff. Plugins (what I’m making) are server-side only, which means I can only modify what happens on the server. The way the server and client communicate is through packets, which are little morsels of information that synchronize the client and the server. For instance, the client might tell the server that it broke a block, and then the server would broadcast that to every other player so they all know as well. If you are experiencing lag, that means that the server and client cannot communicate in real time, so there can be desynchrony. For instance, when you are lagging you might break a block, or type in chat, however because of lag, those packets cannot reach the server. Therefore, while you will see this on your end, the server won’t register it happening, and every other client wouldn’t register it happening. Essentially, it didn’t happen, until the packet can be sent: when you stop lagging.
Ok, after that not-so-quick tangent on packets, lets get back to the issue of setting the destroy stage of the surrounding blocks. The thing is, there’s no event for when a block’s break stage changes. In fact, using the API I can only tell when a player starts breaking a block. So, I need a packet handler. A packet handler is very simmilar to an event handler, however instead of listening for Spigot events, it listens for Minecraft packets. Essentially I just add a listener so that every time a packet is read from or written to a player, it will handle it. So, when I intercept the packet that indicates a player breaking a block, I.. can’t do anything. Unfortunately, that packet doesn’t indicate the break stage of a block, only if the player starts, finishes, or aborts destroying a block. But here’s the thing: if I don’t have that information, the server doesn’t have that information, which means the other clients don’t have that information. Yet.. they do somehow. Someone else see the animation on a block when you’re is breaking it. Thus, I delve back into NMS.
I had to follow the trail of the packet handling within NMS, until I figured out what it did when it received a start destroy packet. And what I found astounded me. When the server was told that the client is breaking a block, it starts tracking every tick how far along the player is. Now this was crazy at first because I figured it would be so much easier just to have the client tell the server the break stage, then the server relay that information! My running theory can be summed up in one word: hackers. You may have seen them on a public server, perhaps you’ve simply heard the stories of people flying around when they aren’t allowed to, or it’s even possible you’ve tried out a hacked client yourself. Regardless, hacked clients work because of packets. If the client tells the server that it’s moved into the air and starts flying around regardless of gravity.. the server simply accepts it. There are some server-side checks that make hacking not entirely ruin the game, but essentially hacked clients just tell the server something is happening that isn’t using false packets. This is called “spoofing”. If the client told the server how far along it was in breaking a block, maybe you would be able to break it instantly. I could be wrong about this, but I can’t really think of another reason.
Ok, back from that quick tangent about hacked clients and spoofed packets. After figuring out what NMS does, I essentially just have to do it myself, but for the 8 surrounding blocks. Copy the code, make it apply to the surrounding blocks, fix a couple hours worth of bugs, and voila! it works. Hope that was somewhat informative about packets, and to be honest making a hacked client sounds like fun. Maybe I’ll take that on as a small project someday.
Buff Ups
Now for the second thing I’ve done over the past week. The premise is that The Beast should have a drop. As I’ve mentioned, I want every zone to have some sort of special item to go with it. For The Beast, it only makes sense as a drop. The Beast is going to be intentially very difficult to kill, sort of as a mini-boss. Right now it’s a bit to strong, and one of my ToDo items under The Beast is literally just “nerf”. Anyway, it’ll be a one-time drop of a nether-star, which will appear on it’s forhead before it’s been killed, and then subsequent times it won’t show up to indicate it’s already been taken. This nether star will represent a “Cybernetic Core”. This is going with the theme of The Beast being a mutant, so it has some sort of technological/robotic core integrated with its biological body.
You can either redeem the Cybernetic Core for a ticket, or you can integrate it with yourself. What I mean by that is you can place it in one of your armor slots (head, chest, legs, feet). It will then “morph to your body”, making it stronger, and turning into Augmented x (ex. Augmented Head). These pieces of armor are indestructible and cannot be taken off, so you’ll have it for the rest of the game. The challenge is, they have to be powerful enough that killing The Beast, a dangerous endeavour, is worth it, but it’s not so overpowered it just lets you win. Who knew? Balancing a game is hard. So far, I’ve only coded the head and chest, but I’ll explain those.
Starting with the Augmented Head, I need it to do something useful that will also relate to the head somehow. The glaring features of the head are the eyes, ears, and mouth. Using that, I came up with this: firstly it gives you night vision. Night vision is simply an effect that will let you see in darkness, which is a valuable asset. Quite simply, I just give the player night vision when they put on the helmet. The harder part is allowing you to see players within range through walls. This is extremley useful, as it will nullify anyone trying to sneak up on you so long as you’re looking around. Seeing players through blocks is easy, there is an effect called “glowing” that gives entities a white outline even through blocks. I add the effect by looping through every player every tick, and if they are within range, giving them the glowing effect - but using packets. I use packets because in this case, I want to create server-client desynchrony. This is because I only want the glowing effect to be visible to the player with the Augmented Head, not just everyone. So, I only tell the person who is being highlighted and the wearer of the Augmented Head that they are glowing. I tell the person who is being highlighted, so that they know that someone can see them. Pretty much done with that!
Now for the Augmented Chest. Chestplates, at least in Minecraft, usually represent the strongest piece of armor. Your chest is at the center of your body, and houses all of your core innards. So, this piece of the Augmented set is intended to simply be good at protecting you. In Minecraft, when the wither gets to be below half health, it gets a wither armor effect. This effect gives the wither a shimmering white outline, and makes it impervious to projectiles. So, for the Augmented Chest, I’m going to give the armor itself good stats to protect you, but it will also make you immune to projectiles. That part is really easy, simply listen for the event fired when a projectile hits, and if they’re wearing the Augmented Chest, cancel the damage.
The hard part is, once again, cosmetic. I want there to be the effect of wither armor surrounding the player, sort of as if the player were possessed by a wither. Having the armor effect without a wither is easy, as the armor will still show up if the wither is invisible. Simply create a wither, teleport it to the player, and make it not collide with anyone so it doesn’t push people around. Easy, no? No. Unfortunately, entities block a player trying to mine blocks or hit any other entity. If there is an entity in front of your face, you can’t mine a block through the entity. Sadly, there is no way to make this happen, so instead I’m making it so that the wither armor only shows up to players who aren’t within attack range of the augmented player. Sadly, it still has a few bugs as I write this, but hopefully those will be fixed soon.
Wrapup
Well, that’s all for today. It’s getting a bit late, and sadly is a school night, so I have to go to bed. The last thing I’ll say is explaining my reasoning for spending so much effort on the small cosmetic things. Just a few here and there won’t amount to much, and probably hardly anyone will see them. However, if you do a lot of them, and people start noticing them, it makes everything look more professional. The lack of small visual things that make everything look better is very noticeable. Anyway, sorry if the last bit is incoherent, my eyes are starting to droop. That’s all for tonight, and see you next week.