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

ModularUI2 migration plan #18398

Open
10 of 32 tasks
miozune opened this issue Dec 15, 2024 · 0 comments
Open
10 of 32 tasks

ModularUI2 migration plan #18398

miozune opened this issue Dec 15, 2024 · 0 comments
Labels
Mod: ModularUI Planning For larger organizational issues, typically opened by staff or admins

Comments

@miozune
Copy link
Member

miozune commented Dec 15, 2024

What

This is a ticket to consolidate all the works to migrate from MUI1 to MUI2. Contributions from anyone are highly appreciated. If you have any questions, feel free to ask me on Discord, though I could be slow to respond.

Plan

Chores

  • Pull changes from upstream MUI2 repository
  • Adapt existing code using MUI2 for breaking changes. Upstream sometimes makes breaking changes, so keep eyes on what has been changed.
  • Merge current working branch from master. GT is quite busy codebase and chances of conflict is high.
  • Create and update wiki page for developers on how to work write MUI2 code and for resource pack makers on how to migrate and to customize various elements

Things to do in order

  • Port covers: feature/mui2-cover
    • There’re a lot of changes on this branch, but what I’m trying to do is:
      • Move away from magic numbers and use enums to manage variables. We could completely obsolete CoverBehavior in the future, but probably not this time.
      • Make cover GUIs more consistent with machine ones. Cover GUI had unique UI system from machine GUI at that time. I kept the overall textures when migrating to MUI1, but now I revisit it and devs agreed that consistency is good.
      • Make standalone cover GUI always have player inventory, while omitting it when opened as cover window on machine GUI. I haven’t worked on this, but it could be achieved by making individual covers return “container” widget and wrap them as needed.
    • CoverAdvancedRedstoneReceiverBase
    • CoverAdvancedRedstoneTransmitterBase
    • CoverArm
    • CoverChest
    • CoverControlsWork
    • CoverConveyor
    • CoverDoesWork
    • CoverEUMeter
    • CoverEnderFluidLink
    • CoverFacadeBase
    • CoverFluidLimiter
    • CoverFluidRegulator
    • CoverFluidfilter
    • CoverItemFilter
    • CoverItemMeter
    • CoverLiquidMeter
    • CoverNeedMaintainance
    • CoverOverflow
    • CoverPlayerDetector
    • CoverPump
    • CoverRedstoneWirelessBase
    • CoverShutter
    • CoverWirelessDoesWorkDetector
    • CoverWirelessFluidDetector
    • CoverWirelessItemDetector
    • CoverWirelessMaintenanceDetector
    • Port features from MUI1 NumericWidget. Or maybe it could be delayed, since there’s also ongoing related refactor on upstream.
  • Lay down basics for GT MTEs
  • Port multiblocks
  • Port singleblocks excluding MTEBasicMachine
  • Port NEI & MTEBasicMachine
    • This could be the hard one. Current GT/NEI/MUI1 integration is just a hack and I’m not sure if MUI2 works in the similar way. If not we need to work something fundamental on NEI side to make customized handler easier.

Involved mods

Note to developers

  • Cover code written in MUI2 is gated behind flag, as I have changed the overall theme of cover UI, and there would be both MUI1 and MUI2 styles of cover GUI for the time being.
  • It’s a good practice to take screenshot of GUI before the change and compare to see if anything got changed inadvertently.
  • But don’t hesitate to improve the bad UI along the way.
  • GTCEu is also working on MUI2 migration. Their code would be really helpful.

Background

Migration to ModularUI was quite successful, allowing many developers to implement impressive GUI features. However, brachy, the original author of MUI, completely reworked the mod and shipped version 2. This happened only 3 months after I finished MUI1 migration. Over the months it kept growing to the point we should consider migration again.

So is it really worth the effort to migrate? Yes, pretty much! It solves various issues MUI1 has:

  • Better sync system. In MUI1 widgets need to implement ISyncedWidget to handle sync, which brought confusion; You cannot tell if widget is synced or not without reading the library source. Also, sometimes you want to do complex operations to a variable that need syncing, but it was really annoying to deal with. I invented FakeSyncWidget, which surprisingly worked well, but MUI2 does similar in a better way; Widget and syncing are, in essence, completely separated. You can even add or remove widgets after the initial widget tree construction, as long as all the sync values needed are defined beforehand (except for ItemSlot.) This would make syncing less headache.
  • Better positioning and sizing system. In MUI1, you can specify widget position relative to parent widget, which is still way better than vanilla way of hardcoding position relative to the base screen. However, In MUI2, you can also specify position relative to each other in “flex” manner - with padding and margin. It also supports positioning widgets relative to bottom or right. It’s quite “modular” now.
  • Resource pack support. I haven’t looked into it deeply, but it looks quite promising. Refer to CleanroomMC wiki if you’re interested. And don’t worry, migration will not be as tragic as it was during the MUI1 transition.

Thanks to Caedis (and the fact I renamed packages under GTNH org, which I still consider myself really bad faith) MUI1 and MUI2 can coexist. So we can work on migration gradually instead of all at once.

This would be a long-running project, especially with my current semi-hiatus status. But I believe this would accelerate the development of GTNH even further!

@serenibyss serenibyss added the Planning For larger organizational issues, typically opened by staff or admins label Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Mod: ModularUI Planning For larger organizational issues, typically opened by staff or admins
Projects
None yet
Development

No branches or pull requests

2 participants