Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify/Clean battle controllers code #3202

Merged
merged 22 commits into from
Aug 28, 2023

Conversation

DizzyEggg
Copy link
Collaborator

@DizzyEggg DizzyEggg commented Aug 4, 2023

As we are all aware of, battle controllers' code is one of GF's worst creations. The amount of duplicated code over the controllers files is truly unmatched.

Goals of this PR:

  • remove all of the duplicated code
  • simplify to make the code easier to follow
  • get rid of unused data and code
  • remove usage of gActiveBattler in the controller files. The functions now take a battler argument.

This PR should be thoroughly tested as I might have accidentally omitted something while copying the functions. Things to keep an eye on are link battles, multi battles, recorded battles and multi link battles as things may break the most there.

Suggestions and reviews are welcome.

Note:
NONE of the functionality has changed, everything works exactly the same way as before. Compatibility with vanilla games is preserved(at least in the state it was before this PR).

Note 2:
I did the math and this PR saves approx whooping 80 064 bytes of space.

@DizzyEggg DizzyEggg added type: BREAKING Not to be merged lightly, needs to be reviewed category: battle-mechanic Pertains to battle mechanics labels Aug 4, 2023
@AsparagusEduardo
Copy link
Collaborator

On one hand, I'm glad we're able to untangle this mess :D
On the other, I wonder if this will break the potential vanilla compatibility, as we've found out that it's actually surprisingly compatible due to all the logic and data being handled by a single game 👀

@DizzyEggg
Copy link
Collaborator Author

On one hand, I'm glad we're able to untangle this mess :D On the other, I wonder if this will break the potential vanilla compatibility, as we've found out that it's actually surprisingly compatible due to all the logic and data being handled by a single game 👀

I see no reason why the compatibility would be broken. I want the flow to remain the same, the difference being there is 1 function doing 1 thing, instead of 5 functions doing the same thing :D

@AsparagusEduardo
Copy link
Collaborator

I see no reason why the compatibility would be broken. I want the flow to remain the same, the difference being there is 1 function doing 1 thing, instead of 5 functions doing the same thing :D

Awesome, we're on the same league then :D

@DizzyEggg DizzyEggg marked this pull request as ready for review August 7, 2023 11:04
@DizzyEggg
Copy link
Collaborator Author

Ready for review. I also updated the first post with some more information.

@AsparagusEduardo
Copy link
Collaborator

If it's not breaking, why does it have the BREAKING tag? 👀

@DizzyEggg DizzyEggg removed the type: BREAKING Not to be merged lightly, needs to be reviewed label Aug 7, 2023
@DizzyEggg
Copy link
Collaborator Author

If it's not breaking, why does it have the BREAKING tag? 👀

You're right, I removed the tag.

src/battle_controllers.c Outdated Show resolved Hide resolved
@ghoulslash
Copy link
Collaborator

I love this PR :)

{
u16 species;
u32 side = GetBattlerSide(battler);
struct Pokemon *party = GetBattlerParty(battler);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I think we can just consolidate all of these GetBattlerParty and gBattlerPartyIndexes into just GetBattlerPartyData calls. Sorry I should have noticed earlier

@ghoulslash
Copy link
Collaborator

ghoulslash commented Aug 21, 2023

It might also make sense to replace the gActiveBattler check in PrepareBufferDataTransfer with a battler argument, but that would require changing all battle controller emit function calls. But currently calling any of those without properly setting gActiveBattler can be problematic. especially since gActiveBattler is used a loop index in some places so can be set to gBattlersCount and therefore emitting data to that battler Id would result in bad UB

edit: actually does this not break some implementations of calling BtlController_x inside the battle controller files since gActiveBattler is not explicitly set?

@DizzyEggg
Copy link
Collaborator Author

It might also make sense to replace the gActiveBattler check in PrepareBufferDataTransfer with a battler argument, but that would require changing all battle controller emit function calls. But currently calling any of those without properly setting gActiveBattler can be problematic. especially since gActiveBattler is used a loop index in some places so can be set to gBattlersCount and therefore emitting data to that battler Id would result in bad UB

edit: actually does this not break some implementations of calling BtlController_x inside the battle controller files since gActiveBattler is not explicitly set?

This should also be done, but I think this PR is big enough as it is.
I don't think it should break anything, if the battler is provided via an argument instead of gActiveBattler.

@DizzyEggg
Copy link
Collaborator Author

Conflicts fixed. Ready to review & merge

@ghoulslash
Copy link
Collaborator

Been testing this in my own game and seems pretty solid. Will do some basic fresh expansion tests soon but should be good to go

Copy link
Collaborator

@ghoulslash ghoulslash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alex confirmed link battles work, singles and doubles work as expected locally as well

@ghoulslash ghoulslash merged commit ee8d930 into rh-hideout:upcoming Aug 28, 2023
1 check passed
@DizzyEggg DizzyEggg deleted the controllers_clean_up branch August 29, 2023 07:26
@AsparagusEduardo AsparagusEduardo mentioned this pull request Sep 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: battle-mechanic Pertains to battle mechanics
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants