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

RPG Maker 2003 battle scene changes #2354

Closed
wants to merge 13 commits into from
Closed

RPG Maker 2003 battle scene changes #2354

wants to merge 13 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Sep 25, 2020

This PR tried to do the following changes:

  • The status window components have been rearranged to match the RPG_RT style.
  • The transparent windows use an alpha of 160 instead of 128 now.
  • The gauge display is more accurate now but still needs work. Getting this to 100% accuracy requires a pixman expert. Picture scaling is a general problem as stated in Picture scale differences #446.
  • In traditional style battles two bugs have been fixed: The SP window got printed over when a skill which costs SP has been used and the HP value didn't change its color if the HP reached critical or zero.
  • In alternative style battles the gauges are now shown transparent if the window is opaque.
  • The ally cursor is always drawn 40 pixels above the Y-Position of the battler. (Tested with RPG_RT, but correct me if this is wrong nevertheless)
  • In the alternative and gauge battle types it is now possible to switch between actors with full ATB gauge. (Fixed in Battle System Rewrite #2399)
  • In the traditional battle type the player is forced to battle manually now. (Fixed in Battle System Rewrite #2399)
  • The ally cursor is only shown in the "Select_Actor" and "Select_AllyTarget" states. (Fixed in Battle System Rewrite #2399)
  • Actors with a "do nothing" restriction due to a state cannot do an action with full ATB anymore. (Fixed in Battle System Rewrite #2399)

@fmatthew5876
Copy link
Contributor

Does it need to depend on the other window changes? It's very unclear if those are correct or not and would take some time to verify.

@Ghabry
Copy link
Member

Ghabry commented Sep 25, 2020

Okay this is a battle PR I'm interested in so will also give some feedback later :)

Initial warning:
This "enemy gets the turn while in the menu" can have many subtile race conditions because enemy state changes while navigating in the menu which the code was not designed for!

@ghost
Copy link
Author

ghost commented Sep 25, 2020

@fmatthew5876: About the dependencies: This PR depends on the commits 4d41077, 932302e and c2da261 from #2313.

@Ghabry
Copy link
Member

Ghabry commented Sep 25, 2020

when it only depends on a few window commits you can "git cherry-pick COMMIT-ID" them instead.

@ghost
Copy link
Author

ghost commented Sep 25, 2020

This PR no longer depends on #2313 now.

@@ -376,7 +376,7 @@ void Scene_Battle_Rpg2k3::CreateUi() {
}

if (lcf::Data::battlecommands.battle_type != lcf::rpg::BattleCommands::BattleType_traditional) {
int transp = lcf::Data::battlecommands.transparency == lcf::rpg::BattleCommands::Transparency_transparent ? 128 : 255;
int transp = lcf::Data::battlecommands.transparency == lcf::rpg::BattleCommands::Transparency_transparent ? 160 : 255;
Copy link
Contributor

Choose a reason for hiding this comment

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

Hard to be 100% sure because my tool doesn't work well for this code. But 160 appears correct.

@fmatthew5876
Copy link
Contributor

fmatthew5876 commented Sep 25, 2020

There is a lot going on here. In order to make this more manageable, could you please split this into 3 PRs. This way we can review and finalize the stuff that is easier to confirm and get it in, while not getting blocked on the more difficult items.

  1. Notification window timing and message support. I.E "Add battle start message" See Battle2k3 Notification window + frame delays #2357 for more info on how to do this correctly. This not only involves notification window, but rethinking how we handle wait delays in the whole battle system.
  2. Implement ATB active mode - as @Ghabry alluded to, this requires very careful testing. Lets do it last after all the other fixes are in
  3. The rest of the stuff here, is probably ok to stay in this PR for now.

@fdelapena fdelapena added this to the 0.6.3 milestone Oct 10, 2020
rueter37 added 13 commits October 18, 2020 10:26
In the traditional battle type the player is required to battle
manually. Auto-battle and instant escaping are not possible in this
mode.
If the battle windows are set to transparent, then use an alpha of
160 for the battle windows.
The states, HP values, SP values and gauges have been rearranged in
the battler status window in the alternative battle type.
The ally cursor has been repositioned and it is shown only in the
Select_Actor and Select_AllyTarget states.
The gauges are displayed more accurate now but the accuracy is still
not at 100%. This one requires a pixman expert.
The components have been rearranged in the traditional battle type.
In the alternative battle mode the menu cursor is now shown in the
ally target menu. Moreover in the ally target menu the first ally is
always preselected now.
If an actor has a "do nothing" restriction and a full ATB gauge, do
not allow the actor to do an action until the restriction is gone.
In the alternative and gauge battle type the user can now select
between actors with full ATB gauges.
The SP window in the traditional battle type was not cleared when the
text had changed which led to overlapped texts. This is fixed now.
The HP values did not display the colors for dead or critical HP in
traditional type battles. This is fixed now.
The battle notifications use full width spaces now.
If the battle mode is alternative and the window is set to opaque,
then display the gauges with an alpha of 96.
@fmatthew5876
Copy link
Contributor

I have not reviewed the PR in detail. There may be things here that I have not fixed yet.

@ghost
Copy link
Author

ghost commented Jan 23, 2021

Closing this PR because it is outdated and interferes with #2399.

@ghost ghost closed this Jan 23, 2021
@ghost ghost mentioned this pull request Jan 23, 2021
91 tasks
@ghost ghost mentioned this pull request Mar 15, 2021
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

3 participants