Draco18s

I've been pretty lazy about updating my dev-environment-forge. I was likely doing a lot of my screwing around with keyboard stuff on 1180 which would, in fact, not have that change.

Ladders are fairly easy, redstone is super complicated, as each side of the redstone dust (that is, the connecting/not connecting edge) is rendered separately.

ClientKeyHandler.up.getKeyCode() ClientKeyHandler.down.getKeyCode() Wut. I had some issues with that, actually. And yes, 1.7.10 here. Do you know if it was a specific Forge version?

Its amazing what kind of information you can convey in your opening post, and how a lack thereof doesn't result in useful replies. Here's what I did when I needed key-up and key-down (specifically, a key bound to an existing option). //client-side event handler @SubscribeEvent public void tickStart(TickEvent.ClientTickEvent event) { EntityPlayer player = Minecraft.getMinecraft().thePlayer; if(player != null) { int jumpKey = Minecraft.getMinecraft().gameSettings.keyBindJump.getKeyCode(); boolean sendPacket = false; boolean state = false; if(jumpKey >= 0) { sendPacket = HazardsEventHandler.instance.setPlayerSwimming(player, Keyboard.isKeyDown(jumpKey)); state = Keyboard.isKeyDown(jumpKey); } else { jumpKey = Minecraft.getMinecraft().gameSettings.keyBindJump.getKeyCode()+100; if(jumpKey >= 0) { sendPacket = HazardsEventHandler.instance.setPlayerSwimming(player, Mouse.isButtonDown(jumpKey)); state = Keyboard.isKeyDown(jumpKey); } } if(sendPacket) { PacketBuffer out = new PacketBuffer(Unpooled.buffer()); out.writeBoolean(state); CtoSMessage packet = new CtoSMessage(player.getUniqueID(), out); UndergroundBase.networkWrapper.sendToServer(packet); } } } You'll not that there are packets involved.

Key event handlers.

Haha, I would too. The artifacts are totally OP. Took a quick look at his stream, yup, I saw one of my crowns.

You'll need to make your own material. Fuck if I know. Artifacts is in like four dozen mod packs. I don't keep track of their names. But probably. And to think that mod was merely an exploration of a new design pattern I wanted to experiment with.

Its really easy. Flag 3 will cause a block update and send the change to the client. Flag 5 will cause a block update and prevent the block from being re-rendered. Etc.

It appears that this is the check that is used to determine if rain should pass through a block: if (!material.blocksMovement() && !material.isLiquid())

Not something I have messed with. I'll take a peek and get back to you.

Not if you're throwing random values like '5' and '1' in there.

You don't even know what the flag does, do you?

Hmm. Apologies. I was trying to trace the code path and couldn't locate the line the last crash happened at (the line number pointed at a line that didn't make any sense) and then was trying to read the function to determine what it was doing. And it looked like it threw a crash if the replacement block had an ID that was not -1, e.g. it would crash if you had registered the block.

Question: Which class did you subclass? You should be subclassing BlockDirt for this to work and must not have registered the new block with the registry already.

Hmm. Here's what I ended up with. for(ForgeDirection dir : OreData.DROP_SEARCH_DIRECTIONS) { if(!world.getBlock(x+dir.offsetX, y+dir.offsetY, z+dir.offsetZ).isNormalCube()) { EntityItem entityitem = new EntityItem(world, (double)x + d0+dir.offsetX, (double)y + d1+dir.offsetY, (double)z + d2+dir.offsetZ, stack); entityitem.delayBeforeCanPickup = 10; world.spawnEntityInWorld(entityitem); return; } } Shoved the cached array into my OreData class (this being the dropBlockAsItem method of my ore blocks), as it seemed the most appropriate location I already had. public static final ForgeDirection[] DROP_SEARCH_DIRECTIONS = {ForgeDirection.UP, ForgeDirection.NORTH, ForgeDirection.SOUTH, ForgeDirection.WEST, ForgeDirection.EAST, ForgeDirection.DOWN};

You should do all of that in the block's renderer. It is unlikely that you should store this information in the TE/block itself.

No, but you can extend one and insert the duplicated necessary methods of the other.

I thanked this post because just yesterday I did it the "wrong" way (using the integer). But in looking at my code I'm not exactly thrilled with the result, as I was trying to find the "best" adjacent empty block in which to spawn the item drops (due to what happens when the block is broken: it replaces itself at 1 lower meta, restricting how many times it can be harvested, but if the block-above is solid, the items jiggle upwards through the ground and tend to make it to the surface, rather that shooting out sideways). Looping through the valid-directions array is cleaner, but I don't actually care about all of the directions (just the first that isn't full-cube) and would like to specifically do "down" last (the scenario where the player is above/adjacent to empty space, the items shouldn't fall into the void; in the reverse scenario they are retrievable once the player fully mines the block). So unless diesieben07 has a suggestion, I'm going to leave my code alone.

That is not how that works.

The fuck? Sort answer: no. Long answer: yes, but you shouldn't be doing what your saying. Because seriously, you want the SERVER to update the block on the CLIENT, because updating the block on the server and sending the change to the client isn't fast enough. The fuck?

[me=Draco18s]pours a bucket of water on the ground.[/me]

Better question: what is your end-goal?

This isn't useful because the function's return doesn't allow for a metadata specification. Do what diesieben said, instead. The other way would be to override public int damageDropped(int meta) as well. But getDrops is the simplest.

https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/block/BlockInvisibleBedrock.java