Speaker 1: Have you ever been deep in Minecraft, maybe building something
Speaker 1: amazing and just thought, man, I wish this worked differently.
Speaker 2: Oh, definitely, like wanting a custom command, or maybe changing
Speaker 2: how blocks.
Speaker 1: Behave exactly Like, would it be cool to type one
Speaker 1: thing and have I don't know, a whole army pop up,
Speaker 1: or maybe make every block you touch turn to gold.
Speaker 2: Yeah. Taking that world you know so well and then
Speaker 2: getting the power to actually tweak the rules with code. Well,
Speaker 2: it's literally a game changer.
Speaker 1: It really is. And that's that's pretty much what this
Speaker 1: deep dive is all about. Today. We've been looking at
Speaker 1: this beginner's guide that focuses specifically on using Java programming
Speaker 1: to make those custom Minecraft mods.
Speaker 2: Yeah, think of this as a bit of a shortcut.
Speaker 2: We're aiming to unpack the core bits of Java you
Speaker 2: really need and show how they plug directly into making
Speaker 2: your own mods, you know, going from just playing the
Speaker 2: game to actually shaping it.
Speaker 1: Okay, so let's start right at the beginning. Why Java?
Speaker 1: Why is that the language for Minecraft?
Speaker 2: Well, the source material is pretty clear on this. Minecraft
Speaker 2: itself is built using Java, so it just makes sense.
Speaker 2: It's the native tongue, if you will. And importantly, the
Speaker 2: guide really emphasizes that it's not some super scary, impossible
Speaker 2: language to pick up, especially just for modding basics.
Speaker 1: That's encouraging. So what tools do you actually need to
Speaker 1: get going?
Speaker 2: It's surprisingly accessible really. First you need the Java development kit,
Speaker 2: the cord Java stuff itself, it's free.
Speaker 1: Okay.
Speaker 2: Then you need a place to write the code. The
Speaker 2: guide recommends net beans. That beans right, Yeah, it's an
Speaker 2: ID and integrated development environment, basically a smart text editor
Speaker 2: for code. Also free.
Speaker 1: So Java net beans. Huh what else do you need?
Speaker 1: The game? Ah?
Speaker 2: Yes, you definitely need the actual Minecraft game client, specifically,
Speaker 2: the guide mentions the Windows or mac os versions. That's
Speaker 2: the paid part around twenty seven dollars currently.
Speaker 1: And that's where you'll actually see your mod in action.
Speaker 2: Well, you need one more piece for testing, according to
Speaker 2: the guide, a Minecraft server you set up, usually on
Speaker 2: your own machine, to start your own little test world exactly.
Speaker 2: Your mod runs on the server, and then you connect
Speaker 2: to that server with your regular Minecraft game client using
Speaker 2: the multiplayer option. That whole setup is your development and
Speaker 2: testing playground.
Speaker 1: Okay, setup complete, Now let's crack open NetBeans. You've got
Speaker 1: this software. Yeah, where do you even click? First.
Speaker 2: Right, So in NetBeans, you typically start by creating a
Speaker 2: new project.
Speaker 1: A project like a folder for the mod pretty much.
Speaker 2: Yeah, it holds all the files related to that specific
Speaker 2: mod you're building. And inside that project, you create a
Speaker 2: new Java class file, and the.
Speaker 1: Class file is where the actual instructions go.
Speaker 2: It's it. It's like a blueprint. You write your Java code,
Speaker 2: your instructions inside that class file.
Speaker 1: Now, for the program to actually well run, it needs
Speaker 1: a specific starting point, doesn't it like computers start here exactly?
Speaker 2: Every standalone Java program that you can just run needs
Speaker 2: a special method called main. Okay, that's the entry point.
Speaker 2: When you hit run, the java is looks for that
Speaker 2: main method first and starts executing the code inside it.
Speaker 1: The guide had that classic first example, right. The im
Speaker 1: spartakan is one.
Speaker 2: Yeah, you type one line of code inside Maine something
Speaker 2: like system out dot printle nimspartacus. You run it in
Speaker 2: net Beans.
Speaker 1: And bam, it appears in the output window.
Speaker 2: Yep, your first little piece of running code. It's a
Speaker 2: good feeling, But coding.
Speaker 1: Isn't always smooth sailing. What about mistakes? Typos?
Speaker 2: Ah? Yes, errors. The guide jumps right into that. It's
Speaker 2: just good. It shows how NetBeans helps you out immediately
Speaker 2: how so well, say you forget a semicolon at the
Speaker 2: end of a line, which is easy to do. Net
Speaker 2: Beans will often put a little red squiggle under it
Speaker 2: or show an error.
Speaker 1: Icon like spell check for code.
Speaker 2: Kind of yeah, it gives you instant feedback telling you, hey,
Speaker 2: something's not quite right here. It really helps catch simple
Speaker 2: mistakes early.
Speaker 1: That sounds super useful for beginners. The guide also mentioned
Speaker 1: comments lines that aren't actually right.
Speaker 2: Comments you start them with for a single line, or
Speaker 2: wrap a block with an NM, and.
Speaker 1: The computer just ignores them.
Speaker 2: Completely ignores them when running the program. But they're absolutely
Speaker 2: vital for humans for understanding what you wrote later exactly,
Speaker 2: or for someone else reading your code. They're like little
Speaker 2: notes explaining why you did something or what a particular
Speaker 2: section of code is trying to achieve. Essential for anything complex.
Speaker 1: Okay, so we can run a basic instruction, but mods
Speaker 1: need to remember things right, like a player's name or coordinates,
Speaker 1: or maybe how much health a mob has. How does
Speaker 1: Java handle that?
Speaker 2: That's where variables come in. You can think of variables
Speaker 2: as named containers, like little labeled boxes in the computer's memory.
Speaker 1: Boxes to store information precisely.
Speaker 2: You put pieces of data into these boxes so you
Speaker 2: can use them later in your mod.
Speaker 1: And these boxes hold different kinds of information.
Speaker 2: Yes, very important variables have types for Minecraft moding. The
Speaker 2: guide highlights a few key ones. You'll use a lot
Speaker 2: like well, is a big one. That's for whole numbers,
Speaker 2: think coordinates xyz or counting items.
Speaker 1: Stuff like that. Okay, in for whole numbers.
Speaker 2: Then there's string note the capital s. That's for storing text,
Speaker 2: player names, messages you want to show in chat command
Speaker 2: words like stone or diamond.
Speaker 1: So inf counts string for text. Makes sense.
Speaker 2: The guide also mentions float and double for numbers with
Speaker 2: decimal points maybe for precise positions or something, and char
Speaker 2: for just a single character. But honestly, int and string
Speaker 2: will get you very far when you're starting out with mods.
Speaker 1: How do you like create one of these variable boxes?
Speaker 2: You declare it. You see the type, then the name
Speaker 2: you want to give it. So int player score creates
Speaker 2: an integer variable named.
Speaker 1: Player score, and putting a value in it.
Speaker 2: You use the equal sign. That's the assignment operator. So
Speaker 2: player score equals one hundred, puts the value one hundred
Speaker 2: into that box.
Speaker 1: The guide also showed some shortcuts, didn't.
Speaker 2: It, Like plus Yeah, player score plus ten is shorthand
Speaker 2: for player score player score plus ten and plus plus
Speaker 2: act like player score plus plus ac just adds one
Speaker 2: very common, saves a bit of typing.
Speaker 1: Are the rules for naming these variables A few simple ones.
Speaker 2: They are case sensitive, so player score is different from
Speaker 2: player score. Okay, no spaces or punctuation usually allowed in
Speaker 2: the name, and you can't use java's reserve words words
Speaker 2: like public class INNT if those already have special meanings.
Speaker 1: Got it. So variables hold the data, What about doing
Speaker 1: things with that data?
Speaker 2: Calculations, right, That's where expressions and operators come in. You
Speaker 2: use operators like plus for addition, for subtraction, for a multiplication.
Speaker 1: For division, just like basic math.
Speaker 2: Pretty much in total score at score one plus score
Speaker 2: two adds two scores together. The guide mentions operator precedence
Speaker 2: like multiplication happens before addition, and this exactly. But you
Speaker 2: can always use parentheses to control the order, just like
Speaker 2: in math class to make sure things calculate the way
Speaker 2: you intend.
Speaker 1: And once you've done a calculation, or you just want
Speaker 1: to display some text, how do you show that to
Speaker 1: the user or maybe in the serverlog.
Speaker 2: The most fundamental way in Java is using system dot
Speaker 2: out dot print allen.
Speaker 1: System dot out dot print allen. Bit of a.
Speaker 2: Mouthful, it is, but you get used to it. Whatever
Speaker 2: you put inside the parentheses gets printed out, usually to
Speaker 2: the NetBeans output window or the Micraft server console. When
Speaker 2: you're moddling like.
Speaker 1: That example, alphae has been killed by a magma cube.
Speaker 2: Huh huh, yeah, that memorable one, that exact text would appear.
Speaker 2: There's also system dot out dot print, which does the
Speaker 2: same thing, but doesn't automatically start a new line afterwards.
Speaker 1: Okay, so we can store info, do math, print stuff out.
Speaker 1: But real programs need to make decisions, don't they Like
Speaker 1: if the player does X, then do HY or repeat tasks.
Speaker 2: Absolutely, that's control flow. You need ways to control which
Speaker 2: lines of code execute and when. Conditional statements and loops
Speaker 2: are the pills for that.
Speaker 1: Conditionals first making choices.
Speaker 2: The simplest is the if statement. You give it a
Speaker 2: condition something that's either true or false. If it's true,
Speaker 2: the code inside the if block runs. If not, it's skipped.
Speaker 1: So if player has enough gold, then run the code
Speaker 1: to give them the item exactly.
Speaker 2: Then you've got if else. This gives you two paths.
Speaker 2: If the condition is true, do the if part. If
Speaker 2: it falls else, do the else part. Plan A, plan B.
Speaker 2: The guide also mentioned the switch statement. That's useful when
Speaker 2: you have one value and you want to do different
Speaker 2: things based on several possible specific values. It could have
Speaker 2: like checking an item type and doing something different for
Speaker 2: a sword, an ax, or a pick axe.
Speaker 1: Okay, decisions covered. What about doing things repeatedly?
Speaker 2: Loops essential for so many modding tasks. Imagine placing blocks
Speaker 2: in a line or checking every slot in a chest.
Speaker 2: You need loops.
Speaker 1: The fore loop is one, right, Yeah.
Speaker 2: The fore loop is often used when you know roughly
Speaker 2: how many times you need to repeat something. You typically
Speaker 2: set up a counter, tell it when to stop and
Speaker 2: how to increment.
Speaker 1: Like for I from zero to nine place.
Speaker 2: A block perfect example. Then there's the wil loop. It's different.
Speaker 2: It keeps looping as long as a condition stays true.
Speaker 1: More like while the button is held down, keep doing
Speaker 1: this exactly.
Speaker 2: The condition is checked before each loop iteration. The guide
Speaker 2: also mentions do while, which is similar, but the check
Speaker 2: happens after the code runs, so it always runs at least.
Speaker 1: Once, and sometimes you need to stop a loop early.
Speaker 2: Yeah, the break statement lets you jump out of a
Speaker 2: loop immediately. If you're searching through a list and find
Speaker 2: the item you need on the third try, you can
Speaker 2: just break out instead of checking the other one hundred items.
Speaker 1: So if else switch for a while. Those are the
Speaker 1: core control tools.
Speaker 2: There really are. Mastering those lets you build the actual
Speaker 2: logic into your mod.
Speaker 1: Now, we talked about variables for single pieces of info,
Speaker 1: but what if you have like a whole bunch of things,
Speaker 1: say all the players online or a list of block
Speaker 1: coordinates for a structure, Making a separate variable for each
Speaker 1: seems inefficient, Totally inefficient.
Speaker 2: That's where arrays save the day. An array is a
Speaker 2: special kind of variable that holds a collection of items
Speaker 2: a list, basically kind of but with a key restriction.
Speaker 2: All items in a single array must be the same type.
Speaker 2: So you can have an array of vents or an
Speaker 2: array of string, but not a mix in one standard array.
Speaker 1: So an inter ray could hold all the y coordinates
Speaker 1: for a tower exactly.
Speaker 2: You create an array and specify its size upfront, like
Speaker 2: in chords equals new Inn fifty, it creates an array
Speaker 2: that can hold exactly fifty integers fixed size. Huh yep.
Speaker 2: That's a key characteristic of basic arrays. Each slot in
Speaker 2: the array is called an element, and you access them
Speaker 2: using an index.
Speaker 1: Number, and the index starts at zero.
Speaker 2: Always zero in Java. So the first element is an
Speaker 2: index zero, the second at index one up to index
Speaker 2: forty nine. In our fifty element array that.
Speaker 1: Reindeer names example in the guide really drove that fixedisz
Speaker 1: point home made an array for eight reindeers.
Speaker 2: And then poor Rudolph couldn't fit because the array was
Speaker 2: full there was no index eight.
Speaker 1: Right. How do you know how big an array is
Speaker 1: once you have it.
Speaker 2: Arrays have a handy length property, so ycords dot length
Speaker 2: would give you fifty.
Speaker 1: And what happens if you mess up and try to
Speaker 1: access say index fifty in that fifty element array.
Speaker 2: Boom, Well not quite boom, but your program will likely
Speaker 2: stop and throw an array index out of bounds.
Speaker 1: Exception an exception like an error.
Speaker 2: Yeah it's job as a way of saying you tried
Speaker 2: to access a part of the array that doesn't exist.
Speaker 2: The guide points out the specific exception usually means there's
Speaker 2: a flaw in your.
Speaker 1: Code logic something you need to fix. In the code itself,
Speaker 1: not just handle during runtime.
Speaker 2: Generally, yes, you should fix your loop or your index
Speaker 2: calculations so it doesn't try to go out of bounds.
Speaker 2: Arrays are fundamental, but the guide also briefly mentions other
Speaker 2: collection types, things like a ray list. It's more flexible,
Speaker 2: like a list that can grow or shrink as needed,
Speaker 2: much more convenient than fixed size arrays sometimes, and hash map,
Speaker 2: which is great for storing key value pair.
Speaker 1: KEYWTE like looking up a word in a dictionary.
Speaker 2: Exactly, you store something using a unique key like a
Speaker 2: player's name, a string and associate it with a value
Speaker 2: like their score an end. Then you can quickly retrieve
Speaker 2: the value just by knowing the key. Very useful structure.
Speaker 1: Okay, arrays and collections for handling groups of data. Now
Speaker 1: let's just step back a bit. The guide talks about
Speaker 1: a really big concept, object oriented programming.
Speaker 2: Op ah yes, oh ohp. It's a whole way of
Speaker 2: thinking about structuring your programs, and it's fundamental to Java
Speaker 2: and by extension, to Minecraft modding with things like spigot.
Speaker 1: So what does object oriented actually mean in this context?
Speaker 2: It means you design your program around objects. Think of
Speaker 2: objects as representations of well things. They could be real
Speaker 2: world things like a player, a wolf, a block, or
Speaker 2: more abstract things like a game rule or a server event.
Speaker 1: And what makes something an object? In code?
Speaker 2: Two main things to find an object. First, it has
Speaker 2: data associated with it, attributes or properties think variables, but
Speaker 2: belonging to that object. Second, it has behavior things that
Speaker 2: can do. These are called methods.
Speaker 1: Okay, So back to that zombie idea earlier.
Speaker 2: Perfect a zombie object would have attributes like health, maybe
Speaker 2: an int, location, maybe a location object is baby, a
Speaker 2: true false, a boolean that's the data right, and its behavior.
Speaker 2: It's methods would be things like attack player, target, move
Speaker 2: towards location, destination, take damage into mounts.
Speaker 1: So an object bundles is data and its actions.
Speaker 2: Together exactly the guide use a virus example, I think
Speaker 2: with attributes like identify an author, same principle, and a
Speaker 2: key part of OKP is controlling access to that data.
Speaker 1: The public and private stuff.
Speaker 2: Yes, you can mark attributes and methods as public meaning
Speaker 2: any part of your code can access them directly, or
Speaker 2: private meaning only the code inside that same object's class
Speaker 2: can access them.
Speaker 1: Why make things private?
Speaker 2: It's about encapsulation, protecting the object's internal state. Usually you
Speaker 2: keep the data health, etc. Private and provide public methods
Speaker 2: get health, set health to interact with it in a
Speaker 2: controlled way. It makes your code more robust and easier
Speaker 2: to manage.
Speaker 1: And methods can give back results you.
Speaker 2: Said yep using the return keyword. A method like get
Speaker 2: health would return the current value of the private health variable.
Speaker 2: A method that just performs an action like attack might
Speaker 2: not return anything. Its return type would be void.
Speaker 1: Okay, Then there were static methods. Those felt a bit different.
Speaker 2: They are a bit different. Remember, the class is the blueprint,
Speaker 2: and objects are the things made from the blueprint. Right,
Speaker 2: Normal methods belong to the objects. Static methods belong to
Speaker 2: the class itself, the blueprint. You don't need a specific
Speaker 2: object instance to use them.
Speaker 1: Like that integer dot parsing example, converting text to a.
Speaker 2: Number exactly, you don't need an integer object. You just
Speaker 2: call the method directly on the integer class integer parcent one,
Speaker 2: two three. They're often used for utility functions that don't
Speaker 2: depend on the state of a particular object.
Speaker 1: And making a new object, like a new zombie in
Speaker 1: the game that uses the new keyword.
Speaker 2: Correct zombie, My zombie equals new zombie When you use
Speaker 2: new a special method called a constructor gets called.
Speaker 1: Automatically a constructor.
Speaker 2: Yeah, it's a method with the same name as the
Speaker 2: class zombie, and its job is to initialize the new object,
Speaker 2: set up its initial state, give its attributes starting values.
Speaker 1: Cool. The guide also covered inheritance using extends.
Speaker 2: That sounds important, Oh, it's huge In Java and Minecraft.
Speaker 2: Inheritance is how you create classes that are based on
Speaker 2: other classes. You make a new class, the subclass or
Speaker 2: child that automatically gets all the non private attributes and
Speaker 2: methods from an existing class.
Speaker 1: The superclass reparent like a family tree for code.
Speaker 2: Kind of. So in Minecraft you might have a monster
Speaker 2: class that extends living entity, which extends entity. This means
Speaker 2: your monster automatically knows how to do everything an entity
Speaker 2: can like exist in the world at a location, and
Speaker 2: everything a living entity can like have health, take damage,
Speaker 2: plus any specific monster things you add, so you.
Speaker 1: Don't have to rewrite all that basic entity stuff every
Speaker 1: time exactly.
Speaker 2: It promotes code reuse and creates a logical hierarchy. Java
Speaker 2: itself has a base object class that everything ultimately inherits from.
Speaker 1: Okay, that op structure makes sense, but what happens when
Speaker 1: things just go wrong while the program is running, not
Speaker 1: a typo that net Beans catches, but like unexpect.
Speaker 2: Situations right run time problems, that's where exceptions come in.
Speaker 2: The guide described them as exceptional circumstances. The program hits
Speaker 2: a situation it wasn't necessarily designed to handle smoothly at
Speaker 2: that exact point, like.
Speaker 1: The user typing text when you expected a number.
Speaker 2: That's the classic example the new calculator, and the guide
Speaker 2: showed this perfectly. If your code tries to use integer
Speaker 2: dot parsin on the text hello, that's going to cause
Speaker 2: a problem. It would crash unless you handle the exception.
Speaker 2: Java lets you anticipate these problems using a tricatch block.
Speaker 1: How does that work?
Speaker 2: You put the code that might cause an exception, the
Speaker 2: risky code like integer dot parse end user input inside
Speaker 2: a tryblock. Immediately after it, you put a catch block.
Speaker 2: The catch block specifies the type of exception it's designed
Speaker 2: to handle, like number format exception.
Speaker 1: So if that specific error happens inside.
Speaker 2: Try, the program immediately jumps to the catch block for
Speaker 2: number format exception and runs the code inside that block
Speaker 2: instead of crashing. Do you Calculator example, use this to
Speaker 2: print a nice message like, Hey, that wasn't a number
Speaker 2: instead of just dying, that's much better. Yeah.
Speaker 1: The guide also mentioned other exceptions like that array index
Speaker 1: out of bounds exception again and null pointer exception.
Speaker 2: Yeah. Null pointer exception happens when you try to use
Speaker 2: a variable that hasn't been initialized to point to an
Speaker 2: actual objecto null pointing to nothing.
Speaker 1: And the guide said you shouldn't always try to catch those.
Speaker 2: It made the point that exceptions like array index outbounds
Speaker 2: or null pointer often signal a fundamental logic error in
Speaker 2: your code. While you could technically catch them, it's usually
Speaker 2: better practice to fix the underlying code flaw that's causing them,
Speaker 2: rather than trying to patch over it with a catch block.
Speaker 2: Prevent the error rather than just reacting to it.
Speaker 1: Got it, fix the bug. Okay, we've chewed through a
Speaker 1: lot of core Java there. The guide also glanced at
Speaker 1: a couple of slightly more advanced topics.
Speaker 2: Just briefly. One was threads. Threads are a way to
Speaker 2: make your program do multiple things seemingly at the same time,
Speaker 2: like multitasking. Much The prime Finder example showed this one
Speaker 2: part of the code. One thread could be doing heavy
Speaker 2: calculations while another thread updates the user interface or progress bar,
Speaker 2: keeping things responsive.
Speaker 1: Useful for long tasks in a mod maybe could be.
Speaker 2: And the other thing was file io input output, reading
Speaker 2: and writing files exactly using Java's built in libraries to
Speaker 2: read data from files like loading mod settings, or write
Speaker 2: data to files like saving player progress or configuration. The
Speaker 2: configurat example showed writing simple key value pairs like username
Speaker 2: max to a dot properties file. It involves concepts like
Speaker 2: data streams and remembering to close the file connection when
Speaker 2: you're done.
Speaker 1: Okay, wow, that's a lot of Java. Now the payoff.
Speaker 1: How does all this variables, loops, objects, exceptions actually let
Speaker 1: you make a Minecraft mod using something like spiggot, which
Speaker 1: the guide mentioned right.
Speaker 2: This is where it connects. Spigot is a popular modified
Speaker 2: Minecraft server software that provides an API, a set of
Speaker 2: two tools and interfaces for mod developers. Your mod is
Speaker 2: essentially a Java program that plugs into spigot.
Speaker 1: So how does a basic mod look?
Speaker 2: Your main mod class will typically extend a class provided
Speaker 2: by Spigot, usually Java plug in. This hooks your code
Speaker 2: into the server's life cycle.
Speaker 1: And making it do something when a player types a
Speaker 1: command like petwolf.
Speaker 2: That's a core feature you override a specific method in
Speaker 2: your main class called on command.
Speaker 1: Override, meaning you provide your own version exactly.
Speaker 2: Spigott calls your on command method. Whenever a player uses
Speaker 2: a command associated with your mod. Spigott gives your method
Speaker 2: information like who sent the command, what the command was,
Speaker 2: and any arguments typed after it.
Speaker 1: So insight on command, you'd check if the command was.
Speaker 2: Petwolf yep, and the guide stressed. You should also check
Speaker 2: if the sender was actually a player, because sometimes bands
Speaker 2: might come from the server console itself, which can't own
Speaker 2: a wolf.
Speaker 1: Good point, and the petwolf example used that on a
Speaker 1: command to what spawn a wolf?
Speaker 2: Yeah, it's code running inside on command would use Pigott's
Speaker 2: a p I calls to get the player's location, spawn
Speaker 2: a wolf entity there, set its color to pink, and
Speaker 2: then set the player who typed the command as the
Speaker 2: wolf's owner.
Speaker 1: Cool. But how does Spigotto that petwolf belongs to your
Speaker 1: mod in the first place?
Speaker 2: Ah configuration, you need a special file called plug in
Speaker 2: dot eml. It's a simple text file you bundle with
Speaker 2: your mod.
Speaker 1: What goes in it?
Speaker 2: Basic info, your mod's name, the author, the main Java
Speaker 2: class that Spigot should load your dot package dot main
Speaker 2: class and crucially a commands section. There you define petwolf,
Speaker 2: give it a description, and make some usage instructions. That
Speaker 2: file tells spiggot, hey I exist and I handle these commands.
Speaker 1: Okay, And what if the command has arguments like transmute
Speaker 1: stone diamond, how do you get stone in diamond.
Speaker 2: Those words come into your own command method as an
Speaker 2: array of string arguments. Your code would look at that array.
Speaker 2: Index zero zero would be stone, index one would be diamond.
Speaker 1: And then you use those strings. Right.
Speaker 2: The guide showed how spigot provides methods like material dot
Speaker 2: get material. You pass it the string stone and it
Speaker 2: gives you back the actual material object representing stone in
Speaker 2: the game. The transmuter mod would use this to figure
Speaker 2: out the from material and the two material based on
Speaker 2: player input.
Speaker 1: This leads into actually interacting with the game world, mobs
Speaker 1: blocks the environment itself. That feels like the real heart
Speaker 1: of modding.
Speaker 2: It really is all those Java object concepts applied directly.
Speaker 1: Here.
Speaker 2: You get references to game objects, living entities, zombie player block,
Speaker 2: and then you use their methods. So for mobs you
Speaker 2: can use methods like world dot spawn to create new
Speaker 2: ones or get an existing mob object and call methods
Speaker 2: on it to change its properties, set its age, apply
Speaker 2: potion effects. The guide mentioned making one mob ride another
Speaker 2: using set passenger lots of possibilities.
Speaker 1: But mods don't just react to commands. What about reacting
Speaker 1: to things happening in the game, like a player mining
Speaker 1: a block or a creeper exploding.
Speaker 2: Yes, event handling this is maybe even more central than
Speaker 2: commands For many mods. Your mod becomes an event listener
Speaker 2: listening for it why for specific events that the Spigot
Speaker 2: server broadcasts whenever something significant happens in the game player movement,
Speaker 2: entity taking, damage, block breaking, inventory clicks, tons of events.
Speaker 1: So your mod is constantly listening in the background.
Speaker 2: Sort of. You have to register it. First. You make
Speaker 2: your main mod class or another class implement the listener interface. Then,
Speaker 2: when your mod starts up, usually in a method called
Speaker 2: on able, you tell spiggott, hey start sending events to
Speaker 2: this listener object.
Speaker 1: Okay, registered?
Speaker 2: Then what Then You write specific methods in your listener
Speaker 2: class and mark them with at event handler. Each method
Speaker 2: takes a specific event type as a parameter, like player
Speaker 2: move event or entity damage.
Speaker 1: Event, and that method automatically runs when that event hass exactly.
Speaker 2: Spiggott sees the event, finds all registered listeners with handlers
Speaker 2: for that event type, and calls their at event handler methods,
Speaker 2: passing in the event object, which contains details about what happened.
Speaker 1: Can you give those examples from the guide again?
Speaker 2: The stone right stone Walker would have an ad event
Speaker 2: handler method that takes a player move event. Inside that method,
Speaker 2: it gets the location the player moved from and uses
Speaker 2: Spiggott's API to change the block at that location, maybe
Speaker 2: to stone or gold or whatever.
Speaker 1: It's the Pathway and health checker.
Speaker 2: That would listen for entity damage event. It's handler runs,
Speaker 2: gets the entity that was damaged, maybe, calculates its remaining
Speaker 2: health percentage, and then uses methods like set custom name
Speaker 2: on the entity object to display that health maybe using
Speaker 2: Spiggot's check color codes to make it red or green like.
Speaker 1: A dynamic health bar above their head.
Speaker 2: Precisely. And the Zeus mod that's out of fun. Yeah,
Speaker 2: that one listens for entity target event. When a mob
Speaker 2: targets a player, the handler runs, gets the mob's location
Speaker 2: and calls World dot strike lightning at that spot.
Speaker 1: Bam. Wow. So events let you react to almost anything
Speaker 1: pretty much.
Speaker 2: It's how you make mods that feel deeply integrated with
Speaker 2: the gameplay, not just triggered by commands. You combine listening
Speaker 2: for the event with using the Java objects player, block, entity, world,
Speaker 2: and Spigot methods strike, lightning, set type, set custom name
Speaker 2: to make changes.
Speaker 1: Speaking of changing things, let's focus on blocks for a second. Yeah,
Speaker 1: how do you pinpoint and manipulate specific blocks in the world.
Speaker 2: You use a combination of classes. Spigot provides World represents
Speaker 2: the dimension overworld nether end location holds specific xyz coordinates
Speaker 2: within that world. Block represents the actual block at a
Speaker 2: given location, and material defines the type of block like
Speaker 2: material dot stone, material dot diamond or so.
Speaker 1: How do you change a block?
Speaker 2: Typically you get the world object, then use a location
Speaker 2: object which might come from an event, or you calculate
Speaker 2: it to get the specific block object using a method
Speaker 2: like world dot get block at location. Once you have
Speaker 2: the block object, you can call methods on it like
Speaker 2: get type to see what it is, or set type,
Speaker 2: material dot goldiebelot to change it.
Speaker 1: The guide mentioned big Dig in Tree Chopper is more
Speaker 1: complex examples.
Speaker 2: Yeah, they illustrate going beyond single Big dig would involve
Speaker 2: some math to figure out all the locations within a
Speaker 2: certain radius of the player than looping through those locations
Speaker 2: to change each block and.
Speaker 1: Tree chopper sounds like it needs to find all the logs.
Speaker 2: Right, that's more complex. You might detect when a log
Speaker 2: block is broken than have code that searches upwards and
Speaker 2: maybe outwards for connected log blocks, potentially using loops or
Speaker 2: even more advanced techniques like recursion, where a method calls
Speaker 2: itself to explore the tree structure. These show how you
Speaker 2: build on the basics to tackle bigger problems. Managing potentially
Speaker 2: lots of blocks and locations.
Speaker 1: With all this power to change the world, literally digging
Speaker 1: holes and chopping trees with code. Managing the actual Minecraft
Speaker 1: world files seems important. Any tips from the guide on
Speaker 1: that definitely.
Speaker 2: It strongly recommends making regular backups of your world folders.
Speaker 1: Just copy the folder.
Speaker 2: Pretty much find your server directory and inside there will
Speaker 2: be folders named after your world, usually World, nether and
Speaker 2: world themed. To do this when the server is not
Speaker 2: running to avoid corrupted files, just copy those folders somewhere safe.
Speaker 1: Good advice. How do you know the world name?
Speaker 2: If it's not just world, You can usually find the
Speaker 2: name listed in the server dot properties file in your
Speaker 2: server directory and.
Speaker 1: The world seed that unique generation number.
Speaker 2: Yeah, the guide mentions you can easily get that in
Speaker 2: game using the command seed. Good to note down if
Speaker 2: you ever want to recreate the exact same terrain later.
Speaker 1: Okay, so, looking back, we've covered quite a bit of ground,
Speaker 1: from the absolute basics of Java.
Speaker 2: Syntax variables, if statements, loots.
Speaker 1: To organizing code with objects, in handling.
Speaker 2: Errors, inheritance exceptions, trycatch, and.
Speaker 1: Then seeing how all those pieces come together using this
Speaker 1: Spigott api to actually make things happen in Minecraft.
Speaker 2: Yeah, writing command handlers, listening for game events, spawning mobs,
Speaker 2: changing blocks. It all uses those core Java concepts and.
Speaker 1: It's worth stressing. Like the guide implies, these skills aren't
Speaker 1: just for Minecraft modding.
Speaker 2: Absolutely understanding variables, control flow, object oriented programming, event handling,
Speaker 2: these are foundational concepts used across vast areas of software development.
Speaker 2: Learning Java from modding gives you a really solid base.
Speaker 1: And for folks who want to dive deeper, the guide
Speaker 1: mentioned to resource.
Speaker 2: Yeah www dot javamincraft dot com sounds like a place
Speaker 2: to find the source code for examples, ask question and
Speaker 2: connect with other people learning the stuff. Community is always
Speaker 2: helpful when learning to code.
Speaker 1: So really taking these first steps into programming through something
Speaker 1: familiar like Minecraft, it fundamentally changes your relationship with the game,
Speaker 1: doesn't it.
Speaker 2: It really does. You're not just playing by the rules anymore.
Speaker 1: You're starting to understand how to write the rules.
Speaker 2: You've got the potential power to reshape that world, So
Speaker 2: the question really becomes what will you create