Think about how aspect state and prototype definitions should work together

[Ruin0x11]

Currently, when an aspect is created, any parameters relevant to it will be passed to its constructor, intended to be used as instanced state. This was intended for things like being able to increase the power of a potion and have that change persist on serialization.

The problem is that this use case is much more uncommon in comparison to the usual case of just creating and using the item normally. In addition, saving all the extra state has a large cost to the overall size of a save file (a serialized map with 300 potions is about 48 kilobytes; stripping the aspects reduces the size to 38 kilobytes). The larger the save gets, the longer it will take to serialize and deserialize.

This definitely needs to be redesigned. In most cases it would suffice to pull the data stored in the item's prototype definition if there's no "modded" data and copy the special buffs or whatever that a mod wants to add only if it wants to. But aspects have no concepts of static prototype data yet; all that's contained in the aspect's definition in _ext is the data to pass to the aspect's constructor. If there is some immutable data that should be shared between all aspects of a specific kind in a certain map object's data prototype, there isn't a good place to put it or a way to indicate it's there.

[Ruin0x11]

Could maybe call data[_type]:ext(_id, IAspectOfSorts) to retrieve the prototype information, or however it will be handled for base.data_ext.

The problem then becomes how to distinguish between immutable prototype and instance data.