#1.20.2
1 messages · Page 3 of 1
we have? what, methods patched onto other vanilla interfaces are nullable (check bootstap context for example)
So lets discuss this out then, cause I can see your side
From my point of view this is the problem:
What do you do when you do not have th relevant provider / advancement serializer / object returned by added method?
Cause making it "nullable", or have any other state then not being there, means there is a functional behavioural state that has to be defined
But for example with the new condition system, that is not possible
Why would the recipe output expose the provider?
It will literally crash / not work, if you try to serialize / deserialize a recipe or advancement without the lookup provider being present on the recipeoutput in some fashion
Because we needed it to serialize conditions and especially holdersets
So we patched in a method to provide it
Why do you need it to serialize conditions?
And made the only vanilla implemention implement that patched method and return the provider that it has access to
Because they can use it...... It is a codec
There is simply no guarantee that there is not a condition which uses them
Or which uses the registry
Ah
Basically what we did, was make the whole recipe serialization system uses codecs (where possible, mojang does recipe serialization it self still via normal ways, but the new conditions and ingredient system, forge provides now is completely codec based)
And that means that, given that recipes already needed it itself during codec based operations (yes not yet during serialization, because they use custom logic), we needed a way to get that into the saving logic of a finished recipe
So that the conditions could be serialized and tagged on onto the jsonobject if needed
And that means that a lookup needs to be there
And as such
My question becomes:
If we want to keep this binary compatibility such a high priority (a higher priority, then cleaning up the code massively, and even a higher priority then allowing better modding infrastructure). How should we address this?
Might I point out that we yesterdag had this kind of discussion as well, and there it was even decided to crash a vanilla client so that modders could have better infrastructure.
I think it's fine for Forge to make these adjustments to vanilla like we already do for the existing file helper etc
I just don't see the need for a registry ops
Because it is needed for the conditional ops
I am starting to feel like you are not trusting mine or @dull bison judgement on making these changes
how does that need a registryops? 
Because it needs to be properly able to access registry names, etc
If you do a serialization which normally needs a registryops but you do not provide one, then it will serialize either the full object, if it can or throw.
condition testing needs the condition context, and condition de serialization shouldn't touch registry contents, that's the opposite of a condition
Given that we do not know what kind of objects are stored in a ICondition, as discussed yesterday, or for that matter in an Ingredient that can be stored in an ICondition, there is no way to know if it is needed or not.
For all you know, people store HolderSetTypes in conditions, which need them....
?!?
What are you talking about
These are codec based systems now
They can do anything a codec can
Including touching the registry if they need to.........
Makes sense to me. Registryops it is
what about a condition that is based on the existance of a datapack registry object?
a point of conditions is to avoid deserializing when registry contents exist, the condition shouldn't assume existence of an object when deserialized
Yeah but the condition needs to check whether it even exists.........
Yeah you can do it with a name only
and for that that works
This is a recipe system right? I can see how people can do conditions that only makes a recipe exist if an item exist
That is already implemented
But it actually does not use the item
It uses the name
To prevent the lookup
Which is maties point
yes. and that happens when the condition is checked against, not deserialized, i.e outside of the codec?
Yet a condition, can easily do something like a holderset lookup, with an empty check ontop
The lookup of the holderset
Happens in the codec
Which requires the registry ops
But the evaluation if they are empty happens outside
This really feels like, potatoe potatoe discussion
We would like to open up the ability for modders to make more advanced conditions and ingredients
By allowing them the access to the registryops
So that they can make better content, in a codec native way.
This will come eventually, hell even in the next one or two minor versions if I squint my eyes and look at the code a bit funny
At that point there will be a provider in that place exactly
And then there is no way around that
So what is the harm to open up that option to our modders now?
maty the condition is checked in the codec now
this is a matter of perspective. the way I see it a condition is stateless. it's constructed using static data and based on that later checks for the validity of a context. because otherwise the test method becomes the constructor. why not add an item field to itemexists and let the deserialization of the condition fail because the item doesn't exist
Actually the condition is now indeed checked within the codec for recipes
Or better said
Yeah the condition should be checked in the test method, not when deserializing
It is done before the deserialization
But only barely
It works like a dispatch codec now
Where a dispatch codec pulls the type key
And then grabs the codec from that to further deserialize the specific type
This grabs the context and the conditions
And then evaluates them all
If it finds them all being good
Then it invokes the actuall codec to deserialize the target
While if it does not
Then it never invokes the underlying codec
And just returns DataResult with a partial empty optional
Which gets promoted
And the gist for people that can not see it
The big advantage is that making something conditional, is a single line patch
yes, I don't see how that's any relevant to conditions being stateless and being de/serialized with a registryops allowing the constructor to become a test method
The constructor is not a test method.......
It never was........
not but you're allowing it to
The only thing it can do now, is get a value from the registry....
Any value from the registriy
by deserializing with the context that test otherwise gets
Or any combination of values from a registry
test becomes useless
If you are really that paranoid, or worried about it, we can unwrap the ops and get the bare ops if you want
With out any wrapping
And run the conditions list codec on the bare root ops
That way it won't have registry ops access
now you can just throw inside the constructor because you have the context you need and not deal with it. "freedom" that comes at the cost of horrible datagen experience
What are you calling horrible
a constructor throwing
You are going from: Adding a none default method is bad for hypothetical compat, to a constructor which could potentially if done extremely maliciously that will throw, to horrible datagen
that recipeoutput patch is needed because you de/serialize conditions with the context (the registry ops)
Yes, so? We want a nice standardized system. That is easy to understand and use
It is not just conditions which can use this btw
Ingredients and other values as well.......
Granted it is not
Cause they directly use JsonOps
At the moment
But they trivially could
and I'm arguing that by deserializing with the ops you're allowing the constructor to easily become the test method
No
It is still running through a codec
There is no direct way to get the registry contents into a conditions constructor
You have to bend the codec, in a horrible bend, to get it, and additionally that does not give you access to the HolderGetter
Nothing more
Yes you can make it throw
But you could already do that
By simply going to the minecraft server instance
And asking for it there........
So I don't see what the problem is
yes you can?.. write a custom codec and cast the ops to registryops. and to make matters worse registry codecs easily throw. a byname codec throws element not found instead of properly failing. so it's easy and trivial to write improper *_exists conditions as the registry ops allows you to opaquely get registry contents inside the constructor
Yeah but that is not an argument
With the old code, you could also easily do that
It was only by convention that we said not to do it
During the call to fromJson on the old serializer, you can easily ask the registry or the server to get the object or throw before the test
It was simply by agreed upon convention that we did not allow it
Not by any codewise prevention
And that is still possible
the old code was manual deserialization from json? codecs allow you to do byname and not even realise the mistake because it just.. works?
Yes this was all manual
I will give you that it is a tiny bit easier, but you at least need a custom codec, and a direct cast
It is not like you can just call a random codec with byName and then it works
You have to engineer it against the design of the system
If we are really that paranoid, then we should stop modding on java in general..........
And with that I said my last word
If you find it such an attocios chagne
Put it up for a vote along the maintainers
what? no? registryfilecodec, Biome.CODEC
those are idiomatic bynames
conditions should def not be in the codec, they are irrelevant to the object, they are external entirely
from what I can tell it's a throwaway codec to reduce patch surface
while it does look like code smell it's fine-ish™️
I do find its throwaway nature weird because every recipe now creates a new codec which is not free
It is the same as a dispatch codec
The advantage of this approach is that any codec, as long as it supports optional results
can be made conditionally
I'm not talking about the codec itself
I'm talking about the fact that you're creating that new conditionalcodec every single time a recipe is decoded
Yes you are, you are talking about the codec which checks if the conditions are met, and if not cancels the further deserialization
Exactly
Which is a couple of additional objects......
yeah that's my complaint 
the codec class itself I don't care about, I care about the https://github.com/neoforged/Kits/blob/1.20.2/src/main/java/net/minecraftforge/common/crafting/conditions/ICondition.java#L26C32-L26C76 ConditionalOps.createConditionalCodec(codec).codec() call every time a recipe is decoded. yes microptimisations blah blah but it is at least a new useless map for each recipe
Ohh right
That is a compressor holder....
Meh
Forgot about that optimization map that they have there
Yeah spamming creation of codecs is never good - if you have to dynamically create new codecs there's probably a design issue of some sort going on
It is a weighting of functionality
We wanted to be able to make every codecable object optional capable via conditions
For future expansion
I can't see the code in question obviously - but is there a reason the codec can't just be made once ahead of time?
As a bonus that results in a tiny patch if we need to add it to vanilla
the trade of: it creates a map
like this approach works if mojang were to use a dispatch codec for recipe deserialization. but it doesn't, not now. so you can grab the conditions array from the json object manually like mojang does with the type
Yes but I have to assume that most of the created codecs are identical
It requires the target codec that in the end will deserialize it
and when and if mojang makes it a dispatch codec you can throw this system at it
Right but this is being called more than once per any given target codec, right?
If I understand the issue right
basically, mojang doesn't use a disptach codec
Can you not wrap the original codec once and call it a day?
but orion patched it with this which wraps the "dispatch" codec every invocation
Not for recipes, yet
...the heck that's vanilla code?
and I don't see a problem with decoding recipes outside like mojang does with the type
Yes
I guess that makes sense
when mojang makes it a dispatch codec this works
From the code it is very clear that they are rewriting this as we speak
If it is really such an issue
I can make it a recipe dispatch codec
And then it is a single codec
Made once
And then never again
Okay, so, I'd argue that the proper way to do this is to wrap the recipe serializers from the registry, so that each serializer gets wrapper once
At least until it's a dispatch codec
The proper simple fix is to make this a dispatch codec
just do that and make sure it throws the same error
I just realised that it is not that trivial XD
Actually
never mind
i am stupid
And overthinking this
just use this constructor directly https://github.com/Mojang/DataFixerUpper/blob/master/src/main/java/com/mojang/serialization/codecs/KeyDispatchCodec.java#L45 so you can do a custom dataresult error
actually you can use partialdispatch
there's an overload with a custom function returning dataresult
As long as it throws a JsonSyntaxException like vanilla it all should be fine
yeah that's a problem 
or well
ehh
I guess not really, as long as you check the error message
it's fine™️
Not really that hard. mapError with a custom error prefix is the way to go
ah nvm vanilla always throws a jsonsyntaxexception when deserializing recipes
so just make sure it has the same error message (using the partialdispatch overload I mentioned)
Nope sometimes it throws a JsonParseException
public static Codec<Recipe<?>> DISPATCH_CODEC = ResourceLocation.CODEC.dispatch(recipe -> BuiltInRegistries.RECIPE_SERIALIZER.getKey(recipe.getSerializer()), resourceLocation -> BuiltInRegistries.RECIPE_SERIALIZER
.getOptional(resourceLocation)
.orElseThrow(() -> new JsonSyntaxException("Invalid or unsupported recipe type '%s'".formatted(resourceLocation)))
.codec());
This should do the same
Yeah that'll work; doing it in the dispatch is the way to go
Funky stack trace but very easy to catch the exception
Yep
It is literally the exact same execution logic
A bit further down the stack
But it works perfectly fine
way further down the stack probably cause it's DFU fuckery but whatever
remove that getasstring call, it's just uneeded overhead
Oh right XD
I am not sure why Mojang did not patch this first thing they did when they had codecs on serializer
also did anyone tackle the common packets or networking in general? I can look into it tomorrow if not
I am on most of that as we speak 😄
Some of the packet splitter is remaining
And some packets might need to be moved aroun
The biggest problem is currently GUI
well I wanted to discuss some stuff about networking like why the context is wrapped in a supplier and if we still need to do it
and I'm not sure whether the network event as an event is still worth keeping
Feel free to poke at it
We have it al on the open heart surgery right now
So if you think you need to change something
And you have at least a shred of reasoning to improve the api for modders
Then go for it
Same way me and schurli did with the codec stuff
tries to find the disection tools
the hacksaw works too if you don't find it
or a machete
~30 files with errors remaining
- networking
- gui
@mental carbon don't forget to make the codecs final
Optional 
No but seriously:
- I don't understand why the dispatch codec is necessary in any way. Why not check for conditions in the json via the usual static helper?
- Which part of the context is provided via the codec and which via the IContext? It sounds very problematic to have two context sources... The dynamic registries can be part of the IContext
You guys are getting two things twisted....
-
we made it a codec in preparation for when Mojang makes recipes a codec. Every other subsystem in this area of the api is now a codec. Even the recipe itself. Just Mojangs dispatch is not. So it is natural that we create a condition system which works natively with the games own serialization systems, and those are codecs.
-
We added support for registry based ops (of which the condition ops is one of) to the recipe output to make more powerfull codecs possible. Does this open up the possibility of people making a condition to screw up. Sure, is this a massive problem no.
The ability to check for conditions in a json object sounds useful to keep
(can use a codec under the hood that is fine)
Basically this system allows any codec to be prefixed with a condition
Regardless of if it is json or not
It is entirely driven by codecs
You can do conditional mbt if you want
Yes but did you keep a nice helper for JsonObject checking?
We did our best, so yes. The helper takes a codec, ops and a carrier for that ops. So in case of recipe jsons, it takes the newly created dispatch recipe codec, the wrapped Json ops, and the jsonobject for the recipe
And it returns an optional
What if I have a JsonObject and I want to check it for conditions?
As in: "Does it have a condition that prevents me from loading it?"
static <T> Optional<T> getConditionally(Codec<T> codec, DynamicOps<JsonElement> ops, JsonElement element) {
return getWithConditionalCodec(ConditionalOps.createConditionalCodec(codec).codec(), ops, element);
}
static <T> Optional<T> getWithConditionalCodec(Codec<Optional<T>> codec, DynamicOps<JsonElement> ops, JsonElement element) {
return Util.getOrThrow(codec.parse(ops, element).promotePartial((m) -> {}), JsonParseException::new);
}
These are the two methods we provide you with
And then there is this one:
static boolean conditionsMatched(DynamicOps<JsonElement> ops, JsonElement element) {
final Codec<Unit> codec = Codec.unit(Unit.INSTANCE);
return getConditionally(codec, ops, element).isPresent();
}
That just does a pure check
Using a unit codec for the payload
Ah yeah that's good (naming should be present but details)
Why not use conditionsMatched for recipes?
Because we do not need to
We can just get the optional
Which does the decode of the condition, then checks the conditions, and then decodes the object in a single clean patch line without needing to fuss around
The dispatch codec is unnecessary
It is, but it cleans up the one last place were there is direct json reading in the recipe manager
I don't like it, that's all I have to say. Let mojang clean their own code, it's generally not our job
IMHO Forge should set an example as to how to do it right
And this is a very big eye sore
It has been for years
And it should have been the first method they patched when they added the registry based dispatch
Sadly they did not
Surely there's a reason why they didn't do it when refactoring recipes
Although I can't see it because it looks so painfully obvious
You have a point that showing a good example of a dispatch codec is very helpful
So alright then, all good. Sorry I'm tired and wasted 15 min of your time and my time 🙃
It is okey
I mean the point of this today, was to not make it perfect for now
You can clearly see in this code that this is an area that is heavily being worked up on
I know but I dread a temp fix becoming permanent 😄
And it would surprise me to not see this area changed in the next pre1
Hopefully
Yeah that's fine
And realistically I want to pipe the ops through to the recipes as well
They are already there
Just not into the ingredients
I think that would be great to have the full registry ops there
To be able to do recipe ingredients based on for example custom data driven registry entries
Yeah all the stuff is there...
So yes
Some commits are still on the horizon here
Okey so heads up on the condition stuff
I am still designing the decoder to deal with the conditions in the data based registry
I need to recode and retool some stuff to create a pure decoder for it
Mojang stupidly made the method that does the parsing take a decoder
But then when it comes to calling the method
They only pass codecs into the method as decoders
Orion, ya done goofed: https://github.com/neoforged/Kits/commit/9c5b8b1bfa9677d059a210255b02e77e94961e73#diff-7baf4a63471af873e33f0b8df9721b61994a816bfa9a4cbbb72706322196da46R186
(In case you're wondering, I have access because I helped with the 1.20 port)
what happened?
A typo, basically
Where?
You wrote manager.(ConnectionProtocol.LOGIN), it's missing the method name
Yes that is on purpose
I don't know what they method name is
And I got kicked for not pushing yesterday evening
So this is my current state
Ah, ok, don't mind me then 😄
Wir the name missing
As of now I can see 8 files with errors left
The food bar has 6 different textures for empty, half, and full and a version for the hunger effect for each
there are only 2 classes left that are not rendering stuff
- IForgeAdvancementBuilder
- SimpleChannel
I am working on finishing the ForgeGui class
we definitly need to have a discussion about what to do with IForgeGuiGraphics
because a lot of methods it uses are now internal and work differently
also for some reason the condition codecs are registered before the registry
Who is working on what?
I just commented out the custom blitNineSlicedSized methods in IForgeGuiGraphics
I am trying to figure out the advancement builder
But its documentation is severely lacking.....
I think the concept "canBuild" is gone
it is checking if the parent exists before creating
Yeah i realise that
While I was working on that I decided to remove the FPS part of FPS_GRAPH since it now shows either the network or fps graph
And I didn't have to make more fields protected that time
Ah I think I figured out a patch for this
12 compile errors left
of ffs AbstractSelectionList is not a Widget
Fixed the advancement builder
Okey
I am going to tkae a look at simplechannel
Simple channel fixed
UnicodeGlyph button fixed
@tranquil salmon or @dull bison what are you working on ?
I have 2 files remaining on my system
I have 1 file remaining
Who is doing ForgeSlider?
not me
not me either
I will take care of it then
It is a simple render call 😄
Okey all errors fixed
Compiling
push 
push
I edited the build.gradle in a commit a couple days ago that removes the uuid argument
@mental carbon
@mental carbon I did the dispatchUnsafe stuff
@mental carbon Fixed scrolling downwards
we need to fix the patch for conditions in datapack registries
in datapack reg stuff the conditions key is "forge:conditions" not "conditions"
Mods for 1.20.1 will be working?
hmmm Unknown registry key in ResourceKey[minecraft:root / minecraft:condition_codecs]: forge:mod_loaded
why is that registry under mc
Missing registration?
I'm checking
Will it be possible to test this version?
Not untill it is released
It's a pity, but I hope I don't have to rewrite all my mods
Did anyone of you have luck with the escape button?
net/minecraftforge/common/crafting/conditions/ConditionalOps.java:187 returns an errored dataresult
the ops is the ConditionalOps and the codec is the ContextRetrievalCodec
Not a JSON object: [{"type":"forge:mod_loaded","modid":"not_forge"}] is the error in the dataresult
question is why is it even trying to parse that object since we already have the parsed conditions at that point
No clue
Were you getting the BootstrapMethodError?
@mental carbon
So it's exclusive to eclipse then
It doesn't like the lambda here: https://github.com/neoforged/Kits/blob/1.20.2/src/main/java/net/minecraftforge/network/NetworkEvent.java#L195
Invalid receiver type class java.lang.Object; not a subtype of implementation type interface net.minecraftforge.network.INetworkDirection
the experiments screen is broken
Seems like there was a patch to ecj for it in june here https://github.com/eclipse-jdt/eclipse.jdt.core/commit/0b6a65a66ed4ae0b3771e50662bdaa5f76ce7036 but hasn't been released yet
also worth noting the next eclipse release is in a couple days
the escape issue also affects e with the inventory but only inside the game
escape works in the world creation screen
creative inv background is broken
creative tab sorting should be validated (I had issues since it became a registry)
did it become a registry this update?
no I think that was 1.20
WTF
well the test mod pushes tabs between vanilla https://github.com/neoforged/NeoForge/blob/1.20.x/src/test/java/net/minecraftforge/debug/CreativeModeTabTest.java
then this is the only issue in the creative inv
tfw useless supplier
So the escape key seems to be being processed both when you press it and release it
Aha
if it is useless nuke it
Fixed the issue
the escape one?
nICE!
They created a commit to fix it in june here: https://github.com/eclipse-jdt/eclipse.jdt.core/commit/0b6a65a66ed4ae0b3771e50662bdaa5f76ce7036
that commit was created about a week after a release and the next release is in a couple days
Also there are no advancements
I want to get rid of the generic mess in channels (bifunction and tobooleanbifunction and all that crap) and make them their own FIs. but i'm
ing on whether FIs should still have the I prefix
my take on that is no I for FIs
Isn't https://github.com/neoforged/Kits/blob/1.20.2/projects/forge/src/main/java/net/minecraft/advancements/Advancement.java#L93 meant to return null when conditions aren't matched instead of when they are?
Yes, unless it got redesigned
question: is the Forge API gonna be seperate now?
No
#1136320550168436798 message <@&1067092163520909374> and we are in world. most stuff is working
This doesn't look like an iron sword
For each item added to a crafting table you get a random item in the output slot
something something the pen is mighter than the sword
ezpz
Ingredient match
only 14 files changed to get rid of the context suppliers 
Also it seems like animals follow you even if you aren't holding anything
Yeah that is all tied to ingredients
So we need to look into what gets send around
yup
Allthough not the anymimals
nice recipe
@mental carbon Is the 2nd part of this or meant to be true if one or more item stacks are empty or all are empty
https://github.com/neoforged/Kits/blob/1.20.2/projects/forge/src/main/java/net/minecraft/world/item/crafting/Ingredient.java#L146
Currently it's true if none of the item stacks are empty
That should indeed be allMatch
Actually
I don't know
The way getItems() works is that it returns a list of itemstacks
It might need to be allMatch
But i am not 100% on that
Finally 😩
?
the loot tables becoming codecs made adding conditions to loot tables much easier 
datagenning loot tables with conditions on the other hand
that's going to be fun
fun for another time 
You should also make the pools conditional for extra fun
so how are loot tables done now? still with a JSON?
So can I now get a thank you....... Cause yesterday evening you sounded completly oposed to this path 😄
I still oppose to deserializing conditions with registry access 
I know
But you have to give it to the solution with the codec
It is very nice to just tag the codec on to an existing codec, and bamn now you have a conditional codec
ForgeExtraCodecs
Has most of them
Unless it is related to conditional ops
Then they are in the ConditionalOps class or in the ICondition interface
That was a fast port 👀
Well
It was however a rather complicated one
And we are not done yet
We have issues with some networking ,. especially on dedicated servers, and with recipes still
wth Map entry '#' : No key tag in MapLike[{"type":"forge:intersection","children":[{"tag":"minecraft:planks"},{"tag":"minecraft:non_flammable_wood"}]}]; No key item in MapLike[{"type":"forge:intersection","children":[{"tag":"minecraft:planks"},{"tag":"minecraft:non_flammable_wood"}]}]; Not a json array: {"type":"forge:intersection","children":[{"tag":"minecraft:planks"},{"tag":"minecraft:non_flammable_wood"}]}
much codec

when you put your portal in the hydrolic press
time to dive into networking
maty is gonna implement the config phase 👀
wish me luck, I'll hate this
good luck, let me send people back into config phase
what is broken with networking?
or are you speaking of nuking the supplier
@fallow sundial Please donÄt
I am currently trying to fix an issue with with packets received by the server having the wrong channel id
don't what 
also requiresFullSynchronization being inside the ingredient type is limiting. stuff like compound ingredients would need that to be dynamic based on the subingreidnets
Yeah, you are right
I need to refactor that again later today
Will clean that up
well I was in the process of doing it
Ah then please go ahead
Don't let me stop you 😄
If you can fix the bug with the network on a dedicated server
Then please fix that as well
Somehow the resource name in the payload is weird
And is empty

also may I ask why did you choose to have the ingredient know its type instead of having it override codec() (as is tradition with all mojang registry codecs)
it means you can't inherit from custom ingredients unless that ingredient also exposes a constructor with a type
which is.. funky
Because ingredients have 2 codecs
And anything with more then just a simple codec, has historically had a type
door rendering is borked
Is that the same issue as with the end-portal, maybe?
could be looks like broken face culling
Weirdly, it looks like that did not update with respects to the changed blockstate.....
I mean yeah, but it having a reference to its type is unneeded, when you can just do
it culls any side that is at the edge of the block
Yet, we don't really do that anywhere....... So........
I don't see a reason to start here.....
The codec for a recipe is not on the recipe
it is on the serializer
The exceptions to that mechanic, is actually stuff like our conditions
Which have the codec() directly on them
And maybe datadriven registries
yes? the entirety of worldgen
basically all codec registries
Yeah but these are not codec registries......
it's a registry of a record of two codecs, the amount of codecs doesn't change the fact that it's a codec registry
Does it matter?
Like you have been nitpicking about this kind of stuff over the last few days
^

Might I ask you, to for now, focus your energy on something like actually fixing some bugs that we still have
We can discuss the changes then later in the actuall review
¯_(ツ)_/¯
Issues:
Rendering
- Blocks with broken face culling:
- Cauldron
- Doors
- Fence Gates
- Flower Pot
- Repeater
- Comparator
- Enchanting Table
- End Portal Frame
- Campfire & Soul Campfire
- End Rod
- Jack o'Lantern
- Sculk Sensor & Calibrated Sculk Sensor
- Sculk Catalyst
- Stained Glass Panes are opaque
Chests are not placeable
Can we put this somewhere were we can edit this?
Like a HackMD
This sounds like some shape comparison issue in Block.shouldRenderFace() to me since it seems to specifically affect non-full faces. At a glance I can't see any issue in that method itself though
Cause we still have some network issues to figure out
is it chests specifically or is it any block item
Are you running normal forgedev or with test mods?
it culls all faces that touch the edge of the block
also can someone get me a 1.20.1 world zip
Yes, but judging from the block list only those ones that don't occupy the whole area of the face, otherwise I would expect the whole world to be "empty"
nope for the door you only see the face on the inside of the block all others are culled (even the full ones)
Hmm, ok, that could be caused a similar way. I'll have to dig a bit when I'm home, I have a few ideas
Btw, Schurli ^
with test mods
Try running without them, there's a dumbass test mod that conditionally cancels chest placement 
👌
the chest or the rendering?
why did orion ask me to create one then?
I can edit but I am not in the team
hmm
now I am
everyone that finds an issue pls add it to the document
if you work on something mark it in the document
when you fix an issue mark it as such in the document
unpowered do?
yes
With or without test mods?
without
u can't binary search this, right?
same thing with redstone ore
yup sea lantern and glowstone
someone pr to invert that condition 
so we have 2 different problems here the culling and the not rendering of light emitting full blocks
so that placing chest doesn't work against diamond blocks 
I wonder if tesselating without AO is broken in general
same for froglights
can you even disable ao in the settings menu
No, only smooth lighting
nice
isn't ambient occlusion needed for blocks like cactus?
heh I was right
tesselatew/oAO is indeeded broken
and I also know why
let's see if this fixes it
let's see

?
What was it?
That whole area was a cluster fuck
The patcher layered 3 patches there over each other
I likely fucked something up trying to untangle it
Nice catch!
my fix probably fixed face culling
yep
stained glass panes are fine on my end
berries are broken too
I only get damage once when entering them
and every time I move
but not if I stand still
that is normal vanilla behaviour
is it? 
Yep. It checks for if entity has velocity.
preferably one with an entity that has an effect
okay so I can make the datafixer take the forge WSD into account
but it's going to be ugly 
datafixer are always ugly
fair point
WSD?
because otherwise you can't update a forge world with custom mob effects
or well you can but all effects disappear
Why are custom effects stored in SD?, when they are already hardcoded on the entities/itemstacks additionally?
this isn't that bad actually 
name to id mappings are saved in the forge WSD because of the saving feature of forge registries that exists because of mob effects?
Aaah so the forge reg data is stored in there?
yes
There is one fly in the ointment though: DFU can not access a registry
So you would need to figure out a way to get that information in there....
IMHO It might be worth it to figure out if the existing DFU Fixer for the mob effects can be redirected to read the Forge field
Instead of trying to shoe horn this system into it
Cause I am pretty sure we write the full name already
vanilla blocks all work some of the testmod blocks need fixing
we do but it's not enough
we don't patch beacons to use the name
But then you are out of luck anyway are you not?
Given that you have no idea what the id is supposed to be?
There might be an argument to be had here
To say: well we can introduce a hardcut here, or at least a softcut on custom beacon effects
Cause I do not think it is a good idea to read in the entire registry in DFU
The point of DFU is that it is completely independent of the registry
actually, serverlifecyclehooks#getcurrentserver works fine during block/entity fixing. it's player and item fixing that doesn't have the server available
and both of those are patched in forge to have the name written
Not really
The problem is that they all use codecs now to deal with effect list
We could patch in here
no no we don't need to patch that
But that is just creating TechDebt
for entities and stews we can redirect to the forge field
yes
and for beacons we can attempt to get a mapping from the current registry because those have been filled with the old ID by the time the fix runs
it's just players specifically (and their inventory) being annoying to deal with as those are stored in the level.dat so there's no server when they're fixed
but chunks (blocks and entities) are on-demand after a server was created
@lean warren smol request if you have time. write me a mod registering like 10 effects in a random order, load it up in 1.20.1, give the effect to a cow, a player, and a beacon (I'll run this as a class in forgedev so you're fine to patch VALID_EFFECTS in the beacon BE), and make a suspicious stew out of it and put it in a chest
I really don't like these kinds of fixes
do we even need to fix this
it's not the first time that modded saves have lost data due to DFU
yes but that's because it's not feasible to have everyone provide a datafixer for their BE
in this case however it's up to neo, and we can fix it
The amount of data loss is negligible
Or even been broken by it entirely (looks at 1.18.2)
There might be an argument to say:
Well we do not fix this
We did not do for 1.18.2
Or any of the other 100 things that mojang broke
that's a stupid argument, if we let worlds be broken before it means we can't do better this time?
We decided not to handle this, doing so allowed us to remove all the code related to persisting registry ids to disk. A 3d party mod could be made to help players who do have a world they wish to upgrade, upgrade but I doubt anyone will actually care tbh.
Im happy to be proven wrong tho 😄
@fallow sundial How many other places still use the int ids for on disk storage?
Is it only the chunk palette
Once it reaches a certain size?
wdym? In 1.20.2 nowhere
Okey
Then I would argue against fixing this
And removing all the code that provides that API functionality
see my registry rework
Yeah I thought yo
it still needs some work but it's mostly there
But did you check the chunk palette
That had previously still a mode were if it exceeded a specific size it fell back to the global registry map
I posted like 2 TODOs it still needs earlier in this thread
The branch is on my GitHub fork of neoforge if anyone wants to use it
I'd argue you could do a branch on the Kits repo that is rebased on 1.20.2 already
See PalettedContainer#Strategy
Which if the palette exceeds 8 bits
it will use the global registry and its int ids
WHich means they still are needed and need to be written to disk
Cause in a modded world it is actually possible to get more then 256 blockstates in a chunk
However I would argue that the HashMap strategy should be extended to cover more bit sizes
Maybe even the linear one as well
That sounds wrong
But my point with respect to the palette and its size still stands
But that is not wrong
I researched this area of the code extensively for C&B
And ran into this snag
@pine ember that's concerning if it's true
If you have more 2^8 different states in your chunk, the palette on disk will be empty
See the GlobalPalette
And then it will pull from the IdMapper for the blockstate map
(can someone look over that code again btw, there's a chance I might have inversed parameters or something, a second pair of eyes doesn't hurt)
This is normally not a problem in Vanilla
Given that the amount of blockstates is sufficiently low
And especially important: always in the same order
New blocks are always at the end
So this rarely happens
But I think if you cram a debug world in a single chunk you can still trigger it
Regardless
We havent saved block ids to disk for a long time now.
This is about blockstate IDs though and not block IDs
Which are tied to each other!
Especially on forge
Yes, my point is that block IDs have indeed not been an issue for a while (at least from what I know) while the state IDs have due to the palette thing you just mentioned
Yep :d
Block ids are as such only implicitly a problem
Since they determine the order in the block state map
so is it just transparent blocks whose culling is broken?
that's already fixed
And that means that the id map that is used is and will be different between two launches with different mods
Yeah but it instantly breaks in the same situation
Remove a mod
And all blockstates are broken
If you have more then the 256 different blockstates in that chunk
Granted that is a big if
But in a modded world with 200 mods that is not unthinkable
yeah, I wasn't aware of that 🤔
Is it 256 in the section (thats 161616 if im correct?) or 256 in the whole chunk?
Whole chunk
Ill need to take a look into this later.
Palettes are defined on a chunk level
not on the section if I remember properly
No it seems to be on the section now
That would make it significantly harder
But not really impossible
Sections are 4096 blockstates in size
1.20.1 has it per section as well
That is still much larger then the 256 but still
I wonder why they did this this way
So yeah, I think this could be an issue for us. But its not a new issue.
They must have realised that they could easily make an optimal palette using logarithmic growth
Which could cover any size they or us would need
Where is this snippet from? Considering it's a static initializer, it's most likely irrelevant to modded blocks (doesn't change anything about the issue though)
Blocks.java
palletes suck. When generating dimensions in code. It breaks them on join and you have to mixin into the pallete getter to return zero when it wants to return -1.
Forge replaces the IdMap with a registry link
But that registry link does exactly the same thing
FFS MOJANK they changed blockstate and model datagen again
Ah, does Forge replace that static block with the rebuildCache() method?
Yeah
🤷♀️ it's not like they could have made it any less comprehensible
I am going to take a look at this later
There's a reason I made all my own stuff for blockstate and model generation for Excavated Variants instead of trying to bundle the vanilla stuff up nicely
exactly
The eventual plan was unification to forge:conditions instead of the raw conditions to avoid potential name collisions
yeah conditions is intrusive as people can't use it for their own codecs
Yeah, would be nice to unify everything
we can change it to forge: and use conditions for datapack backwards compat based on the pack version
We could give the codec the option to check more then one key
writing ingredient with codec produces the wrong output ... it should be flat with the type but it is nested in a value
like, it's doing this? ```json
{
"type": "thing",
"value": {
"field": "etc"
}
}
dispatch codecs have a trap you have to watch out for
trying to remember exactly what causes it...
there's a bit that checks if x instanceof MapCodecCodec
yeah, each subcodec must be a MapCodecCodec
err, it doesn't have to be, but if it's not, it serializes ala the above format
now, how do you make a MapCodecCodec? there's two main ways:
- all codecs produced by RecordCodecBuilder are MCCs
- fieldOf("name").codec() produces a MCC
important bit: xmap does not produce an mcc
if you're using fieldof to make a single-field codec, you have to xmap first, then codec()
public static record IntHolder(int n)
{
public static final Codec<IntHolder> WRONG = Codec.INT.fieldOf("n").codec().xmap(IntHolder::new, IntHolder::n);
public static final Codec<IntHolder> RIGHT = Codec.INT.fieldOf("n").xmap(IntHolder::new, IntHolder::n).codec();
}
yea Codec#either fucks that up
Basically, xmap your MapCodec not your Codec and it'll all be happy. That particular bit of weirdness has been a real pain for me
it shouldn't 
I know that but I can't do either with a mcc and a normal codec
It will if you do it after the map codec step
err where are you using the either
are you using the either for one of the dispatcher's subcodecs or is the dispatch codec one of the two eithered codecs
both actually
I guess only the former would actually cause this problem, so let's consider that one
what two formats are you trying to let this subcodec have
if you only have one field but you can interpret the value two different ways, then that's easily done:
eitherCodec.fieldOf("etc").xmap(to, from).codec();
problem is the either is outside of the .codec() call
can you just show what you have then
public static final Codec<CompoundIngredient> CODEC = ExtraCodecs.withAlternative(
Ingredient.CODEC_LIST.fieldOf("children").codec(),
ExtraCodecs.withAlternative(
Ingredient.CODEC_LIST.fieldOf("ingredients").codec(),
Ingredient.CODEC_LIST
)
).xmap(CompoundIngredient::new, CompoundIngredient::getChildren);
Created Gist at the request of @kindred fractal: https://gist.github.com/NeoCamelot/04bdb8e9c5b223ba15671cb49424c346
Ok that's a cool feature ^^
okay, just to be clear, these are the three json formats it can have? ```json
"ingredient": {
"type": "forge:compound",
"children": []
}
"ingredient": {
"type": "forge:compound",
"ingredients": []
}
"ingredient": []
yes
okay, there's two things wrong here
firstly that third one cannot be part of the dispatch codec
orion I think we can not use the compound ingredient through the dispatch but need to use an outer either
secondly, for the first two, I would either drop one of them, or give them two different subcodecs (two different type ids)
the third one cannot be done via dispatch subcodec but it can be done via the outer either, yeah
no type field = can't be a dispatch subcodec
I know how to do it without the third
is the third a vanilla format? or is that something forge adds
if it's not a vanilla ingredient format then IMO drop it and make people use the explicit type
orion we need to fix ingredients with a list of values (reading works but writing errors)
Okey I will tackle it tomorrow morning asap
Somebody else then needs to deal with the networking issue on dedicated servers
I will check the testmod rendering things
Me personally I don't think I have enough time to do that right now
Plus the reg refactor has to be rebased on DH
well that still needs to be merged which means reviewed if not already
@muted hemlock @dull bison You should be able to use Codec.mapEither to make a MapCodec that works like either, right?
I think it'd solve the problem though?
Oh, except for that direct list one, which needs t ogo outside of the delegate codec anyways
But the other part can be Codec.mapEither(Ingredient.CODEC_LIST.fieldOf("children"), Ingredient.CODEC_LIST.fieldOf("ingredients")).xmap(...whatever...).codec()
But yeah that third one makes no sense because you kinda have to specify a type key in order to delegate
I am already using mapEither but as you said it doesn't work for tge list one which actually is a vanilla feature ... for reading it has a fallback but for writing it errors
I think I fixed ingredients (I hope so) and I am currently working on forges loot table provider
I think we are ready to cleanup and gen patches and then switch to pre2
Test the dedicated server
I got that fixed hold on
I expected
that "I" doesn't fit
?
Pushed btw
wtf a unicode char as packet name
it's an answer packet
Snapshot?
<@&1067092163520909374> https://www.minecraft.net/en-us/article/minecraft-1-20-2-pre-release-3
Yeah but why is it decoded so weirdly
Ooh they fixed something with records?
Greg (I think it was?) pr'd to Proguard a fix for empty records having metadata stripped
Ah, nice
It was based on an issue Jas (VF) raised to them
Ah Gegy, https://github.com/Guardsquare/proguard-core/pull/118, my appologies 
It's not even 2am yet in nz
greg 
we are reading the resource location too early there is another var int in there before it
Had the name in my mind, likely from the meme/spam that was posted in general earlier

hoglins can now be bread
hoglins can now what?
it still concerns me how they broke that
🥖
I would hand it out but the last time I did it gave access to some back channels 
hehe
yeah, I know 
but why 
#builds I was wondering why it hadn't sent a message when I checked turns out I just had to wait a bit longer
I apply for the role the moment it doesnt give back channels :p
same
especially if it means I will never have to navigate the minecraft site because I do not know how to use that
Can you hop into a call?
Cause I was sure I checked that
the erroring packet is:
id: 2
transactionId: 1
payloadPresent: true
packetIndex: 1
id: fml:loginwrapper
#builds perfect 
I know what we are missing ... we are not using readNullable
CompoundTag patch didn't apply
Yeah I know that
fixed
at least this issue is fixed now
yes because that writes a boolean
Oef
I'm on the server
Nice so
pushed
Okey
So that was the last issue if I remember
So I will go through and create the patches
AKA do the cleanup
Attempted to update the CompoundTag patch from mobile
nice
Wait, how did you even know what to change?
1.20.2-pre2 to 1.20.2-pre3 diff
ah
https://gist.github.com/marchermans/65300b65387addeb13eaa74cfc8a7093#file-gistfile1-txt-L199-L449 @dull bison
#builds
Nice
what's this gonna be? I was wondering, but there is nothing there rn
the same as under MinecraftForge but without lex
Srg2Source is a source code remapping tool
interesting
so eventbus is bus now? that's it?
we have an action for creating hard forks including tags
then delete it and re fork it
and give me push access so I can push the neoify commit
what changed?
so it looks like they are ramping down and doing polishing phase? which means maybe rc1 tomorrow/thursday and 1.120.2 next tuesday maybe?
did they finish the stuff they were working on in rc1?
I meant pre1 xD
can't remember what they were doing in pre1 so I'll leave that to the porters
sum codec stuff
I don't think they have made any more code structure changes in pre3, only bugfixing
ok
@dull bison Did some body run the action for you?
nope
I still need push access

