You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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!
The text was updated successfully, but these errors were encountered:
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
Things to do in order
CoverBehavior
in the future, but probably not this time.NumericWidget
. Or maybe it could be delayed, since there’s also ongoing related refactor on upstream.MTEBasicMachine
MTEBasicMachine
Involved mods
Note to developers
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:
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 inventedFakeSyncWidget
, 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 forItemSlot
.) This would make syncing less headache.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!
The text was updated successfully, but these errors were encountered: