#1.21.4 Snapshots
2129 messages · Page 3 of 3 (latest)
Two things stand out as incorrect:
ItemModels don't wholesale replace custom loaders for items, they are just a better option in certain circumstancesExtendedUnbakedModeldoesn't declare the enhanced bake method, it only turns the delegation around so that implementors only have to implement the enhanced one and not the vanilla one. The method is declared inIUnbakedModelExtension
Fabric will likely add a similar system soon, if I get to it soon enough and the next snapshot doesn't refactor everything again
Patches done. One thing we still need to find a good way to reintroduce is IItemExtension#shouldCauseReequipAnimation(), which is a bit of a pain due to the similar but severely less powerful vanilla feature in ClientItem.Properties
What's less powerful about vanilla's?
It only supports playing the reequip animation either always or never (including on slot change). Particularly the detail about the flag disabling the animation on slot change (i.e. scrolling) makes it subpar (this is ignoring the fact that the feature is entirely broken anyway as the animation is still played, the only difference is that the rendered stack is swapped immediately instead of at the low end of the animation - yes, I validated this with an RP in vanilla 21.4 RC3
).
Video of the issue (slowed down to make it more obvious). The paper item has the flag set for disabling the animation via a resource pack.
To be frank, I'm really not sure how this feature is useful
Items who data changes constantly don’t keep bobbing like mad
Except that's not what the vanilla flag achieves (our hook which is currently broken does and I'm using it for that myself) because it applies to any case where the target item is the one specifying the flag in its model
Thonk
Uhhhh
I guess the cleanest solution will be to (a) patch the vanilla bug and (b) replace all checks of the property with our extension which by default delegates to the property?
Yeah, just deciding how exactly to inject the hook is the slightly painful part, particularly because ClientHooks.shouldCauseReequipAnimation() currently does a few additional checks before calling the item extension and may make the vanilla flag no-op for certain cases, so it might need some careful adjustments as well
@royal solar while updating FramedBlocks to the latest version of the port I noticed a flaw in your model loader solution: if a custom loader tries to deserialize a nested model, it can only deserialize BlockModels but not UnbakedModels which makes nesting custom loaders impossible (unless you take the JsonObject representing the nested model, convert it to stringified JSON and put that through UnbakedModelParser.parse() with a StringReader, which is ridiculous). We need to either add an overload of UnbakedModelParser.parse() that takes a JsonObject or go back to the type adapter
is this not a vanilla bug
i dont think this is intended
is there a mojira issue on it
That link is broken for me on github
Ah found the patch
That seems fine could be a broken patch
Unsure
Hmmm that's annoying. I didn't know that people were nesting models like that 😄
I'll add an overload I think it's the best option
Ah I just noticed that we need to parse the Transformation in obj loader
Not sure what is best then
The issue with the hand swap animation seems to be due to the attackStrengthTicker in Player
@royal solar I used the TypeAdapter / JsonDeserializer API to solve the issues with respect to how UnbakedModels are handled when they are declared on an inner level, you can work around that by patching the BlockModel parser, but it was an ugly patch.
I personally think the TypeOf parameters and the fact that you have to use a JsonElement initially are not really a problem at all..... But I guess opinions can vary about it and since the parser when I implemented it only used the interface as a delegate target replacing it would have been pretty easy.
I don't think it's a bad idea, the main problem was that typeOfT is always UnbakedModel so it was a bit pointless + JsonElement as you said
So I reintroduced an interface with a T read(JsonObject, JsonDeserializationContext) method
But now I changed it to read(JsonObject) and if you need to deserialize a vanilla type you use BlockModel.GSON directly... And I'm having second thoughts about this
At least with a custom interface we get the chance to document things a bit more which is always nice
I added back the JsonDeserializerContext parameter but did move everything to vanilla's Gson
the patch is still quite short
it's squashing time now
porting PR is up: https://github.com/neoforged/NeoForge/pull/1724
I'd appreciate it if some folks could test the PR publication with both MDG and NG MDKs to make sure everything works 🙂
datagen seems broken
or well
not fully ran 
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: src/generated/resources/pack.mcmeta
yeah I forgot to rerun it in rc3 and the pack version changed I think
oh i see the port pr is now a thing
i assume that means a all the model reworking and such is done?
time to port my condition builder pr & vanilla data gen prs to 21.4
have been waiting for the model api changes to finalize before porting the data gen pr
as for the condition builder encouragement pr
should i update the main pr to 21.4 or open a new one
(would it be merged into 21.3 at some point?)
I don't see a reason to deviate from the usual policy
so in any case it would have to be merged in 21.4 first
I don't think that backporting to 21.3 brings any value... after all, modders who are on 21.3 should be quick to update 😛
il push to the main pr then and rebase that for 21.4
https://github.com/neoforged/NeoForge/pull/1716
updated to 21.4 gonna go through and remove all the deprecations i made now
Can you merge my PR into yours for the model datagen before updating it? Otherwise that's going to be a real pain to update 
yeah can do, tbh tho i was maybe just gonna start that one over on 21.4
not seen alot of the changes yet tho
just assumed yall changed model stuff that much
would be easier to just start over
That's true, yeah.
am i blind or did mojang remove the skipAutoItemBlock feature from BlockModelGenerators in 21.4?
that means any block model/state generated using the vanilla provider
will always generate a matching item model now
i mean my test block just does
blockModels.createTrivialCube(block.value());
which as far as i can see just generates rhe block model and block state
but yet it has a item model too
ah no i see model copying is now a thing instead
ModelProvider.ItemInfoCollector.copy
unless thats invoked for a given block item
a plain generic model will be generated
which means its less of a "skip this item" more of a "copy this other model" instead
One important detail is also that they switched from iterating the block registry and checking Item.BY_BLOCK (which would for example return the torch item for a wall torch block) to iterating the item registry and checking instanceof BlockItem which avoids finding an item for a block that doesn't actually have a dedicated item
well anyways thats the provider made accessible for modded usage
just now needs any additional changes to support our model extensions
and building a model from scratch
One thing that might be nice is to make ModelProvider.ItemInfoCollector#register() public and pull it up into ItemModelOutput to allow mods to specify non-default ClientItem.Properties (it's only a single flag at the moment, but still)
https://github.com/neoforged/NeoForge/pull/1725
model provider & equipment asset provider have been exposed for modded usage
model generation may still require more patches to support our model extensions
and generating models from scratch
<@&1067092163520909374>
ono

oooooo
Changelog: https://www.minecraft.net/en-us/article/minecraft-java-edition-1-21-4
SnowMan: https://github.com/neoforged/Snowman/commit/be37b7ee3d3eab6bf564eb1c58e95fc22e086e18
Primer (WIP): https://github.com/ChampionAsh5357/neoforged-github/blob/64c5067bde9c39c6ad6c2324c37312e0c9c53d6a/primers/1.21.4/index.md
-# Changes: https://github.com/neoforged/.github/pull/10/files
Slicedlimes Videos:
- Main: https://www.youtube.com/watch?v=9KdklKRY2oQ
- Data/Resource Pack Changes: https://www.youtube.com/watch?v=6K1QzvJx1IE
The Garden Awakens Drop is Minecraft 1.21.4 with the Pale Garden, Pale Wood, the Creaking, Eyeblossoms, Resin and many more features and improvements. Here's a a comprehensive guide to all the news! #minecraftemployee
This guide was made for Minecraft Java Edition. Many new features and some smaller changes also apply to Bedrock Edition.
slice...
uh thanks??
New version detected: 1.21.4.
WOAH
ok just waiting for neoform 😄
Mostly likely for content creators / players who want to immediately explore the new content (and haven't been keeping up with the snapshots)
added snowman and slicedlime video links to pin
nah it says Future Update not Future Hotfix
Yep, likely next release cycle stuff
Recipe minecraft:mangrove_chest_boat can't be placed due to empty ingredients and will be ignored
Is this normal?
we probably messed up something in the item->tag replacement
soooooooooooo
when will @junior epoch close this thread?
/jk
please open an issue
ok
Amint az első stabil verziója a neofotge-nak kijön
not yet, we're still using it
ah ja, ik snap hem
~~not like it stopped him before
~~
looks like it's all the neoforge:difference replacements
closed, a new branch was created for 1.21.3 and the PR was merged to .x
@thin dawn is this correct in NG, at a glance?
Is clientData a runtype in the userdev? then no
simply change the outer data block to clientData
as a name
By default it infers from the name
If the name should stay "data" then yeah
That is the way to do it
But that is not what I would recommend
What existed previously still works. The only issues are that the CompositeModelBuilder currently disagrees with the respective loader and the new ItemModel system is not supported by Neo's custom model generators. We're still experimenting with nuking the custom providers entirely and instead patching the necessary functionality into the vanilla providers
As depending on the convention setup of the user, it will generate a clientData then anyway
ok better to change the name to clientData then
Yep
That is what I would do
Because it matches more with the way runs are supposed to be used
The example you show there is for advanced users that want to have custom runs with custom functionality and names
Basically:
runs {
clientData {
}
}
``` should suffice
If the user does not have any runs configured, but uses conventions, which most do, then it will be named clientData automatically
alright
https://github.com/neoforged/NeoForge/issues/1641 is this bug fixed?