Change Main Menu layout to have full-width Realms and Mods buttons (fixes #249)

[st4r1ight]

Currently, Forge positions the "Mods" button on the main menu next to the Realms button, shrinking the width of "Realms" to make room for "Mods." As described in #249, the "Realms" button is too narrow to display the little icons Mojang adds to the button when the game is in online mode, and they get all bunched up on the right of the button. This PR solves that by widening "Mods" to a full-width button and moving all the other buttons down by one row:

A few notes on what I've done:

Clipped text

Because the main menu is now 24 pixels taller, on some resolutions (such as my laptop in windowed mode), the bottom buttons collide with NeoForge's branding text and the copyright text, as you can see below. I don't know how much of a problem that is, seeing as they collide with the branding text even without the extra button.

Button order

In the original issue, commenters suggested that the layout should be changed to be the same as Fabric's ModMenu mod, which places "Mods" below "Realms." Instead, I chose to put "Realms" below "Mods," partly because I think it looks better that way, but also so the Mods button occupies the same space as it did previously, to avoid breaking mods that hard-coded in its position (or at least lessen the impact), which someone suggested might be a problem. If we decide that the layout should be more similar to ModMenu, it's a very easy change to make.

Pixel count

In order to move the four bottom buttons (Language, Options, Quit Game, Accessibility) down to compensate for the new Mods button, I had to patch the TitleScreen.java and change their relative heights on the screen by 24 pixels. I did this by changing the number 72 (pixels) to 96, as you can see here:

-            Button.builder(Component.translatable("menu.quit"), p_280831_ -> this.minecraft.stop()).bounds(this.width / 2 + 2, l + 72 + 12, 98, 20).build()
+            Button.builder(Component.translatable("menu.quit"), p_280831_ -> this.minecraft.stop()).bounds(this.width / 2 + 2, l + 96 + 12, 98, 20).build()

But I did consider adding on 24 to the total, to make it more obvious that it was changed:

-            Button.builder(Component.translatable("menu.quit"), p_280831_ -> this.minecraft.stop()).bounds(this.width / 2 + 2, l + 72 + 12, 98, 20).build()
+            Button.builder(Component.translatable("menu.quit"), p_280831_ -> this.minecraft.stop()).bounds(this.width / 2 + 2, l + 72 + 12 + 24, 98, 20).build()

I'm not sure which would be best although I prefer the first one, since anyone reading the patch could see the original line anyway.

[neoforged-pr-publishing[bot]]

• [x] Publish PR to GitHub Packages

Last commit published: 6a3f60e3b0ca162f6b45a0bf4f97ab7d42c8f7cf.

PR Publishing

The artifacts published by this PR:

• :package: net.neoforged:neoforge:20.4.102-beta-pr-456-mod-button

Repository Declaration

In order to use the artifacts published by the PR, add the following repository to your buildscript:

repositories {
    maven {
        name 'Maven for PR #456' // https://github.com/neoforged/NeoForge/pull/456
        url 'https://prmaven.neoforged.net/NeoForge/pr456'
        content {
            includeModule('net.neoforged', 'neoforge')
        }
    }
}

MDK installation

In order to setup a MDK using the latest PR version, run the following commands in a terminal.
The script works on both *nix and Windows as long as you have the JDK bin folder on the path.
The script will clone the MDK in a folder named NeoForge-pr456.
On Powershell you will need to remove the -L flag from the curl invocation.

mkdir NeoForge-pr456
cd NeoForge-pr456
curl -L https://prmaven.neoforged.net/NeoForge/pr456/net/neoforged/neoforge/20.4.102-beta-pr-456-mod-button/mdk-pr456.zip -o mdk.zip
jar xf mdk.zip
rm mdk.zip || del mdk.zip

To test a production environment, you can download the installer from here.

[Jab125]

why not leave the bottom row as is and instead, shift every other button up?

[st4r1ight]

That does work, although the "Singleplayer" button clips the splash text a bit, so you kind of have to decide whether you want to clip the branding text or the splash text. My concern is mainly to do with something that @dayo05 said in this comment on #249, that some mods hard-code the position of the Mods button and moving it up by one block would break that. In my first solution, the position of the Mods button doesn't change (only its width changes), so such mods wouldn't break. But if mods are hard-coding button positions, then this change would break at least some of them no matter what. If you move buttons down to make space for the new Mods button, then that breaks mods which hard-code the "Minecraft Realms," "Options," and "Quit Game" buttons. If you move the buttons up, then that breaks mods which hard-code the "Singleplayer," "Multiplayer" and "Mods" buttons (I'm discounting the "Accessibility" and "Languages" buttons since they are fairly new additions to the game).

Mod-breaking aside, I personally think that moving the buttons down is the slightly better solution, but none of them are great since the GUI auto-scaling system is designed with four rows of button in mind, not five. The suggestion to replace "Minecraft Realms" with "Realms" (which apparently old Forge versions did) that I saw in #249 seems like a good alternative, but that would presumably require NeoForge to maintain a translatable text component; I don't know how much effort that would be.

[st4r1ight]

I like this solution better and I've implemented it in my own repository. But I won't make a PR unless we decide not to go ahead with the widened button idea.

[TelepathicGrunt]

That realms button looks like it’ll may barely still overlap the realms icons even without the Minecraft part. The icons nearly reaches center of button. Full width buttons may be the only solution here

[st4r1ight]

I patched the game to display all possible Realms icons and ran it online mode, and you are right - even with just "Realms" the button still isn't wide enough.

[XFactHD]

Removing the larger gap between the full width buttons and the options and quit button might be an option. Could of course also look completely out of place or weird since we're accustomed to that gap existing.

[st4r1ight]

It kind of works, but it doesn't completely solve the clipping because a button (including padding) is 24 pixels tall. The extra space is 12 pixels tall, so in the end the menu is still 12 pixels taller than normal.

[TelepathicGrunt]

Maybe move the neoforge branding to bottom and mods loaded to top? But won’t help narrower screens

[st4r1ight]

If you ask me, this is a pretty pointless battle because there's no way we can make something that works perfectly on all resolutions - in fact as I mentioned in an earlier comment, I experience the text clipping problem even with the current version of NeoForge. I did wonder whether it would work to get rid of the gap (giving us 12 pixels) and then move the whole menu up by another 12 pixels, making it the same distance from the bottom of the screen as before. But frankly I think that's too much effort to solve a problem that we won't be able to completely solve without re-tooling the GUI auto-scaling system or something.

[sciwhiz12]

As a thought, perhaps we can move the NeoForge version to the bottom of the left side, and either append the mods count to that or remove the mods count entirely (and/or display it elsewhere, such as part of the Mods button or on the mods list screen).

[Technici4n]

Two ideas:

• Align the Realms text in the center of the button space minus the space taken by the icons.
• Rotate between the Realms icons instead of displaying all of them at the same time.

[robotgryphon]

IMO mod count has been mostly pointless, due to dependency/library mods and nested JAR files. It hasn't been a very useful metric.

[Eric-01]

The same applies to the "X mods loaded" message in the main menu. If a mod fails to load, the user is informed about this fact in an appropriate message at the loading stage. Therefore, by the time the main menu is visible, the user already knows if all mods have been loaded correctly or if some are missing.

[marchermans]

My 2 cents:

1. Move the Realms text to the left depending on the icons displayed
2. Remove the mods loaded count and append it to the mods list button: Mods (2)
3. Remove the forge version from that screen

[Technici4n]

Re 3., I like the forge version being easily visible.

No other objections. I think the mod count should be visible somewhere (it's a good sanity check in many cases), having it on the mods button is fine but might be a bit ugly.

[marchermans]

Re 3., I like the forge version being easily visible.

No other objections. I think the mod count should be visible somewhere (it's a good sanity check in many cases), having it on the mods button is fine but might be a bit ugly.

Is it usefull on the main screen though? It is in the mods list etc and logs. So how much value do you get from it being on the menu screen?

[st4r1ight]

It occurred to me earlier today that because the Realms icons are drawn onto the screen separately from the buttons, they would probably not reflect the change in position of the Realms button that this patch creates. I didn't pick it up at first since I was testing in offline mode, but when I tested it with my patched Realms version, the notification glyphs did indeed show up on the Mods button instead of the Realms button. So I changed it to put the Mods button at the bottom of the stack, moving only Quit Game, Settings, Language, and Accessibility.

Incidentally, this is why suggestions to move the "Realms" text if there are notification options wouldn't work, or would at least be difficult to implement. The "Realms" button in the "TitleScreen" class has no context around the notification icons; the way that button works is that the "TitleScreen" screen draws its own generic buttons, and then renders a different screen called "RealmsNotificationScreen" on top of those buttons, in just the right position that any notification icons will show up on the right of the "Realms" button. The TitleScreen itself (and thus the logic to control buttons in it) has no idea where on the screen the icons are, or if there even are any icons being rendered. And we would also need to patch "Realms" button itself to allow for arbitrary text alignment; I guess we would need to write our own Button class for the Realms button and replace the generic Button class with that.

[TheCurle]

I don't honestly think this is a good way to solve what is ultimately a minor graphical issue. Invasive changes and rebuilding half of a menu system just to align some text with some icons is hardly what I'd call a valuable usage of time.

I'm inclined to more or less accept that the Realms button will sometimes have text overlapping icons for the couple of seconds that most people have the main menu open before they click into singleplayer or multiplayer or whatever. It's not a huge problem. Definitely not worth all this effort to solve.

[Shadows-of-Fire]

Closing in favor of the approach in #997