It crashes, because that's not how you open a gui.

https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/block/BlockPedestal.java#L140

 

Also, you have a huge crapton of stuff you absolutely should not need in your ContainerGrinder class.

 

You can see caves through the block because you didn't override renderAsNormalBlock and isOpaqueCube to return false: the neighboring blocks are seeing your block as a full, solid, cube, so they're not bothering to render faces that can't be seen.

Look at the Javadoc on world.setBlock(int, int, int, Block, int, int)

As an aside, any reason you aren't storing references to your blocks and items where they can be easily accessed? That would eliminate the need to so FindBlock.

The thing you see in your inventory is a 3D model of it in the world, seen from a diagonal, orthographic,  viewpoint.

You are unlikely to get this representation as a flat texture to draw on the face of a block. Which is why barrel mods draw a 3D block sticking out.

I misunderstood something in a post about TileEntities not ticking on their own in 1.8 early on in the conversion.

 

Yeah, there's a boolean in the TileEntity class that controls their tick/not-tick behavior.  There's a setter for it.

 

Use it.

 

(Or a function you override, I haven't actually messed with 1.8 yet, but the standard behavior still exists)

Nope.  And I managed to dredge up an older post of my own that gave me what I needed, albeit in decimal format.

 

glDisable(GL_TEXTURE_2D);

You could try calling             

GL11.glColor4f(colour.R, colour.G, colour.B, colour.A);

instead of

tess.setColorOpaque_F(1F, 0F, 0F);

 

Calling tess.setColor...no good

Calling tess.setColor and GL11.glColor...no good

Calling GL11.glColor...no good

 

:\

*facepalm*

Then the color might be oriented in RGBA instead of ARGB

Complete the next item in the series:  0, 8, 16...

 

 

24.

 

this.alpha << 24

 

Sticks don't have their own class, so DamageTypes don't.  In fact, many damage types in Minecraft don't have a separate class.  However, the damage sources caused by entities are dynamic objects, created as needed based on the entity causing the damage and what (simple type) of damage it is.

 

You're free to create a new class if you want, it gives you a little extra flexibility such as being able to customize the death-by message,

func_151519_b

.  But the existing classes should be sufficient for your needs.

Or you could check for a null world object and then supply a 0 for metadata instead.

Lets dive in with our IDE, shall we?

 

 

There's fortunately not a lot going on here.  All of our parameters are getting passed to another function (

getDrops

), except one,

p_149690_6_

which is being compared to a random value.  This must be the probability of dropping each item returned by

getDrops

.

 

So what does

getDrops

do?

 

 

Oh hey, all of our other paramters now have names!

Or more accurately, because of math, it's 0 (you start with 0 and start adding things together, and none of the values added end up in the set of bits used by alpha, so its 0).

 

Also, drop the & 255 bit.  That's setting all of your color values to 0.

 

red = 128; //red is 128
red = red << 16; //red is 8388608
red = red & 255; //red is 0
/*
  100000000000000000000000
&                 11111111
==========================
  000000000000000000000000
*/

It will do magic™ (read sun.misc.Unsafe) stuff under the hood

 

And I have a new Skype status message.

There are times when using the Property directly has its benefits.  For example, I have an array of ints used as a dimension blacklist.  To keep things organized, I tell the code to read the list, then sort it, and save it back to the config file.

 

The only way to set a config property is through the Property object (the "get" from the config object only supplies a default, it doesn't change what's there).

 

So the tutorial is not, technically, wrong.

new doubt: If my mod is loaded on a multiplayer server, will it automatically use the server's config instead of the client's or do I have to do something extra for that to happen?

 

Server wins.  It wouldn't make much sense otherwise.

(But it does depend on what you're trying to do, if the code that references these strings only runs client side, then the client wins).

 

that's the one. But there's no method called Confuguration.getOrCreateProperty and no Property class. So I got confused if whether I still needed to do exactly as the tutorial said but using different methods and classes or if things were done in an entirely different way now.

 

Nope, didn't help. :\

 

I'm using the Tessellator for drawing, btw.  And I've already got

tess.setBrightness(15728880)

, but it hasn't made a difference either.

1) Where do  you pop your matrix?

2) Maybe using

glPushAttrib

and

glPopAttrib

will help.

 

1) I trimmed it (there's about 12 lines I removed, checking for various things).  I know about push/pop.  In retrospect I should have left that in.

2)

GL11.glPushAttrib(GL11.GL_ENABLE_BIT)

fixed the block outline color though, thanks!

 

But I still have an issue with the lighting on the quads being incorrect.

Here's just about anything you could ever want to do in an item in one item.

Also use your IDE.

This is the code I use:

Item salmon = new ItemStack(Items.fish, 1, 1).getItem();[/Code]

 

Also known as:

Good job adding, then stripping, the metadata.

I'm trying to draw some world-information as an overlay (so 3D quads, not 2D HUD things) and I'm having two problems:

 

1) I can't get the quads to be full-bright.  They flicker between various lighting values as the camera moves. Pic

2) The block outline's outline color changes. Pic

 

@SubscribeEvent
public void renderEvent(DrawBlockHighlightEvent event) {
	...
		GL11.glPushMatrix();
		GL11.glTranslated(-event.player.posX, -event.player.posY, -event.player.posZ);
		GL11.glDisable(GL11.GL_LIGHTING);
		drawLine(thisBlock, points[i]);
	...
}

private void drawLine(Vec3 blockA, Vec3 blockB) {
	Tessellator tess = Tessellator.instance;
	tess.setBrightness(15728880);
	tess.startDrawing(7);
	int d = Math.round((float)blockA.distanceTo(blockB)+0.2f);

	tess.setColorOpaque_F(1F, 0F, 0F);

	float ox = (blockA.xCoord - blockB.xCoord == 0?-1f/16f:0);
	float oz = (blockA.zCoord - blockB.zCoord == 0?1f/16f:0);

	if(blockA.xCoord - blockB.xCoord > 0 || blockA.zCoord - blockB.zCoord > 0) {
		tess.addVertex(blockA.xCoord + 0.5 + ox, blockA.yCoord - 0.01, blockA.zCoord + 0.5 + oz);
		tess.addVertex(blockB.xCoord + 0.5 + ox, blockB.yCoord + 0.99, blockB.zCoord + 0.5 + oz);
		tess.addVertex(blockB.xCoord + 0.5 - ox, blockB.yCoord + 0.99, blockB.zCoord + 0.5 - oz);
		tess.addVertex(blockA.xCoord + 0.5 - ox, blockA.yCoord - 0.01, blockA.zCoord + 0.5 - oz);
	}
	else {
		tess.addVertex(blockA.xCoord + 0.5 - ox, blockA.yCoord - 0.01, blockA.zCoord + 0.5 - oz);
		tess.addVertex(blockB.xCoord + 0.5 - ox, blockB.yCoord + 0.99, blockB.zCoord + 0.5 - oz);
		tess.addVertex(blockB.xCoord + 0.5 + ox, blockB.yCoord + 0.99, blockB.zCoord + 0.5 + oz);
		tess.addVertex(blockA.xCoord + 0.5 + ox, blockA.yCoord - 0.01, blockA.zCoord + 0.5 + oz);
	}

	tess.draw();
}

 

What've I missed?

Don't ever assume what "common" (or rare or whatever) is when working with materials that are either vanilla (ender pearls, nether stars,  etc) or common mod things (tin, copper). The rarity of materials is entirely dependant on mod composition. A tech mod, for instance, we'll use a TON of iron, making that resource more rare (because there are more things wanting it).

 

Which is why nether stars tend to be the "go to" uber rare resource got a number of mods. And is like "hold on, I haven't even found a nether skeleton yet, much less gotten three skulls."

And what, prey tell,  did you expect an empty onNeighborChange function do?