Fixed TC's tanks taking all the fluid of one type even if they can't contain all of it#3
Open
K0LALA wants to merge 93 commits intoAlpha-s-Stuff:1.20.1from
Open
Fixed TC's tanks taking all the fluid of one type even if they can't contain all of it#3K0LALA wants to merge 93 commits intoAlpha-s-Stuff:1.20.1from
K0LALA wants to merge 93 commits intoAlpha-s-Stuff:1.20.1from
Conversation
Means usages in nested models can just make the field type simple instead of needing to manually wrap to get coloring. They already share most of the same methods afterall To make this easier, made bake (the one matching forge's interface) the primary method to use for SimpleBlockModel baking, and reordered parameters for simplicity
Removes a couple of deprecated methods, mostly repackaging
Incorporate some build script improvements from the latest forge MDK
Notable changes (API): * Fluid texture model was moved to a dedicated, datagennable folder as the model is now further removed from the thing using it (fluid types are very loosely connected to fluid blocks) * Book conditions now use DataLoadedConditionContext, meaning they have access to tag contents for tag based conditions * Book repositories now have a new optional resource getter, will in the future replace the has/get resource methods as its more efficient * Retextured model and connected model both support block colors * Added JsonCodec and GsonCodec for lazily creating codecs for things that have JSON serialize/deserialize, needed for the new global loot modifier stuff * Mantle now ships codecs for loot entries, loot functions, and ingredients along with ItemOutput, more may come in the future as things are forced to migrate * Recipe helper interfaces can no longer get names for registry entries, but do have a new helper to get an item like ID. For simplicy I left the common helpers to just RegistryObject and ResourceLocation, chain the ItemLike helper if you wish to use it with other helpers * ResourceLocation prefixing, suffixing, and wrapping was common enough I created a helper for it, see IdExtender/LocationExtender * UnplacableFluid bucket is now optional * FluidDerredRegister now uses a builder pattern instead of too many overloads for adding fluids. As a result, buckets and blocks are both now optional, and must be requested to register when registering fluids * Retextured blocks no longer store an instance statically, as I was told them being mutable did not mean you are supposed to mutate them (hence them being made immutable in 1.19). Some new helpers exist to make this work * ReversedListBuilder now builds into a consumer instead of assuming a collection. Changes the usage slightly, but was needed for render type/quad collection pairs Removed: * Removed SinglePropertyData, as ModelData has immutable builders now * Removed FluidTextureModel, see above comment on new provider * Removed TRSRBakedModel: was broken and unused, did not feel like fixing it * Removed GenericLootModifierBuilder, new version of GLM provider makes it less useful * Remove model helper color transformer, will probably recreate something similar for colored block model later * Removed AbstractRecipeSerializer as its no longer needed, LoggingRecipeSerializer is now an interface TODO: * Migrate books fully to optional resources * Remove redundant luminosity setting in colored blocks, and possibly simplify code using a quad transformer for color * Add option to tag dump command to dump with source packs * Switch fluid tooltips to using fluid ingredients or fluid predicates instead of fluid tags * Make EdibleItem not so outdated * Migrate away from object holders as the new syntax for them is just dumb
Lists each tag entry with the source that provided it as a bulleted list. Unlike view tag which looks at the live tags, this one looks at the datapack tag list, meaning you see tags nested in tags instead of expanded, will help you trace why a tag has an entry but not why it has a particular value
FluidObject has now been split into FluidObject (for unplacable) and FlowingFluidObject (for placable fluids) The builder in the deferred register now has an unplacable option which disallows a block form Unplacabke fluid now has a constructor taking in the builder Fluid builder now contains a type field, either included in the constructor (for the adapter form) or via methods later (in the deferred form). That type replaces the type in the adapter constructor
Pretty common request, and the fluid objects without blocks are more awkward to create it as they lack a tag
Tinkers used this to simplify some datagen key creation on Minecraft objects. We never want to generate a recipe for another domain.
IdAwareObject just represents an object that can return its own ID, similarly to RegistryObject. Simplifies some utilities as they can automatically work with ItemObject and FluidObject at no extra cost
Misremembered its purpose
Coloring and luminosity are now handled via a quad transformer, which means we no longer need to duplicate most of face bakery Luminsity specifically is now deprecated in favor of forge's emissivity field.
Method is just a simple helper to build the one quad needed for GUI display, since small tool models in tinkers will want that functionality.
Seems like the type of thing that is going to start coming up frequently
See SlimeKnights#203 Makes it more conssitent with item ingredients and recipe helper
I really hate the mod bus, its so stupid how it breaks in so many ways
Was not used anywhere, and gives me the ability to simplify another task elsewhere
They serve a similar purpose to codecs, except they are optimized towards JSON and the byte buffer rather than being arbitrarily generic, which both makes them easier to build and more efficient in the byte buffer. Basic components: * Loadable: A mapping from any type (primitive or object) to/from JSON and the byte buffer * LoadableField: A loadable with context needed to parse it for a specific object, including a getter for the field, its default value, or if its null * RecordLoadable: Loadable that maps to a JSON object, also implements IGenericLoader so it can be used in loader registries. Typcally created using LoadableField * CollectionLoadable: Loadables for lists and set types In the future, will probably ditch IGenericLoader entirely in favor of GenericLoaderRegistry just storing RecordLoadables, as you can always instantiate that directly for the old method of building loaders.
Includes: * ResourceLocation * Registry loadables for any vanilla registry we might reasonably use, plus helpers to create more * Tag key loadables for common tag types * TagCompound for raw NBT fields * ItemStack and FluidStack (with notably advantages over the recipe helper methods) * Ingredient and FluidIngredient (with the ability to allow or reject empty) * ItemOutput In addition, GenericLoaderRegistry and NamedComponentRegistry both implement loadable so they can be used in other builders
Probably want to rework the predicate stuff to be a bit more streamlined, so holding off on those loaders for now BlockPropertiesPredicate is a weird enough loader that I may just want to leave it as a raw implementation, not sure how to make it generic nor if that will be useful, but will see as I migrate tinkers stuff
Lets you reuse some fields for a shared parent interface for instance, though no efficient way to let you pre-load a record loadable with them
Turns out the format specifier I was using does not work on ints, granted its only needed for six digit Fixed the issue by just adding another abstract method, which is one we want to call elsewhere anyways
Just saves another class creation a this one has all the info needed
We don't have a good migration path for interfaces using this directly so its better to not have the IDE "errors"
Can cause issues if someone is to fetch recipe oututs before tags are loaded.
Turns out some people had tinkers support via JSON on 1.19.2, so might as well keep that working
Same deal as fluid ingredient, help other mods that relied on teh old syntax, though in this case no need to deprecate it. Might want a more general way to do a list or value type field in the future
Means anyone using entity ingredient gets it for free
A few data generators can be trusted as stable and want to set a specific order for readability
Same as NamedComponentRegistry, but for objects implementing IdAwareObject. Simplifies the logic for getKey and removes the name specific register method compared to the NamedComponentRegistry
Allows throwing the proper exception type in the constructor for throwing constructors since fields know whether they are in JSON or buffers (constructors don't)
… mapping the type key Would just use record loadable, but until I ditch IGenericLoader that causes a circular dependency. Will probably just ditch it before 1.19 is over with how much its getting in the way
Also relax thread safety on IdAwareComponentRegistry to just register, no one should be registering things at a time when getting may happen
None of the usages (current nor future) ended up wanting that constraint, so we just ended up passing in object everywhere needlessly. This simplifies usage of the class
Seems that flag got added in 1.19.2, and all enchantments use it as part of their condition. Means reasonably we want it in the can protect condition
Frames may be repeated, so the index both is not a valid index into the sprite and getting the index from the frame data may have duplicates. Use the unique frames stream instead to guarantee unique valid frame indexes.
Want them in Tinkers eventually
Broke for someone trying to setup a workspace by it not being absent. Not sure why it worked for me before, but no harm having it (we notably have it on the 1.20 Mantle branch)
# Conflicts: # gradle.properties # src/main/java/slimeknights/mantle/client/model/util/ModelHelper.java
# Conflicts: # build.gradle # src/main/java/slimeknights/mantle/Mantle.java # src/main/java/slimeknights/mantle/client/ClientEvents.java # src/main/java/slimeknights/mantle/client/model/inventory/ModelItem.java # src/main/java/slimeknights/mantle/data/GenericDataProvider.java # src/main/java/slimeknights/mantle/data/loader/RegistryEntryLoader.java # src/main/java/slimeknights/mantle/data/loader/RegistrySetLoader.java # src/main/java/slimeknights/mantle/data/predicate/block/BlockPropertiesPredicate.java # src/main/java/slimeknights/mantle/data/predicate/block/SetBlockPredicate.java # src/main/java/slimeknights/mantle/data/predicate/block/TagBlockPredicate.java # src/main/java/slimeknights/mantle/data/predicate/damage/DamageSourcePredicate.java # src/main/java/slimeknights/mantle/data/predicate/entity/EntitySetPredicate.java # src/main/java/slimeknights/mantle/data/predicate/entity/HasEnchantmentEntityPredicate.java # src/main/java/slimeknights/mantle/data/predicate/entity/TagEntityPredicate.java # src/main/java/slimeknights/mantle/data/predicate/item/ItemSetPredicate.java # src/main/java/slimeknights/mantle/data/predicate/item/ItemTagPredicate.java # src/main/java/slimeknights/mantle/fluid/texture/FluidTexture.java # src/main/java/slimeknights/mantle/fluid/texture/FluidTextureManager.java # src/main/java/slimeknights/mantle/fluid/tooltip/FluidTooltipHandler.java # src/main/java/slimeknights/mantle/recipe/data/FluidNameIngredient.java # src/main/java/slimeknights/mantle/recipe/helper/ItemOutput.java # src/main/java/slimeknights/mantle/recipe/ingredient/EntityIngredient.java # src/main/java/slimeknights/mantle/recipe/ingredient/FluidIngredient.java # src/main/java/slimeknights/mantle/util/JsonHelper.java
Author
|
Do I need to change something, maybe try with the latest successful build from 2 months ago? |
|
I need to change the git branch. The current 1.20.1 branch is based off of upstream 1.19.2 right now which doesn't compile yet |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixed TC's tanks taking all the fluid of one type even if they can't contain all of it, resulting in a huge waste of resources in some cases