#1.20.5/6 Snapshots

1 messages · Page 7 of 1

elder swallow
#

that is true

true jacinth
#

I would want to seek input from SilentChaos and KnightMiner on their opinions

#

I can get ahold of knight pretty easily

#

dunno about silent though

fallen igloo
#

hey @azure sparrow it seems that there are a lot of questions on the design decision to use blacklists for tools could you shed some light on this (or tell us who can)?

true jacinth
#

The blacklist is... easier to define, but that's about all I have tbh

#

and given that the needs_x tags already existed its just very puzzling

elder swallow
#

@fallen igloo volunteered

true jacinth
#

Do I need to start rebasing the network api changes anytime soon?

#

I don't think there are anymore outstanding complaints with the implementation

elder swallow
#

well there's no rush

#

I still need to make a few changes on the snapshot branch kek

fallen igloo
#

does unpick run before or after the patching?

elder swallow
#

before the decompilation

#

hence before the patching

true jacinth
#

I'm out of date, what does unpick do?

fallen igloo
#

deinline constants

azure sparrow
#

it’s basically a straight port of what was there before. the tier comparison is effectively combining all of those needs_ tags, which is what those combination tags do

true jacinth
#

Why the blacklist though?

#

Instead of a combinatoric (laddered) whitelist

azure sparrow
#

those needs_ tags are blacklists, and they’re the most natural way to express the source data (at least imo)

true jacinth
#

They are blacklists for the prior tool, I suppose

#

I think the natural expansion would have been to make laddered whitelists though

#

i.e. create requires_at_least tags, starting at wood, and have the future tags be defined as supersets of the previous

#

and/or can_be_mined_with_X (all names are verbose)

fallen igloo
#

having the needs_ tags contain each other would cause more work for datapack/modpack devs

true jacinth
#

then the definition is
can_be_mined_with_wood -> [almost everything]
can_be_mined_with_stone -> [ #can_be_mined_with_wood, <iron>, ...]

#

etc

true jacinth
fallen igloo
true jacinth
#

Perhaps I'm missing a functional requirement of the design though, the goals that we have may be different from yours

azure sparrow
#

the trouble is that it’s not just that, but can_be_mined_with_stone_pickaxe - so those source tags would need to be split more

#

that or the rule system would need to be a lot more complex

#

but I agree the inversion is not very natural. it’s mostly there because it mapped the logic we already had directly (early-exits based on tier and each tag)

true jacinth
#

The usecase that has become common in modded that is not well supported by the inverse tag list is comparison of individual Tiers

#

The vanilla design is more flexible (since the tools are not required to be strict supersets of the prior)

#

but arguably that flexibility could be contained to the Tool Component rather than the Tier system

#

since the component is what is exposed to datapack authors

azure sparrow
#

“Tier” is basically just a template at this point

#

but I’m curious what the use-case of comparison is?

fallen igloo
#

shadows let comparison go, you can now have a block that is mineable by gold but not by any other tier there is no order

azure sparrow
#

is it figuring out if one tool is “better” than another?

true jacinth
#

Modular tool mods with two heads need to be able to select the "best" one

fallen igloo
#

it could just check if it is in none of the tags

true jacinth
#

The thing is we also need equivalency classes

#

Mods providing new tools for new materials need to be able to say "this tool is as good as X"

azure sparrow
#

I would argue for that being a separate system than the tool’s block break definition

fallen igloo
azure sparrow
#

because two tools might have totally unrelated sets of blocks that they mine, ideally there’s the flexibility to not define each tool as a superset of the last

#

so if you some specifically defined order is needed, it makes sense to define it explicitly

true jacinth
#

The other annoying problem is that if you presently want to define that a block requires a netherite pickaxe, you need to add it to 5 tags

#

This seems cumbersome

#

(this is mostly an argument for having the tag definitions be laddered in terms of eachother)

azure sparrow
#

but that’s only netherite because it doesn’t have a needs_netherite tag

true jacinth
#

diamond too :p

azure sparrow
#

but then you just put it in needs_diamond

dreamy crystal
#

imo tools should take a list of tags that they're valid for, and blocks should just have two tags, something like needs_tool/pickaxe and needs_tier/diamond

true jacinth
#

hm, right, the inversion is fiddling with my head a bit

azure sparrow
#

the incorrect_for tags aren’t really supposed to be modified directly, they’re just combinations of the needs_ collections

dreamy crystal
#

so a netherite pickaxe would be valid for needs_tool/pickaxe and needs_tier/wood all the way through needs_tier/netherite

true jacinth
#

Unfortunately there is another common usecase that arises

#

being able to "upgrade" a tool to the next tier

#

I suppose if everything is determined in relevance to the vanilla tiers it might™️ work out?

azure sparrow
#

this is another case for defining an explicit structure for tier ordering

fallen igloo
true jacinth
#

I believe the trouble with them being disjoint comes in the case of the following:

  1. A tool selects the highest of two arbitrary tiers, T1 and T2
  2. The highest tier is used for all checks, but cannot actually break a superset of the lower
dreamy crystal
true jacinth
#

And the inverse structure makes it impossible to unify between two disjoint sets

azure sparrow
azure sparrow
true jacinth
#

At least if the tag wasn't inverted it would be easier to create a union between two tiers to actually represent the best tier

dreamy crystal
#

to simplify the logic for the tool there could be another tag, something like can_mine/diamond, which would let a datapack/modpack author change tool tiers; the check would then be get_needs_tier(block) == get_can_mine(tool)

#

at least for "vanilla" style pickaxes

true jacinth
#

Fundamentally the need from the modded side is that Tiers are comparable

#

Everything else eventually boils down to that requirement

dreamy crystal
#

for something like tinkers tools, they would change it so that the logic is instead something like get_can_mine(parts).contains(get_needs_tier(block))

fallen igloo
dreamy crystal
#

sure, on the component then

true jacinth
#

the component generated from a tag :p

dreamy crystal
#

(as you can see i haven't looked too extensively at the changes for 1.20.5 other than what i've heard)

fallen igloo
summer furnace
#

I was thinking while in the shower, we need 3 levels of tags:

  • incorrect for X might contain random stuff (eg an "elven metal" tool might not be able to mine iron ore despite being netherite level otherwise)
  • needs X tool should only contain the stuff for one tier
  • so, we should have a third level that is iron_or_higher, that contains [ needs iron tool, diamond_or_higher ], and chains into each other
true jacinth
#

Virtually every single usage I can see boils down to Tier being Comparable

#

Based on Gegy's information the incorrect_for_x tags should never be modified directly

#

and we should design within that constraint

#

the inversion is just screwing with my head

summer furnace
#

it already works like that now, no?

true jacinth
#

atm the incorrect_for tag is the "authoritative" tag

summer furnace
#

I mean in 1.20.4

#

is correct tool checks that the block is not in a higher tier

true jacinth
#

Right, that's what the needs_x tags accomplish

summer furnace
#

1.20.5 just yeets that and replaces it with tags

true jacinth
#

but the incorrect_for tags are the ones that get used and reference the needs_x tags of the above

#

except netherite, which references nothing

fallen igloo
#

aren't all usecases except direct comparison covered by our advanced holderset stuff?

true jacinth
#

Due to the inversion, I don't think so

summer furnace
#

there's two use cases:

  1. define a new tier
  2. define a new block

if you define a new block, you add it to the needs tag for its level, nothing else
if you define a new tier you would need to include all the needs tags above, which is not feasible

true jacinth
#

But perhaps we can just disconnect the breakable blocks from the "level" entirely

summer furnace
#

hence my proposal to introduce a third level thay does the upward chaining

#

diamond_or_higher includes needs_diamond + netherite_or_higher

true jacinth
#

it is (imo) reasonable enough to not support interleaving within the vanilla tiers, there are like 5 of them after all

summer furnace
#

if someone wants to insert themselves between, they just add their or_higher tag to that same tag

#

it doesn't require more than that

#

iron_or_higher : append vampirite_or_higher
vampirite_or_higher: [ needs_vampirite_tool, diamond_or_higher]

#

those 2 tag files are enough to insert yourself in vanilla if we add the chaining intermediates

#
  • incorrect_for_vampirite [ diamond or higher ]
true jacinth
#

Okay, say two of those exist

#

how do you compare them?

#

two things between iron and diamond with disjoint block lists

#

The effective goal of the API is that we are providing a stability guarantee between "levels"

summer furnace
#

will become undefined

#

until a modpack reconciles them

#

iron will refuse to mine both

#

but they will not know of each other

fallen igloo
#

I think based on gegys response we should wait at least a few snapshots for the redesign for the case that mojang changes it again

true jacinth
#

de-inversion of those tags will make things more straightforward

#

hopefully that happens

#

not sure if we can expect native chained definitions

fallen igloo
summer furnace
#

no we shouldn't invert the tags

true jacinth
#

I am curious if anyone actually defines any intermediate tiers between vanilla tiers though

summer furnace
#

aren't stuff like copper/bronze, silver, etc. in between?

true jacinth
#

nope

#

always iron equivalent

#

or stone equivalent

#

nobody is actually adding intermediates

#

copper tends to == stone

#

bronze is == iron

fallen igloo
#

btw gegy are you able to tell us when we can expect the dfu bump to happen?

azure sparrow
#

they will probably stay inverted - as far as I can tell the best you can get without changing the source tags is a more flexible rule system that would only really allow those to be inlined (but that’s not really better)
the key problem being that there’s no needs_wood_tool (this is effectively defined by blacklist from other tags)

true jacinth
#

(similarly for advanced materials which tend to be diamond equivalent)

fallen igloo
#

yea the de-inversion would require a needs_wood tag

true jacinth
#

I agree that needs_wood becomes a very large tag

azure sparrow
#

the inversion is a bit confusing but I think it’s not often that you need to think in that space. it’s much more convenient to have easy setup for blocks

true jacinth
#

its almost the entirety of blocks/mineable

#

At least a native needs_netherite should be present

#

it would be weird if we have to provide it and link it

fallen igloo
#

yea blocks should be the primary usecase

true jacinth
#

If we have the full needs_x spread from the vanilla materials we can then establish a convention for tools beyond that set. I don't see convincing evidence that anyone is injecting tiers between vanilla tiers (imo it would make for super weird gameplay anyway, vanilla's are fairly granular)

#

(that claim based on a usage search of registerTier)

fallen igloo
#

screm @rigid walrus we are not mirroring unpick on our maven

rigid walrus
#

add the fabric maven for now

true jacinth
#

People will still want to compare Tiers but such comparisons can be done though knowledge of the vanilla tags

fallen igloo
rigid walrus
true jacinth
#

@pine egret do you happen to know of any instances of anyone inserting a tier between vanilla tiers?
Or is everything you've seen either equivalent to a vanilla tier or above netherite

pine egret
#

why doth thou pingeth me?

#

ah, tiers

#

good question, in tinkers we don't currently do any custom tiers, but I did do one as an example in my JSON addon just to show it could be done. IIRC I made it below netherite, not that it matters

true jacinth
#

plenty of discussion above

pine egret
#

part of that is I only care about tiers for harevesting

#

I'd honestly love a separation between material tiers and harvest tiers

#

having to make a material tier with 10 properties I don't use just to get a harvest tier is dumb

#

this separation would also mean custom modded material tier can just return a vanilla harvest tier if they don't need custom logic

#

a win win

true jacinth
#

Actually that's a good point

#

Material tier and harvest tier should be disjoint

pine egret
#

from there, just define harvest tiers in JSON and call it a day?

#

😛

true jacinth
#

psst @azure sparrow do that™️ ^

wooden tendon
#

I have seen those

pine egret
#

to be clear @azure sparrow , the "that" is mostly separation, but JSON would be nice so I don't have to do it myself

pine egret
wooden tendon
#

Both

#

I can't remember were though

pine egret
#

most material tiers are people need custom tools, not custom harvest tiers

wooden tendon
#

Was it tetra?

pine egret
#

outside of modpacks that is

#

modpacks do whatever

azure sparrow
#

to vanilla item components at least there’s no concept of tier

pine egret
#

for modpacks, we'd really want to let them change the harvest tier tied to material tiers in JSON if possible

azure sparrow
#

tier is just the template for generating the default components

wooden tendon
#

Maybe that is our issue tzhen?

#

That we think of tiers while in reality they don't exist?

pine egret
#

a modder should be able to say "my copper pickaxe mines whatever gold pickaxes do"

#

a modpack maker should be able to say "actually no, we have a new tag for copper, its between stone and iron, and this tool uses it"

wooden tendon
#

Hmm

#

That is difficult with the new concept I think

pine egret
#

that may be as simple as a tag tbh

azure sparrow
#

yeah, that’s definitely a big use-case. the tags that vanilla uses are reusable, but the tool components don’t strictly require it at least 🙂

pine egret
#

iterate backwards through the tiers, if this tool has the tag, use this tier and give it these blocks

azure sparrow
#

but those tags are specifically mining-related - so it might not make sense for those to be used as a substitute for other kinds of tier comparison

pine egret
#

what other tier comparison is there?

azure sparrow
#

in vanilla, there is none - but the sense that I got from the conversation is that there is some utility to this in modded contexts

#

(that is to say, it probably makes most sense for this kind of structure to exist in mod APIs)

pine egret
#

most of vanilla tiers is just stats

#

none of that is strictly ordered

#

its just the harvest level with an ordering

wooden tendon
summer furnace
#

it's the sense of progression. a better tool opens up more things to mine

#

but that doesn't need to be represented explicitly IMO

#

we just need to make it the least annoying possible while maintaining the functionality

#

I still think the 3 tag solution is best, but we sacrifice the explicit sorting order

fallen igloo
#

@rigid walrus unpick basically only did the command levels

wooden tendon
azure sparrow
#

in terms of gameplay - they are indeed tiered. I mostly mean in terms of tool component definition

wooden tendon
#

Yeah for sure gegy, the tool component has no concept of tiering that is true

azure sparrow
#

the tier mineable tags are basically just convenience for defining these, but strictly it's not required to follow those

wooden tendon
#

Correct

#

That really makes me wonder how we should design this

rigid walrus
fallen igloo
elder swallow
#

Test the installer and userdev as well

true jacinth
summer furnace
#

note that in the current (1.20.4) system "==" doesn't actually exist, the sorter always puts one before or after another
it just happens that if there are no elements in a tag, it's effectively equal

#

so if brass is sorted after iron but with an empty tag, and someone made that tag not empty, it would automatically become > iron

#

it was an active design choice to do it like that, not just a side-effect

fallen igloo
#

we need to capture system.err in the execute tasks

elder swallow
#

Hmmm maybe

#

We shouldn't capture the compilation output though (it's very spammy)

fallen igloo
#

I meant the tasks defined by neoform

fallen igloo
#

installer can't find the unpick neoform

image.png
pine egret
#

What is the snapshot change that propmpted this?

#

did vanilla ditch numeric tier IDs?

summer furnace
#

yes

#

and introduced new tags

#

incorrect for wood -> needs stone | needs iron | needs diamond | needs netherite
incorrect for stone -> needs iron | needs diamond | needs netherite
incorrect for iron -> needs diamond | needs netherite

#

the tiers now have absolutely no "ordering" of any kind in vanilla

#

they just contain increasingly less disallowed blocks in the tags

pine egret
#

and its a blacklist, fun

#

I guess a whitelist is inheriantly harder here

summer furnace
#

that's why my suggestion was to introduce a level of tags in between

[replace tags]
incorrect for wood -> stone or higher
incorrect for stone -> iron or higher
...

[new tags]
stone or higher -> needs stone | iron or higher
iron or higher -> needs iron | diamond or higher
diamond or higher -> needs diamond | netherite or higher

pine egret
#

but then the in between is not practical

summer furnace
#

it's not too bad:

  1. append "mediocrite or higher" to "incorrect for iron" tag
  2. make "mediocrite or higher" = needs mediocrite | iron or higher
  3. make "incorrect for mediocrite" = "iron or higher"
#

the only things we would lose that way, is the ability to list tiers in order, and the ability to distinguish "parallel" tiers

#

eg, mediocrite tool wouldn't be able to mine betweenium level blocks, and betweenium tool wouldn't be able to mine mediocrite level blocks

pine egret
#

hmm, that would be problematic for my usecases

#

I need to be able to tell which of two tiers is "higher"

#

if I can assume they are all linear, that can be done by tag size comparison

elder swallow
#

Can't you check both tiers every time?

pine egret
#

not relevant really

elder swallow
#

return canMine(tier1) || canMine(tier2) essentially

pine egret
#

my tools have a mining tier stat

#

that stat shoud be displable to the player as the highest mining level from a few sources

#

I don't want to tell the player "this tool mines at Iron, Diamond" because I have no idea which is better

summer furnace
#

hmm you'd have to choose a tier explicitly, like "this tool is Iron tier", whatever that means would depend on the tag

#

instad of going by level

pine egret
#

I don't go by level

#

all my tier choosing is based on their names

summer furnace
#

but I suppose that doesn't work for anything taht increases tier by 1

pine egret
#

before tier sorting let me determine which of two tiers was greater

#

I never just increase tier by 1, its always a max operation

#

this tool has tier iron, but a modifier wants tier diamond. Diamond is better, use that

#

this tool has tier netherite, with a modifier wanting tier diamond, stick with netherite

foggy steeple
#

Allow player to choose?

pine egret
#

ah yes, lets add a UI for a decision they may not know

#

if its vanilla tiers that is easy, sure

#

but its just an unneeded UI, we should know

#

the logic to "get the best of both worlds" (aka merging) is not hard, the problem here is just telling the player what this tool can mine

foggy steeple
#

The UI could show list of blocks the tier can mine in JEI style so they can glance at it to see which groups of blocks they want to be able to mine

pine egret
#

again, this is an unneeded UI

#

the whole point here is to show them info in a tooltip

#

you should not have to use a UI to tell the tooltip what to show

foggy steeple
#

It sounded like, and I can be wrong, that Mojang was pushing to make the tier system no longer be tiers. Like datapacks can make stone tools mine blocks that iron tools cannot mine

#

Unless I misunderstood

pine egret
#

looked to me like its just datapack controlled

#

I mean, you could make it not hierarchical I suppose

#

if that ends up being something I need to support, I just show all names in the tooltip and accept the loss

#

I could probably reduce the list with a set contains check if needed

#

means I get to construct a graph of how tiers compare to see if any tier is redundant, a fun time

#

but yeah, the actual harvest logic is easy, just only blacklist if its blacklisted in all tiers the tool has

fallen igloo
#

there is no such thing as tiers anymore (they are still in the code but they are just templates)

blazing valve
#

net.neoforged.neoforge.network.codec.NeoForgeStreamCodecs.lazy
What is the point of that?

#

It has no docs for when to use it 😅

#

It also seems to do the same thing as net.minecraft.network.codec.StreamCodec#recursive at a glance

elder swallow
#

Wouldn't surprise me since the lazy Codec is a recursive Codec

wooden tendon
#

A LazyCodec was there because sometimes it was not possible to build a codec directly (registry was not build etc) or it was expensive to do, if it was unsure if the codec was needed (through a cap for example)

#

The lazy codec was there to cover both cases

blazing valve
#

Well I figured as much, but Mojang has a stream codec that seems to do exactly the same thing 😅

#

(Maybe it was introduced in a later snapshot)

elder swallow
#

we should just remove the neoforge one

wooden tendon
#

Layzy codec was designed for normal codecs

blazing valve
#

Uhm Orion

#

Check my message again 😄

#

net.neoforged.neoforge.network.codec.NeoForgeStreamCodecs.lazy

fallen igloo
#

yea I introduced that and I think stream codecs didn't have a recursive one yet

blazing valve
#

Ah yes, that explains that, should be removed in that case

#

lazy is just such a better name for what it does.... recursive really made me make a double take

#

I assume this is needed because the registry it references will class-load the entry-class, which itself then defines the codec (hence the "recursion")?

fallen igloo
#

no recursive was made so a codec can reference itself a literal recursion

blazing valve
#

Okay 🤔 the uses I found were for wrapping a registry

#

Hm no, I must be mistaken. You are right, it seems to be used in real recursive data structures.

#

IDK we could keep the lazy one for clarity

fallen igloo
#

I mean in dfu the lazy one is just a wrapper around the recursive one that ignores the parameter (that is the new dfu version on the repo)

blazing valve
#

I probably need to test in which case it actually needs to be used when referencing registries

#

Very annoying observation: RegistryFriendlyByteBuf needs a full RegistryAccess while all new NBT serialization methods pass through only the HolderLookup.Provider 🤔

elder swallow
#

Are you serializing a byte buf to NBT?

blazing valve
#

You know exactly what this is 😄

elder swallow
#

Client side state saving?

blazing valve
#

syncing,y es

elder swallow
#

Well you can call a HolderLookup.Provider method with a RegistryAccess

#

Ah but we write a bytebuf to nbt for syncing I presume

blazing valve
#

Yup... so within an NBT write method, you have a HolderLookup.Provider. If you want to construct a RegistryFriendlyByteBuf there, you really can't

elder swallow
#

Yeah

#

For static registries you can grab a global RegistryAccess but it's a bit ugly

blazing valve
#

It's quite... verbose 😄

elder swallow
#

Just use deferred register thonk

#

Ah but you are

#

Well the builder is not too different from attachment types or other things I'd say

prisma locust
#

what is the theoretical procedure if I wanted to rebase the 24w12a branch on 1.20.4

#

I assume git rebase would just conflict on everything

slow prism
#

tbh i'd add a subclass for components that exposes a register(string, unaryop)

fallen igloo
#

I think components is a candidate for a dedicated DR like items/blocks

fallen igloo
median wasp
#

So while you could use recursive as lazy, using lazy makes your intention much clearer

fallen igloo
#

I mean...

image.png
blazing valve
dreamy crystal
#

you could use the regular holder<registrytype> type

reef parcel
#

Because it's a holder, it's just not possible to get around if you also want the specific type of the object. Though, you can get around it by just making a bunch of DeferredBlock, DeferredItem, DeferredDataComponentType, etc. Or yeah, if you don't need specific type, just use the Holder interface

blazing valve
#

Well you do need the specific type especially for data component types

#

We should at least probably patch something into DataComponentMap to make it usable directly in my opinion. For deferred items it's not a problem due to ItemLike, but for the component types, one has to call a lot of .get() to use them with DataComponentMap

reef parcel
#

Then yeah, that should be added to neo as another convenience class

blazing valve
#

Hm, there is also no pre-made CODEC for a DataComponentMap, as far as I can see, right? Only for the patches?

pine egret
#

The tags alone are enough for me to make a stat of sorts

#

Stat merging gets a little weird

wooden tinsel
#

assuming that those things are decoupled from one another

digital drum
#

is there a way to test snapshot versions in userdev?

prisma locust
blazing valve
#

What's the right process to PR to the port?

#

I'd like to add a SINGLE_FLUID_CODEC to FluidStack to mirror the SINGLE_ITEM_CODEC from ItemStack. Essentially a CODEC to serialize the stack without a count

summer furnace
blazing valve
#

Wait but we PR to the port tree and not Kits?

#

Ah interesting, thanks for the reference PR. I'll do that then

summer furnace
#

the idea is to keep Kits strictly for patch work

#

as soon as the patched vanilla code can be removed, it gets transferred to the public repo

elder swallow
#

I think it would make more sense

blazing valve
#

That works, but I'd just mirror ItemStack 1:1 and make one that has amount=1 same as ItemStack.SINGLE_ITEM_CODEC. I understand "SINGLE_MILLIBUCKET_CODEC" is not as sexy

#

but serves the use case of serializing a filter

stray bay
#

just make one with amount=1000

#

error on encode if it doesn't

blazing valve
#

No that's not how the SINGLE_ITEM_CODEC works either 😄

pine egret
#

like, fluid with size 1?

summer furnace
#

and no tags/attachments

pine egret
#

I'd probably want that size to be a parameter instead of fixing to 1 personally, it could be useful for say, a fluid stack in a recipe with size 1000

#

so I don't have to manually set its count after the fact

summer furnace
#

SINGLE_ITEM_CODEC is a codec that stores an Item serialized, but returns an Itemstack

blazing valve
summer furnace
#

no tag/attachment data

#

public static final Codec<ItemStack> SINGLE_ITEM_CODEC = ITEM_NON_AIR_CODEC.xmap(ItemStack::new, ItemStack::getItem);

#

unless it has changed in 1.20.5

blazing valve
#

in 1.20.5:

public static final Codec<ItemStack> SINGLE_ITEM_CODEC = ExtraCodecs.lazyInitializedCodec(
    () -> ExtraCodecs.validate(
            RecordCodecBuilder.create(
                p_332617_ -> p_332617_.group(
                            ITEM_NON_AIR_CODEC.fieldOf("id").forGetter(ItemStack::getItemHolder),
                            ExtraCodecs.strictOptionalField(DataComponentPatch.CODEC, "components", DataComponentPatch.EMPTY)
                                .forGetter(p_332616_ -> p_332616_.components.asPatch())
                        )
                        .apply(p_332617_, (p_332614_, p_332615_) -> new ItemStack(p_332614_, 1, p_332615_))
            ),
            ItemStack::validate
        )
);
summer furnace
#

it has changed, then

#

:P

blazing valve
#

It is actually useful for me now, for storing "item types" (for filters, etc.)

pine egret
#

what about a function that returns a fixed size fluid codec, then a static field for FluidValues.BUCKET_VOLUME

blazing valve
#

That is totally fine, Techs method could be used to expose that

#

I'd just like to have the symmetry with ItemStack here 😄

pine egret
#

or 1, whichever you prefer for the "default", just think bucket is more useful than 1

blazing valve
#

Although I understand "SINGLE" is not great for something uncountable as fluid

#

I suppose a modder would normally use this for filters where the amount shouldn't really matter, but yeah a bucket is likely the "default" amount

summer furnace
#

FLUID_VARIANT_CODEC

pine egret
#

that does remind me that I need such a serializer for my non-codec stuff on 1.19.2, as it has come up

summer furnace
#

or

#

COUNTLESS_FLUID_CODEC

pine egret
#

FLUID_BUCKET_CODEC and static fixedSizeFluidCodec(int size)

#

BUCKET_FLUID_CODEC? either way, I'd just put the count in the name, that is what it is

#

its not really countless, its just fixed

blazing valve
#

Yeah, true enough, it should be easy for a modder to spot the symmetry with SINGLE_ITEM_CODEC in my opinion

pine egret
#

if you want 1, MILLIBUCKET_FLUID_CODEC could be the name

blazing valve
#

1 bucket is fine too, really

elder swallow
#

I like the idea of FluidStack not having a default amount

#

That's why I suggested the static method instead of a codec field

rigid walrus
#

unpick is much better designed for situations like this:

    public static final int TYPE_INSIDE = 0;
    public static final int TYPE_FACE = 1;
    public static final int TYPE_EDGE = 2;
    public static final int TYPE_CORNER = 3;

instead of constants like this:

    public static final char SYNTAX_START_COMPONENTS = '[';
    public static final char SYNTAX_END_COMPONENTS = ']';
    public static final char SYNTAX_COMPONENT_SEPARATOR = ',';
    public static final char SYNTAX_COMPONENT_ASSIGNMENT = '=';
#

It seems to also not support comparisons against 0

elder swallow
#

It's designed with bit masks in mind

#

Could it be limited to those?

#

(e.g. level update flags)

frail hatch
#

Does it also unpick references to glfw?

median wasp
#

Unpick supports both numerical constants and bitmasks

#

I created an unpick file for all of LWJGL 2's OpenGL support

#

It took a few hours

#

It should also work for LWJGL 3, but it won't have as much coverage percentage, since LWJGL 3 has more stuff

digital drum
digital drum
#

nvm got it

rigid walrus
blazing valve
#

That's likely something for Fabric Discord 🤔 I'll ask there

#

But at a glance, I'd agree

lime galleon
true jacinth
#

well yes atm by virtue of the sorting registry everything has to be "inbetween"

#

but functionally they are all just identical

elder swallow
#

For tier sorting I think we can just standardize the level_N tags

#

And ask modders never to use them directly for their tools

#

Then if you are a modpack maker you just override all the tool blacklist tags to do what you want

#

Regarding in-code tier checks... I wouldn't even expect mods to continue using Tier

#

So... probably not worth salvaging that functionality

blazing valve
#

Heh:
Caused by: java.lang.IllegalArgumentException: Data components must implement equals and hashCode. Keep in mind they must also be immutable. Problematic class: class net.minecraft.world.item.BlockItem

blazing valve
#

Dunno if we really need the annotation yet as implementing equals/hashCode would be sufficient. For "true singletons" not part of a registry one wouldn't do that though

#

CC: @elder swallow

reef parcel
#

Iirc, there's a method to call to simply say "ik what I'm doing, this doesn't impl equals/hashcode, but it's fine". That was the compromise over an annotation

stray bay
#

can we just add Block and Item (and modders are responsible for adding other registry object types if they need them) and check superclasses?

reef parcel
#

I'd say always use holders

#

Yes, that breaks specific typing unless you use deferred, but it's already covered by neos validation and avoids all ordering issues

stray bay
digital drum
blazing valve
#

Also: What is the benefit of using holders here?

#

Also: Blergh due to all the codecs it's now very hard to actually figure out which item fails the serialization 😄 It's just deeply nested in Codecs

elder swallow
#

Right above the check

blazing valve
#

That's well hidden. Intentionally so? 😄

#

The flaw I see is that you need to call that for all subclasses of Item

#

and all subclasses of Block

#

since the check is based on the concrete class of the object being attached, and not on the generic type of the component

reef parcel
#

Which is why you should just be using a holder

blazing valve
#

Can you explain why though

elder swallow
#

I think that the registry contains check is fine

blazing valve
#

The markComponentClassAsValid is probably pointless due to the subclass issue, unless we start searching the inheritance tree upwards as well

elder swallow
blazing valve
elder swallow
#

Meh 😄

elder swallow
#

(besides registry objects)

#

Would it be preferable to use Holder? No idea

#

I think that people would expect Block and Item to work

blazing valve
#

the mark method is fine as well

reef parcel
#

I don't see why you wouldn't use a holder. Mc is clearly heading toward data driven elements, so things like block would eventually need a holder. It provides load order safety and is generally covered without needing to be marked as safe. All MC data components which use registry objects use holders.

blazing valve
#

Yes I'd like to know why, though 😛

#

You mean in case datapacks that define blocks get reloaded?

#

Don't misunderstand: If we're to issue a general recommendation to "`just use holders", I'd like to fully understand why 😄

#

I basically just skipped fully understanding holders for the most part and thought of them purely as a mechanism to solve cross-references within the datapack registry objects

stray bay
foggy steeple
#

I would expect blockstate to be the json defined part. Not blocks themselves

#

Like a special blockstate json to define the properties and behaviors of the block with the block as type

stray bay
#

that still means the block instances get reconstructed and replaced on reload

foggy steeple
blazing valve
#

Well let's stay with Item then, for now

#

What happens if you reload a datapack and the Item actually goes away

#

All it can do is crash at that point, no?

stray bay
#

anyway, holders aren't really good enough because squirrsnipe

#

we'd need some sort of special 'optional holder' that devolves to air or whatever if the block disappears from under it

blazing valve
#

Sorry, I need to be more precise: An item that is referenced by your component really no longer exists (so the holder is dangling)

stray bay
#

probably blockstate also wouldn't be suitable at that point, we'd need something that can cope with properties being added or removed even if the same block id does still exist in the registry

#

yeah, i got it, it was the same thing i was getting at just with blocks as the example

#

anyway, dealing with things being made dynamic isn't going to be done overnight

foggy steeple
#

PLS

#

NO AIR SPECIAL ENTRY IN TAGS WHEN REMOVING STUFF

stray bay
#

even if we forbid directly attaching a single block or item, people are definitely going to do, like, "record that contains a List<ItemStack>" for their own attachments and those will

stray bay
foggy steeple
#

The holder would be in the registry right? And if an entry is removed, the holder points to air but still in registry?

stray bay
#

anyway, an object that has e.g. a block as an attachment has to do something when that block is no longer registered.

blazing valve
#

I have no idea what happens and how Holders actually help with this particular problem

fallen igloo
#

why is there a discussion about why not to use holders for something?

stray bay
#

right now blocks can only be removed when the game is fully restarted (due to the mod that registers the block being removed or having its config changed), so it's only a problem for the serialized representation, and the most obvious ways of doing so do result in air

blazing valve
fallen igloo
#

for what usecase?

stray bay
#

hmm

blazing valve
#

DataComponents attached to ItemStack

stray bay
#

really, if we're anticipating the fully dynamic situation [and let's keep in mind we have no idea how many minecraft versions in the future that will be], we should really only be allowing ResourceKeys as attachments

fallen igloo
#

holders are probably better there since resolving if something needs an instance is easier than wrapping if something needs a holder

stray bay
#

[vs registry objects or holders]

#

i guess the question is

fallen igloo
#

I mean a reference holder is just a resource key bound to the registry

stray bay
#

what actually happens to a holder when the registry reloads

#

and what happens if there is no object registered with that name

#

if we don't want to have the discussion about dynamic blocks or items, consider if someone wanted to put, i don't know, a biome as an attachment

#

though really biomes shouldn't be deleted after world creation either, idk what a good example is even for dynamic registries then

blazing valve
#

I'd just really like to understand what the point of holders is right now for Block/Item/et al

stray bay
#

it's future-proofing, the merit is debatable but that is what it is

foggy steeple
#

Existing biome defaults to ocean if biome is removed iirc

fallen igloo
blazing valve
#

One would presumably use a Registry.holderByNameCodec

fallen igloo
#

yes

stray bay
#

codec only really solves the issue for if the value disappears while the game is offline, not in an online resource pack reload

blazing valve
#

One can do that, but why would one do that? 😄

#

No, I was not getting at that at all, just at what you would get (reference or direct) if you were defining a data component

fallen igloo
#

if it comes from a registry it is always a reference

#

and if you want to use something from a non static registry then you don't even have access to Registry.holderByNameCodec only to the RegistryFileCodec like with Biome.CODEC

blazing valve
#

Sure but that is not the case for Block/Item 🤔

stray bay
#

ultimately, people are definitely going to have attachments that are things like records or lists that contain static registry objects and they are going to work fine and nobody is going to have a reason to expect it to cause a problem, so having bare static registry objects as attachments work is necessary for consistency imo

fallen igloo
#

I think staying consistent here is just the easiest way, we need holders for some so just do it for all

elder swallow
#

I don't really see the point of using holders myself

stray bay
#

also, whatever version blocks or items are made dynamic in, presumably there won't be an easily obtainable codec for blocks that doesn't return a holder anyway, so they'll have that pushing them to rewrite to holders

fallen igloo
#

for stuff like GameEvents you need a holder now and you don't always have a RegistryAccess

stray bay
#

you can always get a RegistryAccess from Minecraft or ServerLifecycle if you really need one - unless you also don't know what side you're on i suppose

blazing valve
#

Although that doesn't really help in that case I suppose

#

Anyway, ItemStack still holds an Item internally, so I am really not sure what forcing Holder<Item> is supposed to accomplish atm

fallen igloo
#

I was more talking about usage but you can't get the holder for an entry with a HolderLookup anyway

elder swallow
#

It's also quite annoying to go from Item to Holder, as you need to call that deprecated function

fallen igloo
#

as I said resolving when you need an instance is easier than wrapping when needing a holder

stray bay
elder swallow
#

That's even more annoying 😛

prisma locust
#

it's also much slower

#

the performance overhead of doing a map lookup instead of just reading a field off the object in Forge 1.19/1.20 was significant

#

and I believe Mojang registries also use a map to retrieve delegates

blazing valve
#

Caused by: java.lang.IllegalStateException: Cannot encode empty FluidStack That's gonna cause some bugs 😄

shut wraith
#

Following up from #neoforge-github: how should we make PRs targeting the snapshot that depend on PRs only merged to 1.20.4 and not yet present on the snapshot branch? Just leave the PR targetting 1.20.4 until the snapshot branch is updated?

blazing valve
#

Probably, the snapshot branch should be... rebased? Is that how we'd do that?

#

IIRC we don't wanted new changes targetted at the port branch before porting was done. But I might have missed some follow-up on that.

shut wraith
#

But it depends on tech's earlier resource pack fix which isn't on the porting branch yet

#

But I'm not sure how the process there is supposed to work, so I suppose I'll just leave it as is for now

blazing valve
#

The fix for the resource packs is not strictly related to the 1.20.5 port, so we might want to keep it as a PR and identifiably as its own commit?

shut wraith
#

Ah, so target the 1.20.5 branch once that's a thing

#

I'll leave it as it for now then

blazing valve
#

That's my understanding at least, y eah

#

Primarmily because it might just be all squashed together and rebased i.e. when the next snapshot hits.

shut wraith
blazing valve
#

I thought Tech suggested the commits to be squashed

shut wraith
blazing valve
#

Hm so FluidTank#writeToNBT is just broken right now
Should a platform util-class like FluidTank offer a CODEC and STREAM_CODEC now?

blazing valve
shut wraith
#

Yeah fair enough.

#

Ugh, testing out the snapshot porting branch locally is pain because it's still on gradle 8.1 so I have to manually specify my java path to not be j21

blazing valve
wooden tendon
elder swallow
#

Is there no saveOptional?

#

does this mean that SimpleContainer compacts items now?

image.png
blazing valve
blazing valve
blazing valve
#

It's a start, there is sooooooo many bugs 😐

image.png
edgy arrow
#

call them surprise features and leave them in?

blazing valve
#

This "pattern" for ItemStack stack doesn't work anymore and always returns empty tags 😄

CompoundTag result = new CompoundTag();
stack.save(provider, result);
return result;
elder swallow
#

TierSortingRegistry is nuked for now

true jacinth
#

I think generic level_x tags will be the way to go for that

elder swallow
#

maybe

summer furnace
#

I really dislike the level_x tags, they feel way too rigid

elder swallow
#

they'd only serve as a default

#

modpack makers can do what they want

summer furnace
#

the whole point of tier sorting was to NOT give tiers a number

#

now that vanilla yeets their numbers, we add back our own

true jacinth
summer furnace
#

do they really? or do they just want to know what comes before/after?

true jacinth
#

There are modifiers for tic/silent's/etc that perform the action of +1 mining level, which in essence moves to the next "real" tier

summer furnace
#

yeah but you don't need a number for it, you just need them to be sortable in a deterministic way

true jacinth
#

Well, yes, but the most abstract way to do that is via tags, and in lieu of trying to name all the tags, we would just use a level_x tag

#

they can then be rearranged by pack authors if necessary

reef parcel
#

data maps? thinkies

true jacinth
#

data maps can only bind to registry objects

summer furnace
#

my issue with level_x, is that it gives things hard numbers, which are impossible to reconcile without basically recreating all the tags in every single modpack

#

it doesn't just allow modpack authors to figure things out, it forces them to

true jacinth
#

what thonk

#

your typical modpack would never interface with them

reef parcel
#

oh right, duh.

summer furnace
#

how not?

true jacinth
#

only if the modpack desires to rewrite the mining levels

summer furnace
#

if every mod adds diamond+1

#

every mod has level_5

#

someone has to say which one is 6,7,8

#

(random numbers)

true jacinth
#

I was planning on providing default numbers up to 7 (with 5/6/7 being empty, and 0-4 being the wood-netherite)
I only know of one mod atm that is even adding post-netherite mining levels

#

as long as we provide the default tags mods can set their own equivalencies

summer furnace
#

IMO this is 5 steps back from what we had. I don't have a better idea right now, but I really don't like this one

#

it feels like designing things only thinking of the forgecraft people, and not the wide modding community at large

true jacinth
#

?

#

I don't think forgecraft cares too much about mining levels, lol

carmine raft
#

AutoSwitch would like to know which tool is better than the other
I think in practice I just assume mining speed/damage for that currently

summer furnace
#

I meant that in the sense of msot of the "big names" in modding being there :P

true jacinth
#

I'm making assumptions based on my knowledge of usage history going back to ~1.5.2

#

People will need to be able to do the following in a consistent way:

  1. Set what blocks can be broken by a given tier group
  2. Set what tiers are in a given tier group
  3. Compare tiers
summer furnace
#

I guess I just really hate removing features on the ground of "I don't happen to know anyone who uses it"

true jacinth
#

Modpack authors may need to do the following:
4. Change what blocks can be broken by a given tier group
5. Change what tiers are in a given tier group

#

The easiest way to satisfy all requirements is by having two tag sets, though ideally we would have Tier tags (but that requires making a Registry<Tier>

summer furnace
#

that's another thing. I really have no idea how this would work without tagging the tiers themselves

elder swallow
true jacinth
#

Well you tag all the items that use the tiers, which is a bit ugly
I'm not sure if we can introduce a Registry<Tier> (though, why not, we already have a psuedo-registry)

elder swallow
#

TierSortingRegistry not being able to define equivalent tiers was a flaw in the system IMO

stray bay
#

when was tier sorting even added? 1.17?

summer furnace
#

it wasn't a flaw, it was an explicit design choice

stray bay
#

that was when all the tag stuff was in vanilla anyway

summer furnace
#

it was discussed and decided to do it that way

stiff galleon
#

maybe the design was flawed harold

deep spoke
#

As of the snapshot does vanilla not have ordering in their tiers anymore?

true jacinth
#

vanilla never had ordering

summer furnace
#

it was decided to do it that way for the benefit of modpack authors, so that they would automatically get the tiers to not be "effectively equal" simply by adding blocks to a tag

#

without having to mess with the sorting

true jacinth
#

the snapshot introduced a new tag that is declared by the tier which declares what blocks are invalid for the Tier

stray bay
#

"never" is a big word, vanilla tiers used to be numbered, back in 1.12 at least, maybe even up to 1.16 if i'm remembering right

true jacinth
#

which makes the current model used by the registry invalid

summer furnace
#

yeah I'm not arguing against removing TierSortingRegistry -- makes no sense as things are now

#

I just don't like hardcoded numbers :P

slow prism
#

should I move the port commits on the neo repo to #neoforge-private hmmm

deep spoke
#

Would it be viable to design a new model as opposed to trying to make the old model keep working?

summer furnace
#

that's what we are doing

stray bay
#

I don't think it's a problem if two above-diamond tiers registered by different mods that don't know or care about each other are by default equivalent to each other as long as modpacks can easily change it

summer furnace
#

we just aren't agreeing on what the new system will have to look like

stray bay
#

i do think it's important to be able to register a tier that's between two existing tiers, not just above all existing tiers

deep spoke
#

I mean, a model that does not have ordering

stray bay
#

and it's not clear if the current design has that

elder swallow
lime galleon
true jacinth
#

I've scanned a ton of mods via github search, nobody is injecting "real" tiers (those with different block lists) between the vanilla tiers

stray bay
#

not even terra firma craft?

elder swallow
#

in reality people might just make blocks that can only be broken by select tools

#

i.e. instead of using levels and tiers etc they might just have a list of blocks that require "advanced pickaxes"

true jacinth
#

Not that I could tell, no - the thing is vanilla already has 5 distinct "levels", which is sufficient for progression

deep spoke
#

Are e.g. shears and swords using these tier tags?

stray bay
#

shears do not, swords do but nothing in vanilla cares for sword mining level

lime galleon
# stray bay not even terra firma craft?

TFC has tiers that are in theory between vanilla tiers, but

  1. we don't much care about the exact vanilla compat, and
  2. we don't actually populate our tags because I couldn't make tools that were "exactly equal to" vanilla ones.
summer furnace
#

okay so to recap:

  1. vanilla now has two kinds of tags
    a. first, the "needs_x_tool" block tags, which define which blocks require at least a certain tier
    b. second, the "incorrect_for_x" block tags, which define which blocks cannot be mined by a certain tier. these tags contain "needs_x_tool" tags inside
  2. vanilla no longer has any numbering or ordering on tools, they only use the tiers as a way to provide the tool with a default "block blacklist" tag
  3. modders want a way to compare two tiers and know which tier is higher relativeto each other
    a. modders also want a way to get the next tier up in a chain of tiers, or the next tier down
  4. we cannot do this automatically using tier sorting, because the actual mining hierarchy is far too tag-dependant
deep spoke
#

Hmm, does bamboo instant breaking with any sword count as a "mining level"

true jacinth
#

no

stray bay
#

in principle we could directly compare the tags for comparison purposes

#

if they are exactly equal they're equal, if one is a subset of the other they're ordered, if neither is a subset of the other they're unorderable

deep spoke
reef parcel
stray bay
#

it's also weird because bamboo is technically an axe block, swords are special cased

#

spiderwebs are a normal sword block iirc

deep spoke
#

Ah right, mining levels are only for increased dig speed and whether items drop, right?

summer furnace
#

now, there's two issues with level_x, that I see.

  1. it is impossible to insert a tool between vanilla tags, without overwriting all the tag files
  2. it is impossible to distinguish between "tier branches" defined by different mods. that is, if mod1 says it has a "strongium" and "overpowerium" above netherite, and mod2 says there's "titanium" and "unobtanium", there's no way for a mod to know based on level_x+1, that unobtanium is the successor of titanium, and not "overpowerium"
true jacinth
#

yes

stray bay
#

there is no block in vanilla that specifically requires e.g. an iron sword, so sword tier only really matters for damage and speed [for vanilla blocks and default data, that is]

deep spoke
#

Hmm, does tier of sword affect speed?

stray bay
#

yes

true jacinth
#

The two issues are mostly based on theoreticals though;
In practice, we have not observed anyone doing (1), and there is sufficiently small sample sizes of mods doing (2) that they should be able to agree on which tools go in which "level"

deep spoke
#

Huh, I don't remember wooden vs diamond sword mining at different speeds, but will check.

stray bay
#

hmm

#

sword isn't a subclass of DiggerItem so maybe not

deep spoke
#

Ah, that'll be it then

stray bay
#

ah, swords only have a single tag for blocks, instead of using the tier system

summer furnace
#

as I said before, though, I don't have a better idea

#

if we have to settle for this, we can settle for this

stray bay
#

[well, single tag plus special casing for cobwebs and bamboo]

summer furnace
#

I just don't have to like it

#

so I would like to see if there's a better option

#

before giving up and settling on a bad design

true jacinth
#

I am of the opinion that there are no game design improvements to be made from having more levels jammed into the vanilla space
but also I see no avenues to make it possible due to the tag-backed system

stray bay
#

the normal sword tag includes a ton of stuff actually, mostly plant based stuff like leaves, melons, etc

deep spoke
#

IIRC the sword tag also has some instant-break blocks? Or maybe that was the axe

stray bay
#

afaict it's not better than an axe for those but it's better than bare hand

true jacinth
#

as I don't know how you would reconcile the tags if you could add something between the vanilla tags

elder swallow
#

it's very easy to add something between the vanilla tags

stray bay
elder swallow
#

just add it to the blacklist of all the tools below your tier

#

and add the blacklist of all the tools strictly above your tier to your own blacklist

#

™️

stray bay
#

is it possible to define a tag that includes a tag and then selectively excludes items from it? if not maybe that would be a useful feature to have in general

summer furnace
#

my best idea so far, which doesn't work in practice
would be a way to define tiers in json files, in a way like this: diamond.json - ```
{
"precedessor": "iron",
"incorrect_for_tier": "tag:name"
"repair": "...",
"speed" etc...
}

the predecessor would be used to build a hierarchy tree, and be exposed in some way.

however, it doesn't work well in practice due to there being no hard requirements for the tiers to include each other, meaning if this file isn't kept in sync with the tags, you would end up with higher tiers not being able to mine things lower tiers can mine
elder swallow
#

forget about defining tiers in json files 😄

#

we have tags and nothing else

summer furnace
#

no lol, I make JsonThings :P

elder swallow
#

😛

summer furnace
#

defining tiers in json files is something I will be doing

true jacinth
#

I'm sure tiers will be json files eventually

summer furnace
#

either in neo, or myself

#

I mean I already do, I just have to change it for 1.20.5 :P

#

in any case, that's my best idea, and it's not viable

stray bay
misty crow
stray bay
#

does that remove from entries added by including tags, or only from entries added by earlier datapacks?

summer furnace
#

I don't believe it's recursive

#

it only affects the tags in the current file and predecessors

#

if I remember correctly

stray bay
#

i'm not sure i understand how 'recursive' applies to what i said

misty crow
#

If I recall correctly, all additions (including from referenced tags) are evaluated first and then the removals are done

stray bay
#

that might be workable then

summer furnace
#

I can't find where the removals are, anyone has the code location for it?

#

the tag loading has changed far too much between 1.16.5 and now :P

misty crow
#

TagFile or something like that. The tag loading is ridiculously complicated

elder swallow
summer furnace
#

if (!tagloader$entrywithsource.entry().build(pLookup, tagloader$entrywithsource.remove() ? builder::remove : builder::add)) {
lol

elder swallow
#

add a force-allow override for redstone ore

stray bay
#

oh, are rules available without using the nbt components?

#

i.e. can you construct a list of default rules directly in a DiggerItem

elder swallow
#

keep in mind that each item has its own set of default components

#

DiggerItem does barely anything nowadays

summer furnace
#

items provide default components

stray bay
#

ok that solves that then

elder swallow
#

this is the key thing

image.png
summer furnace
#

the runtime attached components are replacements for the defaults

elder swallow
#

Tier is literally just a convenient way for vanilla to instantiate the corresponding components

stray bay
#

that also means if, say, Project E wants only its dark matter and red matter pickaxes to be able to mine dark and red matter blocks, it can handle them directly in rules and not use a tag so no-one else's above-diamond tiers can do them

elder swallow
#

or well... that might not be fully true yet

#

but I wouldn't be surprised if Tier just disappeared entirely

elder swallow
stray bay
#

and if we want to find out if one tool is strictly better than another we can build the set of all blocks that their rules allow them to mine, and determine if one is a subset of the other

#

(set comparison is an expensive operation but it could be cached)

elder swallow
#

you can only do that by iterating the block registry

#

or caching

stray bay
#

iterating the rules

#

but yeah basically, it's still expensive and should be cached

#

enum Orderability { LESS, GREATER, EQUIVALENT, UNORDERED } Map<Pair<Item, Item>, Orderability> cache; etc

#

we don't really need a way to say "these two unorderable tiers sit between the same vanilla tiers / are both above diamond" since we can compare to the vanilla tiers as well to answer that if we are interested in knowing it

#

and i am deeply unconvinced that "i want to be able to mine other mods' tier 5 blocks but not their tier 6 blocks" is a thing, though "I want to be able to mine any block that can be mined by any tool" [so excluding bedrock, barriers, technical blocks] probably is.

elder swallow
#

yeah I think that the concept of global mining levels is/was quite flawed

#

you generally want mod progressions to be separated

fallen igloo
#

can we please defer the replacement of the tier system until someone actually requests a system with a usecase and not just model a system after the old system which was based on the Tier enum just because that is how it worked before

#

(and we shouldn't count "I want a system that works like before because xyz" as a request with a usecase)

elder swallow
#

yeah that's more or less what I did by nuking the TierSortingRegistry

fallen igloo
#

did you also nuke the associated packets and config tasks

elder swallow
#

yes

fallen igloo
#

👍

elder swallow
#

just pushed the bump to FML v3

#

now we have neoforge.mods.toml

true jacinth
#

norge.mods

slow prism
#

@elder swallow don't forget to rename the tests mods.toml too thinkies

fallen igloo
#

and the testframework one too

elder swallow
#

Did I forget them?

wild pine
elder swallow
#

why is the bot there thinkies

stiff galleon
#

bots can't even copyright their code smh

elder swallow
#

ok it was my mistake

#

I force-pushed the bot out

fallen igloo
#

we need to sign the cla with the bot account @slow prism

elder swallow
#

Well do we

#

It's not supposed to end up in the squashed commits, it was my mistake

stiff galleon
blazing valve
#

Can we link to an article explaining the usage from the bot comment?

slow prism
slow prism
fallen igloo
#

because in the future I want the bot to do the squashing too

restive raft
slow prism
#

it's a gh app

stray bay
#

can github somehow be told "squash all these commits and the resulting commit has 'CLA signed' status if all of the original commits do"?

wooden tendon
#

no

restive raft
#

we (or possibly I -- I forget which among us enabled the CLA assistant, and if management access is locked to whoever enabled it) might be able to import it into the CLA assistant manually

slow prism
fallen igloo
#

Can I allow bot user contributions?
Since there's no way for bot users (such as Dependabot or Greenkeeper) to sign a CLA, you may want to allow their contributions without it. You can do so by importing their names (in this case dependabot[bot] and greenkeeper[bot]) in the CLA assistant dashboard.
from the cla-assistant faq

blazing valve
#

Oh, interesting small change that caused many of my custom item models to become "invisible"

#

The ItemColors now expect the returned color to include an alpha component

#

(which mine didn't, leading to alpha=0 -> invisible)

stray bay
#

huh

#

i wonder if block colors do it too if the block model itself renders in the translucent render type

#

[they almost certainly don't if it doesn't, and i have no prediction for if it'll affect cutout thresholds]

blazing valve
#

I did the lazy thing and just wrap all my ItemColors at registration time now lol

# 
private static ItemColor makeOpaque(ItemColor itemColor) {
    return (stack, tintIndex) -> FastColor.ARGB32.opaque(itemColor.getColor(stack, tintIndex));
}
stray bay
#

huh, if it does, using an alpha block color to randomize cutout thresholds could be an interesting thing to do to, say, leaves

blazing valve
#

now, how did I move a block to the translucent layer to try this

#

I have not touched this in so long

prisma locust
#

specify it in the json model

blazing valve
#

Ah, we're still using ItemBlockRenderTypes

prisma locust
#

yes, but also no

stray bay
#

there was a plan to deprecate ItemBlockRenderTypes at one point but it is never going to happen

blazing valve
#

Another item for the "move back to forgisms" backlog

#

Okay this model does not look right in translucent 😄

#

But since the color is visible, I'd say it does not respect alpha of the blockcolor

#

Yeah it doesn't. Looking at Vanillas code, it just extracts RGB from it. While the item renderer now extracts ARGB from it

stray bay
#

huh i didn't realize you could color ME chests - how do you do it? i know terminals just take it from the attached cable

blazing valve
#

color applicator

#

Ah. render_type in a multipart model is likely just ignored, is it?

stray bay
#

you have to specify it in the parts

#

since part of the point of the thing is to have different quads in different render types

blazing valve
#

Yeah, looks okay then. But as stated above it ignores the alpha anyway

dreamy crystal
# blazing valve

I wonder if this means they're going to fix translucent item rendering 🤔

#

specifically, these parts

image.png image.png
restive raft
#

though I forgot that FAQ even existed

prisma locust
#

the PR publishing still appears broken

elder swallow
slow prism
blazing valve
#

So we gotta rebase the port?

#

Our workflows are not great for that 😅

slow prism
#

I mean it has to happen at some point but yeah

prisma locust
#

I would greatly appreciate rebasing it

#

and would be willing to try and help if someone explained what needs to be done

blazing valve
#

I can rebase it, the problem is that I couldn't push it to the original repo and PR-ing a rebase is not possible heh

prisma locust
#

we can't commit directly to the snapshot branch?

slow prism
#

he can't

#

he's not a maintainer

prisma locust
#

I see

elder swallow
#

I can rebase later

blazing valve
#

I think I'll even get our CI/CD to pass once the snapshot is actually published 🤔

#

The AE2 port is kinda done. Tests pass and all.

fallen igloo
#

snapshot day

restive raft
#

it is Wednesday, my dudes

wooden tendon
#

No this is patrick!

short cove
#

Has mojang typically released snapshots the week before April fools in the past?

#

They're fixing bugs so we'll definitely get those

#

But it's probably a much smaller snapshot than we've been seeing

clear bane
#

depends
they could have had a few people work on the april fools version\

fallen igloo
#

gegy 🐸 or no 🐸 ?

foggy steeple
#

Snapshot today now parallelizes entity ticking on off threads to break all entity mods

#

(Joking)

summer furnace
#

they are certainly resolving a lot of tickets

stiff galleon
#

april fool's snapshot will have a bunch of random custom blocks

foggy steeple
#

Random blocks of John Cena

fallen igloo
restive raft
#

they're doing a lot of merges to prep for the snapshot /jk

elder swallow
rigid walrus
#

I pushed the changes for the unpick definitions that I currently have to the unpick branch although it currently requires running the publishToMavenLocal gradle task with the latest commit on the unpick repo

elder swallow
#

👍

stray bay
stiff galleon
#

itemstacks are now multithreaded

fallen igloo
#

hmm no 🐸 yet

reef parcel
#

these snapshots have been pretty late recently thinkies

elder swallow
#

they just found an issue with their CompletableFutures

#

damn I just crashed with io.netty.handler.codec.EncoderException: Pipeline has no outbound protocol configured, can't process packet net.minecraft.network.protocol.common.ClientboundKeepAlivePacket@63336b67

#

why is this not fixed yet wat

fallen igloo
#

our race condition?

elder swallow
#

yeah

#

well, mojang's

dapper hornet
elder swallow
#

at last

stiff galleon
#

Maces enchanted with Wind Burst will emit a Wind Burst upon hitting an enemy, launching the attacker upward and enabling the linking of smash attacks one after the other

elder swallow
#

very cool gameplay changes

slow prism
#

Non-default components on item stacks containing block items are now stored on block entities when placed

elder swallow
#

this sounds like a MapCodec-ification

image.png
#

BE components?

slow prism
#

yeah curious

lean anchor
#

Did nobody raise the alarm?

#

smh

elder swallow
#

maty dewit

slow prism
#

<@&1067092163520909374>

elder swallow
digital drum
#

any big diffs?

stiff galleon
#

bad omen is no longer given by killing raid captains, is instead given by drinking ominous bottle

elder swallow
#

LETS GOOOOO

cloud raven
#

Oh shit yeah I forgot it's wednesday

digital drum
#

finally 😭🔥

elder swallow
#

ok there's a billion codec-related changes lol

lean anchor
#

oh god, Density V on a mace..

#

+5 damage per block fallen

elder swallow
stiff galleon
#

bad omen now drops itemized from raid captains and vaults and is basically a "drink this to fight the uber version" now

digital drum
slow prism
#

it actually is

digital drum
lean anchor
#

oh good, I won't accidentally set off raids in villager farms anymore

image.png
elder swallow
#

there's a few things left in ExtraCodecs

plucky brook
#

But they've purged extra codecs as far as possible?

stiff galleon
#

wait... components on blockentities?

digital drum
elder swallow
#

of course

image.png
#

that is awfully close to attachments 😂

digital drum
#

BlockEntity#load -> BlockEntity#loadAdditional

blazing valve
#

Well do they just store it to maintain state of the item placing the BE?

elder swallow
#

what is this crap

image.png
blazing valve
#

wdym crap 😄

#

There was no data component map codec before, I told ya

digital drum
#

why not just place the codec in DataComponentMap

elder swallow
#

yeah ik

elder swallow
blazing valve
#

and the get/getOrDefault methods in ItemStack were not implementing any interface

elder swallow
blazing valve
#

Oh, why the hell

#

I didn't notice that 🤔

digital drum
#

BlockEntity.applyComponents -> BlockEntity.applyImplicitComponents(BlockEntity.DataComponentInput)

slow prism
#

can BEs have components that they actually use independent of items

digital drum
#

BlockEntity.applyComponents -> applyImplicitComponents

#

saveWithoutMetadata -> saveCustomOnly

#

wait no

#

saveWithoutMetadata still exists

#

but does smth else

#

what data components may a BE have?

elder swallow
digital drum
#

TrialSpawner's config system has changed a bit

elder swallow
#

wtf is .split().added()

blazing valve
#

Gut feeling: they apply all supported components to the internal BE state

#

but keep any unsupported components around for when the BE gets turned back into an item

elder swallow
#

yeah that's exactly what they do

slow prism
#

people will be so annoyed about immutability

elder swallow
#

oh yeah cause the patch is Map<type, Optional<component>>

blazing valve
#

Well the BEs internals aren't

elder swallow
#

so they separate the "addition" and "removal"

digital drum
#

AbstractProjectileDispenseBehavior is gone

elder swallow
digital drum
#

just listing the changes

elder swallow
#

generally we try to only list the relevant changes 😄

digital drum
#

got it

elder swallow
elder swallow
blazing valve
#

People can always just use CustomData

#

because it's trivial to port

#

CustomData as the data-type for a mod-specific attachment

elder swallow
#

sure but it's not mutable

#

(or well you're not supposed to mutate it)

blazing valve
#

CustomData.update(MyModComponents.STUFF, stack, tag -> { tag.putString("blah", "123");});

#

Is not that hard to do

elder swallow
#

oh that's quite nice heh

plucky brook
elder swallow
#

yes

plucky brook
#

Fine by me thinkies

blazing valve
#

So, honestly? I went the "hard" route of making everything custom records in custom attachments 😄

#

but there is a lower effort path

elder swallow
#

yeah

#

well I'd probably do a low effort port first and then slowly clean it up

plucky brook
#

Old NBT data not handled by datafixers are just in custom data, right?

elder swallow
#

who knows

dapper hornet
#

anything major technical this time ?

wild pine
#

once ported to this snapshot will the pr (#748) be updated and "fixed" to allow the pr publishing to publish?

restive raft
#

probably

digital drum
#

is this the last snapshot?

restive raft
#

we have no idea

stray bay
# elder swallow BE components?

I'm guessing that the plan is to eventually de-legacy-ify the custom_name stuff and the other stuff is a bonus. Though I can think of several mods that have enchantable blocks that would benefit from this.

reef parcel
#

looking back at 1.20.1, MobEffects are significantly better now (onEffectStarted, onEffectAdded, onMobRemoved, onMobHurt, etc)

blazing valve
#

So, the BE is only storing the patch though, right?

#

Meaning it doesn't have any of the item-default components available

stray bay
elder swallow
slow prism
#

bad mojang

elder swallow
#

Not sure how it's populated

slow prism
#

that's in basecontainer be

stray bay
#

ah, nice

blazing valve
slow prism
#

it relies on each block manually calling collectImplicitComponents

blazing valve
stray bay
#

there used to be a big if/else statement for, at least, all instantaneous effects, now HealOrHarm is its own class et c

reef parcel
blazing valve
reef parcel
#

oo, wait, can you also define custom particles too now in mob effects?

#

yeah, you can. i missed that somehow

blazing valve
#

Well and in the last snapshot they only calledSavetoItem in creative mode context lol

fallen igloo
#

has anyone checked if they changed potion recipes in any way (except for adding new ones)

reef parcel
#

just did lol was wondering the same

#

it is. the same

#

unfortunately

fallen igloo
fallen igloo
#

welp time to wait for the unpick release so we can get the new unpick neoform

rigid walrus
blazing valve
#

How could I actually help with ports like that? Well. Can I? 😄

summer furnace
#

you are Maintainer, you definitely can choose to participate in the "patch churn"

#

although that's neoform, that's decompile post-processing right?

fallen igloo
#

that's not the patchening that's working on NeoForm patches

#

it is making the decompiled source compile on all common compilers and fixing decompiler errors

blazing valve
#

Yes, I have no idea of the process though, and how to avoid stepping on each others feet

fallen igloo
#

coeh is the only one who knows afaik

kind sable
#

Huh interesting didn't know they were still updating this game.... Good on them. /S

#

Interesting snapshot
I'm not a huge fan of all the tags they are adding tho....
Like there are too many and not everything has every tag. They added tags for immune for 2 potions... What if I want to make something immune to some other effects?

#

I think some of these tags should be auto created for each type. Like if you register in a new effect it auto makes an empty "immue_to_xyz" tag

#

Same goes for the mobs and how some have poisonous/ tempt extra tags but most only have food

fallen igloo
#

the thing that bothers me most is the inconsistencies between cat and wolf feeding

boreal flint
#

the thing that bothers me is mace functionally invalidating basically all combat for mods

#

lol

kind sable
#

Yeah... What the hell is "is_meat"??

boreal flint
#

😉

slow prism
#

time to join the "refusing to update" club?

kind sable
#

I think they are gonna Nerf the mace enchant a bit more

rigid walrus
kind sable
#

Also the mace is really terrain dependent...
If you don't have any height difference than it isn't that great

boreal flint
#

uh no

kind sable
#

Unless you also have a bunch of wind chargers

boreal flint
#

it applies after 1.5 blocks fallen

#

and with enchants scales to like 12dmg/block

#

so you can oneshot most standard mobs with even a slight incline

#

ad on top of that the other enchant launches you back up

#

so you can then just chain it

#

and if they were gonna nerf it, they wouldn't have added half of this stuff to begin with (or the advancement for dealing 100 dmg in a hit???)

kind sable
#

I think they are gonna change the enchantment to only do 0.5dmg/block/level

boreal flint
#

lol right..

#

that's why they're doubling down on it

#

so they can go back on it later

kind sable
#

But also it is not that easy to get a mace....

boreal flint
#

OP is OP no matter how long it takes to get

#

idk why people don't seem to understand that lol

kind sable
#

Anyway mods can always make their mobs resistant to mace

boreal flint
#

so dumb

#

I'm gonna end up having to nerf its scaling and apply a bunch of durability damage or something

#

it's just gonna be stupid

reef parcel
#

i enjoy it's capabilities frankly. it's more game-y and fun

rigid walrus
#

they added an inner class to BlockEntity that currently only has a codec to read components from the components field

elder swallow
#

Yeah it's cursed

#

Probably just a lazy singleton

#

Maybe that's the new lazilyInitializedCodec

median wasp
#

There's probably more plans for the class

dry stumpBOT
#

[Reference to](#mojira message) #mojira [➤ ](#mojira message)This ticket has just been resolved as Fixed!

technici4n referenced ·
Technici4n
[MC-268727] Server disconnects the client when sending a keepalive packet while transitioning out of configuration phase

Hello, there is a tricky race condition in the latest snapshot, due to the server-side handling of ServerboundFinishConfigurationPacket. The packet is terminal, which causes the connection to become unbound immediately when it is received. It is then queued for processing on the main thread, which will eventually setup the outbound GAME protocol. In the meanwhile, it can happen that a keep alive packet is sent to the client, causing an immediate disconnection due to
I have created a 24w07a Fabric mod that does exactly this, you can find it at https://github.com/Technici4n/MC-268727-repro.

Status

Resolved as Fixed <t:1711619724:R>

Fix Version

Future Update

Assignee

[Mojang] Timur Nazarov

Votes

2

Comments

1

Created

<t:1708685884:R>

Quoted
elder swallow
#

Finally hehe

dapper hornet
#

for the snapshot versions, are there any changes related to how mod is detected and loaded ? I am testing a minimal project on the last snapshot build and the mod isnt being detected/loaded at all. No logs either. I think I am missing something

slow prism
#

the mods.toml file was renamed

foggy steeple
#

Is there no logging?

summer furnace
#

I hoped we would have some warning if a mods.toml file is detected but not a neo.mods.toml

#

just like we detect a fabric mod

dapper hornet
foggy steeple
#

Who did rename and no logging stabolb

#

That’s a stab moment

slow prism
summer furnace
#

we don't?

#

I'm fairly certain we used to

slow prism
#

no, that code hasn't worked since 1.17 or earlier

summer furnace
#

huh

slow prism
#

(thank god)

summer furnace
#

it definitely did work in the past

slow prism
#

as I've said many times before, with the current locator design any kind of warning or other loader detection would be bad

summer furnace
#

we really need this warning though