Draco18s

Put a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox inside a strongbox... You might have a problem with NBT depth, yes.

And from.

Unfortunately I do not know, as I haven't yet messed with the new model system. I do know it's possible though: there's been one other fullbright question in the last couple of weeks, although it didn't use the term "fullbright" either. Just wanted to correct the mistake, as "glow" doesn't actually mean anything in computer graphics. There's fullbright (render as if under perfect illumination), emission (object emits light, or at least appears to), and bloom (the blurry hazy "glowy" edge thing, usually reserved for objects receiving so much illumination that they ordinarily go solid white without HDR).

FYI: ChunkDataEvent is for reading/writing to disk, but in no way tells you that the chunk has been removed from memory and to disassociate any extra data from your Map. ChunkEvent.Load/Unload on the other hand, runs on a separate thread. (ConcurrentHashMap is needed, fortunately this Map alone should be sufficient to solve that problem). You'll still have to figure out a couple other problems (the sequence of events that get fired is not simple); just don't do something like world.getChunkFromChunkCoords(x, z).isChunkLoaded because that'll load the chunk and be useless.

FYI, "glowing" isn't the correct term. You want "fullbright."

In some languages in some cases you need an empty string to get the compiler to understand that you want a string here (and not something else, like an integer, which can be implicitly converted to a string, but only does so if the object its being added with is already a string). e.g. string someString = 1; //no good string someString = ""+1; //good But ChatFormatting.BLACK is already a string, so there's no need.

So there is a .gradle at my MDK directory, and a .gradle at my user home... which one are you referring to? user home.

I don't use it often enough to remember the keyboard shortcut.

Oh my god, so much wrong with this thread... If you want TileEntities you have to actually create TileEntities. And the TEs should be the ones implementing all of this power API interfaces, not the block.

https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/components/ComponentFireball.java#L66-L78 The class isn't an Item class, but it utilizes the same methods.

Right click, references, find in workspace.

If it doesn't, then don't mark it as such.

You should f figure out a way to make the APIs load after their standard counterpart and not care about being before or after some other mod. Why does the JEI-API *have* to load before FEI?

Still a stub. @Override public int EnergyStored() { // TODO Auto-generated method stub return 0; } And even in your EnergyDuctBase that method will return 0 as well, because it multiplies its tick rate by the result of EnergyGenerating() which returns 0: //done @Override public int EnergyGenerating() { return 0; } You will almost certainly not be able to get this to work without using TileEntities.

Cough. BlockDuct line 114: @Override public int EnergyStored() { // TODO Auto-generated method stub return 0; } How do you plan on implementing that method?

You don't need to do that. You only have to do it in your main class: @Mod(modid = "ModID", name = "ModID", version = "1") public class Main{ @Instance("ModID") public static Main instance; public static Material newMaterial = (new Material(MapColor.sandColor)); }

Line 105 of that paste has a method that calls itself. Also, setLightLevel is not how you get a block to emit light on a per-instance basis. That will cause all copies of the block to start emitting light. You also never reset the light value. That block also never calls EnergyDraw in order to determine how much energy it should take from anywhere. Similarly, EnergyIn isn't called from anywhere and similarly does nothing. Then in your EnergyDuct block your EnergyStored method returns 0, meaning it would be incapable of sending energy anywhere. But if we look at this a little more closely: where would this block store energy? If we create a field for it, all of our Duct blocks would share that variable!

Post some code.

First things first, why are you still on 1.7.10 Next, if a class implements an interface, its subclasses will already be implementing that interface, you don't need to declare it again: BlockAC extends Block implements IAc BlockEnergyDuctBase extends BlockAC implements IAc Third, define "not working."

Grab a stack of notecards, write on three of them: JEI {JEI-API} FEI {FEI API} Now, using the before[] and after[] listed in that screenshot, sort them.

Hahahaha This is priceless. @SideOnly(Side.CLIENT) //make sure this method does not exist on a dedicated server public ItemStack onItemRightClick(ItemStack stack, World world, EntityPlayer player) { if(!world.isRemote) //if we're on the server thread... { //...then access the client side class! Minecraft.getMinecraft().displayGuiScreen(new GuiLivre1()); } return super.onItemRightClick(stack, world, player); }

I don't think your github is up to date with that crash. Line 30 where it's crashing is blank and backtracing through the call stack I don't see anything wrong.

You're trying to do something that isn't natively supported, so you're mostly on your own. Once your block gets larger than 1x1x1 you would, in effect, have a multiblock.

You should be looking at exactly 1 line of TileEntityHopper if I understood Choonster correctly, the line that says what interfaces it implements.