Better electronic file handling

[ShnitzelX2]

Is your feature request related to a problem? Please describe.

Currently, files on in-game electronic devices (which will be referred to here as E_FILE) are anemic and separately handled. They consist of:

• SD cards, containing recipes that can be "downloaded", i.e. learned with e-device
• laptops/phones containing lore/maps as built-in actions and e-books/photos as manually inserted
• USB sticks containing "software"

Poring over some history, it looks like this has been the case for over a decade. There have been a lot of requests for better electronic devices and files. This includes, but is probably not limited to:

• #3791
• #39454
• #51064
• #62467
• #65837
• #67125
• #70490
• #74394
• #75784

My main motivation for planning this out is that I love getting the lore bits from laptops/phones, but you have to go out of your way, searching every device individually, to get them; ditto for maps. If we want to make searching devices easier, I feel like it makes more sense to implement E_FILE support broadly.

Solution you would like.

Infrastructure

units::ememory is a new unit, representing digital storage (B, KB, MB, GB, TB, etc.).

E_FILE is a new item type. It represents an electronic file. E_FILE items have:

• category: "media", "software", "map", "instructional", "classified/quest", "junk"...
• ememory_size: e.g. 42KB
• autoread: whether the file is automatically identified
• item_act: another item's id that this file will emulate on read

E_FILE_DEVICE is a JSON use_action flag that will be applied to existing electronic devices that should handle E_FILES.

E_FILE_STORAGE is a new pocket type. It can only hold E_FILE items, and can't transfer them via the inventory -- only through the use_action of an E_FILE_DEVICE. It only has a ememory_max field for how much units::ememory it can hold.

use_action

e-devices will spawn with item_groups of E_FILE items. While "unread", an e-device will look like: laptop computer (x/x charge) <unread>. The following actions can be taken with an E_FILE_DEVICE:

• browse devices will reveal E_FILE types (but not identify its contents -- your character sees a filename, file extension, and drive space) and automatically remove junk files for any selected nearby unread devices. So a laptop computer (x/x battery) <unread> could be browsed and then look like laptop computer (x/x battery, 8.2/512 GB storage) <11 files> and would expand to: - 2 unread media files - 8 unread text files - 1 unread map file There's a small chance that files are identified outright on browse (presumably because their filename is very clear).
• read files reveals what individual unread E_FILE items are on nearby devices, activating read effects of e.g. revealing a map, or learning recipes from a book.
• move files moves files from nearby devices to the current device, with a toggleable list provided.
• All of these are combined in one combo action: browse/move/read from nearby devices.
• copy files allows files to be copied from one nearby storage device to another. All of these actions train computer skill like computers (beginner). With computers skill < 1, wait times are increased significantly, and browsing has a small chance to wipe all unread data.

Reworking Existing Content

• E_FILE_DEVICE will merge/replace EINKTABLET and ELECTRICSTORAGE for laptop, smart_phone, and eink_tablet_pc. Those devices will also have a non-removable E_FILE_STORAGE.
• sd_card and usb_drive will have E_FILE_STORAGE, and EBOOK+SOFTWARE pocket types will be merged into E_FILE_STORAGE.
• The existing download map data action is a E_FILE of category "map". On read, it'll do the same thing.
• Recipes are now E_FILE of category "instructional" and are learned on read
• Lore bits are now E_FILE of category "media" and are consumed on read
• USB software is now E_FILE of type "software", remove software_data field
• NPCs should be able to learn from videos or e-books.

New content

• Videos are an obvious addition. They act identically to books, but can only exist in an E_FILE of category "media".
• Since books and individual recipes can be E_FILES, their electronic forms should probably be as common as their physical forms. To compensate, books should be less common in general.
• E_FILE_DEVICE and E_FILE_STORAGE items should have copies that have less/more storage. There should also be a portable hard drive item; I don't think storage space should be too much of a concern as far as gameplay goes, maybe with the exception of certain missions.

Quirks

• E_FILE items should not be worth value for the time being because merchants can't discriminate between copied media. Similarly, E_FILE items with charges shouldn't be electronically copied.

Stuff that could be added later

• Encrypted files that can't be read normally
• Disassembly of e-device yielding intact E_FILE_STORAGE device

Describe alternatives you have considered.

This is a top-level rough draft, no code has been written. Feedback, ideas, and anything I missed are all appreciated.

Additional context

No response