Document Poffin Manager portion of Poffin Case App

[VicSevenT]

The Poffin Case app allows the player to throw out poffins or feed them to pokemon. The app makes use of the party menu and pokemon summary screens, and also has two interfaces unique to itself, the poffin list where the player can search though their poffins to trash them or give them, which I've named the PoffinManager. and a cutscene that plays when a poffin is used.

This PR documents all but the feeding cutscene, which I decided to break off for a future PR as this one was already getting pretty big. The poffin case interfaces make up overlay 79, with the three files documented here being for the PoffinManager and the remaining two undocumented files relate to the cutscene. In the process of documenting the interface there were a couple of other poffin-related files that I documented which contain some logic shared with the poffin-making interface.

One other piece to note is that I adjusted the use of the terms "type" and "flavor" for poffins. "Flavor" now refers to the five attributes a poffin can have (dry, bitter, sweet, sour, and spicy). This is consistent with the use of "flavor" for berries. "Type" refers to the 29 distinct names a poffin. "Type" is determined by flavor, and determines the appearance and some behavior of the poffin.

[lhearachel]

Some preliminary feedback, mostly centered on structure.

[lhearachel]

suggestion: Move this file into include/applications/poffin_case, probably as defs.h?

[VicSevenT]

Similar to my other comment, I wonder that if these are to be moved, they should probably just go into include/poffin_case.h as that's where the New and Free functions for these structs are.

[lhearachel]

suggestion: Merge this header into the poffin_case.h header (wherever that one ends up).

[VicSevenT]

There is actually also an include/poffin_sprite.h in this PR, which is where I think this should be merged into if anywhere. The PoffinSprite objects are used in both the poffin case and in the poffin making minigame (OV83), so I don't think including them into poffin_case.h directly makes sense.

Is there a standard being followed about when struct_defs files should get merged into other headers? I had originally been planning to, but then held off when I realized that there are a handful of other documented files that were kept separate in struct_defs.

[lhearachel]

question: What makes this specifically a manager_main? Is there a separate application entry-point?

[VicSevenT]

Yeah, the initial application entry-point is in src/poffin_case.c. That calls multiple sub-applications, including the pokemon summary and party menu, and also the PoffinManager defined in manager_main.c. There is a second poffin case exclusive app, which I am pretty sure is the poffin-feeding cutscene, with its entrypoint in ov79_021D2268.c. With my current naming scheme I was thinking this would become cutscene_main.c or something like that.

[lhearachel]

note: You'll want to keep an eye on #852 for some tooling on how to replace these resource IDs with generated constants.

[VicSevenT]

Would it make sense/be preferred for src/poffin_case.c to be moved into src/applications/poffin_case. Technically, I think it would fit, as that file is the overall controller for the whole app. This would mean putting a file from the main code into a directory that is otherwise a single overlay, which is my main hang up. Is there a preference on trying to keep overlay source files in their own directories. Looking a little through main.lsf I didn't see any examples of this being done before (putting a main source file in a subdirectory with overlay files) but maybe I missed something, or maybe there just hasn't been a reason to do so up to this point.

[Gudf]

I didn't see any examples of this being done before

I actually did exactly that for src/applications/town_map/context.c (see line 268 in main.lsf). Somewhat similar case IMO, this is essentially the file with the code for creating and reading back the object used to communicate with the parent application, so it made sense to put it alongside the rest of the application's code.

[VicSevenT]

I actually did exactly that for src/applications/town_map/context.c (see line 268 in main.lsf).

Oh cool. I took a look, and yeah I do think it is a somewhat similar situation. Based on that and all the other conversations above + thinking about it for a few days, I've gone ahead and moved src/poffin_case.c to src/applications/poffin_case/main.c, and moved some other files around to simplify (also then moved manager_main to just manager).