Electronic storage overhaul

[ShnitzelX2]

Summary

Infrastructure "electronic storage overhaul"

Purpose of change

This is a demo for the implementation of #78043. It should not be merged or undrafted and will be submitted later as several separate PRs. It contains some known bugs, astyle/json formatting not guaranteed, this is a rough draft. This is the final draft.

The main goal here is to generalize EBOOK storage to be more usable, visible, and convenient. Additionally, general e-file handling allows for future content.

The existing actions that substitute for the lack of general electronic storage are separately implemented and therefore can't be mass-processed, which means that a lot of the time they -- maps, lore bits, e-books, software, everything on memory cards, etc. -- are ignored for convenience's sake.

And that's bad. E-devices being ignored isn't realistic in our modern world, nor in the Cataclysm, where they should be treasure troves of useful information as opposed to the current method of learning: primarily physical books.

Describe the solution

How does this work?

An e-file is simply an item inside a E_FILE_STORAGE pocket, identically to how the EBOOK pocket acts. While in the pocket, e-files take up ememory_size, up to ememory_max for the pocket. Each usable e-device (smartphone, laptop, e-ink tablet) now has an E_FILE_STORAGE pocket, and removable media devices do as well (USB drive, memory card, cameras, and the new portable hard drive).

This means that e-devices can be spawned with contents: items and/or item groups.

The following file operations are available to the player via the new E_FILE_DEVICE use_action and related efile_activity_actor:

• Browse reveals the contents of nearby e-devices, allowing for further operations. This is currently equivalent to powering on an e-device then going through its contents, picking out important files, and wiping the rest.
• Read (from external devices) activates the iuse function for an e-file.
• Move onto/off moves files to a single e-device or from multiple e-devices.
• Copy onto/off copies only eligible files to a single e-device or from multiple e-devices. Currently, the only files capable of being copied are manuals. If copies of selected files already exist, they are skipped.
• Wipe deletes files.
• Browse + move is a combo call for convenience.

What's reworked?

memory card (unread) and related functions have been generalized:

• music was not re-implemented because it's identical to smartphone music, which is unlimited and free
• generic photos were not re-implemented because there are books that do effectively the same thing
• recipes from memory_card are now stored in a recipe catalog, which auto-combines with other recipe catalogs. Recipe catalogs will be loot on e-devices. Reading a recipe catalog will list its recipes.
• photos from memory_card are now stored in a photo gallery, which auto-combines with other photo galleries. Reading a photo gallery will view its photos, identically to a camera.

The use_actions for smartphones' map application and local files are now e-files: map cache and questionable media file. They work identically and will be loot on e-devices.

Cameras now are e-storage and still take pictures, but can only view contained photos. You can move photos off of them with the new actions.

Obsoletes ELECTRICSTORAGE, EINKTABLETPC, EBOOKREAD use_actions

Describe alternatives you've considered

Lots! I've iterated over the design a few times on and off for the past month, and this is the result.

But I leave critique up to the community. Merge this for yourself and play around with it, look through the code, etc, and let me know what you think. There's lots of polishing left to do, and lots of things that could be done differently.

Testing

Outside of manual testing, none yet. I'm not writing tests until we've settled on a final design.

SUS/OFFICE has some test e-devices with files on them, so use e.g. light_industry for testing

Additional context

Various screenshots

Yet to-dos:
- test cases
- computer skill can change mid-activity
- verify efile_transfer serialization works
- actually do migration/obsoletion beyond removing use_action json entries for items
- migrate EBOOK/SOFTWARE -> E_FILE_STORAGE
- obsolete memory card (unread), data_handling_activity_actor

• check hardcoded software, memory card
• item groups for e-devices (lots of data!)

Follow-ups:

• chapters read of unique books should be globally shared amongst all copies
• map cache centers on spawn location OMT, not current OMT
• map cache / lore file inventory display "(used)" on read
• fix "multiple copies of books can be stored to a device" (carry-over from previous e-book system)
• music efiles?
• bulk copy (mostly UI issue)
• varieties of phones/laptops/tablets
• smartphone, etc. should yield correctly browsed memory card when disassembled
• hacking & outcomes
• anything left in the above to-do list

[Maleclypse]

I want to say I love this design. No real complaints from me

[GuardianDll]

Also big fan of this piece of content being finally mainstreamed, instead of books using one pocket, usb apps using another pocket, map and snippets using eoc, and photos and music using some totally hardcoded thingy

[ShnitzelX2]

I've undrafted to check clang-tidy, etc. I've run it twice locally already, so there shouldn't be too many issues. This is my final draft, so once all the checks are good it can be reviewed.

[github-actions]

Spell checker encountered unrecognized words in the in-game text added in this pull request. See below for details.

Click to expand

• (unbrowsed)
• This is a filtered collection of PDFs, images, and texts that contains instructions for making useful items. Any electronic recipe catalogs will be added to this one.
• abstract copiable electronic file
• abstract copiable electronic files

This alert is automatically generated. You can simply disregard if this is inaccurate, or (optionally) you can also add the new words to tools/spell_checker/dictionary.txt so they will not trigger an alert next time.

Hints for adding a new word to the dictionary

• If the word is normally in all lowercase, such as the noun word or the verb does, add it in its lower-case form; if the word is a proper noun, such as the surname George, add it in its initial-caps form; if the word is an acronym or has special letter case, such as the acronym CDDA or the unit mW, add it by preserving the case of all the letters. A word in the dictionary will also match its initial-caps form (if the word is in all lowercase) and all-uppercase form, so a word should be added to the dictionary in its normal letter case even if used in a different letter case in a sentence.
• For a word to be added to the dictionary, it should either be a real, properly-spelled modern American English word, a foreign loan word (including romanized foreign names), or a foreign or made-up word that is used consistently and commonly enough in the game. Intentional misspelling (including eye dialect) of a word should not be added unless it has become a common terminology in the game, because while someone may have a legitimate use for it, another person may spell it that way accidentally.

[emixa-d]

In digital cameras I know of, there is a SD memory card where the pictures or video are stored in, and it can easily swapped in/out (in fact, it was the main way to get pictures on/off the camera). So, instead of having an E_FILE_STORAGE pocket, perhaps give digital cameras a pocket that can contain a single memory card?

Likewise, in most laptops I've used, there is a SD memory card slot (usually empty and only used for transfer, at least that's how I used them). Although, they seem to be disappearing.

I see the capacity of storage devices is constant per-type. Perhaps in the future some higher-capacity (and lower capacity) variants could be added, and high-capacity variants would be a lucky find (although perhaps not that relevant, since memory cards are very lightweight).

[GuardianDll]

Memory slots may be reasonable, but out of scope of this PR

[ShnitzelX2]

In digital cameras I know of, there is a SD memory card where the pictures or video are stored in, and it can easily swapped in/out (in fact, it was the main way to get pictures on/off the camera). So, instead of having an E_FILE_STORAGE pocket, perhaps give digital cameras a pocket that can contain a single memory card?
Likewise, in most laptops I've used, there is a SD memory card slot (usually empty and only used for transfer, at least that's how I used them). Although, they seem to be disappearing.

Yeah, it would be realistic, and maybe someone could put it in later. It's a long list of things to do for little gain IMO, since you can already read/move pictures on a camera.

I see the capacity of storage devices is constant per-type. Perhaps in the future some higher-capacity (and lower capacity) variants could be added, and high-capacity variants would be a lucky find (although perhaps not that relevant, since memory cards are very lightweight).

This is on the follow-up list!

[GuardianDll]

Review thoughts, all the stuff can be done post-merge:

• efiles.json may need the weights updated, "prob": 100 makes little sense unless it's a junk file
• ememory_size may benefit from using range notation, and picking a random size on generation? tho since it is an item now, i don't know if it can be tied to it

[ShnitzelX2]

efiles.json may need the weights updated, "prob": 100 makes little sense unless it's a junk file

I already have a follow-up in the works for this PR, so I'll add this to it.

ememory_size may benefit from using range notation, and picking a random size on generation? tho since it is an item now, i don't know if it can be tied to it

Not by type, at least not without using an item_var. In some cases, this might be fine, in other cases it would be better to generate ememory_size by properties of the item type. That being said, yes, a lot of the file sizes are placeholders for now.

[Byzz2077]

dont have anything usefull to add to this discussion except, man I love this change.

Thank you

[ZhilkinSerg]

EBOOK pocket type probably should be obsoleted