Minecraft Forums

My Item class has it. Just look at the type hierarchy in Eclipse and it will list all the methods.

Here is the actual code from the Item class:

    /**
     * Sets the unlocalized name of this item to the string passed as the parameter, prefixed by "item."
     */
    public Item setUnlocalizedName(String unlocalizedName)
    {
        this.unlocalizedName = unlocalizedName;
        return this;
    }

Maybe your class path is wrong and you're looking at the wrong Item class or something?

There is still an setUnlocalizedName() method.

I was looking at it but it looks really hard/impossible to intercept the frustum checking. The RenderGlobal class creates a new "camera" from the Frustum class every screen refresh. There is no public field that contains it rather simply a local field so you can't access it directly or even with Java reflection. You would have to replace the entire global rendering which would be a crazy amount of coding to get right and would use lots of reflection.

I think the first thing is it would be interesting for you to place a beacon and also try structure block. Both of those use the infinite bounding box. See if they behave the same.

The actual code that renders tile entities is pretty simple. In RenderGlobal it is:

            RenderHelper.enableStandardItemLighting();

            TileEntityRendererDispatcher.instance.preDrawBatch();
            for (RenderGlobal.ContainerLocalRenderInformation renderglobal$containerlocalrenderinformation1 : this.renderInfos)
            {
                List<TileEntity> list3 = renderglobal$containerlocalrenderinformation1.renderChunk.getCompiledChunk().getTileEntities();

                if (!list3.isEmpty())
                {
                    for (TileEntity tileentity2 : list3)
                    {
                        if (!tileentity2.shouldRenderInPass(pass) || !camera.isBoundingBoxInFrustum(tileentity2.getRenderBoundingBox())) continue;
                        TileEntityRendererDispatcher.instance.render(tileentity2, partialTicks, -1);
                    }
                }
            }

            synchronized (this.setTileEntities)
            {
                for (TileEntity tileentity : this.setTileEntities)
                {
                    if (!tileentity.shouldRenderInPass(pass) || !camera.isBoundingBoxInFrustum(tileentity.getRenderBoundingBox())) continue;
                    TileEntityRendererDispatcher.instance.render(tileentity, partialTicks, -1);
                }
            }
            TileEntityRendererDispatcher.instance.drawBatch(pass);

So to render it needs the camera to think the bounding box is in the frustum.

However, I did find one other thing to try. If you follow the render code further, there is actually a check for TileEntity#getRenderDistanceSquared() which defaults to 4092. That means it will only render if the distance is 63 blocks or less away. i don't think it is that far away in your videos, but for a windmill you probably want to see it from really far away anyway so why don't you try overriding the getRenderDistanceSquared() method in your TileEntity to be a much larger number.

You responded to a post that was four years old in a thread that was five years old!

Those variations are classes that extend the normal one. For example EntityHusk extends EntityZombie. This is normal Java (or object-oriented) programming technique where most of the functionality is contained in the parent class and the variations are created in child classes.

So you just need to make your own class that extends whatever you're trying to change, and override the methods that control what you want to change. Then you need to register the entity (along with its model and textures and sounds and such) like any normal custom entity.

I think the getRenderBoundingBox() is already the method that controls whether it will render or not. Basically there is a Frustum which is basically a "cone" shape from the camera that determines everything that is considered to be within the view. However, since the model for something that is outside that cone might still need to be rendered (like in your windmill case) you can specify a box (which can be infinite meaning always render) that determines everything that is worth viewing.

The code will never (normally) render something outside of the view since that would be wasteful.

Did you try the infinite box? That is what the vanilla beacon uses.

Not sure about max size. You'd have to trace the call hierarchy for the render bounding box to see where it is used. I did that for you and it seems that it is called by the RenderGlobal#RenderEntities() which checks if the box is in the "frustum" but invoking the Frustum#isBoundingBoxInFrustum() method which calls the ClippingHelper#isBoxInFrustum() method.

I noticed that in the vanilla getRenderBoundingBox() that it returns INFINITE_EXTENT_AABB for some cases. Why don't you try that instead of creating your expanded bounding box.

If that doesn't work then you should trace the code yourself to see if you can figure it out. I can't see anywhere that it is specifically limited. However the ClippingHelper method is using a "dot product" operation which I don't know how much math you know but is a way of projecting vectors onto each other. It is possible that that dot product has some limitation due to rounding or something. Like maybe when you get to a certain angle the amount of the angle to the tile entity doesn't project enough onto the frustum. It's also possible there is a bug in the ClippingHelper math -- for most vanilla tile entities there aren't any especially large bounding boxes.

I think you need to expand it in all directions because it can be facing different directions (or else you need to include the facing logic when doing the expansion). For example I'm not sure how you're sure in this case that the Z direction is the thin dimension. I would just expand them all -- I don't think it should hurt unless you had like a lot of windmills all in the same view.

Whenever I'm coding something new I put debug print statements all through my code. Then I can see exactly whether it is executing as I expect. You should put at least one console statement (System.out.println() or logger if you've got one set up) in every method of your code. I usually print out the values of the important fields. If there are any loops or if statements I add additional statements to each code path so I can confirm all the values are as I expect.

In your case you should add more and follow the code execution. It should be obvious at what point the code is starting to act differently than you expect, and then you can focus your attention on that part. With computer debugging there is almost never a reason to guess when you have tools to trace the execution itself.

If you get a black and purple texture it means that somewhere you are not properly pointing to your asset file. In fact, you should get a warning in your console that says that. You should review your console messages (or post them here if you don't understand them).

Usually it is just a typographical error like a slight difference in the actual name of the path or file. It can also be because you didn't register it. And in cases of things with models it can be a typographical error in the model JSON as well.

Awesome, good work. I know I wasn't giving you easy answers but felt you had the ability to figure it out with a few hints, which is the way to become a stronger modder.

To solve your remaining issue, it is related to the fact that of course minecraft defaults to skipping rendering of blocks whose collision blocks are outside of view (this is called frustum culling). For tile entities, there is a getRenderBoundingBox() method you can override to specify a bigger one. I think that should fix it.

Did you look at the examples? I've already said you need a block that has a TileEntity that has a TESR. The TESR can get information (like rotation of the windmill from the TileEntity, just up to you to apply the rotation during the rendering. What do your Block, TileEntity and TESR classes look like so far?

It means it doesn't have the correct import. Do you have the import for the IRenderFactory? Sometimes Eclipse can help you figure it out (right click on the red-underlined words and see what it suggests) but sometimes you can't. In any case, from an IDE perspective it doesn't know where to look for the information regarding the class/interface.

I've already answered your other question about how to check what is in a player's hand and how to set it to something new.

You're asking a lot of questions. It is good that you're excited to make progress but you should really take some time to figure things out yourself if you want to advance as a modder. For example, to figure this out all you needed to do was to look at other items that are consumed, or look at classes that change what is in the player hand like an EntityItem that gets picked up. You look at the vanilla source code and see how they do it and use that yourself.

Also, you can just look at classes like EntityPlayer and look at all the methods that are available. You'll quickly see there are methods related to held items.

Basically, I'm saying you need to start studying the vanilla source code. Otherwise you're going to ask a dozen questions every time you try to do something new.

The TileEntity just needs a field that is a collection like a Java ArrayList and whenever someone clicks on it it adds the item to that list and then checks if the list contains everything needed to make something.