Jump to content

Recommended Posts

Posted

I have a block that needs extra data stored on it, so I  am using a tileEntity to store 1 integers.  When I create the ItemStack containing the block, I add extra data to it storing these extra values. This part works fine. What I need to  happen is, upon placing the block, a TileEntity is created for it and the values from the ItemStack are stored on it.

 

The behavior I am seeing is that I am creating the TileEntity, setting the values, and they exist on the TileEntity, but then it creates another tileEntity without the right values and overwrites the old one.

 

 

 

Relevant Code:

 

  Reveal hidden contents

 

 

 

  Reveal hidden contents

 

 

Sample output from placing a block

 

  Reveal hidden contents

 

The first part is from initially placing the block. I see it create an unitialized tile enity, as expected. I then see it read a 0,9 block; this is also expected, as this should be the NBT data from the itemstack getting applied to the TileEntity and read in. Then there is a setting params call; this part should be redundant, and ws added as part of my expiremtnation, but it is just setting the 0,9 data again. Then it creates a new 0,0 unitialized tileentity.

The stack trace shows this one is coming from teh code

tileentity = this.getTileEntity(pos, Chunk.EnumCreateEntityType.CHECK);

                    if (tileentity == null)
                    {
                        tileentity = block.createTileEntity(this.worldObj, state);

on Chunk.

which implies that the tileEntity from before is not on the chunk, so it is trying to load it again and overwrites the one with stored data. This again goes through the "load NBT data", and "set paramters" calls, and seems to end with the correct 0,9 data saved.

 

After the ..., I triggered the block to read the data. It says "writing" and stores the correct 0,9 data, but then another call to create a TileEntity is made.

This again seems to come from the Chunk call, where it is not finding a TileEntity at the the positon, and so makes a new one. I am changing the BlockState at this point, but it is the same block with a different blockstate, and it should be able to continue on with the existing TileEntity. This gets a 0,8 pair, since the getMetaFromState happens to return an 8, but that shouldn't be getting called in teh first place. This happens several times, leaving me with a different set of data than I inteded.

 

This all seems to be stemming from the Chunk.getTileEntity returning null.

Posted

Hi

 

I think it might be bad news to call this.markDirty(); in your TE constructor.  It's not necessary (vanilla TE don't do it) and it just might be causing your symptoms, by reading chunk information before your TE has finished constructing.

 

-TGG

Posted

That was the last thing I tried doing.

 

Here is the output without that

 

 

  Reveal hidden contents

 

 

This does look a bit cleaner, but the basic issue is the same; it comes in and overwrites the TileEntity with a fresh one at the .Chunk.setBlockState(Chunk.java:725) call.

I'll also remove the onBlockPlacedBy method, as it seems to be redundant.

 

 

  Reveal hidden contents

 

This makes the placement look like I want; it gets placed, then it loads the extra NBT data I wanted, setting the parameters, then writes them back out.

However, the second part is still smashing over it with the wrong data.

 

Posted

I figured out my issue. The shouldRefresh method on TileEntity tells whether the tile entity should be removed if the blockstate is update. Its default implementation has a "!isVanilla" on the test, so the non-vanilla tile entities always returns true, and hence the TileEntity gets deleted, even when the block itself hasn't changed.

I had to override this method, and this prevented my TileEntity from getting deleted before I was ready.

Posted

Wow, that's nasty.  Too subtle for me.  There must be more to it than that, TileEntities which spontaneously lose their data doesn't sound right.

 

Might have to add that to my example project as a warning.

 

-TGG

Posted

Its not quite spontaneous, but if you change the blockstate, it happens. With vanilla blocks, changing the blockstate to a different blockstate for the same block is fine, but not for non-vanilla blocks. I don't know why they felt that non-vanilla blocks should have a different default behavior.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

  Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

  Your link has been automatically embedded.   Display as a link instead

  Your previous content has been restored.   Clear editor

  You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Create New...

Important Information

By using this site, you agree to our Terms of Use.