derf6060

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.

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.

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.

Alright run "gradlew build" and it should make a build directory + other stuff. After that the jar file should be located under "./build/lib" I believe and then you can release it.

I believe its some variable called sourceCapatibility... There are 2 lines one at 18 and the other at 20... Also you will need to change version, group, and archivesBaseName too because they are used for naming the jar file.

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. Hmm, that actually might make it easier to keep the TileEntity validated. Thanks Choonster.

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

I have a skype account.

This might take a bit because I don't use the vanilla launcher anymore because I prefer MultiMC.

Oh boy your doing it manually. Um let me post a couple of screen shoots for you...

Yeah post a screen shot of it will help.

Are you running the vanilla launcher or something like MultiMC?

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

Thats probably true. I'm really just doing this for my sense of curiosity. I just want to see if I can do or not. From the results I have at the moment it can be done. I agree that it will increase traffic. I'm going to try and identity bottle necks that will cause a ton of network traffic. For example my six sided tank I'm working on has 2 packet that are sent from both the its TileEntity and GuiContainer. Ones for updating the Server Side FluidTank with the Client Side Fluid Tank. What I would do is find the areas were the Server Side Tank needs an update. Those packets will need to be sent when the tank is fill or draining from one of the sides of the block or if a user files and empties a bucket. For the other Packet which aids with configuring the sides of the block to fill and drain the tank from a side of the block. The only time when this happens if the user press a button in the gui to change the configuration. Plus I'm just playing around with Minecraft modding. My mod is experimental anyway. If the mod was a bigger mod that requires a ton of maintenance or appeal to a ton of Minecraft users then I would change my tone about it. I focus more on the polish factor and optimize code so the to keep UPS issues down. Enough of this silly wall of text. Take it easy man.

Its cool dude. I agree with you that its probably not the best way to go about it. Its simply a hot fix for the moment. I'm trying to make a more general routine that would make the data inside the message abstract so the packets can be more ambiguous. Lets say reduce the amount of Packet implementations down to 2 different variants. One packet that will be used to client to server communication and the other is server to client communication. The data portion is were the Runnable stuff will happen. I'm just trying to find a way to decouple data from the message. I'll probably post the system at a later date.