When a class is abstract, there is necessarily at least one child of it somewhere. Classes need to be instantiated, or they wouldn't have a purpose.
In case of World, there are multiple childs. WorldServer, WorldClient...you choose the one you want, then you replace with your own child instance where appropriate.
In your case, i already suggested WorldServer to be replaced in MinecraftServer#worldServers.
If you don't understand that, you have two choices:
-learn more Java
-use Forge(I would advise both, anyways)
I was thinking, instead of just overriding the codes, why don't I just instead make my own files for copies of those specific codes, and then try to implement them into my code... That'd work out better in the long run right?
What you just said doesn't make sense. Code is not loaded by magic, it is actually called by code from the place where it is needed.
The only easier option has already been explained in previous posts: Just edit the base classes with your stuff in and ship them with the mod.
I mean, how is your mod loaded anyways ? Did you even work out the code needed to add a new block ?
Went back to trying to edit base code, went to your suggested isNormalCube, and when I make it so that an instantof my block file, set to true, then it breaks the block just like canProvidePower being turned off, which is partially the code.
Basically what I did is adding an if statement to return true for only my block under the var1 and before the return,
1. Screw editing. Tired of getting weird things happening to comment after edit with using the HTML code functions! -n-
2. Everything seems to be working fine now, except the updating method I am using at the moment might become a performance issue, and could be already. I did a Piston BUD(Block Update Detector), and with my block not powered or anything next to the Piston BUD, it would constantly update the piston, so it was almost like there was no BUD issues in the piston code xD
Not sure what to do yet about my current updating methods. :/
#Edit: Did a test on a flat world with the floor being my blocks... Yeah, it lagged when I turned a lever on, took about 3-10 seconds to update and tell the first block to update itself... o-o
I've managed to seemingly fix the looping of the updating, schedualBlockUpdate was the cause. Would there be a way to add a tick delay to a method?
Right now the delays are off, the shedualBlockUpdate was controlling the timing so now some of my contraptions are going too fast.
I'd like to avoid adding one to notifyBlockOfNeighborChange, since I have 7 lines of that, but I will if it's needed. Seems like that could be the only option, I am not sure right now, I'm sleep deprived so I am overlooking a lot of things at the moment.
I didn't notice this until after looking for the code I used previously which was just returning scheduleBlockUpdate and nothing else, so thanks again! XD
Also, on page 5 of this post, you gave a diagram of how the updating works. I am not sure exactly which of the surrounding blocks my block is updating, but shouldn't it be something like this?
The glass being the blocks I want to update...
Also since the block is orientation based, face 0 is the face that gives off the update, no other directions get updated. Seems like a good thing for this block.
Hm? It already knows the orientations, I've already got something in place for that. I just am not sure it's updating just those blocks represented by the glass blocks and nothing else. I am not sure exactly how to test that and was wondering if you knew based off my code example which blocks exactly it's updating.
Uhm... Hmm... Here's what I now have for the updating
//Block Placement & Updating//
/**
* Called when the block is placed in the world.
*/
public void onBlockPlacedBy(World par1World, int par2, int par3, int par4, EntityLivingBase par5EntityLivingBase, ItemStack par6ItemStack)
{
int var6 = determineOrientation(par1World, par2, par3, par4, par5EntityLivingBase);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
/**
* Ticks the block if it's been scheduled
*/
public void updateTick(World par1World, int par2, int par3, int par4, Random par5Random)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
public void updateNeighbors(World par1World, int par2, int par3, int par4)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
/**
* Lets the block know when one of its neighbor changes. Doesn't know which neighbor changed (coordinates passed are
* their own) Args: x, y, z, neighbor blockID
*/
public void onNeighborBlockChange(World par1World, int par2, int par3, int par4, int par5)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
/**
* Called right before the block is destroyed by a player. Args: world, x, y, z, metaData
*/
public void onBlockDestroyedByPlayer(World par1World, int par2, int par3, int par4, int par5)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
if (this.isPowered)
{
updateNeighbors(par1World, par2, par3, par4);
}
Basically I guess I am just wanting reassurance that my notifyBlocksOfNeighborChange are just updating ONLY the blocks represented as glass. Those which are glass are the ONLY neighboring blocks that I want to update, and looking at the code, and based on test, it does look like it is what it's doing. You know more about this than I, so I figured you'd be able to tell by looking at the block notifyBlocksOfNeighborChange I have set up for my block.
/**
* This will update the determined sides
*/
public void updateNeighbors(World par1World, int par2, int par3, int par4)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 + 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 - 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 + 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 - 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 + 1, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 - 1, this.blockID);
}
Again just to be clear, I am just wanting to make sure my notifyBlocksOfNeighborChange would only be updating just the glass blocks, and no other blocks, lol.
I'm testing a few things with it, how would I set the cords like that for notifyBlocksOfNeighborChange?
#Edit: It's updating the neighboring blocks just like the Repeater does, so I guess it's fine as is. This is probably about the last thing I need to fix, so I will go test things more before calling it finished.
Thanks so much, without your help I would have probably gave up on the project. Right now I'm pretty much finished, just a bit of polishing up and stuff. ^^
I had a custom keybind actually hard coded inside my own class files, but just today made a configurable one, which gives the ability to reverse the direction upon placing the block. I will probably post both codes for others to use. :3
Bad thing about this is that when you're flying in creative and need to place the block in reverse orientation onto an interactive block (like Dispensers), then you need to hold 3 keys together, Shift + Space + Reverse Orientation Key.
Space + Shift, obviously just when you're flying so you don't plummet to the ground, other wise it's just Shift + Reverse Orientation Key. Which I preconfigured to be CTRL
However, the wonderful thing about this is that the way I have it set up, I should be able to very simply apply this code to any orientation based block, like Pistons, Dispensers, Repeaters, Chest, and so on.
What do you think of this as a recipe?
(Recipe doesn't call for burnt out Redstone Torch, the applet I used has bad textures)
Too expensive maybe? Mostly people will want to make a lot of these, and Quartz is already so widely used, I don't want it to be a burden to craft.
Haha, I might have done most of the work, but it really helps to actually get some help with things, and for me in general it helps to have someone to be able to bounce ideas off of, especially when they know what they're talking about.
I've been working on this project for close to a year, been asking questions here on MCF for a little while with bad help, or no help and deleting a lot of threads. Then there are the Java forums where people seem to try to help then just tell me to go read a book, which doesn't help me at all as I have ADHD. XD
Yeah, definitely thee kind of thing that keeps someone from just rage quitting something they love doing.
Well, of course this very well could have been made without it, but the way my block is being implemented in various places does impact the overall design a lot.
One being the way the tracks are set up. My block only allows the power to be directed right to the Powered Track where it's needed the most, and does not affect the Hoppers at all.
Otherwise without them you'd have to make some kind of solution that's at the same height as the tracks, which in the example image, would be on the top Powered tracks, and then the top cart would grind against the blocks causing it to slow down slightly. I found that's actually a thing, and something I was using as a slowing mechanism before.
And then this one isn't as important, but still defiantly helps. My block helps to make things much more compact in a lot of ways, one being a fill up station as seen below, as well as the Minecart seen here going to a fill up station, and deposit station.
Yeah, this most definitely has the possibility to revolutionize how Redstone devices are built.
The Semi Automatic Cobblestone Generator is a prime example. Sadly there is not any speed improvements in my newer design, but it takes like 19 seconds to generate an entire line I think. I probably need to re-time the generators, but it's still pretty fast like tick tock.
#Edit: I was also able to make a Semi Automatic Stone Generator, since this block can't be washed away it's now much easier to make, but not as compact as the Semi Automatic Cobblestone Generator.
This block also helps make something else more possible. Can you guess what it might be?
P.S. I left a clue to what this device is, somewhere in this post. Hehe.
In case of World, there are multiple childs. WorldServer, WorldClient...you choose the one you want, then you replace with your own child instance where appropriate.
In your case, i already suggested WorldServer to be replaced in MinecraftServer#worldServers.
If you don't understand that, you have two choices:
-learn more Java
-use Forge(I would advise both, anyways)
And, I did this, seems like it's what you meant, I'm not sure, but it's not working.
I was thinking, instead of just overriding the codes, why don't I just instead make my own files for copies of those specific codes, and then try to implement them into my code... That'd work out better in the long run right?
The only easier option has already been explained in previous posts: Just edit the base classes with your stuff in and ship them with the mod.
I mean, how is your mod loaded anyways ? Did you even work out the code needed to add a new block ?
Went back to trying to edit base code, went to your suggested isNormalCube, and when I make it so that an instantof my block file, set to true, then it breaks the block just like canProvidePower being turned off, which is partially the code.
Basically what I did is adding an if statement to return true for only my block under the var1 and before the return,
if (var1 instanceof BlockRedstoneDirectional)
{
return true
}
-else return original return-
Original rip from Block class
[/pre]
[pre]
#Edit: getIndirectPowerLevelTo, in the World class seems to be the thing to override, now to screw around with it! [/pre]
1. Screw editing. Tired of getting weird things happening to comment after edit with using the HTML code functions! -n-
2. Everything seems to be working fine now, except the updating method I am using at the moment might become a performance issue, and could be already. I did a Piston BUD(Block Update Detector), and with my block not powered or anything next to the Piston BUD, it would constantly update the piston, so it was almost like there was no BUD issues in the piston code xD
Not sure what to do yet about my current updating methods. :/
#Edit: Did a test on a flat world with the floor being my blocks... Yeah, it lagged when I turned a lever on, took about 3-10 seconds to update and tell the first block to update itself... o-o
But seeing as this isn't BUD friendly, not sure if it'd be well accepted by those who do a lot of Redstoning. ^^;
Right now the delays are off, the shedualBlockUpdate was controlling the timing so now some of my contraptions are going too fast.
I'd like to avoid adding one to notifyBlockOfNeighborChange, since I have 7 lines of that, but I will if it's needed. Seems like that could be the only option, I am not sure right now, I'm sleep deprived so I am overlooking a lot of things at the moment.
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
if (!var8 && isPowered)
{
{
par1World.scheduleBlockUpdate(par2, par3, par4, this.blockID, 1);
}
}
if (var8 && !isPowered)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalActive.blockID, var6, 2);
updateNeighbors(par1World, par2, par3, par4);
}
I didn't notice this until after looking for the code I used previously which was just returning scheduleBlockUpdate and nothing else, so thanks again! XD
Also, on page 5 of this post, you gave a diagram of how the updating works. I am not sure exactly which of the surrounding blocks my block is updating, but shouldn't it be something like this?
The glass being the blocks I want to update...
Also since the block is orientation based, face 0 is the face that gives off the update, no other directions get updated. Seems like a good thing for this block.
par1World.notifyBlocksOfNeighborChange(par2, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 + 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 - 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 + 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 - 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 + 1, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 - 1, this.blockID);
//Block Placement & Updating//
/**
* Called when the block is placed in the world.
*/
public void onBlockPlacedBy(World par1World, int par2, int par3, int par4, EntityLivingBase par5EntityLivingBase, ItemStack par6ItemStack)
{
int var6 = determineOrientation(par1World, par2, par3, par4, par5EntityLivingBase);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalIdle.blockID, var6, 2);
if (var8)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalActive.blockID, var6, 2);
}
updateNeighbors(par1World, par2, par3, par4);
}
/**
* Ticks the block if it's been scheduled
*/
public void updateTick(World par1World, int par2, int par3, int par4, Random par5Random)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
if (!var8 && isPowered)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalIdle.blockID, var6, 2);
}
if (var8 && !isPowered)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalActive.blockID, var6, 2);
}
updateNeighbors(par1World, par2, par3, par4);
}
public void updateNeighbors(World par1World, int par2, int par3, int par4)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 + 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2 - 1, par3, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 + 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3 - 1, par4, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 + 1, this.blockID);
par1World.notifyBlocksOfNeighborChange(par2, par3, par4 - 1, this.blockID);
}
/**
* Lets the block know when one of its neighbor changes. Doesn't know which neighbor changed (coordinates passed are
* their own) Args: x, y, z, neighbor blockID
*/
public void onNeighborBlockChange(World par1World, int par2, int par3, int par4, int par5)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
boolean var8 = this.isGettingInput(par1World, par2, par3, par4, var6);
if (!var8 && isPowered)
{
{
par1World.scheduleBlockUpdate(par2, par3, par4, this.blockID, 1);
}
}
if (var8 && !isPowered)
{
par1World.setBlock(par2, par3, par4, Block.redstoneDirectionalActive.blockID, var6, 2);
updateNeighbors(par1World, par2, par3, par4);
}
}
/**
* Called right before the block is destroyed by a player. Args: world, x, y, z, metaData
*/
public void onBlockDestroyedByPlayer(World par1World, int par2, int par3, int par4, int par5)
{
int var5 = par1World.getBlockMetadata(par2, par3, par4);
int var6 = getOrientation(var5);
if (this.isPowered)
{
updateNeighbors(par1World, par2, par3, par4);
}
super.onBlockDestroyedByPlayer(par1World, par2, par3, par4, par5);
}
//End Block Placement & Updating//
Basically I guess I am just wanting reassurance that my notifyBlocksOfNeighborChange are just updating ONLY the blocks represented as glass. Those which are glass are the ONLY neighboring blocks that I want to update, and looking at the code, and based on test, it does look like it is what it's doing. You know more about this than I, so I figured you'd be able to tell by looking at the block notifyBlocksOfNeighborChange I have set up for my block.
Again just to be clear, I am just wanting to make sure my notifyBlocksOfNeighborChange would only be updating just the glass blocks, and no other blocks, lol.
#Edit: It's updating the neighboring blocks just like the Repeater does, so I guess it's fine as is. This is probably about the last thing I need to fix, so I will go test things more before calling it finished.
40 Various clock designs. Just after a few hours of testing.
I had a custom keybind actually hard coded inside my own class files, but just today made a configurable one, which gives the ability to reverse the direction upon placing the block. I will probably post both codes for others to use. :3
Bad thing about this is that when you're flying in creative and need to place the block in reverse orientation onto an interactive block (like Dispensers), then you need to hold 3 keys together, Shift + Space + Reverse Orientation Key.
Space + Shift, obviously just when you're flying so you don't plummet to the ground, other wise it's just Shift + Reverse Orientation Key. Which I preconfigured to be CTRL
However, the wonderful thing about this is that the way I have it set up, I should be able to very simply apply this code to any orientation based block, like Pistons, Dispensers, Repeaters, Chest, and so on.
What do you think of this as a recipe?
(Recipe doesn't call for burnt out Redstone Torch, the applet I used has bad textures)
Too expensive maybe? Mostly people will want to make a lot of these, and Quartz is already so widely used, I don't want it to be a burden to craft.
I've been working on this project for close to a year, been asking questions here on MCF for a little while with bad help, or no help and deleting a lot of threads. Then there are the Java forums where people seem to try to help then just tell me to go read a book, which doesn't help me at all as I have ADHD. XD
Also, have a 64x Automated Furnace Array
Well, of course this very well could have been made without it, but the way my block is being implemented in various places does impact the overall design a lot.
One being the way the tracks are set up. My block only allows the power to be directed right to the Powered Track where it's needed the most, and does not affect the Hoppers at all.
Otherwise without them you'd have to make some kind of solution that's at the same height as the tracks, which in the example image, would be on the top Powered tracks, and then the top cart would grind against the blocks causing it to slow down slightly. I found that's actually a thing, and something I was using as a slowing mechanism before.
And then this one isn't as important, but still defiantly helps. My block helps to make things much more compact in a lot of ways, one being a fill up station as seen below, as well as the Minecart seen here going to a fill up station, and deposit station.
The Semi Automatic Cobblestone Generator is a prime example. Sadly there is not any speed improvements in my newer design, but it takes like 19 seconds to generate an entire line I think. I probably need to re-time the generators, but it's still pretty fast like tick tock.
#Edit: I was also able to make a Semi Automatic Stone Generator, since this block can't be washed away it's now much easier to make, but not as compact as the Semi Automatic Cobblestone Generator.
This block also helps make something else more possible. Can you guess what it might be?
P.S. I left a clue to what this device is, somewhere in this post. Hehe.