Replies: 3 comments 2 replies
-
I'm not well versed in Pandora (yet), so my advice is based on intuition and not an expertise. But to me this sounds like your approach outlined in #41 is enough to tackle the problem. Supporting incompatible data schema and code versions seems like a great hassle with comparatively little benefit in a scenario with usually tiny databases. I would prefer to update the whole state of my database at once via migration scripts. |
Beta Was this translation helpful? Give feedback.
-
Idea: remove
|
Beta Was this translation helpful? Give feedback.
-
This proposal is implemented by #102 |
Beta Was this translation helpful? Give feedback.
-
The problem
PandoraEntity
is stored insideres://data.pandora
, meaning that it usually ships with the game and is read-only. One could make changes to loaded entities while the game is running but there is really no way of saving these changes. Also, next time the entity is loaded the changes would be reverted.This is why Pandora has the concept of
PandoraEntityInstance
which can be created as follows:The instance then is a "copy" of the original entity but with the ability to change its attributes and save and load it to a custom save game via
Pandora.serialize()
andPandora.deserialize()
- the idea with #41 is to even support auto-migration of changes, e.g. if the entity changed, all its instances will get the changes automagically.While this works great, this becomes problematic once we use custom scripts:
this means that while custom scripts allow us to be very specific about properties (and introduce type-safety), instantiating them loses that type-safety. To solve this, one would need to introduce a custom script like so:
and then inside
Item
do this:and then one could do:
Pandora even maintains this type via
Pandora.serialize()
andPandora.deserialize()
but it has some disadvantages:This leads to massive overhead and is rather error prone.
Any ideas would be greatly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions