#1.20.2

1 messages · Page 3 of 1

mental carbon
#

Cause else we need to always check if we have a vanilla recipe outputs

#

That can return that data

#

Which is completely unreasonable

fallow sundial
#

we have? what, methods patched onto other vanilla interfaces are nullable (check bootstap context for example)

mental carbon
#

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

kindred fractal
#

Why would the recipe output expose the provider?

mental carbon
#

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

kindred fractal
#

Why do you need it to serialize conditions?

mental carbon
#

And made the only vanilla implemention implement that patched method and return the provider that it has access to

mental carbon
#

There is simply no guarantee that there is not a condition which uses them

#

Or which uses the registry

kindred fractal
#

Ah

mental carbon
#

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.

kindred fractal
#

I think it's fine for Forge to make these adjustments to vanilla like we already do for the existing file helper etc

fallow sundial
#

I just don't see the need for a registry ops

mental carbon
#

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

fallow sundial
mental carbon
#

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.

fallow sundial
#

condition testing needs the condition context, and condition de serialization shouldn't touch registry contents, that's the opposite of a condition

mental carbon
#

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.........

jagged agate
#

Makes sense to me. Registryops it is

dull bison
mental carbon
#

Or a none_registry object like "item_exists"

#

.......

fallow sundial
#

a point of conditions is to avoid deserializing when registry contents exist, the condition shouldn't assume existence of an object when deserialized

mental carbon
#

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

jagged agate
#

This is a recipe system right? I can see how people can do conditions that only makes a recipe exist if an item exist

mental carbon
#

That is already implemented

#

But it actually does not use the item

#

It uses the name

#

To prevent the lookup

#

Which is maties point

fallow sundial
mental carbon
#

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?

dull bison
#

maty the condition is checked in the codec now

fallow sundial
#

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

mental carbon
#

Actually the condition is now indeed checked within the codec for recipes

#

Or better said

kindred fractal
#

Yeah the condition should be checked in the test method, not when deserializing

mental carbon
#

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

fallow sundial
#

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

mental carbon
#

It never was........

fallow sundial
#

not but you're allowing it to

mental carbon
#

The only thing it can do now, is get a value from the registry....

#

Any value from the registriy

fallow sundial
#

by deserializing with the context that test otherwise gets

mental carbon
#

Or any combination of values from a registry

fallow sundial
#

test becomes useless

mental carbon
#

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

fallow sundial
#

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

mental carbon
#

What are you calling horrible

fallow sundial
#

a constructor throwing

mental carbon
#

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

fallow sundial
#

that recipeoutput patch is needed because you de/serialize conditions with the context (the registry ops)

mental carbon
#

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

fallow sundial
mental carbon
#

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

fallow sundial
#

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

mental carbon
#

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

fallow sundial
mental carbon
#

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

fallow sundial
mental carbon
#

You are rightz

#

holdergetter.get(...) will throw

#

That is sad

fallow sundial
#

those are idiomatic bynames

mental carbon
#

I noted your discontent with the change

#

And I will think about it

quiet talon
#

conditions should def not be in the codec, they are irrelevant to the object, they are external entirely

fallow sundial
#

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

mental carbon
#

The advantage of this approach is that any codec, as long as it supports optional results

#

can be made conditionally

fallow sundial
#

I'm talking about the fact that you're creating that new conditionalcodec every single time a recipe is decoded

mental carbon
#

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......

fallow sundial
#

yeah that's my complaint thinkies

mental carbon
#

It does not create a map

#

It creates some lambdas sure.....

#

But not a map

mental carbon
#

Ohh right

#

That is a compressor holder....

#

Meh

#

Forgot about that optimization map that they have there

mossy bobcat
#

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

mental carbon
#

It is a weighting of functionality

#

We wanted to be able to make every codecable object optional capable via conditions

#

For future expansion

mossy bobcat
#

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?

mental carbon
#

As a bonus that results in a tiny patch if we need to add it to vanilla

#

the trade of: it creates a map

fallow sundial
#

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

mossy bobcat
#

Yes but I have to assume that most of the created codecs are identical

mental carbon
fallow sundial
#

and when and if mojang makes it a dispatch codec you can throw this system at it

mossy bobcat
#

If I understand the issue right

fallow sundial
#

basically, mojang doesn't use a disptach codec

mossy bobcat
#

Can you not wrap the original codec once and call it a day?

fallow sundial
#

but orion patched it with this which wraps the "dispatch" codec every invocation

mental carbon
#

Not for recipes, yet

mossy bobcat
fallow sundial
#

and I don't see a problem with decoding recipes outside like mojang does with the type

mental carbon
#

Yes

mossy bobcat
#

I guess that makes sense

fallow sundial
#

when mojang makes it a dispatch codec this works

mental carbon
#

From the code it is very clear that they are rewriting this as we speak

fallow sundial
#

but until then ehh

#

looks bad

mental carbon
#

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

mossy bobcat
# mental carbon Yes

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

mental carbon
#

The proper simple fix is to make this a dispatch codec

fallow sundial
mossy bobcat
#

But yeah, honestly, I'd make it a dispatch codec

#

That's probably simplest

mental carbon
#

I just realised that it is not that trivial XD

#

Actually

#

never mind

#

i am stupid

#

And overthinking this

fallow sundial
#

actually you can use partialdispatch

#

there's an overload with a custom function returning dataresult

mossy bobcat
#

As long as it throws a JsonSyntaxException like vanilla it all should be fine

fallow sundial
#

yeah that's a problem harold

#

or well

#

ehh

#

I guess not really, as long as you check the error message

#

it's fine™️

mossy bobcat
#

Not really that hard. mapError with a custom error prefix is the way to go

fallow sundial
#

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)

mossy bobcat
mental carbon
#
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

fallow sundial
#

oh those aren't the same

#

damn it LUL

mossy bobcat
fallow sundial
#

throwing inside the dispatch function is thinkies

#

but if it works

mossy bobcat
#

Funky stack trace but very easy to catch the exception

mental carbon
#

Yep

#

It is literally the exact same execution logic

#

A bit further down the stack

#

But it works perfectly fine

mossy bobcat
#

way further down the stack probably cause it's DFU fuckery but whatever

mental carbon
fallow sundial
#

remove that getasstring call, it's just uneeded overhead

mental carbon
#

Oh right XD

#

I am not sure why Mojang did not patch this first thing they did when they had codecs on serializer

fallow sundial
#

also did anyone tackle the common packets or networking in general? I can look into it tomorrow if not

mental carbon
#

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

fallow sundial
#

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

mental carbon
#

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

fallow sundial
#

tries to find the disection tools

dull bison
rich void
#

or a machete

dull bison
#

~30 files with errors remaining

  • networking
  • gui
fallow sundial
#

@mental carbon don't forget to make the codecs final

mental carbon
#

Rigt

#

55 errors totla on my end

kindred fractal
#

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
mental carbon
#

You guys are getting two things twisted....

#
  1. 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.

  2. 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.

kindred fractal
#

The ability to check for conditions in a json object sounds useful to keep

#

(can use a codec under the hood that is fine)

mental carbon
#

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

kindred fractal
#

Yes but did you keep a nice helper for JsonObject checking?

mental carbon
#

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

kindred fractal
#

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?"

mental carbon
#
    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

kindred fractal
#

Ah yeah that's good (naming should be present but details)

#

Why not use conditionsMatched for recipes?

mental carbon
#

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

kindred fractal
#

The dispatch codec is unnecessary

mental carbon
#

It is, but it cleans up the one last place were there is direct json reading in the recipe manager

kindred fractal
#

I don't like it, that's all I have to say. Let mojang clean their own code, it's generally not our job

mental carbon
#

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

kindred fractal
#

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 🙃

mental carbon
#

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

kindred fractal
#

I know but I dread a temp fix becoming permanent 😄

mental carbon
#

And it would surprise me to not see this area changed in the next pre1

kindred fractal
#

Hopefully

mental carbon
#

Again

#

IMHO the change is fine as is

#

It sets a good example for modders

kindred fractal
#

Yeah that's fine

mental carbon
#

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

kindred fractal
#

Yeah all the stuff is there...

mental carbon
#

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

lean warren
lean warren
#

A typo, basically

lean warren
#

You wrote manager.(ConnectionProtocol.LOGIN), it's missing the method name

mental carbon
#

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

lean warren
#

Ah, ok, don't mind me then 😄

mental carbon
#

Wir the name missing

dull bison
#

As of now I can see 8 files with errors left

tranquil salmon
#

The food bar has 6 different textures for empty, half, and full and a version for the hunger effect for each

mental carbon
#

Yep

#

They split the widgets texture

#

Which is the biggest source of errors still

dull bison
#

there are only 2 classes left that are not rendering stuff

  • IForgeAdvancementBuilder
  • SimpleChannel
tranquil salmon
#

I am working on finishing the ForgeGui class

dull bison
#

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

tranquil salmon
#

also for some reason the condition codecs are registered before the registry

mental carbon
#

Who is working on what?

dull bison
#

I just commented out the custom blitNineSlicedSized methods in IForgeGuiGraphics

mental carbon
#

I am trying to figure out the advancement builder

#

But its documentation is severely lacking.....

#

I think the concept "canBuild" is gone

dull bison
#

it is checking if the parent exists before creating

mental carbon
#

Yeah i realise that

tranquil salmon
#

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

mental carbon
#

Ah I think I figured out a patch for this

tranquil salmon
#

12 compile errors left

dull bison
#

of ffs AbstractSelectionList is not a Widget

mental carbon
#

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?

dull bison
#

not me

tranquil salmon
#

not me either

mental carbon
#

I will take care of it then

#

It is a simple render call 😄

#

Okey all errors fixed

#

Compiling

dull bison
#

push stabolb

tranquil salmon
#

push

mental carbon
#

Give me a second double checking my work :XD

#

It is thinking about it......

tranquil salmon
#

I edited the build.gradle in a commit a couple days ago that removes the uuid argument

mental carbon
#

<@&1067092163520909374> The obligatory porting screenshot 😄

dull bison
#

@mental carbon I did the dispatchUnsafe stuff

tranquil salmon
#

@mental carbon Fixed scrolling downwards

mental carbon
#

Ah

#

Did I use the wrong value there?

dull bison
#

we need to fix the patch for conditions in datapack registries

mental carbon
#

Why?

#

I thought I fixed that

dull bison
#

in datapack reg stuff the conditions key is "forge:conditions" not "conditions"

mental carbon
#

Ahhh

#

Okey

#

Why did they do that?

warm root
#

Mods for 1.20.1 will be working?

mental carbon
#

Unsure

#

Some yes

#

Some no

dull bison
#

hmmm Unknown registry key in ResourceKey[minecraft:root / minecraft:condition_codecs]: forge:mod_loaded

fallow sundial
#

why is that registry under mc

dull bison
#

I'm checking

warm root
mental carbon
#

Not untill it is released

warm root
#

It's a pity, but I hope I don't have to rewrite all my mods

mental carbon
#

Did anyone of you have luck with the escape button?

dull bison
#

net/minecraftforge/common/crafting/conditions/ConditionalOps.java:187 returns an errored dataresult

mental carbon
#

Maybe the wrong codec?

#

Or something with the wrong ops?

dull bison
#

the ops is the ConditionalOps and the codec is the ContextRetrievalCodec

mental carbon
#

How is that able to return an errored state?

#

?!?

dull bison
#

Not a JSON object: [{"type":"forge:mod_loaded","modid":"not_forge"}] is the error in the dataresult

mental carbon
#

Ah that is an array

#

Question is where it is throwing that

dull bison
#

question is why is it even trying to parse that object since we already have the parsed conditions at that point

mental carbon
#

No clue

tranquil salmon
#

Were you getting the BootstrapMethodError?

#

@mental carbon

#

So it's exclusive to eclipse then

dull bison
#

the experiments screen is broken

tranquil salmon
#

also worth noting the next eclipse release is in a couple days

dull bison
#

the escape issue also affects e with the inventory but only inside the game

#

escape works in the world creation screen

mental carbon
#

Yeah

#

Something with the input management

dull bison
#

creative inv background is broken

#

creative tab sorting should be validated (I had issues since it became a registry)

rich void
#

did it become a registry this update?

dull bison
#

no I think that was 1.20

fallow sundial
#

yes that was 1.20

#

aslo wdym by "validated"?

dull bison
#

spawn eggs being on page 2 with test mods enabled

#

is this correct?

normal wigeon
#

WTF

dull bison
#

then this is the only issue in the creative inv

mental carbon
#

Likely a misalligned patch

#

Or I called the wrong method when I tried to fix it

fallow sundial
#

tfw useless supplier

tranquil salmon
#

So the escape key seems to be being processed both when you press it and release it

mental carbon
#

Aha

dull bison
tranquil salmon
#

Fixed the issue

dull bison
#

the escape one?

mental carbon
#

nICE!

tranquil salmon
#

Also there are no advancements

fallow sundial
#

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 thonking on whether FIs should still have the I prefix

dull bison
#

my take on that is no I for FIs

tranquil salmon
arctic sphinx
#

Yes, unless it got redesigned

mental carbon
#

oeps XD

#

Yopu are right coehlrich

#

My mistake

rich void
#

question: is the Forge API gonna be seperate now?

mental carbon
mental carbon
#

#1136320550168436798 message <@&1067092163520909374> and we are in world. most stuff is working

kindred hatchBOT
#

[Jump to referenced message.](#1136320550168436798 message)

tranquil salmon
#

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

arctic sphinx
#

something something the pen is mighter than the sword

fallow sundial
mental carbon
fallow sundial
#

only 14 files changed to get rid of the context suppliers thinkies

tranquil salmon
#

Also it seems like animals follow you even if you aren't holding anything

mental carbon
#

Yeah that is all tied to ingredients

#

So we need to look into what gets send around

dull bison
mental carbon
#

Allthough not the anymimals

fallow sundial
tranquil salmon
#

Currently it's true if none of the item stacks are empty

mental carbon
#

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

drowsy condor
rich void
#

?

fallow sundial
#

the loot tables becoming codecs made adding conditions to loot tables much easier harold

#

datagenning loot tables with conditions on the other hand

#

that's going to be fun

#

fun for another time thinkies

kindred fractal
#

You should also make the pools conditional for extra fun

fallow sundial
#

ehh actually

#

fair point actually

rich void
#

so how are loot tables done now? still with a JSON?

mental carbon
fallow sundial
#

I still oppose to deserializing conditions with registry access stabolb

mental carbon
#

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

fallow sundial
#

¯_(ツ)_/¯

#

where would I put a codec util method

mental carbon
#

ForgeExtraCodecs

#

Has most of them

#

Unless it is related to conditional ops

#

Then they are in the ConditionalOps class or in the ICondition interface

true pivot
#

That was a fast port 👀

mental carbon
#

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

dull bison
#

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"}]}

fallow sundial
#

much codec

tranquil salmon
lethal bane
daring ginkgo
#

when you put your portal in the hydrolic press

fallow sundial
#

time to dive into networking

lethal bane
#

maty is gonna implement the config phase 👀

fallow sundial
#

wish me luck, I'll hate this

lethal bane
#

good luck, let me send people back into config phase

dull bison
#

or are you speaking of nuking the supplier

fallow sundial
#

I've already done that

#

I'm talking about the common configuration phase

mental carbon
#

@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

fallow sundial
#

don't what thinkies

#

also requiresFullSynchronization being inside the ingredient type is limiting. stuff like compound ingredients would need that to be dynamic based on the subingreidnets

mental carbon
#

I need to refactor that again later today

#

Will clean that up

fallow sundial
#

well I was in the process of doing it

mental carbon
#

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

fallow sundial
mental carbon
#

But it works on an integrated server

#

So currently I am pretty stumped

fallow sundial
#

well did you check the buffer

#

integrated server packets are copied

mental carbon
#

As far as I can tell the buffer is fine

#

But I am 100% on that

fallow sundial
#

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

mental carbon
#

And anything with more then just a simple codec, has historically had a type

dull bison
#

door rendering is borked

mental carbon
dull bison
#

could be looks like broken face culling

mental carbon
#

Weirdly, it looks like that did not update with respects to the changed blockstate.....

fallow sundial
dull bison
#

it culls any side that is at the edge of the block

mental carbon
#

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

fallow sundial
#

basically all codec registries

mental carbon
#

Yeah but these are not codec registries......

fallow sundial
#

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

mental carbon
#

Does it matter?

#

Like you have been nitpicking about this kind of stuff over the last few days

dull bison
mental carbon
#

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

fallow sundial
#

¯_(ツ)_/¯

dull bison
#

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

fallow sundial
#

Chests are not placeable
thinkies

#

ah yes

#

make it h1

mental carbon
#

Like a HackMD

lean warren
mental carbon
#

Cause we still have some network issues to figure out

fallow sundial
#

is it chests specifically or is it any block item

lean warren
#

Are you running normal forgedev or with test mods?

dull bison
fallow sundial
#

also can someone get me a 1.20.1 world zip

lean warren
dull bison
lean warren
#

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

lean warren
dull bison
lean warren
#

Try running without them, there's a dumbass test mod that conditionally cancels chest placement screm

fallow sundial
#

can confirm, works without test mods

lean warren
#

👌

dull bison
fallow sundial
#

btw schurli we already have a neoforged team hackmd 😛

#

chest placing

dull bison
fallow sundial
#

you're in the org, you should see it

#

if not i can get you an invite link

dull bison
#

I can edit but I am not in the team

fallow sundial
#

hmm

dull bison
#

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

fallow sundial
#

powered lamps also don't render

dull bison
#

unpowered do?

fallow sundial
#

yes

mental carbon
fallow sundial
#

without

mental carbon
#

Interesting

#

Could be many things.....

#

Sadly

rich void
#

u can't binary search this, right?

dull bison
#

same thing with redstone ore

mental carbon
#

Problems with light emitting full blocks?

#

Check glowstone

dull bison
#

yup sea lantern and glowstone

lethal bane
dull bison
#

so we have 2 different problems here the culling and the not rendering of light emitting full blocks

lethal bane
#

so that placing chest doesn't work against diamond blocks thinkies

fallow sundial
#

I wonder if tesselating without AO is broken in general

dull bison
fallow sundial
#

can you even disable ao in the settings menu

dim sonnet
#

No, only smooth lighting

fallow sundial
#

nice

rich void
#

isn't ambient occlusion needed for blocks like cactus?

fallow sundial
#

heh I was right

#

tesselatew/oAO is indeeded broken

#

and I also know why

#

let's see if this fixes it

rich void
#

let's see

fallow sundial
mental carbon
#

?

#

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!

fallow sundial
#

my fix probably fixed face culling

dull bison
#

now mark them as fixed in the HackMD

#

after testing

fallow sundial
#

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

dull bison
#

that is normal vanilla behaviour

fallow sundial
#

is it? thinkies

lethal bane
#

iirc yes

#

you don't get pricked if you don't move into thorns squirrelhat

fallow sundial
#

well then

#

also can anyone get me a 1.20.1 world

jagged agate
fallow sundial
dull bison
#

time for the debug world

#

there is a hole between the black wool and the dandelion

fallow sundial
#

okay so I can make the datafixer take the forge WSD into account

#

but it's going to be ugly harold

dull bison
#

datafixer are always ugly

fallow sundial
#

fair point

fallow sundial
#

saveddata

#

same thing

#

WSD is worldsaveddata (the mcp name)

mental carbon
#

Ah okes

#

Why is it needed?

#

Did DFU remove it?

fallow sundial
#

or well you can but all effects disappear

mental carbon
#

Why are custom effects stored in SD?, when they are already hardcoded on the entities/itemstacks additionally?

fallow sundial
#

this isn't that bad actually thinkies

fallow sundial
mental carbon
#

Aaah so the forge reg data is stored in there?

fallow sundial
#

yes

mental carbon
#

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

dull bison
#

vanilla blocks all work some of the testmod blocks need fixing

fallow sundial
#

we don't patch beacons to use the name

mental carbon
#

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

fallow sundial
#

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

mental carbon
#

The problem is that they all use codecs now to deal with effect list

#

We could patch in here

fallow sundial
#

no no we don't need to patch that

mental carbon
#

But that is just creating TechDebt

fallow sundial
#

for entities and stews we can redirect to the forge field

mental carbon
#

In DFU?

#

Or what?

fallow sundial
#

yes

mental carbon
#

Yeah that is what I was coing to point out

#

Good 😄

fallow sundial
#

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

mental carbon
#

I really don't like these kinds of fixes

fallow sundial
#

who does harold

#

okay question

muted hemlock
#

do we even need to fix this

fallow sundial
#

aaaagh

#

fuck

muted hemlock
#

it's not the first time that modded saves have lost data due to DFU

mental carbon
#

^

#

And mojang fixed it for the future

#

So I am not sure we should even fix this

fallow sundial
#

in this case however it's up to neo, and we can fix it

mental carbon
lean warren
mental carbon
#

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

fallow sundial
#

that's a stupid argument, if we let worlds be broken before it means we can't do better this time?

pine ember
#

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 😄

mental carbon
#

@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?

mental carbon
#

Okey

#

Then I would argue against fixing this

#

And removing all the code that provides that API functionality

tacit vale
#

see my registry rework

mental carbon
#

Yeah I thought yo

tacit vale
#

it still needs some work but it's mostly there

mental carbon
#

But did you check the chunk palette

tacit vale
#

I checked everything yeah

#

any int ids are only networking

mental carbon
#

That had previously still a mode were if it exceeded a specific size it fell back to the global registry map

tacit vale
#

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

mental carbon
#

Sadly

#

The global palette are still in use

dull bison
mental carbon
#

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

fallow sundial
#

we can still do this and forget about the beacon

#

(for those without access)

mental carbon
#

For DFU yeah that is fine maty

kindred fractal
mental carbon
#

But my point with respect to the palette and its size still stands

mental carbon
#

I researched this area of the code extensively for C&B

#

And ran into this snag

kindred fractal
#

@pine ember that's concerning if it's true

mental carbon
#

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

fallow sundial
mental carbon
#

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

pine ember
lean warren
#

This is about blockstate IDs though and not block IDs

mental carbon
#

Especially on forge

lean warren
#

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

mental carbon
#

Yep :d

#

Block ids are as such only implicitly a problem

#

Since they determine the order in the block state map

winged hull
mental carbon
dull bison
mental carbon
#

And that means that the id map that is used is and will be different between two launches with different mods

pine ember
#

We sort the blocks here

#

It has its own issues, but mostly works

mental carbon
#

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

pine ember
#

yeah, I wasn't aware of that 🤔

#

Is it 256 in the section (thats 161616 if im correct?) or 256 in the whole chunk?

mental carbon
#

Whole chunk

pine ember
#

Ill need to take a look into this later.

mental carbon
#

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

lean warren
mental carbon
#

That is still much larger then the 256 but still

#

I wonder why they did this this way

pine ember
#

So yeah, I think this could be an issue for us. But its not a new issue.

mental carbon
#

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

lean warren
# mental carbon

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)

mental carbon
#

Blocks.java

winged hull
#

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.

mental carbon
#

Forge replaces the IdMap with a registry link

#

But that registry link does exactly the same thing

dull bison
#

FFS MOJANK they changed blockstate and model datagen again

mental carbon
#

I realised what is the issue

#

They only use 4 bits for the size

lean warren
mental carbon
#

Yeah

muted hemlock
mental carbon
#

I am going to take a look at this later

mossy bobcat
#

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

muted hemlock
#

exactly

mental carbon
#

^

#

I have a custom variable growth palette

#

For C&B

quiet talon
fallow sundial
#

yeah conditions is intrusive as people can't use it for their own codecs

kindred fractal
fallow sundial
#

we can change it to forge: and use conditions for datapack backwards compat based on the pack version

mental carbon
#

We could give the codec the option to check more then one key

dull bison
#

writing ingredient with codec produces the wrong output ... it should be flat with the type but it is nested in a value

muted hemlock
#

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:

  1. all codecs produced by RecordCodecBuilder are MCCs
  2. 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();
    }
dull bison
#

yea Codec#either fucks that up

mossy bobcat
#

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

muted hemlock
dull bison
#

I know that but I can't do either with a mcc and a normal codec

mossy bobcat
muted hemlock
#

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

dull bison
#

both actually

muted hemlock
#

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();
dull bison
#

problem is the either is outside of the .codec() call

muted hemlock
#

can you just show what you have then

dull bison
#
    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);
kindred fractal
#

Ok that's a cool feature ^^

muted hemlock
#

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": []

dull bison
#

yes

muted hemlock
#

okay, there's two things wrong here

#

firstly that third one cannot be part of the dispatch codec

dull bison
#

orion I think we can not use the compound ingredient through the dispatch but need to use an outer either

muted hemlock
#

secondly, for the first two, I would either drop one of them, or give them two different subcodecs (two different type ids)

muted hemlock
#

no type field = can't be a dispatch subcodec

dull bison
muted hemlock
#

is the third a vanilla format? or is that something forge adds

dull bison
#

it was the previous forge format afaik

#

the 2 named ones are the new formats

muted hemlock
#

if it's not a vanilla ingredient format then IMO drop it and make people use the explicit type

dull bison
#

orion we need to fix ingredients with a list of values (reading works but writing errors)

mental carbon
#

Somebody else then needs to deal with the networking issue on dedicated servers

dull bison
#

I will check the testmod rendering things

tacit vale
quiet talon
#

Plus the reg refactor has to be rebased on DH

tacit vale
#

well that still needs to be merged which means reviewed if not already

mossy bobcat
#

@muted hemlock @dull bison You should be able to use Codec.mapEither to make a MapCodec that works like either, right?

muted hemlock
#

maybe

#

that wasn't the problem here though

mossy bobcat
#

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

dull bison
#

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

dull bison
#

I think I fixed ingredients (I hope so) and I am currently working on forges loot table provider

dull bison
#

I think we are ready to cleanup and gen patches and then switch to pre2

mental carbon
#

Test the dedicated server

dull bison
#

I will need to start in offline mode

#

you started to debug this

mental carbon
#

I got that fixed hold on

fallow sundial
#

I expected
that "I" doesn't fit harold

dull bison
#

wtf a unicode char as packet name

mental carbon
#

That is the empty string

#

Something is sending the server a weird packet

dull bison
#

it's an answer packet

arctic sphinx
#

Snapshot?

mental carbon
mossy bobcat
arctic sphinx
#

Greg (I think it was?) pr'd to Proguard a fix for empty records having metadata stripped

mossy bobcat
#

Ah, nice

arctic sphinx
#

It was based on an issue Jas (VF) raised to them

tranquil salmon
true pivot
#

greg harold

dull bison
arctic sphinx
muted hemlock
#

hoglins can now be bread

dull bison
#

hoglins can now what?

true pivot
kindred fractal
#

🥖

lethal bane
#

ah wait

#

I'm slow

#

I should just also apply for the role

arctic sphinx
#

I would hand it out but the last time I did it gave access to some back channels harold

true pivot
#

hehe

tranquil salmon
#

#builds I was wondering why it hadn't sent a message when I checked turns out I just had to wait a bit longer

daring ginkgo
lethal bane
#

same

daring ginkgo
#

especially if it means I will never have to navigate the minecraft site because I do not know how to use that

mental carbon
#

Cause I was sure I checked that

dull bison
#

the erroring packet is:
id: 2
transactionId: 1
payloadPresent: true
packetIndex: 1
id: fml:loginwrapper

lethal bane
#

#builds perfect shipit

dull bison
#

I know what we are missing ... we are not using readNullable

tranquil salmon
#

CompoundTag patch didn't apply

dull bison
#

fixed

mental carbon
#

Seriously?!?

#

That was all it needed the readNullable?

dull bison
#

at least this issue is fixed now

mental carbon
#

OIkey

#

Lets see if you can get on the server

dull bison
mental carbon
#

Oef

dull bison
#

I'm on the server

mental carbon
#

Nice so

dull bison
#

pushed

mental carbon
#

Okey

#

So that was the last issue if I remember

#

So I will go through and create the patches

#

AKA do the cleanup

tranquil salmon
#

Attempted to update the CompoundTag patch from mobile

tacit vale
#

nice

tacit vale
tranquil salmon
#

1.20.2-pre2 to 1.20.2-pre3 diff

tacit vale
#

ah

mental carbon
tranquil salmon
#

#builds

mental carbon
#

Nice

dull bison
#

can't publish to maven local proguard fails

#

(also need push access to the repo)

rich void
dull bison
arctic sphinx
rich void
#

interesting

rich void
fallow sundial
dull bison
#

then delete it and re fork it

#

and give me push access so I can push the neoify commit

mental carbon
#

Ah okey

#

Will do in a minute

rich void
mental carbon
#

Actually that is taking me a bit longer

#

Can somebody run the action for schurli

inland mesa
#

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?

rich void
#

did they finish the stuff they were working on in rc1?

inland mesa
#

rc1?

#

they released pre3 today

rich void
#

I meant pre1 xD

inland mesa
#

can't remember what they were doing in pre1 so I'll leave that to the porters

rich void
#

sum codec stuff

inland mesa
#

I don't think they have made any more code structure changes in pre3, only bugfixing

rich void
#

ok

mental carbon
#

@dull bison Did some body run the action for you?

dull bison
#

nope

mental carbon
#

Okey let me do it for you then

#

Running now

#

Done

dull bison
#

I still need push access

mental carbon
#

Yeah I am trying to figure that out

#

@fallow sundial Your action is broken