Force serialize entity via API

[SoSeDiK]

Makes an entity serializable via API no matter what.
Previously you'd get an empty component (and an error later when trying to spawn the deserialized entity) in some cases:

• When the entity is marked as non-persistent.
• When the entity is a passenger.
• When the entity is not saveable (misc entities like lightning, knot, etc.).
• When the entity is "invalid" (dead, unloaded, etc.).

Now there's no problem serializing & deserializing & spawning entities in those cases.

[Owen1212055]

The issue I see is that wouldn't this allow for the serialization of entities in an invalid state and then their state will be "reset"? Not sure if that's a good thing.

[SoSeDiK]

The issue I see is that wouldn't this allow for the serialization of entities in an invalid state and then their state will be "reset"? Not sure if that's a good thing.

Yes, it would, and that's partially the goal. Before you'd get a byte[] of invalid data, and now you'll have the last captured state of the entity, which can be manually "reset" (spawned) into a new valid entity.

Personally, I don't think this is a problem for API which does nothing by itself and is even placed in Unsafe.
I'd say it's a dev's responsibility if they want to take into account such cases. After all, it was them who tried to serialize a dead entity, for example (which is considered invalid too).

[Owen1212055]

Well, in my opinion, if you try serializing an invalid entity I wouldn't expect it to magically be deserialized as a valid entity?
It's just tricky now since you will have to account for odd cases where "the entity will be serialized as a valid entity, despite being invalid"

[SoSeDiK]

serializing an invalid entity I wouldn't expect it to magically be deserialized as a valid entity

I think it depends. My wording might've not been the best, but I'll try to explain.

Upon deserialization, you'll get the same set of data as before serialization.
So while the entity might be considered invalid, its data is valid and shouldn't be prevented from deserialization via API.

For example, if you serialize an entity with 0 health you'll also get an entity with 0 health upon deserialization, and nothing will happen if you try to spawn it, because, well, it's "invalid".
Of course, you can change the health via API and spawn now a valid entity.

One other example of an "invalid" state is when the entity was despawned.
It's invalid because it's not present in the world (someone called entity.remove() or a chunk was unloaded, for instance).
This, by game's means !entity.isValid() state, shouldn't prevent you from serialization & deserialization & manual spawn of an entity too, because the entity's data is valid.

[lynxplay]

Generally after looking at this, I think it might be worth hiding these "bypasses" behind some form of flag system similar to relative teleportation. E.g. if I as a plugin wants to save an entity that is a vehicle, it could actively define that by passing some EntitySerialisazionCheckBypassFlag.PASSENGER to the method to indicate that specific check should be ignored.

I do not really want to end up with completely invalid entities being saved when all I want to do is passenger saving.
Alternative would be to just allow a flag to toggle on passenger/non-persist saving and never allow non-serialisable and invalid entities to be saved (knots etc).