BlockState deserialization two different formats?

Sponge Sponge Support
1

When the server starts it seems to be randomly choosing one of the following formats for serializing/deserializing a BlockState.

test { BlockState="minecraft:wool[color=red]" ContentVersion=2 }

test="minecraft:wool[color=red]"

When one of the formats is chosen, and I try to deserialize an object using the not chosen format it throws this exception:

Sponge versions:

This is annoying because I can’t put a serialized BlockState in a file without the server throwing an error 50% of the times.

2

I don’t have your problem, it works fine for me but post your code. Maybe I can help you

3

ModuleConfig (In case you need it, but I am pretty sure it works fine):
https://github.com/Bammerbom/UltimateCore/blob/master/src/main/java/bammerbom/ultimatecore/sponge/config/ModuleConfig.java

4

I think it’s a sponge bug but you can use this custom serializer, for me it works fine.

public class BlockStateSerializer implements TypeSerializer<BlockState> {

	@Override
	public BlockState deserialize(TypeToken<?> type, ConfigurationNode node) throws ObjectMappingException {
		try {
			return Core.getRegistry().getType(BlockState.class, node.getString()).get();
		} catch (Throwable t) {
			throw new ObjectMappingException("Can't deserialize a BlockState", t);
		}
	}

	@Override
	public void serialize(TypeToken<?> type, BlockState obj, ConfigurationNode node) throws ObjectMappingException {
		try {
			node.setValue(obj.getId());
		} catch (Throwable t) {
			throw new ObjectMappingException("Can't serialize a BlockState", t);
		}
	}
}
1 Like
5

That works, thank you.

6

I feel like this is a problem where Configurate is pulling up the DataSerializable deserializer before the CatalogType deserializer. @zml thoughts on this issue? I could very well supply a proper serializer for BlockState, but I can imagine that this case will occur for any other objects that extend CatalogType and DataSerializable.

1 Like