- Can now use trapdoors with copycat panels
- Copycat bars are less likely to cause zfighting
- Fixed waterwheels not updating flow score in some edge cases
- Metal Scaffolding no longer zfights with adjacent non-solid blocks
- Boiler status now highlights information about water flow when insufficient
- SimplePacketBase#handle now accepts Context instead of
Supplier<Context>
- SimplePacketBase#handle now returns boolean, which, if true, calls
Context#setPacketHandled(true)
- Overhauled UX of scroll values and item filtering
- Filtered item extraction can now be configured to pull "up to x items" per operation
- Removed some unused assets
- Fixed inside faces of scaffolds not using the correct textures
- Fixed inside faces of scaffolds not connecting
- Copycat panels now accept iron bars and modded instances of it
- Added andesite, brass and copper bars (textures to be replaced)
- Rename AllBlockPartials -> AllPartialModels
- Make AllPackets.channel private and use getter method instead
- Make config fields in AllConfigs private and use getter methods
instead
- Optimize SyncedBlockEntity#sendData
- Added the Large Water Wheel
- Water wheel fins are no longer directional
- Water wheels now only have two speed levels
- Liquid can no longer spread perpendicularly on top of water wheels (experimental)
- New crushing wheel model
- CustomRenderedItemModel no longer holds partials
- Store partials as PartialModels in static fields in renderers
- Remove all CustomRenderedItemModel subclasses
- Remove CustomRenderedItemModelRenderer#createModel
- CustomRenderedItemModelRenderer is no longer generic
- Store items with custom renderers in CustomRenderedItems instead of
CustomRenderedItemModelRenderer
* Make Encasing utilize Interfaces
* Add Javadoc to IEncasable and IEncased interfaces
* Fix Weird block.block issues (No clue where those came from)
* Final Touch ups for now and made requirement for casing normal Block instead of CasingBlock
* Make requested changes
* Add more parameters for tryEncasing, for use in handleEncasing
Move handleEncasing to Encased Interface for more flexability
* Simplify and organize
- Rename:
- Encasable -> EncasableBlock
- Encased -> EncasedBlock
- EncasableRegistry -> EncasingRegistry
- Remove EncasedBlock#setCasing
- Remove encasedBlock argument from EncasedBlock#handleEncasing
- Add Registrate builder transformer to EncasingRegistry for easy use
---------
Co-authored-by: PepperCode1 <44146161+PepperCode1@users.noreply.github.com>
Can't test it due to java shenanigans, but I think this will work.
It's worth noting that this will only be specific to merging as long as transferAll is. If anything else ends up using transferAll, all that needs to happen is adding an intermediate method that posts the event instead of transferAll doing it, then calls transferAll
- Fix NPE in CarriageSyncData (Unknown cause)
- Fixed crash when applying text to display boards before they initialise
- Fixed incorrect itemstack remainders on Weighted Ejectors
- Other mods' wrenches now always behave like the Create wrench on IWrenchables
- Finish refactor of item description tooltips and kinetic stat tooltips
- Change Palette to use Style instead of ChatFormatting
- Remove old code in TooltipHelper
- Add deferred registration capabilities to AttachedRegistry
- Move creative mode tabs to AllCreativeModeTabs
- Delete IItemHandlerModifiableIntermediate
- Delete StorageInterfaceMovement
- Crashes that occur during schematic loading no longer terminate the server
- Fixed crash when creating new belts at existing chutes/funnels
- Fixed ghost items appearing on non-powered belts when extracted from
API v1 has been deprecated for over a year now and should no longer be used. There are two options for implementation of this fix:
- Use the dedicated shields.io route
- Update it to still manually construct the request with API v2
Each has advantages and disadvantages. Namely, the former no longer has the precise count, and the latter will need manual reconstruction every time that the API updates. Considering that this is down to the clock with how many deprecation warnings have gone out at this point, I believe the former is the best option, and thus the one I have implemented in this PR. If you believe the latter is better, feel free to request that change.
