Skip to content

fix: made Custom Titlescreen more robust against freezing#20

Merged
KdGaming0 merged 1 commit intoKdGaming0:v4from
Tangos-Mods:v4
Mar 15, 2026
Merged

fix: made Custom Titlescreen more robust against freezing#20
KdGaming0 merged 1 commit intoKdGaming0:v4from
Tangos-Mods:v4

Conversation

@Pankraz01
Copy link
Copy Markdown
Contributor

PR Description

Summary

This change fixes the title screen replacement loop without changing the normal PackCore startup flow.

It also removes an unnecessary preLaunch dependency on the PackCore client initializer so preLaunch no longer pulls client-side classes in earlier than needed.

What changed

1. Guard the title screen replacement path

In PackCore.java, the ScreenEvents.BEFORE_INIT hook now bails out when:

  • the screen is not a TitleScreen
  • the screen is already a PackCoreTitleScreen
  • PackCore is already in the middle of replacing the title screen

The welcome wizard behavior stays the same:

  • if successfulWelcomeWizard is false, PackCore opens WelcomeWizardScreen
  • otherwise, PackCore opens the configured custom main menu

2. Decouple preLaunch from PackCore

In PackCorePreLaunch.java, packcoreDir is now built from gameDir.resolve("packcore") instead of reading PackCore.PACKCORE_DIR.

Why this works

Title screen loop

PackCoreTitleScreen extends TitleScreen. That means the global BEFORE_INIT hook also sees PackCore's own replacement screen unless it is explicitly excluded.

Without a guard, this flow can happen:

  1. Vanilla TitleScreen initializes
  2. PackCore replaces it with PackCoreTitleScreen
  3. PackCoreTitleScreen initializes
  4. The same hook runs again because it is still a TitleScreen
  5. PackCore replaces it again

That creates a re-entry loop.

The fix works because PackCore now stops once it is already handling its own replacement path. Vanilla TitleScreen is still redirected, but PackCore's own title screen is not redirected again.

preLaunch safety

preLaunch only needs the PackCore config directory path. It does not need the full PackCore client initializer.

By computing the path locally instead of touching PackCore.PACKCORE_DIR, PackCorePreLaunch no longer forces PackCore to load during the preLaunch stage. That keeps early startup simpler and avoids loading unrelated client classes before the normal client entrypoint runs.

Behavior impact

  • The welcome wizard still opens when successfulWelcomeWizard is false
  • The configured PackCore main menu still replaces the vanilla title screen
  • PackCore no longer reprocesses its own title screen and loop on init
  • preLaunch still reads and applies config packs exactly as before

Verification

  • .\gradlew.bat compileJava

@KdGaming0 KdGaming0 merged commit d0b84ae into KdGaming0:v4 Mar 15, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants