The ability to print photos from e-notes would be a huge boon to putting more cameras in circulation. People guard their cameras jealously because they are the only way to reproduce photos. We got half-way there with photo scanning, but a scanned photo can't be reprinted.
There used to be worries about more printed photos leading to extra bloat for the MOO but now that photos have been compressed to 25000u each, maybe this won't be as much of a concern.
Some reasoning behind not printing photos from e-notes.
The way photos work currently with cameras is one photo is created, and then a child of that photo is created each time you print it. Those children take up virtually no space as they just reference the parent, and the parent is written to disk and only loaded when someone looks at the photo.
When you scan a photo into an e-memory module, that is scanned into the 'virtual filesystem' that e-notes use and stored in a relational database. The connection between the original photo and the scanned photo is lost. In fact, the original photo could indeed be completely recycled and no longer in game, or it could still exist.
Additionally, each time the SAME photo is scanned, it is fully stored in SQL, leading to duplicate photos in SQL, and eventually, this will take up a lot of space. This is already an issue, so semi-limiting how many photos are scanned is in our best interest from a bloat perspective.
If you were to then print that photo, a new version of the photo would need to be created, not a copy, but a fully new version of the object, and that would need to be stored to disk when instantiated into the game. Any time a photo was printed, it would create a completely independent copy of that photo. That is non-optimal and causes bloat.
The issue we have with storing a million photos in the relational database is that those photos also exist on disk, disconnected, and duplicates will exist in the relational databse. And these two systems (taking a photo, storing to disk and scanning a photo, storing in SQL) were put in place at different times by different coders and do not communicate.
Ideally, we would move all photos off disk and into SQL, rewrite everything to do with photos and cameras and when you take a photo it goes right into SQL as a permanent reference, never deleted, even if the photo object in game is recycled. Then when you scan a photo we would just pass a reference to the photo stored in SQL and store that in the virtual filesystem thereby normalizing the data. Then we could allow you to store as many as you wanted in an e-memory.
What I've just described as the 'optimal' process is pretty time consuming -- 25-40 hours of work. And the value doesn't really seem to be there. Yeah it would be super cool-- but if we have a coder with that much spare time, there are more pressing things they could be working on that will deliver better returns.
Hopefully this at least explains where we are at and why.
-- S
I've noticed a similar filesize bloat with mp7s to photos that makes it impractical to store multiple long recordings on one e-mem and makes distribution to others more impractical. This bloat has led me to regard VoiceNotes as more of a roleplay item rather than something useful for playback, meaning I might record a single item and then distribute a written digital transcript via email. Maybe a cap on mp7 filesize could be useful as well.
