There's no proper fluid interface in cauldron block so its only working for Water and Lava. If any mods uses cauldron as other fluid holder, it might have to change, but I've never seen one.
* Did you know this?
Tank units can just generate lags by existence
* add Valid inventory check
Very modded extension can declare RebornInventory with size 0 to only process fluids without items, for that case
* separate as function
and more condition check to reduce extra lag
* Parentheses
Co-authored-by: Ayutac <skoch02@students.uni-mainz.de>
by adding wart blocks and shroomlights to the blocks the industrial chainsaw searches for.
Tested, works. In review to make sure this is appropriate for the mod.
* Added advancements crafting data for block breaker and placer
(From 7a31de7b869e67697f85aeca9f0a5099c6bc7d62)
Added Block Breaker Machine (#2871)
* Added a new machine that can break blocks in front of it
(From e56a51da2b0c4e144cdf70ebff53d7097e81b5ce)
Added Block Placer Machine
* Added a new machine that can place blocks in front of it
(From e80de2ec82e0a14f161137e4b147bb455a839e3d)
Added Block Breaker and Placer recipe
(From dccdf76eacb8ceb7075897170e098bc346b8b4db)
Break blocks instead of removing + Refactoring
* Cache World-common recipe and use it
solves weird recipe errors and small performance improvement
Expects : RebornRecipes are Immutable
* okay what is that split?
this actually solves recipe getting evaporated by modifying recipe object itself
* Fix#2847 Allowing values larger than Integer.MAX_VALUE
* Allowed the GUI to display `Long` numbers to fix overflow values
* Added missing Death Messages from stepping on the fusion reactor
* Fusion Control using TranslatableText
* I've converted LiteralText to TranslatableText
* #2775 Adding trinket support for BatpackItem
* Added support for wearing BatpackItems in the 'back' trinket slot on the chest. This frees up an additional space for regular armor.
* BatpackItem only output when in chest armor slot
* Cache Torus.generate result for Origin
Fusion Coils are laggy, not by ticking block entities, just purely by torus.generate(BlockPos.origin, size)
* Assign TorusListCache
* use cached result
* Resin Basin updated. Thanks to Spearkiller and Ayutac.
Hitbox has been updated to half a block, better matching the model.
Item model has been updated by Spearkiller to look nice.
There was a weird inconsistency about the amount of sap given to player depending on either putting it into an inventory or breaking the block.
Right click to harvest basin didn't work as intended, so removed for now.
Also it seems the block states (full/pouring/pouringTime) are not saved via nbt?
Also also wow the warnings.
* Added removal of sap from basin when right -clicking.
The error was me not understanding that "setFullState" had nothing to do with the variable "isFull". My bad, my bad.
For some reason one right click triggers the onUse twice, and previously I didn't correctly update the sap after the first one, but now it should work. Testing went off without a hitch.
* In-depth update of chrome->chromium, thanks to Ayutac, Xanthian
This fixes Bug #2621 without accidentally destroying items (untested, but the chrome item registration isn't changed) and supersedes PR #2780 which only made language changes.
I just plainly copied the lang changes from Xanthian. As for the chrome stuff, I thought long and hard how to do it properly. Possible variants:
1. Change tag names in constructor for chrome only.
2. Change tag names in enum for chrome only.
3. Don't change the internal tag names of the enums, but change the tag registration process in datagen for chrome only.
4. Introduce CHROMIUM variant, add conversion recipes etc. and hope over time CHROME can be safely removed.
(4) always had the potential of item loss, so I discarded it first. Deciding between (1), (2) and (3) was harder. The drawback of (2) is code bloating by adding a lot of extra enum constructors, especially for cases which already had enum constructor options. But in the end I decided to go with it because it was the cleanest solution to a dirty problem. This is the first time I encountered a datagen drawback, because if we didn't register by running through the enum array, we could have simply changed it there; a possible (5) but still worse than (2).
* Whoops, forgot recipe changes with the tags
* Merged chromium with hardness/resistance
Replaced the isHot argument from constructors with default false while I was at it.
I increased the capacity of tanks to be even remotely considered an alternative to storage units with cells. I kept the values conservative since increasing is always an option, but decreasing might cause item loss.
Changes:
Basic Tank: 35 -> 128 (about 3.5 times)
Advanced Tank: 200 -> 512 (about 2.5 times)
Industrial Tank: 500 -> 1024 (about 2 times)
I oriented myself at the storage unit steps, which are quadrupled with each tier until advanced, then doubled to industrial.
While I was at it, I changed everything to powers of 2 with the shift operator (so other code readers aren't too confused about seemingly arbitrary values) and added explaining comments.
Just like in last commit, assembling machine one is a bit hacky (we add dummy classes), but better than putting an if into RebornRecipe and faster+safer than correcting the differences between assembly_machine and assembling_machine in the code.
Centrifuge one is a bit hacky (we add dummy classes), but better than putting an if into RebornRecipe and faster+safer than correcting the differences between centrifuge and industrial_centrifuge in the code.