OreCruncher

My guess is the robot is looking at one of the corners of the block? Have you tried offsetting each axis by 0.5D?

You try searching the internet for "opengl draw hollow circle"?

I had something similar with some of my HUD code when a player hit F1 or F5. Turns out I forgot to disable alpha and blend before returning from my render routine. GlStateManager.disableAlpha(); GlStateManager.disableBlend(); Not sure if this is your case, but make sure you clean up appropriately at the end of your render or things could get munged.

Follow up. I instantiated a Frustum instance and it works pretty well. In my case I am concerned about points rather than boxes so I pass in the coordinate twice to isBoxInFrustum(). It shaved quite a bit off the tick time for this routine.

I am looking at optimizing my mod a bit and one obvious place would be to avoid doing any analysis work on blocks that are not in the player's field of view. My mod essentially scans a cuboid region around the player every few ticks or so and it stands to reason if I limit the blocks to what the player is looking at it would be more efficient. So my question(s) are: 1. Is there a frustum available that I could use during a client tick to do this filtering? 2. If not, could I use the Frustum class to do what I want, or is it geared primarily for rendering? 3. Failing 1 & 2, is there a good example on the internet related to Minecraft to do what I am looking for? Thanks!

OK. Think I know why the problem is occuring. My particle is rendered during the renderLitParticles() pass. This occurs *before* the renderParticles() pass where the interpPosXYZ values are updated. This means that my particle renderer was using the values from the previous pass, not the current one. Seems to me that the interpPosXYZ values should be updated prior to *any* particle rendering.

My first impression was too much white space on the page. Is there a theme or setting somewhere more data can be packed into a display page?

Honestly, they did answer your question. For this you will need server side support to send that data to the client. I have dealt with similar things in my mod.

OK. If I were to use the RenderManager.viewerPosXYZ calculations instead of the Particle.interpPosXYZ values the problem goes away. Anyone know of a reason why I *shouldn't* use the RenderManager information rather than the Particle information?

I made a crappy video that can be found here. If you are patient you can see the footsteps appear to slide across the tops of the blocks when I strafe. It doesn't do this on 1.10.2.

Copy/paste from the Minecraft code: /** * Renders the particle */ public void renderParticle(VertexBuffer buffer, Entity entityIn, float partialTicks, float rotationX, float rotationZ, float rotationYZ, float rotationXY, float rotationXZ) { float f = ((float)this.footstepAge + partialTicks) / (float)this.footstepMaxAge; f = f * f; float f1 = 2.0F - f * 2.0F; if (f1 > 1.0F) { f1 = 1.0F; } f1 = f1 * 0.2F; GlStateManager.disableLighting(); float f2 = 0.125F; float f3 = (float)(this.posX - interpPosX); float f4 = (float)(this.posY - interpPosY); float f5 = (float)(this.posZ - interpPosZ); float f6 = this.world.getLightBrightness(new BlockPos(this.posX, this.posY, this.posZ)); this.currentFootSteps.bindTexture(FOOTPRINT_TEXTURE); GlStateManager.enableBlend(); GlStateManager.blendFunc(GlStateManager.SourceFactor.SRC_ALPHA, GlStateManager.DestFactor.ONE_MINUS_SRC_ALPHA); buffer.begin(7, DefaultVertexFormats.POSITION_TEX_COLOR); buffer.pos((double)(f3 - 0.125F), (double)f4, (double)(f5 + 0.125F)).tex(0.0D, 1.0D).color(f6, f6, f6, f1).endVertex(); buffer.pos((double)(f3 + 0.125F), (double)f4, (double)(f5 + 0.125F)).tex(1.0D, 1.0D).color(f6, f6, f6, f1).endVertex(); buffer.pos((double)(f3 + 0.125F), (double)f4, (double)(f5 - 0.125F)).tex(1.0D, 0.0D).color(f6, f6, f6, f1).endVertex(); buffer.pos((double)(f3 - 0.125F), (double)f4, (double)(f5 - 0.125F)).tex(0.0D, 0.0D).color(f6, f6, f6, f1).endVertex(); Tessellator.getInstance().draw(); GlStateManager.disableBlend(); GlStateManager.enableLighting(); }

I hope I can explain this.... I have a particle that gets rendered just above a block in the XZ plane. It is static - doesn't move or have animations. It will fade after a period of time. In 1.10.2 it renders fine. It sits where it it supposed to regardless of how the player moves. In 1.11.2-13.20.0.2223 it seems to float when the player moves. This impression is given because it looks like the render position of the particle shifts slightly in the direction of the player movement. When the player stops moving, the particle goes back to where it is supposed to be. I could be wrong, but it seems the particle interpPosXYZ values are off. It's like the sequence of calculating the player's position changed in relation to the interpPosXYZ calculation. EDIT: (Updated observation) In 1.11.2-13.20.0.2223 it seems to float when the player moves. Looking for words to describe it. If I were standing above the particle and looking down it is fixed where it should be. If I were to move left, it looks like it shifts further right sliding above the block surface. If I move right it shifts left. The further I move the more it slides. It's like it is the top of some sort of cube that shifts based on the camera, but it really is a 2D texture laying just above a block. (If you want I can provide a link to my mod if you want to download and compare the versions.) The render code can be found in Minecraft's ParticleFootStep particle. So my question is whether I have to do anything special for rendering a particle in the XZ plane in 1.11.2. This slight shifting can be a bit nauseating for me and I imagine it could be for others as well. The particle needs to be "fixed" to avoid the floating sensation.

In 1.10.2-12.18.3.2221: public boolean onBlockDestroyed(ItemStack stack, World worldIn, IBlockState state, BlockPos pos, EntityLivingBase entityLiving) { if ((double)state.getBlockHardness(worldIn, pos) != 0.0D) { stack.damageItem(1, entityLiving); } return true; } In 1.11.2-13.20.0.2223: public boolean onBlockDestroyed(ItemStack stack, World worldIn, IBlockState state, BlockPos pos, EntityLivingBase entityLiving) { if (!worldIn.isRemote && (double)state.getBlockHardness(worldIn, pos) != 0.0D) { stack.damageItem(1, entityLiving); } return true; } The 1.11.2 version has a check for isRemote. In my sandbox I believe it is preventing the tool break sound from playing in the client. Under this all the logic is using the "play sound" that excludes the player. Am I missing something?

Yes. Saw that. It shows it being used in the BlockState Json. What I want to do is make a "normal" model file that has submodels, and then refer to *that* Json from the BlockState Json. It's not clear to me if this is possible. This being said I dropped back and punted to keep things simple. I decided I didn't want to tackle this particular challenge for the moment. What I wound up doing is using Choonster's BlockSappling example and modeled (no pun intended) my BlockState off of that.

I have a block that has several variants: 1. The first variant has a simple "cross" model with a texture. I finally have that block rendering in world as well as inventory. Yay! 2. The second variant is an entirely different model. What I want to do is use existing models from Vanilla as sub-models to build a composite. (I want to make a bone pile using the item "bone" and "skull".) I see that the blockstate json has this an ability to do sub-models based on state. In my case I just want to build a model reusing existing models as building blocks, and refer to that composite model from the blockstate. The only attribute that can alter rendering of the model is a rotation around Y, but that can be handled easily up in the blockstate and would (generally) apply to any models that it refers to. Anyways, I was wondering if what I want is possible, or do I need to go back and rethink this. From Java implementation standpoint all these blocks have the same capabilities. The only thing that is changing is what they look like in the world based on the variant type.

The question is more along the lines of software design and best practice than something relate to Capabilities. Your "it seems cleaner as is" is a pretty good indication of what you should do. I personally would keep them separate because that is the way I think and it fits within most OOP practices. Main benefits that I would see in keeping them separate: Organization. If you see an something labeled "Utensil Drawer" you know you can find your utensils there. Maintenance. Overtime your mod will grow and if you have a single Capability you pack things into its going to get unwieldy. Public API. Not sure if this is a requirement for you, but keeping things separate would help facilitate making an API. You may want "thrist" available to other mods, but not the "tracking" data.

*Picks himself off the floor - blinks* OK. Got that working. What I think happened is that I tried something similar to this but one of the values for the translation was off. Maybe I need to stop writing code at such late hours of the evening. For posterity here is the updated code: public void renderParticle(VertexBuffer worldRendererIn, Entity entityIn, float partialTicks, float rotationX, float rotationZ, float rotationYZ, float rotationXY, float rotationXZ) { final float x = ((float) (this.prevPosX + (this.posX - this.prevPosX) * partialTicks - interpPosX)); final float y = ((float) (this.prevPosY + (this.posY - this.prevPosY) * partialTicks - interpPosY)); final float z = ((float) (this.prevPosZ + (this.posZ - this.prevPosZ) * partialTicks - interpPosZ)); final float pitch = MathStuff.wrapDegrees(this.currentPitch + this.pitchRate * partialTicks); final float yaw = MathStuff.wrapDegrees(this.currentYaw + this.yawRate * partialTicks); final float roll = MathStuff.wrapDegrees(this.currentRoll + this.rollRate * partialTicks); Minecraft.getMinecraft().renderEngine.bindTexture(TextureMap.LOCATION_BLOCKS_TEXTURE); GlStateManager.enableRescaleNormal(); GlStateManager.pushMatrix(); GlStateManager.pushAttrib(); GlStateManager.translate(x, y, z); GlStateManager.scale(this.scale, this.scale, this.scale); GlStateManager.rotate(roll, 0, 0, 1.0F); GlStateManager.rotate(pitch, 1.0F, 0, 0); GlStateManager.rotate(yaw, 0, 1.0F, 0); GlStateManager.translate(-0.5F, -0.5F, 0.5F); final int i = this.getBrightnessForRender(partialTicks); final int j = i % 65536; final int k = i / 65536; OpenGlHelper.setLightmapTextureCoords(OpenGlHelper.lightmapTexUnit, (float) j, (float) k); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); final BlockRendererDispatcher blockrendererdispatcher = Minecraft.getMinecraft().getBlockRendererDispatcher(); blockrendererdispatcher.renderBlockBrightness(this.state, 1.0F); GlStateManager.color(1, 1, 1, 1); GlStateManager.popAttrib(); GlStateManager.popMatrix(); GlStateManager.disableRescaleNormal(); }

public void renderParticle(VertexBuffer worldRendererIn, Entity entityIn, float partialTicks, float rotationX, float rotationZ, float rotationYZ, float rotationXY, float rotationXZ) { final float x = ((float) (this.prevPosX + (this.posX - this.prevPosX) * partialTicks - interpPosX)); final float y = ((float) (this.prevPosY + (this.posY - this.prevPosY) * partialTicks - interpPosY)); final float z = ((float) (this.prevPosZ + (this.posZ - this.prevPosZ) * partialTicks - interpPosZ)); final float xRotation = MathStuff.wrapDegrees(this.xPeriod + this.xRotationRate * partialTicks); final float yRotation = MathStuff.wrapDegrees(this.yPeriod + this.yRotationRate * partialTicks); final float zRotation = MathStuff.wrapDegrees(this.zPeriod + this.zRotationRate * partialTicks); Minecraft.getMinecraft().renderEngine.bindTexture(TextureMap.LOCATION_BLOCKS_TEXTURE); GlStateManager.enableRescaleNormal(); GlStateManager.pushMatrix(); GlStateManager.pushAttrib(); GlStateManager.translate(x, y, z); GlStateManager.scale(this.scale, this.scale, this.scale); GlStateManager.rotate(xRotation, 1.0F, 0, 0); GlStateManager.rotate(yRotation, 0, 1.0F, 0); GlStateManager.rotate(zRotation, 0, 0, 1.0F); final int i = this.getBrightnessForRender(partialTicks); final int j = i % 65536; final int k = i / 65536; OpenGlHelper.setLightmapTextureCoords(OpenGlHelper.lightmapTexUnit, (float)j, (float)k); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); final BlockRendererDispatcher blockrendererdispatcher = Minecraft.getMinecraft().getBlockRendererDispatcher(); blockrendererdispatcher.renderBlockBrightness(this.state, 1.0F); GlStateManager.color(1, 1, 1, 1); GlStateManager.popAttrib(); GlStateManager.popMatrix(); GlStateManager.disableRescaleNormal(); } This all works except the render "origin" of the block is one of it's corners. I just want to convince the model that it's actually been shifted so instead of rendering along an axis "0..10" it's something like "-5..5".

Currently my render can render an existing baked model for a block (for example Dirt) at a point in the world. However, when I rotate the model (GlStateManager.rotate) it rotates relative to one of it's corners. What I want to do is shift the origin from the corner to the center of the block so that when I do the rotations it will behave the way I want. I am hoping for something easy. I really don't want to dust off my old math texts to do some fancy math. I am getting to old for that.

Alrighty. I hope not to go this route but it's good to know at least there is a chance. Thanks!

Roughly this is what I want to do: clientTick(TickEvent.ClientTickEvent event) start worker threads, each thread scanning (READING) the area around the player join the worker threads and collect results iterate the results and do mundane things endClientTick A key point in all this is that the worker threads will be READING the world state, not doing any updates or firing events. I expect the reads to be a bunch of getBlockState() calls. So before I go down a rathole is this something that is possible? (I have done multi-threaded applications for half my career so I am familiar with the frameworks. What I don't know too well is how static the underlying data and structures are during the client tick while my mod has execution "control".)

Yep! Adding the event listener allowed me to do what I needed. Thank you very much!

Thanks! I will give that a whirl and see what sticks.

First off, this is client side only - can't assume the mod is installed on the server. The situations I need to detect are: Block place/break Water block place/scoop Water flow changes Obidian/cobble/stone creation when lava/water mix There are server side events for these things, but I did not see anything client side. My question is how I can detect these situations client side without any server side support?

Forge 1.10.2-12.18.3.2185 I have a class that has been annotated with @Mod.EventBusSubscriber as well as @SideOnly(Side.CLIENT). The server crashes with "An error occurred trying to load an EventBusSubscriber..." on this class when trying to load as a dedicated server. I would have expected the @SideOnly annotation to suppress event registration. Is Forge working as expected, or is this a Forge issue? Thanks! EDIT: Never mind. Found that there are extra things I could set so doing a @Mod.EventBusSubscriber(value = { Side.CLIENT }) solves it. All it took was for me to make a post here.