jeffryfisher

You could spare yourself from some block model files if your blockstates json referred to vanilla models. My own walls mod has a blockstates file that looks like this: { "forge_marker": 1, "variants": { "geometry": { "0": { "model": "wall_post" }, "4": { "model": "wall_n" }, "8": { "model": "wall_n", "y": 90, "uvlock": true }, "2": { "model": "wall_n", "y": 180, "uvlock": true }, "1": { "model": "wall_n", "y": 270, "uvlock": true }, "12": { "model": "wall_ne" }, "10": { "model": "wall_ne", "y": 90, "uvlock": true }, "3": { "model": "wall_ne", "y": 180, "uvlock": true }, "5": { "model": "wall_ne", "y": 270, "uvlock": true }, "6": { "model": "wall_ns" }, "9": { "model": "wall_ns", "y": 90, "uvlock": true }, "14": { "model": "wall_nse" }, "11": { "model": "wall_nse", "y": 90, "uvlock": true }, "7": { "model": "wall_nse", "y": 180, "uvlock": true }, "13": { "model": "wall_nse", "y": 270, "uvlock": true }, "15": { "model": "wall_nsew" }, "16": { "model": "wall_ns_above" }, "17": { "model": "wall_ns_above", "y": 90, "uvlock": true } }, "skin": { "0": { "textures": { "wall": "blocks/stonebrick" }}, "1": { "textures": { "wall": "blocks/stonebrick_mossy" }}, "2": { "textures": { "wall": "blocks/stonebrick_cracked" }}, "3": { "textures": { "wall": "blocks/stonebrick_carved" }}, "4": { "textures": { "wall": "blocks/brick" }}, "5": { "textures": { "wall": "blocks/hardened_clay" }}, "6": { "textures": { "wall": "blocks/netherrack" }}, "7": { "textures": { "wall": "blocks/quartz_block_chiseled" }}, "8": { "textures": { "wall": "blocks/obsidian" }}, "9": { "textures": { "wall": "blocks/sandstone_normal" }}, "10": { "textures": { "wall": "blocks/sandstone_carved" }}, "11": { "textures": { "wall": "blocks/stone" }}, "12": { "textures": { "wall": "blocks/stone_granite_smooth" }}, "13": { "textures": { "wall": "blocks/stone_diorite_smooth" }}, "14": { "textures": { "wall": "blocks/stone_andesite_smooth" }}, "15": { "textures": { "wall": "blocks/end_stone" }} } } }

I think you should include the MODID in the reg name, but you probably shouldn't use that as your whole name.

I think you should include the MODID in the reg name, but you probably shouldn't use that as your whole name.

I think the others were too ambitious when they told you to learn Java. First you must learn object-oriented programming (and its concept of inheritance). *Then* learn Java, and then look at your code again. After applying what you learned, your questions will pertain to Forge knowledge gaps rather than fundamental coding errors, and we will be happy to help. As the forum description says, this is not a Java classroom.

I think the others were too ambitious when they told you to learn Java. First you must learn object-oriented programming (and its concept of inheritance). *Then* learn Java, and then look at your code again. After applying what you learned, your questions will pertain to Forge knowledge gaps rather than fundamental coding errors, and we will be happy to help. As the forum description says, this is not a Java classroom.

It's interesting to see position-dependent rain (world.isRainingAt(pos)). I wonder if that method is already testing whether it can see the sky.

It's interesting to see position-dependent rain (world.isRainingAt(pos)). I wonder if that method is already testing whether it can see the sky.

Many of the vec3d methods are client-side only (used for rendering), so check it. If so, then imitate rather than calling server side.

Because you're using submodels, I can't help any further. I just don't know how those pieces will be put together. Most of my experience is with 1.8 anyway, and I suspect that the json processing is still evolving. In 1.8, I could use the Forge advanced json to separate modeling from texturing, but I could not use it to separate the different aspects of modeling. In other words, I could not use one property to choose a model, and then use a different property to set its rotation. All of the modeling had to be set together (model name, rotations, uv-lock...). I wasn't forced into a complete Cartesian product, but I did end up writing more tedious lines than I had expected.

For now, you might start with a custom receiver block, something you code yourself to look beyond its own neighbors for its source of power. Put one of those under your lamp, and then create a custom set of remote buttons and switches that can be configured to throw power to any receiver within range (i.e. skip the intermediate sender block).

A couple months ago I invented a pressure plate that would be owned (breakable and usable) by the player who places it. This is the class I wrote to implement weak pointer references: import java.lang.ref.WeakReference; import java.util.List; import java.util.UUID; import net.minecraft.entity.EntityLivingBase; import net.minecraft.entity.player.EntityPlayer; import net.minecraft.entity.player.EntityPlayerMP; import net.minecraft.nbt.NBTTagCompound; import net.minecraft.server.MinecraftServer; /** * Usage notes: * * 1) When the ownable object first becomes owned, it should call setOwner. * * 2) Classes employing WeakOwner must Override read and write NBT to call WeakOwner's. * * 3) Whenever you need the player, use getOwnerEntity. It will return null if the player is not online. */ public class WeakOwner { private WeakReference<EntityPlayer> ownerEntity; private UUID ownerID; public void setOwner(EntityLivingBase owner) { // The definitive moment when owner is known a-priori this.ownerID = owner.getUniqueID (); if (! (owner instanceof EntityPlayer)) { // Awkwardly, Block's onBlockPlacedBy method gives us a livingBase this.ownerEntity = new WeakReference (null); // And we must instantiate our private fields at all costs System.out.println ("Owner set by non-player entity!"); } this.ownerEntity = new WeakReference ((EntityPlayer) owner); } public EntityPlayer getOwnerEntity() { EntityPlayer owner = ownerEntity.get (); // See what entity we already know if (owner == null || owner.isDead) { // If useless, owner = lookupOwner (); // Try to find it } return owner; // WARNING: May still be null (not logged in) } public UUID getOwnerID() { return ownerID; } public EntityPlayer lookupOwner() { if (ownerID == null) return null; List<EntityPlayerMP> allPlayers = MinecraftServer.getServer ().getConfigurationManager ().playerEntityList; for (EntityPlayerMP p : allPlayers) { if (p.getUniqueID ().equals (ownerID)) { setOwner (p); return ownerEntity.get (); } } return null; } public void readFromNBT(NBTTagCompound compound) { // Read two longs into the UUID, not used until needed ownerID = new UUID (compound.getLong ("UUIDMost"), compound.getLong ("UUIDLeast")); ownerEntity = new WeakReference (lookupOwner ()); } public void writeToNBT(NBTTagCompound compound) { // Write owner's UUID to two longs, in order needed at read if (null == ownerID) return; compound.setLong ("UUIDMost", ownerID.getMostSignificantBits ()); compound.setLong ("UUIDLeast", ownerID.getLeastSignificantBits ()); } } Here's part of the p-plate class: /** * Owner may invert the detection from self to everyone else. */ @Override public boolean onBlockActivated(World w, BlockPos pos, IBlockState state, EntityPlayer p, EnumFacing side, float hitX, float hitY, float hitZ) { TileEntity te = w.getTileEntity (pos); if (te instanceof classTEOwnerPlate) { classTEOwnerPlate smarte = (classTEOwnerPlate) te; if (smarte.toggle (p)) { w.playSoundEffect (smarte.x (), smarte.y (), smarte.z (), "dig.snow", 1.0F, smarte.isInverted () ? 1.0F : 0.2F); te.markDirty (); return true; } } return false; } /** * The only function here is to set owner in our tile entity. If we can't do that, then bad things will happen. */ @Override public void onBlockPlacedBy(World w, BlockPos pos, IBlockState state, EntityLivingBase elb, ItemStack stack) { super.onBlockPlacedBy (w, pos, state, elb, stack); // For now, a no-op, but who knows? TileEntity te = w.getTileEntity (pos); if (te == null) { System.out.println ("Failed to get TE!"); return; } if (! (te.getBlockType ().getClass () == this.getClass ())) { System.out.println ("TE is for wrong block: " + te.getBlockType ().getUnlocalizedName ()); return; } ((classTEOwnerPlate) te).setOwner (elb); } and part of the TE class: public void readFromNBT(NBTTagCompound compound) { // NBT tells us who placed us originally super.readFromNBT (compound); this.inverted = compound.getBoolean ("inverted"); this.owner.readFromNBT (compound); } public void writeToNBT(NBTTagCompound compound) { super.writeToNBT (compound); compound.setBoolean ("inverted", this.inverted); this.owner.writeToNBT (compound); } As you can see, I added the concept of "inverted" that you probably don't need, so ignore that. You should be able to connect the dots from here. Also, if you're unfamiliar with weak references (as I was when I started), look up an article on them.

When you rotate an asymmetric model 180 around z or x axis to turn stairs upside-down, then you will change one facing in the process (x-axis flips N-S; z flips E-W). If you have trouble visualizing this in your head, then get something wedge-shaped that you can turn in your hands. Then for this particular model, the default facing is east (the rotation zero need not be written into the json file). Are you sure? I thought Y was vertical, hence rotating around it to face E-S-W-N. Don't confuse the axis of rotation with the faces around it. Get that wedge in your hands and start playing with it to see what I mean. I think so: You may apply X, Y & Z rotations. That's 3 axes. You should never need more.

See if the enum value "half" is case sensitive. For some reason, class Asphalt_Simple_Slab does not seem to inherit the property that you define in class NewSlab. What's the code for Asphalt_Simple_Slab?

For starters, don't pad your recipes with blank lines or columns. It looks like you have a shaped 2x2 recipe, so write two lines of two char each. Then set some break points and step through the process of updating the crafting table's output. Add an ingredient and see what goes wrong.

Your subject line looks like a warning message that you received, which means you've already been told by the compiler what you did wrong. Did you forget to register your TE? See Jabelar's TileEntity article

If you're making new slabs, then why didn't you simply extend slab? If you're not making new slabs, then you need to be careful how much of slab's code you copy-paste. For instance, if your class does not have a method called isDouble(), then you can't use it. If your block is designed to always occupy the lower half of its cube and never the upper half, then don't imitate slab's upper and lower logic. Next steps (using paste-bin, github or at least spoiler tags to frame big pastes): 1) Show us your code (the entire block class) 2) Show us the error (everything in the log file from the first appearance of your mod loading)

Is the pathEntity set and then wiped, or is it never set? If wiped, then what's wiping it?

What would happen if you created your own extension of the miner's delight and coded two features: 1) It grows on your stone 2) When harvested, it drops the item that you really want. If your stone spawns naturally in the world, then you might want your generator to add a few of your delights where your stone meets air. You might then need to find an event where somebody tries to plant the other mod's item on one of your stones. At that moment, you'd want to substitute one of your delight blocks in the world in place of the other mod's block.

Eclipse has a deep nest of preferences, and many have hotkeys that can accidentally flip them. You can try exploring them yourself, or you can Google Eclipse + preferences.

We usually don't give Java lessons here, but I'll make an exception: You need to use the "new" operator to create an instance of the class. You can either do it inline as you're calling the constructor, or you can store the result in a field to pass into the constructor. If you have any more questions of this nature, please Google "Java programming" plus whatever keywords you have rather than posting here. Come back when you need to ask about something peculiar to Forge.

From your context, I reckon that "exists" means "in play" as opposed to being placed at a specific xyz coordinate in the world. For some blocks, you can use the ore dictionary to see of there are any renditions of selected common-name substances like copper ore/ingot/block. Hunt down a tutorial on oredict. For non-dictionary blocks, you will either need reflection (to see if a particular class has a particular field) or you will need a separate version of your mod for separate versions of Minecraft because you can't even compile some incompatible code. You can also use the postInit event handler to poke at other mods to see who's loaded and what they're providing.

Suggestion: Change ur whole approach to brew a potion instead (3 bottles of water plus dust ingredient yields 3 bottles of new mystery fluid). Then you just need a way to convert your potion into a fluid source block when you use it in the world.

Well, for starters, it looks like you've completely commented out your preInit event handler, so it looks like your mod main does nothing.

Wow! That's going to F up almost every block in every mod! As a ghostbuster once said, "OK, Important safety tip."

The change log shows a couple NPE fixes since build 1887, so there's a chance that updating Forge could help. However, you should first set a few relevant break points and step to the crash in the debugger to see if anything jumps out at you. Find what's null, where it should have been initialized, and then try to see why it wasn't. If neither effort helps, then get ready to post lots of source code. PS: If you don't need examplemod, then get rid of it