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:
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.
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: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_FILEsupport broadly.Solution you would like.
Infrastructure
units::ememoryis a new unit, representing digital storage (B, KB, MB, GB, TB, etc.).E_FILEis a new item type. It represents an electronic file.E_FILEitems have:category: "media", "software", "map", "instructional", "classified/quest", "junk"...ememory_size: e.g. 42KBautoread: whether the file is automatically identifieditem_act: another item's id that this file will emulate on readE_FILE_DEVICEis a JSONuse_actionflag that will be applied to existing electronic devices that should handle E_FILES.E_FILE_STORAGEis a new pocket type. It can only holdE_FILEitems, and can't transfer them via the inventory -- only through the use_action of anE_FILE_DEVICE. It only has aememory_maxfield for how muchunits::ememoryit can hold.use_action
e-devices will spawn with item_groups of
E_FILEitems. While "unread", an e-device will look like:laptop computer (x/x charge) <unread>. The following actions can be taken with anE_FILE_DEVICE:browse deviceswill revealE_FILEtypes (but not identify its contents -- your character sees a filename, file extension, and drive space) and automatically remove junk files for any selected nearbyunreaddevices. So alaptop computer (x/x battery) <unread>could be browsed and then look likelaptop 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 fileThere's a small chance that files are identified outright on browse (presumably because their filename is very clear).read filesreveals what individual unreadE_FILEitems are on nearby devices, activating read effects of e.g. revealing a map, or learning recipes from a book.move filesmoves files from nearby devices to the current device, with a toggleable list provided.browse/move/read from nearby devices.copy filesallows files to be copied from one nearby storage device to another. All of these actions train computer skill likecomputers (beginner). Withcomputersskill < 1, wait times are increased significantly, and browsing has a small chance to wipe all unread data.Reworking Existing Content
E_FILE_DEVICEwill merge/replaceEINKTABLETandELECTRICSTORAGEforlaptop,smart_phone, andeink_tablet_pc. Those devices will also have a non-removableE_FILE_STORAGE.sd_cardandusb_drivewill haveE_FILE_STORAGE, andEBOOK+SOFTWAREpocket types will be merged intoE_FILE_STORAGE.download map dataaction is aE_FILEof category "map". On read, it'll do the same thing.E_FILEof category "instructional" and are learned on readE_FILEof category "media" and are consumed on readE_FILEof type "software", remove software_data fieldNew content
E_FILEof category "media".E_FILES, their electronic forms should probably be as common as their physical forms. To compensate, books should be less common in general.Quirks
E_FILEitems should not be worth value for the time being because merchants can't discriminate between copied media. Similarly,E_FILEitems with charges shouldn't be electronically copied.Stuff that could be added later
E_FILE_STORAGEdeviceDescribe 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