I have to say I am not familiar with the Vec3 data type, but it looks reasonably straightforward as a coordinate storage.

It does strike me that you are creating 4 vertexes to draw a line, and yet nowhere do you tell the tesselator that is is a line you want to draw. Seems to me that it would prefer to draw a plane somehow?

 

tess.addVertex(...);

 

The tessellator (and thereby GL) is in quad drawing mode.  So it expects a multiple of four vertices arranged clockwise around the surface normal.

I chose quads because while there is a line mode (two verts) you don't have control over the thickness of that line.  It would be 1 pixel thick, always.

 

 

 

Probably particles then.  And particles are like ultra-cheap entities.

See this class[/i].

Minecraft is faking a dome-shaped sky over a flat world, so it makes the apogee of the sun/moon always pass directly overhead the player. That is good for purposes of the calculation required for this mod, but I'm not entirely certain whether that makes the rotation point actually at the player. It is possible below the player somewhere inside the ground.

 

Its centered on the player.  It's only a fake dome.

You can see this when flying up, or rather, being blasted by TNT or teleporting into the sky thousands or even millions of blocks.

As for the 31 * all that stuff, idk.  I saw it used and it seemed to work...

 

"All that stuff" is an in-line Hash(int) function.  The point of it is to effectively generate a pseudorandom number with your data as the seed.  It works better than id + meta*500 because the ID can be larger than 500.  ID=500, meta=0 will have the same "hash" as ID=0,meta=1.  This makes your hash range very limited.  You should go back to what you had before.

 

Your new Equals() method looks fine, though.

Note:

A.equals(B) => a.hashCode() == b.hashCode()

a.hashCode() == b.hashCode() =/> A.equals(B)

 

Hint: ItemIds can get very very large, very very quickly.  1.6 had a block array that stored up to 4096 block IDs, each of which had an item ID that matched.  1.7 is effectively unlimited.

If it looks like solid beams, then it is most likely done using direct GL calls.  Which aren't that difficult, really.  Its just a matter of knowing the two end points and drawing a line.

 

You'll have to escuse this lump of code, its stolen from my own purposes and some of it is useless to you.  I trimmed what I know is, but there are likely lingering references.

I call this function from a DrawBlockHighlightEvent event, but I am specifically interested in the block the player is looking at.

 

//draw a line between two blocks
private void drawLine(Vec3 blockA, Vec3 blockB) {
	Tessellator tess = Tessellator.instance;
	tess.startDrawing(7);//quads
	tess.setBrightness(15728880);
	tess.setColorOpaque_F(1F, 0F, 0F);//red

	Vec3 recLong = blockA.subtract(blockB);
	Vec3 perpendicular = Vec3.createVectorHelper(recLong.zCoord, recLong.yCoord, -recLong.xCoord);
	perpendicular = perpendicular.normalize();

	float Width = 1f/16f;

	Vec3 R1 = blockA.subtract(blockB);
	Vec3 R2 = blockA.subtract(blockB);
	Vec3 R3 = blockA.subtract(blockB);
	Vec3 R4 = blockA.subtract(blockB);

	R1.xCoord = blockA.xCoord + perpendicular.xCoord * Width;
	R1.zCoord = blockA.zCoord + perpendicular.zCoord * Width;
	R2.xCoord = blockA.xCoord - perpendicular.xCoord * Width;
	R2.zCoord = blockA.zCoord - perpendicular.zCoord * Width;
	R1.yCoord = blockA.yCoord - 0.01;
	R2.yCoord = blockA.yCoord - 0.01;

	R3.xCoord = blockB.xCoord + perpendicular.xCoord * Width;
	R3.zCoord = blockB.zCoord + perpendicular.zCoord * Width;
	R4.xCoord = blockB.xCoord - perpendicular.xCoord * Width;
	R4.zCoord = blockB.zCoord - perpendicular.zCoord * Width;
	R3.yCoord = blockB.yCoord + 0.75;
	R4.yCoord = blockB.yCoord + 0.75;
	tess.addVertex(R1.xCoord + 0.5, R1.yCoord, R1.zCoord + 0.5);
	tess.addVertex(R3.xCoord + 0.5, R3.yCoord, R3.zCoord + 0.5);
	tess.addVertex(R4.xCoord + 0.5, R4.yCoord, R4.zCoord + 0.5);
	tess.addVertex(R2.xCoord + 0.5, R2.yCoord, R2.zCoord + 0.5);

	tess.draw();
}

Idiot.*

 

1) Use the method that has a world passed to it. You should never use Minecraft.getMinecraft(). It happens to be safe here do to the SideOnly annotation, but it is still a bad idea.

public IIcon getIcon(IBlockAccess world, int x, int y, int z, int side)

2) "it returns false" makes no sense for a method that returns IIcon. You meant that isDaytime is returning false. You never once mentioned using this method.

3) world.getTotalWorldTime()

 

I would have to look, but isDaytime might not be useful client side. I so know that total world time will work though, as it (or at least the variable that method returns) is used by getMoonPhase, which is a client side method.

 

*sorry, I'm a bit grumpier than usual. I can't sleep and it's 5am. You posted half intelligible gibberish, played the pronoun game, and forced me to ask for clarification rather than posing what you meant (with code!) the first time.

obfuscated (SRG) name instead.

 

Just to clarify, SRG and Obfuscated are not the same.

Obfuscated: af()

SRG: func_173982_a()

MCP: doSomething()

 

The obfuscated ("notch") names are what you'd find if you examined the vanilla jar manually.  The SRG names are run-time translations that Forge performs (Forge runs a class transformer on every vanilla class at priority 1000, most coremods run afterwards, but they can run first if they so desire).  MCP ("Minecraft Coder Pack") names are the ones you see in the development environment, if they are available (otherwise you'll see the SRG names).  SRG is intended as a "version agnostic" naming scheme so that mods do not depend on a specific version of Forge to run.

it would always return  false

 

What.

Or you could use the getIcon(World, x, y, z) methods and ask the world what time it is...

That would be a problem... I'll have to look into some way of blocking this...

 

if(player.posY < 64) { //probably underground }

Mouse over the function

Right click

Find references

 

Magic

Processing power is irrelevant when all blocks that are identical use the same texture across all copies.  You can put as much block as you want, it is literally irrelevant.

 

If you want a block to have a different look, you need to be more clever than simply placing "more" of them.

What do I use to get the itemStack of a custom item? Items class only contains vanilla items, do I need to do a search for name?

 

Of you didn't figure it out:

New ItemStack (MainModClass.yourItem)

Minor correction:

Materials are a combination of things, the bit that "isn't supported" is likely the shader, which handles  how lighting affects the object (hint: Minecraft has no lights).

I'm not sure what all the flags represent

 

Is in the Javadoc.

1 causes a block update.

2 sends the change to the client.

4 prevents it from being rerendered.

Flags can be added together.

I would create a separate class to hold that last, too. Call it a recipe manager. It would then hold the relevant information about your custom recipes and you could have a method called isSolvent(item) which would check the passed stack/item against the list and return true or false.

When I did this for my millstone, I used metadata to define which block held which position.  When the multiblock was incomplete, they are all metadata 0.  When the 3x3 (just the stone portion, the windvanes and axel form a secondary multiblock) is formed, it updates the full form with each position's meta.

 

Then when the user tries to interact I check the metadata and if its an "invalid" for the action, nothing happens.

 

For what you're doing, you can do something similar.  Simply pick a point in the formation that will act as the "master" and when the user tries to interact with any of them, just forward the interaction to the master block: you know where it is, so just call world.getBlock(masterX, masterY, masterZ).action(world, masterX, masterY, masterZ)

If I agreed with you, I wouldn't have been asking the question for two days now.

 

The Tessellator is just a wrapper around OGL calls, with the assumption that you want to draw quads.  Quads are just four vertices specified in a specific order (counterclockwise, iirc).  Cubes consist of 6 sides (12 if you count the inside faces) and 8 verticies.

 

Drawing each set of 4 to make a side doesn't matter what direction you draw in, because you're going to draw in both in order to get the front face and the back face anyway.

 

Anyway, glad you found setRenderFromInside().  I didn't know it existed,  and thanks to elix for mentioning the caveat.

http://www.apostropheabuse.com/

I think you need a GL.end() and GL.start() in there somewhere if you want to change certain properties, like alpha, and not retro-actively overwrite.

 

I can't tell from here, though.

Use the tessellator and do it manually, it's not that hard.

Minecraft "cube" rendering system has no notion of back faces. It is simply six single-sided quads.

If you want a hill, I wouldn't use perlin: your edges are too fixed to exterior constraints. I'd use the square-diamond algorithm.

Hopper doesn't count. The hopper checks every tick to see if there are any items above itself, which is not useful here.

Order matters.

Ahh, that's what I didn't know.