[1.11.2] When creating a new IBlockState does the TileEntity get recreated?

[derf6060]

If it does get destroyed is there a way to reuse the old TileEntity?

[LexManos]

Look at the methods in TileEntity...

[derf6060]

Thanks lex I'm going to take a good look at them and experiment some more.

[Choonster]

TileEntity#shouldRefresh is the method to look at. This controls whether the TileEntity is re-created when the IBlockState changes.

[derf6060]

Oh man I face palmed so hard. I forgot to call TileEntity#validate during the block state update because the TileEntity becomes invalid if you update the block state. I feel silly now. Thanks LexManos. P.S. Sorry about earlier.

 

40 minutes ago, Choonster said:

TileEntity#shouldRefresh is the method to look at. This controls whether the TileEntity is re-created when the IBlockState changes.

Hmm, that actually might make it easier to keep the TileEntity validated. Thanks Choonster.

[jeffryfisher]

Just don't fall into the mistake of overriding shouldRefresh to simply return false (never regenerate). There are situations when a TE should be cleaned up (e.g. when the new block type isn't the one the TE class supports), so make sure yours is well behaved.

[Draco18s]

3 hours ago, jeffryfisher said:

Just don't fall into the mistake of overriding shouldRefresh to simply return false (never regenerate). There are situations when a TE should be cleaned up (e.g. when the new block type isn't the one the TE class supports), so make sure yours is well behaved.

I still don't get why the default behavior is "oh, it's not vanilla, that means it always refreshes!"

[derf6060]

9 hours ago, jeffryfisher said:

Just don't fall into the mistake of overriding shouldRefresh to simply return false (never regenerate). There are situations when a TE should be cleaned up (e.g. when the new block type isn't the one the TE class supports), so make sure yours is well behaved.

You read my mind. I was thanking about that during break at work I like "hmm, if I simply return false the TE wont become invalid so the deletion process won't work." You proved my from theory from work. Thank jeffryfisher.

[derf6060]

6 hours ago, Draco18s said:

I still don't get why the default behavior is "oh, it's not vanilla, that means it always refreshes!"

 I don't get it either I find it silly when I was looking at TE source.  I would imagine that would cause a nasty garbage collection issue were a lot of TE's getting deallocated and reallocated by simply doing a BlockState changes.

[LexManos]

Mainly because it's better to be more strict then it is to be lenient.

Combined with trying to make it clear to modders that different block states are different blocks. {A concept that Mojang is trying to force in code for a long time}

Its more 'We want it to always refresh, but vanilla breaks that sometimes, so special case vanilla'

[derf6060]

8 hours ago, LexManos said:

Mainly because it's better to be more strict then it is to be lenient.

Combined with trying to make it clear to modders that different block states are different blocks. {A concept that Mojang is trying to force in code for a long time}

Its more 'We want it to always refresh, but vanilla breaks that sometimes, so special case vanilla'

Makes since to me. And it also explains the problem I was having too. What to do... I guess I'll follow the rules but make exceptions when I need too. Thanks for the help and clarification.