Abastro

What? it would not change anything.. It already OVERRIDES the method, and it makes the symptom. About the problem, try putting breakpoints on readNBT, and see if it calls the method on state change.

Because Forge Configuration always contains the comment, so i cant send it using a packet. And any non built-in config platforms are really not preferable. (I don't want to import any external library) To Belpois: It does not contains comment on packet. Please read the whole thread...

You should replicate the effect of the Air Bubble, and save & load the data from the entity using the IEEP.

Since it is deeply related with the world, it has to be sent by packet like world info.

The TileEntity would be refreshed and reloaded on the metadata change, so I suspect that the data would not be synced with original. But if your tileentity saves & loads well, then I don't know..

Because I want to make the "configurable" system able to be changed either by GUI or Text.

What do you mean by "none of the ones in my custom crafting manager work either" ? Are your custom recipes not registering?

As I said, it is partially encoded basic information on planets, which can be sent from the Server. Since server specifies the form of world on client, it has to be sent using packet.

And the "Efficiency" is important. + Making XML bytestream writer would just double the effort.

Does it support bytestream output, too?

Is it really the full report? It seems that fml is corrupted..

When you just remove the worldIn.getTileEntity(pos), does everything works fine? Like saving & loading the chest inventory, etc. + Post your full block class, including the updateTick method.

How did you place your StupidSpawner? Please show the code related with placing the block. It seems that there would be the problem.

You would have to give correct acceleration for that, depend on the height from the liquid block. giving same acceleration when it is over BlockLiquid would just make it glitch around, since it would not be 'smooth'

Try adding @Override on onPlayerStoppedUsing method, to check if it overrides the correct method on item.

Log please.

No, It would be a LOT harder to read. Then even I would not know what property means what, for it is very complicated config. I'd need both readme file and comments, and they might not be enough!

No, it is actually not 'config'. In fact, It is partially encoded basic information on planets. On File Configuration part, it is encoded to be more readable. On Bytestream part (for packet), it is encoded to be compressed. + It has to be sent by packet, since it will modify the world regardless of client configuration.

Maybe I am only remembering the old version of the Forge Configuration.. Anyway it is not hierarchical (only it can be shown as "hierarchical" using dots) and it cannot be written on bytestream. (+without comments) So it would take much more effort to change my system to use it. I'd rather end up using reflection to JsonWriter.

Oh I misremembered it. This problem happens because Container#inventoryItemStacks does not synced with the inventory on some case. I don't know why this only happens on Creative mode.. but there would be some reason. (It was serious problem on my InvWorks mod, so I solved it by syncing it) Maybe using methods of EntityPlayerMP would solve the problem.

What I mean by "dynamic", is that I have to find every existing category, and read information from each. AFAIK Forge Configuration can be hierarchical, but not dynamic.

If it is needed, why don't you return false when only blockstate changes? (you would have to return false for id change) & It seemed that it is always called on every id/blockstate change.

You don't need a new WorldProvider for doing that. You only need new WorldType for that. You have to look into the WorldType class, which is involved in World Generation on default dimensions. + This is what BoP does. Also you can see the code of BoP.(In case that it is open source) (Then your mod would not be compatible with BoP.)

No. I think it will be much more complicated to use it.

Yes, I know. But NBT is really bad for configuration, and I saw someone using JSON format to send object using packet. It seems to be portable enough. (Of course I'd write the JSON in bytestream for sending packets) and I said something wrong, the reason that I selected JSON is for the configuration. Since my configuration have to be dynamic and hierarchical, I cannot use Forge Configuration. Actually I tried to make my own config type, but I realized that it is hard work and It And then I found that JSON is well suited for my objective. and about hocon, is it accepted as a default library for Minecraft? If not, I think it would be difficult to use it.. Then I'd end up using my current way.