Bag Box

[evanwporter]

(Discussion title can be changed later)

Adds a Basic Bag. I developed it on the same branch as the RR branch so all of those changes have been carried over from RR. NOTE: Look at the first commit for reviewing changed files.

Currently this just adds a super basic bag.

Here the bag is unopened

Here we added an item to the bag

Added it back to slowbro

Currently nothing gets saved to file.

Here are necessary things to do before the bag-box branch is merged

• Detach it from RR branch
• Add item count. Ideally a little number in bottom right corner of item sprite
• Store bag to file
• Mark changed OHPKM so its clear which one needs to be modified.
• Allow Boxmon to be modified by converting them to OHPKM
• Allow items to be deposited by dropping anywhere in grid (currently they can be only dropped on another item).
• Tweak aesthetics of Box so its consistent with the other save cards

Things to think about

• Storing the bag. There are two maybe three reasonable options. JSON/XML or Serializing a class.
  • JSON would make it very easy to hack in a bunch of masterballs while serializing an object would discourage that.
• Interfacing with Pokemon saves to extract or inject items would be cool
• Item sort button
• Item search box

@andrewbenington

[andrewbenington]

@evanwporter
Ooh I love it! In that screenshot, are you opening the bag of a game save? or is it a single centralized bag? I feel like we could have the OpenHome bag on the right, and be able to toggle between that and the filter being visible. Then for each save file we can let the user toggle between the game's PC boxes and item bag.

To your point about serializing the bag data, my philosophy with OpenHome is that people are going to cheat if they really want to, so there's no point in trying to obfuscate it just to deter them. Let's store it as JSON, because that's more compact and readable than XML, and having a human readable format makes debugging a lot easier (vs storing a javascript class in a binary format)

[evanwporter]

Centralized bag. I won't lie accessing the Game Save bag is much more difficult.

[evanwporter]

Also I won't lie I do not know how we should mark each OHPKM as changed so that it can be saved. But I assume the best way is to access whatever thing marks a pokemon as being moved.

[andrewbenington]

Modified OHPKMs are tracked in the openSaves state, in the modifiedOHPKMs field. Right now its just updated when a mon is moved between saves. We/I can add a new action type to just mark one as modified, which can be used when moving items.

OpenHome/src/renderer/state/openSaves.ts

Lines 18 to 24 in 276f825

	export type OpenSavesState = {
	modifiedOHPKMs: { [key: string]: OHPKM }
	monsToRelease: PKMInterface[]
	openSaves: Record<string, OpenSave>
	homeData?: HomeData
	error?: string
	}

For a save, the modified box slots are tracked in this field:

OpenHome/src/types/SAVTypes/SAV.ts

Line 48 in 276f825

updatedBoxSlots: BoxCoordinates[]

[andrewbenington]

And yeah I can work on adding item bag access to the save types

[evanwporter]

Yeah I don't think bag access is too difficult. It just a matter of looking it on Bulbapedia/PKHex. More of a slog than anything.

[evanwporter]

By the way, for this I created another branch--I know there's a lot of branches--but hopefully we are able to start closing some of them soon.

[evanwporter]

Also here's what I got.

I think the bag looks better on the right side.

But I need troubleshoot why the filter is overextending.

I can release these edits as a commit if you want to poke your head around. I won't be able to get to troubleshooting for a little bit.

[andrewbenington]

Yeah that would be great, thanks. The tabs look like they're not in the card in this image but i'll poke around when i'm home from work

[andrewbenington]

actually we could also make "Filter" a dropdown and get rid of the tabs. that way it takes up less space. i'll play around with it

[evanwporter]

Also I think we should move the Mawile Sprite in Home up slightly. With a mega stone it looks like this

[andrewbenington]

@evanwporter let me know when you push your latest changes to bag-box; it's a couple commits behind main so we should merge main into bag-box before things diverge too much

[evanwporter]

Nvm, now its good to merge

[andrewbenington]

just merged the changes. i also moved a bunch of radical red stuff from pokemon-files to this repo so it's all in one place.

[evanwporter]

Note: I defined the bag to be a static class--coming from a C# background static classes are usually discourages, but this should be fine for now since there will only be one bag per OpenHome. The most important thing we need to do now is to have the bag read the json at the very beginning of the program. Also have it write to file when program is saved.

[andrewbenington]

yeah it shouldn't be a static class, it should be a new state file in src/renderer/state. State management in React needs to be handled carefully, because otherwise the renderer might not update when you expect it to. For now a static class is fine, but before we merge the bag branch it should be moved to context/reducer logic to avoid cryptic bugs down the line. I can do that if you'd like

[evanwporter]

@andrewbenington

I can do that if you'd like

Yeah that's be good. Honestly I'm not quite sure where to go with the Bag from here. I haven't looked too in-depths at the program. So while I can easily call SaveToJSON when the bag is closed and ReadToJSON when its opened, but I know this is not what you want... But these shouldn't be too difficult to implement, since I've already implemented all of the item transfer mechanics as well as the tabs (Filter will need to be made into a dropdown).

TLDR: I don't know where to go with the bagbox.

[andrewbenington]

yeah my priority is getting the radical red stuff merged first, I haven't gotten around to it yet but there are a bunch of inconsistencies with Radical Red moves. After that's done I'll work on the bag stuff

[evanwporter]

@andrewbenington

Kind of along the same lines as issue #55, what happens when a pokemon is moved to a generation with moves. not from that generation? The moves are likely removed... But then what happens when that pokemon is moved back the OH with no move changes? Does OpenHome fill in the missing moves with its saved moves?

[andrewbenington]

Right now no, those moves are lost. That shouldn't be too hard to implement though, just a couple more lines in updateData() in OHPKM.ts. updateData is the function called to update the OHPKM file with new data from a game save (evs, ribbons, moves, etc)