Shiny hunt fishing#1146
Conversation
Added the Shiny hunt fishing files to the rpo. no modifications made to the FRLG Panels.cpp or source files saved with this commit. Implements an automated fishing-based shiny hunting program for FRLG. Features: - Adaptive timing system that adjusts button press delay based on missed bites - Encounter detection using dialog and battle transition watchers - Shiny detection using existing encounter handling logic - Stats tracking for encounters, shinies, and errors - Notification support when a shiny is found - Configurable bite timing window - Compatible with registered rod workflow Code structure follows existing FRLG program patterns: - Descriptor + Instance class structure - Standard StatsTracker implementation - EventNotificationOption owned by program class - Consistent namespace and option registration layout Future improvements planned: - Optional rod auto-registration - Optional audio-based shiny detection redundancy - Periodic autosave support - Ball selection and auto-catch workflow
Reduce extra spacing and clarify adaptive timing, fail-safe logic, and detectors. Added program to PokemonFRLG_Panels.cpp and to SourceFiles.cmake. No functional changes.
I think the python string that adds programs to sourcefiles.cmake makes a lot of changes to the order. To minimize the apparent changes, I copied the original file and manually added my programs to it.
|
Don't forget to create a guide for the wiki |
| Protects progress if crash occurs later. | ||
| */ | ||
| env.log("Performing initial autosave."); | ||
| save_game_to_overworld(env.console, context); |
There was a problem hiding this comment.
Is there a reason for this save? Most of the automation programs only save if there is a long running process with notable progress. For example Tournament Farmer in SV, Restaurant Farmer in LZA, Nugget Bridge Farmer in FRLG. All of these gain items, money, or levels over hours of grinding. These only save after x number of runs to minimize the loss if the game crashes. A save before the loop doesn't really "Protect progress" if there hasn't been any progress to protect. An initial save would be needed if you were planning to call soft_reset however that isn't needed in a program like this.
| save_game_to_overworld(env.console, context); | ||
|
|
||
| /*Return to overworld after saving.*/ | ||
| pbf_mash_button(context, BUTTON_B, 1000ms); |
There was a problem hiding this comment.
This shouldn't be needed. The name save_game_to_overworld should be a good hint that it returns in the overworld. Also the description of the method states "This function returns in the overworld."
Not that there is a choice as the moment you confirm the save the game auto-closes the start menu.
| If timeout occurs, run_until returns negative. | ||
| */ | ||
| int ret = | ||
| run_until<ProControllerContext>(env.console, context, [&](ProControllerContext& context) |
There was a problem hiding this comment.
If you are just waiting there is a similar method called wait_until
|
|
||
| /* | ||
| =============================================================================== | ||
| Constructor |
There was a problem hiding this comment.
This is more of a personal preference and I'd like to leave formatting decisions to the maintainers. But a comment that says the Constructor is a Constructor feels like unnecessary bloat. When reading the file its just another thing that needs to be skimmed over to get to the actual code.
Some general rules I like to follow for comments:
If there is a comment in the logic its probably better to describe why a decision was made not describe what the code is doing. I should be able to know what the code is doing by reading the code. If someone changes the logic later they shouldn't have to double the work by also changing the comment that states what the code its doing.
Comments that give an overview of what a shared method does can be quite helpful. See PokemonFRLG_Navigation.h or PokemonLZA_BasicNavigation.h for examples. Notice how there are minimal comments in the logic of the cpp file. This is even easier to follow in a project like this where there are frequent logging calls that also describe whats happening in real time.
2 participants
Adds a fishing-based shiny hunt program for FRLG.
This attempt should address all concerns about formatting.
The program automatically casts the registered fishing rod, detects bite dialogs, adapts timing for reliable hook success, and handles encounters using existing FRLG navigation and battle logic. It checks the pokemon for shininess when encountered and flees if not shiny.