1.21.5 Snapshots

[gleaming pendant]

I'll look into it once stuff compiles

Fluids I don't want to look into so I suggest we keep the rejects around until someone volunteers to fix them

[frank sigil]

I'm doing it right now, I'm adding an interface that needs to be implemented by the component and is checked if it can perform the action

[gleaming pendant]

No please don't do a hacky fix like that

Let's do the proper thing it's quite simple

[frank sigil]

what do you mean hacky my solution is clean

[glass wagon]

There are currently 2 item sub predicates: ItemAbilityPredicate and PiglinCurrencyItemPredicate

[gleaming pendant]

Lol 😛

"Interface implemented by the component" sounds really cursed

[frank sigil]

well how would you do it? the only other thing I could think of is on the item properties

I was thinking doing this in the item extension would work:

default boolean canPerformAction(ItemStack stack, ItemAbility itemAbility) {
    for (TypedDataComponent<?> component : stack.getComponents()) {
        if (component.value() instanceof IAbilityComponent abilityComponent && abilityComponent.canPerformAction(stack, itemAbility)) {
            return true;
        }
    }
    return false;
}

so anyone can say my component makes the item able to do X

[glass wagon]

DataComponentHolder.getAllOfType

[frank sigil]

default boolean canPerformAction(ItemStack stack, ItemAbility itemAbility) {
    return stack.getAllOfType(IAbilityComponent.class)
            .anyMatch(abilityComponent -> abilityComponent.canPerformAction(stack, itemAbility));
}

the question is just how do we patch it into the Tool record since pickaxe, axe, hoe and shovel all use it

with the only difference being the tag

[fleet dome]

Is there precedent in Vanilla for the component objects having OOP-ish behavior in them?

I've seen them more as attached data with behavior living elsewhere so far

[frank sigil]

yea the tooltip stuff

welp my impl does not work because of a stream codec...

do we have a way to make a connection type dependant stream codec?

I need to skip the abilities if the other side is not neo

found it

9 files to go

[glass wagon]

for ItemAbilityPredicate DataComponentPredicate can only get a specific component without casting DataComponentGetter

[lunar saffron]

You can't just skip them, otherwise we're basically back to the "share tag" nonsense of the past where the excluded data was lost when the creative inventory came into play

[frank sigil]

well we need to skip them for vanilla clients because they don't know about the existance of abilities

it will be synced for neo clients but not for other

[lunar saffron]

Not syncing them at all is not an option. We need a more elaborate solution, which is the whole reason why Tech told you to wait and let him do it, he already has a plan for solving this

[drifting finch]

Syncing them is also not an option

Because the vanilla client has no idea that they exist

And will never process them anyway

[frank sigil]

yea and since it is about default components on the item it won't get overwritten anyway

[haughty spade]

well, they may be default "by default"

but components can be added to a stack separately from the defaults

[frank sigil]

well yea but I don't think the client ever overrides what the server has

and if the server is neo then the abilities should persist

[haughty spade]

creative menu replaces server stacks with client provided stacks in many cases

[drifting finch]

Whcih does not matter here

[haughty spade]

like not just the ones you drag from the item list

[drifting finch]

because the vanilla client will never know the components

So we will never receive them anyway

Which means that the default components will hold

Because they are not overriden during deserialization...... /me thinks

[haughty spade]

yeah

the issue, IMO, isn't the default components

those shouldn't be a problem

[frank sigil]

I think xfact and tech wanted to put it in the arbitrary data component and read it from there which is not clean

[haughty spade]

but we can't add an ability component and then tell people not to use it dynamically

[drifting finch]

That is a workable idea in my opinion, but way less clean then the driven solution you implemented

[haughty spade]

because people need to do that

[drifting finch]

They still can

Just that it won't effect the vanilla client

[frank sigil]

we don't add a new component, because we can't (components are a synced registry)

neo can NEVER add a component type without breaking vanilla client compat, what I did is patch it in the tool component

[drifting finch]

That should be fine

[haughty spade]

how's that extra data sent to the client?

[drifting finch]

I agree with XFact though

This needs to be tested with a vanilla client

[haughty spade]

if it's encoded in the tool component, it will be discarded by vanilla clients

[drifting finch]

Which IMHO is fine-ish

[frank sigil]

with a connection dependent stream codec

[haughty spade]

so, a vanilla client connects in creative mode, drags a couple stacks around, and then that info is immediately lost

[drifting finch]

IMHO that might be fine

Because that is what the client wants no?

[haughty spade]

it's not what the user wants, though

[frank sigil]

idk how the creative inventory works nowadays

[haughty spade]

same as it has always done, in essence

[drifting finch]

Is it?

Because the user is using a vanilla client

....

[haughty spade]

yes

but the ability list is something the server is actively using to make decisions

[drifting finch]

Agreed it is at least 50% unwatned

[haughty spade]

and then suddenly poof, gone

that custom itemstack with tool properties stops being able to act as a pickaxe

[drifting finch]

Given that is vanilla behaviour

That should not be changed

[haughty spade]

but we ARE changing it, that's the whole point of the abilities

they replace hardcoded vanilla logic

[drifting finch]

Except that it is not hardcoded anymore.....

It is a component on the itemstack

[haughty spade]

then we should get rid of the abilities for which it is no longer hardcoded

if ToolComponent is enough to convey the information about which actions the tool can take

then our canPerformAction should be implemented to use that information

[drifting finch]

https://minecraft.wiki/w/Data_component_format#tool

As far as I can see this makes every possible variation possible

Custom shears

Tool combinations

[haughty spade]

yeah but it also introduces a huge issue

[drifting finch]

etc

[haughty spade]

we can't give that custom tool component a name

we can't say "yep it's a pickaxe"

we may be thinking of this from the wrong direction

[drifting finch]

Well you are

There is no concept of a pickaxe

There is just a concept of: This is a tool, and this is the correct tool for the harvest of this block

That is all

[haughty spade]

no, I go to the item list, and there's multiple that are called Pickaxe, and they mine similar kinds of blocks

[drifting finch]

That is backwards

Because you can't ask it from the item list alone

[haughty spade]

yes that's the point I was trying to make

[drifting finch]

You need to take the thing you are trying to harvest into account

[haughty spade]

currently, as of 1.21.4, the item ability system is going in this direction

which is now obsolete

[drifting finch]

I know

And in my opinion it is backwards

[haughty spade]

that's why I said we may be thinking this from the wrong direction

[drifting finch]

Ah okey

Well yeah

[haughty spade]

because preserving this idea may be the wrong solution

[drifting finch]

Correct

[haughty spade]

the question then becomes: what do mods need out of this?

what features do modders need?

[drifting finch]

Unsure

[haughty spade]

who is calling canPerformAction, and what decisions are made based on it?

[drifting finch]

I mean things like entirely custom tools are possible with this

Regardless of what the item or harvested resource is

Items like the paxel are possible

Because you can add multiple rules

[haughty spade]

I can list these off the top of my head, but I assume there's more:

1. identify if the current tool is valid for the thing you are looking at
2. automatic tool switching
3. non-world interactions (eg. placing a tool in a "magic ore generator" machine)

[drifting finch]

Making combi tools trivial

1 & 2 are easy

[haughty spade]

1 and 2 can be done with the ToolComponent alone

[drifting finch]

I am pretty sure there is someway to simulate the Tool Components behaviour

That leaves tree

[haughty spade]

just checking the compatibility tag + digging speed stat

[drifting finch]

Yeah

And 3 is also easy

The ore generator knows the tool

And has a collection of resources it can generate

It just needs to check whether or not it is the correct tool for the resource, like 1 and 2 do

So that all seems fine

[haughty spade]

not necessarily, many mods "like that" want to automatically support all mod additions without hardcoding

[drifting finch]

That will work

[haughty spade]

yeah so

[drifting finch]

Because if it is a custom tool, it will have the component (which internally determines what it can harvest)

And if is talking abouve custom modded resources: They need to be added to the tag anyway so that a player can harvest them

[haughty spade]

I would argue, all the _DIG abilities can go.

[drifting finch]

100%

Sword + Shield as well

[haughty spade]

can we say the same for _STRIP, _SCRAPE and _WAX_OFF?

[drifting finch]

Unsure

[haughty spade]

and _FLATTEN and _DOUSE

[drifting finch]

Depends on how that is implemented these days

I would need to check

[haughty spade]

and carve and disarm and trim ... and till and cast and throw ... damn we ended up with a LOT of abilities lol

[drifting finch]

Yep

[haughty spade]

this list was MUCH shorter when I wrote it

[drifting finch]

Lets go down the list

[haughty spade]

looking at 1.21.1 cos that's the dev env I have here at the work computer ```java
// Default actions supported by each tool type
public static final Set<ItemAbility> DEFAULT_AXE_ACTIONS = of(AXE_DIG, AXE_STRIP, AXE_SCRAPE, AXE_WAX_OFF);
public static final Set<ItemAbility> DEFAULT_HOE_ACTIONS = of(HOE_DIG, HOE_TILL);
public static final Set<ItemAbility> DEFAULT_SHOVEL_ACTIONS = of(SHOVEL_DIG, SHOVEL_FLATTEN, SHOVEL_DOUSE);
public static final Set<ItemAbility> DEFAULT_PICKAXE_ACTIONS = of(PICKAXE_DIG);
public static final Set<ItemAbility> DEFAULT_SWORD_ACTIONS = of(SWORD_DIG, SWORD_SWEEP);
public static final Set<ItemAbility> DEFAULT_SHEARS_ACTIONS = of(SHEARS_DIG, SHEARS_HARVEST, SHEARS_REMOVE_ARMOR, SHEARS_CARVE, SHEARS_DISARM, SHEARS_TRIM);
public static final Set<ItemAbility> DEFAULT_SHIELD_ACTIONS = of(SHIELD_BLOCK);
public static final Set<ItemAbility> DEFAULT_FISHING_ROD_ACTIONS = of(FISHING_ROD_CAST);
public static final Set<ItemAbility> DEFAULT_TRIDENT_ACTIONS = of(TRIDENT_THROW);
public static final Set<ItemAbility> DEFAULT_BRUSH_ACTIONS = of(BRUSH_BRUSH);
public static final Set<ItemAbility> DEFAULT_FLINT_ACTIONS = of(FIRESTARTER_LIGHT);
public static final Set<ItemAbility> DEFAULT_FIRECHARGE_ACTIONS = of(FIRESTARTER_LIGHT);

[drifting finch]

STRIP can stay

That seems to route through: getToolModifiedState

Which should be fine

https://github.com/neoforged/Kits/blob/25w06a/src/main/java/net/neoforged/neoforge/common/extensions/IBlockExtension.java#L762

Anything in here should be fine

[haughty spade]

I assume by that, that vanilla stripping is still hardcoded?

[drifting finch]

No

That is also routed through here

See the check for AXE_STRIP

[haughty spade]

no I mean, in vanilla

[drifting finch]

It is hardcoded in vanilla yeah

As far as I can see

[haughty spade]

we use getToolModifiedState because it is hardcoded in vanilla

[drifting finch]

Because its code resides natively in the ItemAxe item

Yeah all of these are hardcoded

As far as I can see

So that should not matter

It is purely the DIG it seems where we need to refactor

[haughty spade]

yeah I see it: https://github.com/neoforged/Kits/blob/25w06a/projects/neoforge/src/main/java/net/minecraft/world/item/AxeItem.java

was this ever considered as a datamap?

[drifting finch]

Maybe unsure

It would make a good candidate to be honest

[haughty spade]

yeah - block -> stripped block

[drifting finch]

We should probably add it

But it is not currently

OXIDATION is

[floral mesa]

why? why is it a requirement that everyone be forced to datagen if the code-based solution has literally no downsides besides not generating json files?

at that point all it does is change the source of the data

[trail fable]

as someone who fucks around with modpacks and datapacks on a semi-regular basis: if we do this, PLEASE add a way to export to a datapack

my first step when trying to change something data-driven is to extract the relevant mod jar(s) and work with the integrated datapack

and it is EXTREMELY frustrating to see recipes or similar in game, but not in the datapack

it makes things needlessly confusing and hard to trace

[compact hare]

ARRP moment

[haughty spade]

yeah IMO everything that might be wanted to be edited by a user should be a json file if at all possible

(or some other file format that is present in the jar and easily editable by a datapack/resource pack)

[trail fable]

I am not against the idea per se, but I want this to easily be extractable to JSON for use cases that require it

[frank sigil]

if people can register stuff to dp registries from code what hinders them to not even make a codec for it and thus produce a non serializable state

[warm night]

It is almost tomorrow

[haughty spade]

by varying definitions of "almost"

cos timezones

[oblique tusk]

New Zealand is already in our tomorrow

and likely Australia as well

[frank sigil]

Keep:

• AXE_STRIP
• AXE_SCRAPE
• AXE_WAX_OFF
• HOE_TILL
• SHOVEL_FLATTEN
• SHOVEL_DOUSE
• SWORD_SWEEP (vanilla uses swords tag)
• SHEARS_HARVEST (vanilla uses .is(Items.SHEARS))
• SHEARS_REMOVE_ARMOR (vanilla uses .is(Items.SHEARS))
• SHEARS_CARVE (vanilla uses .is(Items.SHEARS))
• SHEARS_DISARM (vanilla uses .is(Items.SHEARS))
• SHEARS_TRIM (used in getToolModifiedState)
• FISHING_ROD_CAST (vanilla uses .is(Items.FISHING_ROD))
• BRUSH_BRUSH (vanilla uses .is(Items.BRUSH))
• FIRESTARTER_LIGHT (used in getToolModifiedState)

Remove:

• AXE_DIG
• HOE_DIG
• SHOVEL_DIG
• PICKAXE_DIG
• SWORD_DIG
• SHEARS_DIG
• SHIELD_BLOCK

Unknown:

• TRIDENT_THROW (not used anywhere)

we could use tags for the shears stuff and a neoforge tag for sweep

[trail fable]

I'd also use tags for fishing rods and brushes there

simply because why not™️

[gleaming pendant]

Tags are not a replacement for tool actions

[trail fable]

what can tool actions do that tags cannot

[gleaming pendant]

NBT awareness (components now)

[drifting finch]

Yeah we should not replace them with tags

But we can trivially replace the DIG actions with the relevant Components

The rest is not a problem anyway

Because their implementation is not in danger

[gleaming pendant]

I don't think so

[drifting finch]

Given that mojang already has with the tool component, It is not a question of thinking, but rather a fixed stated fact

Unless we missed something

[gleaming pendant]

These actions don't do anything, they exist as metadata

[drifting finch]

So does the tool component

[trail fable]

so why not have people check for the relevant component being present instead

[drifting finch]

Vanilla already does that for them

So that is not really a problem

[trail fable]

exactly

[drifting finch]

Regardless

Tech might be right

Both giga and I might have missed something

Which is not unthinkable

So if he has a usecase that is not covered by it

Then that needs to be addressed

[gleaming pendant]

Ask yourself how you'd query whether an item stack is a pickaxe-type item or not

[drifting finch]

You are not

As discussed above

That concept does not exist

Because even a fence can be a pickaxe-like

[trail fable]

what does pickaxe-type item mean

[drifting finch]

Because it is has a tool rule that makes it so

The concept of a "pickaxe", "axe", "shovel" is gone

At least from the perspective of the item it self

[gleaming pendant]

It means that the player understands that it acts similarly to a pickaxe

[trail fable]

if you want to know if it is a tool with the "breaks pickaxe block" tool rule, then query the tool component and check if it has that relevant component

[trail fable]

"what the player understands" is never a rule to go by, ever

[gleaming pendant]

Well you could check if it can break stone ig

[drifting finch]

Whether it acts similar to a pickaxe is depending on what you target

[drifting finch]

That can trivially be checked against the tool component

[frank sigil]

but what about recipes... I saw some mod using a tool action ingredient and this can not be replaced by a component ingredient because you can't check pickaxe/shovel/axe

[drifting finch]

And additionally depends on the loaded datapacks on the server

[trail fable]

that would've been Farmer's Delight iirc

[drifting finch]

May I assume that the recipe is at least contextual? If not then I wonder why the tool is there in the first place.

But if it is, then the recipe just as the player can again derive whether a given item can harvest a given resource from the tool component

[gleaming pendant]

That is supported by the engine, but not obvious to players. There is a disconnect between what the system allows mods/datapacks to do, and what players perceive

[drifting finch]

Not really........ Because whether some itemstack is a tool that can harvest stone, wheat, dirt etc, is highly contextual to the world the player is in and what datapacks / resourcepacks are loaded.

So there is no real disconnect

[haughty spade]

my SewingKit mod used tool action ingredients too, but either I changed it in 1.21.x already or I wouldn't see it as a problem to change it over to a tag

[frank sigil]

how would you do that in an ingredient/item predicate?

[drifting finch]

As the world creates the stacks with the relevant components so that they match the context that the player is in

[drifting finch]

That entirely depends on the context, you would need to give me an example recipe

Like the tool represents something in the recipe

ANd that representation should be embedded in the ingredient/item predicate/custom recipe

The intent is what matters

Not whether it is actually a "pickaxe"/"axe" etc

[trail fable]

iirc farmers delight has this (pseudocode but you get the idea)

{
  "type": "farmersdelight:cutting",
  "input": "minecraft:oak_log",
  "tool_action": "neoforge:axe_stripping",
  "output": [
    {
      "item": "minecraft:stripped_oak_log"
    },
    {
      "item": "farmersdelight:bark"
    }
  ]
}

[drifting finch]

If the intent of the player is to use the itemstack (regardless of item) as a harvest tool for say stone

Then that intent needs to be reflected in the thing that controls that check

[haughty spade]

okay I already changed it so nevermind https://github.com/gigaherz/SewingKit/blob/a7e111a5fe1fa27e6af01f56e1698ccd108d417c/src/main/java/dev/gigaherz/sewingkit/SewingKitDataGen.java#L514

[drifting finch]

Different story, as those stay, so not currently a problem

But you would need to implement the cutting recipe in such a way that it checks whether the intent of the item is to "cut" the relevant resource

[trail fable]

well yeah, but imagine that we replaced it with axe_dig instead

[drifting finch]

Okey

The intent of such a recipe would be to do some processing with the "axe" if the axe is able to process the block next to it for example?

[trail fable]

because I do think there are recipes in FD which use pickaxe_dig for e.g. amethyst block -> amethyst shards

[drifting finch]

Then the implementation should check whether or not the tool component allows the harvest for that block

[trail fable]

I agree

[drifting finch]

So solved

[trail fable]

and I think this is semi-trivial to do

yeah

[drifting finch]

It is actually extremely trivial, blockitem -> default blockstate -> tool component check

There is no complex process here

[trail fable]

yeah

I'm not trying to work against you here Orion, just so that's clear :P

[drifting finch]

The advantage of using the cmponent here is that now when you have a custom world which makes a fence a tool that can harvest logs etc, it will work as well

Natively

[drifting finch]

Completely understood

[trail fable]

I'm actually trying to support your point by providing an example and showing a solution

[drifting finch]

But it is important that we discuss these situations through

So that we can figure out if our solution works

[trail fable]

I don't see a problem with the solution

[drifting finch]

Me neither

[trail fable]

personally, I think it might be desirable to include this ingredient type with Neo natively

[drifting finch]

That is difficult

[trail fable]

i.e. a item predicate ingredient or something like that, because that is what it boils down to

[drifting finch]

Because an ingredient is focused on a single slot

[trail fable]

why is that difficult?

[drifting finch]

While such an interaction is with a seperate slot (or none at all) in the same recipe

[floral mesa]

is a correct summary of what's going on here that the idea of a pickaxe item has been replaced by an item having a component that says "acts like a pickaxe"?

[drifting finch]

To check whether slot A contains a valid axe, it needs to know what it is going to harvest, which will reside in a different slot

[trail fable]

it's being replaced by the already-present "breaks pickaxe-breakable blocks" tool rule

[trail fable]

... no?

[drifting finch]

Not quite, but more like: the idea of a "pickaxe" has been replaced with a data component that says: "harvests like a pickaxe did in the past"

[trail fable]

whether it is considered an axe is dependent on the tool's component

not on whatever item is there in the other slot

[drifting finch]

And the target 😄

The rules in the component check what you are trying to harvest

[trail fable]

why is the target relevant here?

[floral mesa]

Ok so tools can now conditionally decide whether they harvest like pickaxes

[trail fable]

okay wait hold up

[drifting finch]

Yeah based on what they are targetting

[floral mesa]

That's incredibly inconvenient for recipes yeah

[drifting finch]

With different speeds etc

[floral mesa]

To be fair, this was probably already an issue before

[trail fable]

I don't have an IDE available, can you show me what the "breakable" tool rule's check looks like

[drifting finch]

They need to check 2 slots, not for recipes, but for ingredients

[haughty spade]

you can heuristically decide "it's an axe if its valid items lost contains the items an axe can mine

[drifting finch]

Sure one sec

[drifting finch]

You could indeed feed it the tag yeah

[drifting finch]

https://minecraft.wiki/w/Data_component_format#tool

Notice that the rules section actually filters for a given block

[trail fable]

hm

[drifting finch]

So you can have a mega dump diamond pickaxe which mines everything but obsidian

For example

[trail fable]

[NBT List / JSON Array] blocks: The blocks to match with. Can be a block ID or a block tag with a #, or a list of block IDs.
is there any info kept in code about whether this is a tag or not?

[drifting finch]

It is a holder list last time i checked

So no

[trail fable]

hm

[drifting finch]

Hence me always speeking of the intent of the player

It is the intent of the player that controls all of this

[trail fable]

how feasible would it be to do a subset check with the tag and the list of breakable blocks?

[drifting finch]

Not what the item wants

[floral mesa]

my first impression is that will be way too slow in a pack where the mineable tag is huge

[drifting finch]

You can do that trivially, but that is not needed

[frank sigil]

HolderSet so you can check if it is a named (so a tag)

[drifting finch]

As I said, you can do this with a custom recipe easily

A custom recipe can just get the "axe"

[trail fable]

yeah that's what I was thinking as well, but idk how optimized it is so it may not actually be a problem

[drifting finch]

and the other block in it

And check for the intent to harvest

If true then the recipe matches

If not then no

[trail fable]

I mean honestly, I could see the point in having that be a crafting recipe

[drifting finch]

We could provide a shapeless recipe yeah in that direction

[trail fable]

"any pickaxe-like item" + quartz block -> 4 quartz items

[drifting finch]

As an example of how to do it

[drifting finch]

Well it would be: anything that can harvest the item in the other slot + quartz -> 4 quartz item

The recipe can be generic

To be specific:

[trail fable]

well yeah, this was just an example

[drifting finch]

Any tool matching quartz + quartz -> 4 quartz item

Because the "blocks" entry in the rule might not always be a tag

It could be a list or a direct item as well in the component data

[trail fable]

yeah, exactly

[drifting finch]

For example a pickaxe that can only harvest quartz

All in all I don't think there is a situation where the intent of the modder/player is not expressable in the question: Can this tool harvest this block? when it comes to the *_DIG abilities

[frank sigil]

SHIELD_BLOCK can go too

[haughty spade]

yeah that became a component

I remember people putting it on a sword to make a pre-1.9-ish sword

[merry falcon]

Can’t we just waifu the ItemAbility usages and see what people are querying and for what

[drifting finch]

I did that earlier today

I have to say Waifu is nice maty very nice

[torpid sandal]

The main ones I used are block transform queries

[torpid sandal]

Usually the question is "does this tool act like a pickaxe"

E.g. you have some sort of miner villager who wishes to use a pickaxe

[drifting finch]

That is the wrong question in modern day minecraft though

[torpid sandal]

No it's not

[drifting finch]

The concept of a pickaxe is now solely defined by whether any given item can harvest any given other block

[torpid sandal]

We have pickaxe tags from vanilla

[drifting finch]

Then check that

[torpid sandal]

They aren't NBT sensitive

[drifting finch]

But if your logic asks: "behaves" questions, then you need to check the tool tag

[drifting finch]

Then check the tool component

[torpid sandal]

And before you say it, components are nbt

[drifting finch]

Yeah I mean that

If you need something that is NBT specific

Then check the relevant tool component

In any other case the tag should suffice

Unless I am misunderstanding what you mean with "nbt sensitive"

What kind of "nbt sensitive" are we talking about here?

(cause extracting that from WAIFU is actually not possible as far as I know)

[dark wasp]

fundamentally I think there's three tiers of nbt-sensitive

A) itemstack has a specific component
B) itemstack has a specific component with exact value
C) itemstack has a component with non-trivial or context-dependent value predication (e.g. enchanted with silk touch)

[drifting finch]

THat is not what I mean.....

We are explicitly not looking for a "binary" compatible solution that is just plug and play.

I want to understand the usage of the "NBT". What are you doing with it in the abilities callback that you need the NBT exactly?

The onlything I can imagine is for a filter / energy check / speed check (all of which can also be implemented through the tool component)

Like what are you semantically doing in the cases A, B and C

[torpid sandal]

My experience with vanilla tells me said component will be hard coded to a degree that I cant practically use it without losing functionality. This is nearly equivalent to telling me "just extend pickaxe item"

[torpid sandal]

Have you seriously never played tinkers construct or tetra?

[drifting finch]

I understand your sentiment, but that is not really helping us at all.

[drifting finch]

Yes

Which is why I am like 99% sure you can configure the tool component to do what you need

[torpid sandal]

So you are going to try and lead the direction Neo should go in this area wiithout having any knowledge of what mods actually want

[drifting finch]

You just might need to set it, next to whatever other component you currently read

[torpid sandal]

Gotta love returning to that paradigm

[drifting finch]

.....

That is not at all what I am saying to trying to do

[torpid sandal]

How about this, make a post in a more accessible location. Say, a RFC on GitHub. Tell people you are planning to drop pickaxe dig and alike, and your proposed alternative

[drifting finch]

That is not going to happen

[torpid sandal]

See what the modders who were querying that say, along with what the other tool mods devs say

[drifting finch]

This is exactly the place where we discuss these changes

[torpid sandal]

Otherwise I'm forced to believe your goals aren't being a compatibility layer in Neo

[drifting finch]

You are free to constructively provide feedback, usage examples etc

[floral mesa]

i think the context that we are dropping this as part of trying to port to a snapshot, while already being a full snapshot behind, is important

[torpid sandal]

If you don't care to discuss with the community

[drifting finch]

So that everybody that works on this API can constructively and combined with each come to a proper result

[floral mesa]

it's not like we're changing it on a whim

the old paradigm simply can't apply unchanged

[drifting finch]

It is also not like mojang has not set a completly different precedent

[torpid sandal]

My usecase is tinkers construct

We mine blocks with broader tags than vanilla

[drifting finch]

With it requiring, often, a combination of data components to get a specific result

[torpid sandal]

But it still mines everything a pickaxe does

[drifting finch]

So? Set one or more tool rules, that achieve the desired result

[torpid sandal]

My experience with modloader devs is they will believe that a solution works without verifying it, causing me trouble when I port later. Have you verified that it's possible to expose the pickaxe component without being limited to exclusively that behavior?

[drifting finch]

Yes

I already verified that

[torpid sandal]

Remember that the harvest tier, is going to vary based on NBT too

[drifting finch]

And tested it, because there are vanilla commands that allow you to do so

[torpid sandal]

Along with the mining speed

[drifting finch]

Yes that is implementable

Please read up on the tool component posted above

[torpid sandal]

Vanilla commands are set via NBT those properties

My goal is set via different NBT the vanilla properties

[drifting finch]

And that is my point; you might need to set your NBT for your processing, and the tool component to do the proper processing on dig etc

Because that is the precedent mojang has set

With how components in general work

[torpid sandal]

Yeah, that's always the reason people use to change features that don't benefit mod

[drifting finch]

?

Why would this not benefit mods

[torpid sandal]

Don't tell me of mojangs precedent. Tell me it's not a loss of functionality

[drifting finch]

It is not

[torpid sandal]

If it's not, then I can work with that

[drifting finch]

It just means you need to set 2 components

Instead of one

Which is not a loss of functionality

[torpid sandal]

And make sure you understand what the functionality is in requesting

[drifting finch]

Because mojang is moving away from one massive element, to small composable elements

[torpid sandal]

Tinkers is over a decade old, play it for 5 minutes to make sure you understand ot

[proven compass]

iirc this was also a networking thing cuz it's checked on the client

[drifting finch]

I did

I undersdtand it

[torpid sandal]

You just said 5 minutes ago you never have

[floral mesa]

I think most people in this discussion have played Tinkers before and know the general idea

[drifting finch]

You can rebuild it completely in vanilla these days..........

[torpid sandal]

No you can't

[proven compass]

I believe it was discussed making a strippable data map but vanilla clients won't work w it

[drifting finch]

Sorry i misread the question

I have played Tinkers before

Even made addons for it

[torpid sandal]

You woefully misunderstand the mod if you think being able to set harvest components via commands is rebuilding the mod

[drifting finch]

Well probably not completely

But a good part of it can be rebuild

Thinks like different tool parts from different materials

That create different tool levels

With different mining speeds

All can be rebuild

Swords might be difficult

Components for it exist

[torpid sandal]

The whole point of combining parts is that combine behaviors

[drifting finch]

But that does not mean that the completely flexibility for that is achievable (like slash speed, equip reload speed)

[drifting finch]

That is still possible

[torpid sandal]

There is no concept in vanilla of adding two stars together to get a larger stats via component id wager

Sure, I can implement that in Java

[drifting finch]

There is

You can implement that

Through custom recipes

[floral mesa]

The point is you dynamically manipulate the vanilla components on the tool

[drifting finch]

Exactly

[floral mesa]

Instead of hardcoding them like the default tools do

[drifting finch]

I assume he dynamically alters his own component?

I have not checked Tinkers code because I am at work

[floral mesa]

well it's still NBT, but yes, afaik

[drifting finch]

But from working on addons back then tinkers just manipulated his own NBT

So that is completely similar to how components work

[torpid sandal]

We have not done that in 5 years

[drifting finch]

I expected as much

Given your expertise in this area and developing mods it should be much improved now

Regardless of whether you use components or not

[torpid sandal]

We have a list of materials, a list of modifiers, and combine those together to compute behaviors some of which are right now cached in NBT and others are queried directly from the modifiers

I've been told it should be possible to generate vanilla components based on mine

[drifting finch]

Well consider the mineable blocks and speed simply cached in NBT

[torpid sandal]

My concern is some vanilla components impose too strong behaviors that I only want part of

[drifting finch]

And with mineable blocks, they are HolderSets

So they could be anything you need internally

[torpid sandal]

Can I register new holder set types in Neo?

And can I register a type specific to blocks?

[drifting finch]

Unsure....... right now

Does anybody know that

[dark wasp]

yes

[drifting finch]

Currently at work

[dark wasp]

I designed the system to support that

[torpid sandal]

I know neo adds some custom types

[drifting finch]

Ah okey

Well then yeah

[dark wasp]

specific to blocks? probably not

[torpid sandal]

That as in both questions?

[dark wasp]

I only read the first question before I wrote the answer, no

[raven blade]

Ig you can error if it's not blocks lol

[drifting finch]

Yeah you can make it specific to blocks

[dark wasp]

yeah, what's the context here

[drifting finch]

By erroring out

[torpid sandal]

Yeah, might be forced to instanceof

[drifting finch]

The question is do you need to

[torpid sandal]

Some of my minability is based on other registries

[drifting finch]

So?

[torpid sandal]

Rather than being a tag

So my current behavior queries that registry to see if it's valid

[drifting finch]

I assume it is a combination of other mineable tags

[torpid sandal]

No

[drifting finch]

Well other tags then

[torpid sandal]

I said other registers

[dark wasp]

a holderset is fundamentally just an ordered set of registrables

[torpid sandal]

No

[drifting finch]

Okey

[torpid sandal]

Easiest to explain as they are recipes

[drifting finch]

But you should still be able to go from: Tool setup -> List of mineable blocks?

Right?

[torpid sandal]

Should be doable, may not be the most efficient thing in some cases but it can be cached somewhere globally probably

[drifting finch]

You would technically only need to compute this when the tool configuration changes, correct? (and then cache it in the tool component)

[torpid sandal]

Sure, but tool configuration can change a lot

[dark wasp]

lemme try to understand what you're trying to say you need here

you want to parse a set of blocks, but only certain blocks are valid members of that set, you want to predicate/validate the block instance somehow in a manner which requires that you actually have a Block in order to test it

is that correct?

[torpid sandal]

So I'll probably need a second layer on that cache

[drifting finch]

Yeah but you get notified everytime it does

Like you know when the table crafts the configuration

Or when a recipe applies an upgrade

And that does not happen too often

[torpid sandal]

Basically, yes. Do holder sets require me to know all the members ahead of time or can they be determined later?

My experience with ItemStack NBT says it parses on world load before recipes load

But maybe components fixed that timing

[dark wasp]

holdersets fundamentally cannot be parsed until after the registries load

err

[torpid sandal]

On 1.20 I've had some bugs where on server connect, verifyTagAfterLoad runs before tags load

It's a fun time

[frank sigil]

knight the only thing you can't easily do with the vanilla system that you had before is variable mining speed based on things that are not just the block that is being mined, everything else should be doable with tool rules

[dark wasp]

important concept of holdersets is that they reevaluate whenever tags load

[drifting finch]

The item itself also has influence

[torpid sandal]

Neo still have an event for that?

[dark wasp]

they are baked, but not finalized

[drifting finch]

So the data you have is: item that is used as tool + the target

[dark wasp]

holdersets are actually mutable, they have listeners/callbacks to the registries to update themselves after tag load

[drifting finch]

And I am not aware of any system in tinkers, even right now looking through its code, that requires more then that information

[frank sigil]

I think so yea

[torpid sandal]

Works for me

[dark wasp]

so, even if the holderset loads before tags do, it's a moot point, because the holderset reloads whenever tags do

[torpid sandal]

Any of my weirder computations can just use said event worst case

[dark wasp]

(mojang designed tag holdersets to do that)

[torpid sandal]

That's what I was asking, good that it works

Means custom holder set is what I need rather than just computing a list and tossing it in a list holder set probably

[frank sigil]

tool rules basically define a tag plus an optional mining speed and optionally if that rule makes it able to drop

so not using a tinkers example but a paxle would just have all the rules for pickaxe, axe, hoe and shovel

[dark wasp]

are the rules composable like that?

[drifting finch]

Yeah

The first rule where the target matches is taken though

So you need to take a bit of care with crafting your rules list

But in practice the composeability is nice

[frank sigil]

public float getMiningSpeed(BlockState p_336131_) {
    for (Tool.Rule tool$rule : this.rules) {
        if (tool$rule.speed.isPresent() && p_336131_.is(tool$rule.blocks)) {
            return tool$rule.speed.get();
        }
    }

    return this.defaultMiningSpeed;
}

public boolean isCorrectForDrops(BlockState p_336189_) {
    for (Tool.Rule tool$rule : this.rules) {
        if (tool$rule.correctForDrops.isPresent() && p_336189_.is(tool$rule.blocks)) {
            return tool$rule.correctForDrops.get();
        }
    }

    return false;
}

and tools just use

Tool.Rule.deniesDrops(incorrectTierTag),
Tool.Rule.minesAndDrops(minableWithTag, speed)

and as minableWithTag you can use an OrHolderSet with all the tool tags you want

or if you want different speeds use separate rules

[frank sigil]

ok we have a big TODO for later with abilities but for now we still have the ticket system and some fluid related patches

[raven blade]

when are we redoing fluids?

[merry falcon]

i could put up a bounty for whoever does a redo of fluid api and gets pr merged

[gleaming pendant]

I'd start fixing all compilation errors

It will be easier to test these things once they run

[frank sigil]

hmm mojira is back and it knows that a user for my email address exists but the password is wrong and resetting doesn't work

according to the build I just did 140 compile errors

[floral mesa]

I hope the current mojira theme is just a bad configuration and not the intended theme

[frank sigil]

yea it looks... empty

[weak wasp]

I mean, I can do it again, I just don't think it'll work on the Fluid level (or at least match vanilla) as the fluid velocity logic is tied to a group of fluids rather than the individual flowing and still objects

[frank sigil]

it is just stupid that still and flowing are separate fluids, mojang pls fix thx

[frail patio]

Sorry to bother you again but I've been porting more APIs and the fact that UnbakedModel no longer extends ResolvableModel is annoying (equivalently, the fact that the only possible dependency - the parent - is hardcoded in ModelDiscovery.ModelWrapper). Custom UnbakedModel implementations may have more dependencies than just their parent. Custom UnbakedModel implementations may also want to directly interact with their model dependencies as UnbakedModel objects, and use them to determine what the top value for each property is (the values cached in ModelDiscovery.ModelWrapper in each slot); the logic for deciding the top value is currently hardcoded in ModelDiscovery.ModelWrapper.

Unhardcoding these things would be great, but if it's too much unnecessary work for vanilla I understand too. Making an API for these things is possible, albeit not trivial.

[weak wasp]

UnbakedModel should never touch other UnbakedModels as that would implement a race condition given that they are loaded in parallel. You could try to have one UnbakedModel contain multiple instances, not cleanly, but possible. As for the ResolvedModel, I could see extensions of that similar to the model loader system where an UnbakedModel can specify what resolver to use

[frail patio]

The retrieval of UnbakedModels would happen in a separate method in UnbakedModel and the method would only be called during discovery

[weak wasp]

Sure, but that's essentially saying that an UnbakedModel (model JSON) has some type to specify how to resolve its dependencies

Which is fine

[frail patio]

It would be unhardcoding the inner part of the loop in ModelDiscovery.discoverDependencies

[frail patio]

What do you mean by type?

If UnbakedModel extends ResolvableModel it can just provide its dependencies though it, then get UnbakedModel objects for those dependencies in the new method

[weak wasp]

I'm imagining some identifier used to say, don't resolve to a ModelWrapper, resolve to my object instead

[frail patio]

That's a bad idea because ModelWrapper controls the caching, and I don't think anyone wants to reimplement caching

If the caching isn't a concern then maybe that would work too

[weak wasp]

The wrapper itself only does caching based on the ModelState, which is for block states

Could be mistaken about that though

[frail patio]

It has 7 cache slots

[weak wasp]

Oh, are you talking about loading the other properties like the texture and stuff?

[tardy leaf]

*It has 7 hardcoded slots + a map for generic use, which vanilla uses for storing baked quads per model state

[frail patio]

Right

[weak wasp]

The only thing I would consider a cache there would be the model state. The rest are just resolving the model itself, except stored in some arbitrary reference

[tardy leaf]

I don't see UnbakedModel as anything more than collection of properties
If you want to carry more stuff, add more properties

[frail patio]

That is also planned, but how am I supposed to add parent2 if dealing with dependencies is completely hardcoded in discovery?

[tardy leaf]

The question is what use case needs parent2?

It's a job of model above to request all dependencies

[frail patio]

Neo adds composite models (I mean those in models/) which effectively have an arbitrary amount of parents

[torpid sandal]

sometimes I wonder whether Mojang looks at Tinkers' Construct source code to design some of their changes

its not identical code, but its the same design I use

makes sense though they would go that route, my system was written in part to ensure all vanilla tools could be implemented, even weird ones like shears and swords

[tardy leaf]

There is a refactor pending that might clarify it, but I think natural place for extended models is "leaf" of blockstate, i.e. generalization of Variant

[weak wasp]

It would be nice if Variant could do something similar to the item composite model

[tardy leaf]

you have state dispatch (and randomization) in front, it spits out a model something for specific position that had access to various baked resources, including very static, very limited existing UnbakedModel

[weak wasp]

But still, having UnbakedModel be a ResvolableModel still wouldn't solve the issue since it would still need some ResolvedModel instance to get the required quads for baking

[frail patio]

I agree with that, though having actual types in the blockstate file like in item files would be great

[weak wasp]

Not to mention nothing really takes in an arbitrary model, instead relying on the direct list of BakedQuads or a QuadCollection, meaning more abstraction would need to be done

[frail patio]

Indeed, only extending ResolvableModel doesn't do much because it would only unhardcode one thing

[tardy leaf]

I hope I can get that refactor through, but it's unlikely to happen by tomorrow

[weak wasp]

The best bet would be to provide the model loader stuff on the BlockStateModel, allowing composites or whatever there instead

I feel like touching the model JSON pipeline would be too much of a hassle, at least the more I look into it

[frail patio]

Without types that seems difficult

[weak wasp]

Well, you could always specify that in a loader

[frail patio]

Variant and multipart entries can only define resource models, not something like a composite

[weak wasp]

It seems much easier to patch since you effectively can control what quads to choose and how it bakes

[frail patio]

Loader where?

[weak wasp]

On the block state definition file itself

You might need to reimplement some behavior, but I think that's better than a mess of patches

[frail patio]

Well yes but how exactly? Make it so anywhere where vanilla allows a model reference you can use an object with "type" instead that uses the corresponding custom deserializer?

[weak wasp]

Either that or you just take over the entire blockstate file

Would need to think about it more since both systems have plenty of annoyances

[merry falcon]

You need more redbull

[weak wasp]

It would boil down to which is less annoying to implement and maintain

[drifting finch]

Take your time boq

[tardy leaf]

How about loading your magic in parallel with simple models and then providing it in model bakery?
I don't think we are going to support our static models carrying magic, because if anything can happen in there, we can't be responsible for loading that in parallel. And if format is not extensible, forcing extensions is also not great.
Take a look at how item models work, there is static model and then custom - that's the goal

[frail patio]

I suppose if you still want to support part of the vanilla format, the codecs are available, though changing anything about the format would require remaking all codecs

[weak wasp]

I don't really see a better way due to the QuadCollection stuff and direct BakedQuad passing in the item model

[frail patio]

Loading can still happen in parallel since no references should be resolved/exposed during loading; In my suggestions I only meant that where ModelDiscovery already does resolve references/interact with UnbakedModel it would just delegate the logic to some object that the UnbakedModel would own/produce/create instead of it being hardcoded in ModelDiscovery (in my initial message I implied that this object would be the UnbakedModel itself but that isn't necessary)

I completely agree with models/ models being static and block/item models being dynamic and I'm not suggesting a change to this. Any use case of the suggested extensions would still only allow a custom UnbakedModel to produce static values/geometry

[tardy leaf]

I'd suggest to stop thinking in terms of UnbakedModel. This file having a parent is already a mistake and a loading cost. It should be controlled by single file only

[frail patio]

Ah hm

[tardy leaf]

Want two parents? Bake two models

After refactors BlockStateModel actually returns a list of parts. In this version some upcasting might be needed, but it's a well defined point where code can diverge between vanilla and modding

[frail patio]

Indeed, it would be diverging anyway

[frail patio]

So would your response to a use case like "I want my UnbakedModel to replace its parent's UnbakedGeometry such that the ModelState it receives is transformed by an arbitrary matrix" would be to pass the transformed ModelState to ResolvedModel.bakeTopGeometry in a custom BlockStateModel.Unbaked/ItemModel.Unbaked?

(To be clear that use case existed as a Fabric API test)

[lunar saffron]

Neo's "root transforms" also basically work like that

[frail patio]

Yes, the test was trying to replicate those

I feel like it's less of a problem for Neo because the property is standardized so it can inject the logic directly into ModelDiscovery.ModelWrapper.bakeTopGeometry via patch

[lunar saffron]

That's true, yeah

[frail patio]

If the goal is to remove any sort of references between models/ models then indeed my suggestions don't really make sense, but I didn't know that was the direction vanilla was heading

[tardy leaf]

arbitrary state is a weird case, since you can just instrument default implementation of UnbakedGeometry

[frail patio]

Requiring modification of the vanilla code for that is somewhat part of the problem I'm trying to solve

[tardy leaf]

That modified ModelState comes from somewhere. If you can already replace implementation to something that creates whatever horror wearsModelState's skin, you can also just replace it with something that knows how to bake their own model type directly

[frail patio]

You mean BlockStateModel.Unbaked/ItemModel.Unbaked?

[tardy leaf]

Yeah

[frail patio]

Makes sense

[tardy leaf]

I know it might be a cost to build loading infrastructure next to existing one, but considering your (potentially unbound) list of potential modification and our ongoing refactors, having stable code on the side might be worthwhile

[frail patio]

I suppose it can only be stable if it is known what your plans are for models, but I think you have made them clear enough for this purpose today

Though I'm not entire sure whether #1313560104359956542 message is actually true

[floral mesa]

history will repeat itself if we build custom loading infrastructure

isn't that basically what happened in 1.12? 😂

but boq is right, that's basically what I do for my dynamic model loading optimization now

much easier than trying to hack it into vanilla's new code

[frail patio]

I was about to say, that is the only real, full reimplementation of model loading

[floral mesa]

well, kinda, I still use the vanilla codecs etc

[frail patio]

Everything modloaders provide is effectively small hooks/modifications to vanilla loading code

[floral mesa]

and in 1.21.5 I'm still using ModelWrapper, although I manage parent resolution myself instead of using ModelDiscovery

[tardy leaf]

I don't think that dependency is going to disappear, not without full format redo
but I don't have plans to make more of it

but that format is a bit of dead-end, since it's shared between items and blocks, which have different requirements

[frail patio]

A unified source of static geometry is great (as in, convenient for resource pack and mod developers)

If it could be unified with entities that would be even better

[fleet dome]

It is more concrete than just generic static geometry though

The current format, that is

[frail patio]

How can geometry be more static than static geometry?

What do you mean?

[tardy leaf]

it's a bunch of cubes

[frail patio]

Yes, that's what I mean by static geometry

[frank sigil]

down to 90 compile errors

[haughty spade]

someday we'll see meshes and animation curves stored in vram and processed in the vertex shader, where all entities using the same model draw in 1 instanced rendering draw call
dreams

[frail patio]

[raven blade]

what beautiful dreams you have

[floral mesa]

down to 61 compile errors

57

most remaining errors are gametests or forced chunks

[cinder saffron]

Excellent, almost ready in time for the (potential) new snapshot!

[floral mesa]

issue: we're one snapshot behind already

[proven compass]

they gave you an extra week before giving you double work

[haughty spade]

once the porting is over adapting to a new snapshot shouldn't be world-breaking though

[proven compass]

Lil break

[haughty spade]

unless it is, that is

[proven compass]

until they refactor everything u just ported

[steep hamlet]

no?
they released a snapshot a day later

[proven compass]

oh was that sheep colors

its exam week that feels like a while ago mb 😅

[winged salmon]

https://www.minecraft.net/en-us/article/minecraft-snapshot-25w08a

spawn egg updated looks

sheared sheep have colour on java pog

[haughty spade]

<@&1067092163520909374>

Light the fire! Start the engines!

[marsh mural]

Changelog: https://www.minecraft.net/en-us/article/minecraft-snapshot-25w08a
SnowMan: https://github.com/neoforged/Snowman/commit/3fa401d1ea5193ad82fd293e467e3e934aec0063
Primer: https://github.com/neoforged/.github/blob/c719ec587021129993fe2a76e21df8939aa6aee9/primers/1.21.5/index.md
-# Changes: https://github.com/neoforged/.github/pull/14/commits/c719ec587021129993fe2a76e21df8939aa6aee9

Slicedlimes Videos:

• Main: https://www.youtube.com/watch?v=owMWwa5nnKg
• Data/Resource Pack Changes: https://www.youtube.com/watch?v=Og1-oecZxzk

[haughty spade]

HAH!!!

Overhauled the visuals of each Spawn Egg to improve readability and accessibility

[spice geyser]

[haughty spade]

I LITERALLY JUST DID THAT SAME THING IN MY EYES MOD

used a custom icon instead of the vanilla colors one

"just" I mean, in the 1.21.4 port for it

[cinder saffron]

Ah, so they got you this time. Happens to someone every week, it feels like.

[haughty spade]

my egg icon will match vanilla better in 1.21.5+ lol

no no

I did the vanilla before vanilla did it

:P

my mod in 1.21.4:

[winged salmon]

Actually a banger snapshot

[haughty spade]

oooh

oh so the shape itself changes

For example, smaller mobs tend to have a smaller Spawn Egg

[winged salmon]

a mod I used to work on in 1.16.5:

[marsh mural]

-# Added snowman link

[haughty spade]

wut

they made new wolf variants, but only in sound

[merry falcon]

Yeah I did the same for my mod too a while back. No one should be doing default egg look lol

[haughty spade]

it used to be the easy choice

just pick 2 colors

but now with client items

it's harder than making your own texture lol

[merry falcon]

5 spawn eggs in this pic (one is a fake spawn egg that is craftable)

[haughty spade]

heh

[marsh mural]

oh thats gonna mess me up, im so used to the creative tab icon being pig

[haughty spade]

heh

[weak wasp]

The spawn egg template is gone now because of the change

[haughty spade]

oh wow they are WAY MORE SPECIFIC than I expected!

[fiery tusk]

😮 cool

[stiff flicker]

oh wow

[merry falcon]

Enchanted books when

[haughty spade]

they should have used the allay egg for the tab

or the cow one

[cinder saffron]

Could you send a screenshot of the spawn eggs tab, so we can see all the different egg textures?

[haughty spade]

I just did that

well not the tab

[merry falcon]

Nope, you’re invisible

[haughty spade]

I searched Egg

[cinder saffron]

Oh. Whoops.

I stepped away for about three seconds and then forgot to scroll up.

[cinder saffron]

Wow, those are weird.

[winged salmon]

they look cool

[merry falcon]

They are accessibility friendly

[cinder saffron]

That is true.

[wanton apex]

I know a texture pack to make.
"Old Spawn Egg Textures"

[haughty spade]

heh

I "photoshopped" my egg next to the vanilla ones. it looks kinda boring now lol

it's fitting though

[wanton apex]

hm

[haughty spade]

so I think I'll keep it as-is

[winged salmon]

I find it nice how the ones from the mod I used to work on fit pretty well with them already lol

[haughty spade]

yeah

[lunar saffron]

Visual wolf variants were added a while ago

[haughty spade]

yeah I toyed around wit hthe variants

now they have texture variant + sound variatn separately

[marsh mural]

mojang fixing a whoopsie i see

Looth

[haughty spade]

heh

[wanton apex]

Looth

[final kiln]

i love these

wither and dragon spawn eggs

[final kiln]

wild to think that i'm one of the first non-mojang people to see these two

[real bolt]

Sheep now has a separate texture for its wool undercoat, which is dynamically recolored in-game

[marsh mural]

well thats good to know, the helper for generating spawn eggs from the template was removed (and i assume the template json itself is also gone)
makes sense cause mojang no longer needs them
but thats a pain for modders, forces you to make an actual spawn egg texture now rather than using the old template

[haughty spade]

I assume they mean tinting, like the wool itself?

[real bolt]

It's something Neo could probably ship

[real bolt]

It's shown in the cover image

[haughty spade]

no point shipping something mojang no longer uses

people just need to draw icons for their eggs

[sterile abyss]

https://www.youtube.com/watch?v=0OhUrjGkHso

[thin cairn]

Using the old textures would violate the new design style and look out of place, so yeah, Neo definitely shouldn't add it back

[marsh mural]

yeah i agree, much prefer the uniquie texters per spawn egg
makes finding a specific mobs egg alot easier
just thought i would let people know that helper (and potentially json too) are gone now, for those that who were using them

[thin cairn]

If modders want to just use the old one and violate the modern style, that's on them. They shouldn't be aided by the loader though

[haughty spade]

yep yep

[winged salmon]

the article says that the pngs are removed

[marsh mural]

ahh, i dont read the changelog tbh, i dive straight into reading the code changes

[final kiln]

hmm golom

[weak wasp]

Why is all wolf sounds a datacomponent now?

Apparently its now a variant thing

[haughty spade]

yeah, there's multiple sound variants for wolf

I guess they made it a component so it can be stored in the spawn egg for the wolf

[thin cairn]

I wonder when Mojang will bump Gson

[marsh mural]

yeah sounds look to be tied to a specific wolf, not the variant of wolf
so i guess stored on the item so that commands and such can specify what sounds a wolf will spawn with

[fleet dome]

I am such a sucker for good icons

and those spawn eggs are fire

[marsh mural]

missed opportunity to have shulker egg be animated, poking its head out every now and then /hj

[cinder saffron]

Do you want to cause us more work in trying to hold to the vanilla style?

[wanton apex]

okay, someone gotta suggest that

[wanton apex]

https://bugs.mojang.com/
make the suggestion!!!

[marsh mural]

animation is optional, not a requirement

[weak wasp]

Quick primer today: https://github.com/neoforged/.github/pull/14/commits/c719ec587021129993fe2a76e21df8939aa6aee9

@marsh mural

Main things are the addition of wolf variants, the changes in the spawn egg texture, and the addition of the dry foliage colormap

[terse escarp]

Feedback discord, not bug tracker right? Or has something changed wrt that

[marsh mural]

yeah i dont think im gonna make the suggestion, was joking about it tbh
but if anyone else wants to yoink the idea and suggest it go ahead

[thin cairn]

Suggestions don't go on the bug tracker anyway

[vagrant obsidian]

so, catching up, and if I understood anything else from today

🥚

[dark wasp]

do entitytypes still have the two color numbers or are those just gone now

I was using those for other things

[thin cairn]

There were no changes to EntityType

[weak wasp]

Entity type?

Do you mean the tint source colors on the spawn egg?

Those were removed with this update as they changed them to flat textures

Same with the spawn egg template

[dark wasp]

nvm I brained wrong

yeah these two

oof, if those are gone I'm gonna have to rework entity-detectors

(I had another item in that mod which reused the spawn egg tints)

maybe I can do something cursed with the spawn egg texture at runtime

[marsh mural]

Those haven't existed for a while iirc since they were specified in the client item iirc via a tint source

[dark wasp]

yeah but I haven't updated anything that used the spawn egg colors past 1.21.1 yet

good to know I'm already fucked

[marsh mural]

https://github.com/misode/mcmeta/commit/93a827b2185760b210e21bee2d1052a7125da343
Yeah this whole update is basically tearing out the tint sources and replacing them with dedi models/textures

[barren temple]

Oof fml
Not fancy mod loader

[marsh mural]

Yeah sucks means more work for modders, not as simple as supplying 2 integers anymore, but I'm all for more fancy cute looking spawn eggs tbh, makes browsing inventories with them easier plus like I said cute eggs

[barren temple]

Yes, I prefer that too. I just had other uses cases for the two colors in a mod to make it compatible with each entity type (change colors based on interacted entity)

[marsh mural]

-# Added sliced limes update video to pinned message

[frank sigil]

55 errors left mostly tickets and gametests

after we fix those 2 things we can gen patches and update to the latest snapshot

[final kiln]

i do have code wich can get the most accurate avg color from any NativeImage

if you need it

[glass wagon]

for tickets the forced chunks system now uses TicketStorage where seemingly the only extra functionality that forced chunks has is:
After a game test is completed all force loaded chunks get removed
The forceload command
Blocks and entities will only be ticked if there are any players or any force loaded chunks

[proven compass]

i hope the wolf sound thing is changed to be like villager profession vs type

where there's per biome and then per variant

cuz i like variants but it should be visual like the panda

also where do we leave suggestions on this cuz the feedback site doesn't have a section

they removed the wolf howl sound

cuz it was unused

but id be so cool if a wolf's ambient sound was a howl during a full moon and it made wolves around it howl too

[glass wagon]

The previous check for whether to tick chunks now only applies to spawning entities

[frank sigil]

well yea but what were the things we bolted on? we need to look into how we can make our stuff work again or if we should just yeet it

[gleaming pendant]

Forced chunks in vanilla were really problematic because you couldn't track multiple sources trying to force the same chunk

You want to make sure that as long as one mod wants to force the chunk it remains forced

[glass wagon]

The main problem I see is that Ticket can no longer store any additional information about the source except for the type

The way ender pearls work is that vanilla readds the ticket right before the previous ticket times out

[frank sigil]

44 errors only tickets and gametests

maty where are your gametest fixes?

who wants to do the ticket system or has an idea how to fix it? I have no idea how it even works

[frank sigil]

what should the parameters for BLOCK, BLOCK_TICKING, ENTITY, ENTITY_TICKING be?

parameters are long timeout, boolean persist, TicketType.TicketUse use

where TicketUse is
LOADING
SIMULATION
LOADING_AND_SIMULATION

[gleaming pendant]

Ig I can have a look tonight

[frank sigil]

I'm going through it rn but where did the codec for encoding a map as list of pairs go?

[glass wagon]

TicketStorage can optionally persist tickets and have multiple combinations of ticket types and ticket levels per chunk so would ForcedChunksManager still be necessary if a source field was added to Ticket and a validation listener added to TicketType?

[frank sigil]

won't work because it only can have 1 ticket per chunk pos

[glass wagon]

TicketStorage can have multiple tickets per chunk pos as long as they have different ticket types or ticket levels (or with more checks in isTicketSameTypeAndLevel)

[frank sigil]

well as far as I see we support multiple tickets of the same type in the same chunk

but 17 errors left

[dark wasp]

nah I've a better idea

given two textures, can an item model run a blend func on them?

wait no

ehh I'll poke around with the item model system once I port the thing

[haughty spade]

fwiw, you'd need a custom shader that accepts the two textures and blends them (or at least one that sets up a different blend function for the second layer)

[river mural]

Ticking should be loading and simulation and the non types should be loading

At least if I had to guess

Also the goal of the ForcedChunkManager is to allow mods to force chunks to be loaded (and have either a block position or an entity marked as the “owner”). That way you can put two chunk loader blocks for example in the same chunk and have a ticket applied to both and then removed from one without having to worry that the other one will also be removed. As an aside it also provides a way to clear invalid ones on load if people want to do extra validation.

I forget about the ticking variant, that might be for what covers later patched into the system to allow chunks to do things like random ticks even if there isn’t a player nearby or even in the dimension

If you give me a tldr of how to setup kits (unless it is as simple as just pulling and doing setup or whatever), and I might be able to look at it some this afternoon/evening when I get back. While it has been a while, theoretically I have a decent understanding of how it works (and how vanillas ticket system used to work) as I wrote the initial implementation of the class in question https://github.com/MinecraftForge/MinecraftForge/pull/7642

[river mural]

But yes. We support this (multiple tickets in the same chunk), but we don’t support multiple tickets for the same blockpos

[dark wasp]

can a blockpos in one dimension have a ticket for a chunk in another dimension?

[river mural]

I don’t believe so

[fleet dome]

pull and don't run setup

you should be able to just pull and build directly

[frank sigil]

checkout the branch named for the snapshot from the kits repo

I think sci made it the default branch

[oblique tusk]

it should be, yes

[river mural]

okay, took a glance and have some ideas for how to implement it in a way that isn't too much of a mess. I will experiment with it some when I get back later today

[frank sigil]

eww why does mojira look worse when logged in

[frigid sand]

jira cloud?

[frank sigil]

and when you are logged in you are no longer on bugs.mojang.com but on report.bugs.mojang.com which always opens the tickets in a new tab and you don't have access to see the ticket content (for the same ticket that you could see on bugs.mojang.com)

I at atlassian

[steep hamlet]

trust me

bitbucket is way way worse

and slow

and fucked

[frank sigil]

yea but on prem jira was better than whatever this is

[river mural]

okay, making decent progress on fixing the forced chunk stuff. Not sure I will end up finishing it tonight, but if not I can try to finish it up tomorrow

[gleaming pendant]

so what's the status of the DIG item abilities? we should remove it?

the implementation of IAbilityComponent is quite problematic as it will cause weird issues with vanilla clients

[gleaming pendant]

I tried to look at usages through waifu but seemingly it can't search for fields?

[proven compass]

kill it

[raven blade]

only maty knows the magic words

[gleaming pendant]

so, I'm not sure that SHEARS_DIG can be replaced by just checking whether the tool can dig

[proven compass]

does shears not use Tool like the others

[gleaming pendant]

it does, but the acacia_leaves loot table checks against minecraft:shears which is obviously not sufficient in a modded context

[proven compass]

interesting

i wonder if u should make a neoforge tag

[gleaming pendant]

neoforge overrides that loot table to check against the SHEARS_DIG tool action

for obvious reasons a tag is not enough

(tags are not nbt sensitive, hence item tags are usually a poor fit for behavior)

[proven compass]

ah forgot about nbt

[gleaming pendant]

an example, this time of PICKAXE_DIG, which might be tricky to replicate without item abilities: https://github.com/desht/ModularRouters/blob/5805883db123caa3358d64b98880fae0cdd0c987/src/main/java/me/desht/modularrouters/recipe/PickaxeModuleRecipe.java#L97

[proven compass]

no?

that can check the tool component

[gleaming pendant]

please write such a check in pseudocode

as in: how would you actually do it?

I think it's more complicated than it sounds

[proven compass]

wasnt the whole point of removing the dig abilities that there is now no such thing as a pickaxe

in that sense there is also no such thing as shears right

mm no

cuz shears still have an item for shearing

[gleaming pendant]

shears are a special case since the item is hardcoded in the loot table

[proven compass]

i feel this would be a case for serverside data components

since its only ever checked on the server

for shears specifically

[gleaming pendant]

there is no special class for the pickaxe item anymore, but of course pickaxes are still a thing

[proven compass]

admittedly i dont have access to the snapshot code what does pickaxe init look like now

isnt it just defining a Tool component with valid blocks

[gleaming pendant]

yes, but that is in fact not substantially different from how it worked before

[proven compass]

so while some items r registered as a pickaxe, there is nothing in the item itself that determines that its a pickaxe

[proven compass]

before it was understood that u extend PickaxeItem for a custom pickaxe

[gleaming pendant]

by overriding some methods in your item you could always implement arbitrary rules for the mining speed of blocks, and whether drops are allowed or not

[gleaming pendant]

that was never the case, however PickaxeItem was a convenient place to check the item ability

[frank sigil]

yo any mojangster here that wants to un-hardcode shears from loot tables this snapshot cycle?

[proven compass]

how tho

what would they check for

they would probably opt for a tag

but that doesnt work for us

[gleaming pendant]

a tag with a single entry? I doubt it

[proven compass]

solution: add teired shears and make a tag for it

simple

cant wait to see that next wednesday

[frank sigil]

probably a loot context param or something like they did for enchantments

[proven compass]

ooh

can neo add those

those r server sided

tho that draws back to how does one define shears

u could add a param to check for tool abilities ig...?

but i'd rather remove all the dig abilities

[gleaming pendant]

I'm not sure there is really a technical reason to remove them besides "the default implementation for pickaxes got a bit more tricky"

[river mural]

oh and when you fix a hunk/reject do I just delete it from the file/delete said file?

[gleaming pendant]

yes

[proven compass]

how r u gonna put that on vanilla items

you'd have to have an anonymous class for every normal tool item

[gleaming pendant]

delete single hunks if you didn't fix the whole reject, or delete the whole file if you did fix all hunks

[gleaming pendant]

not necessarily

server-side components are another possible solution

[proven compass]

were those figured out

[gleaming pendant]

in my head yes

[proven compass]

it'd be a kinda icky solution but it would work

[gleaming pendant]

I didn't get to implementing yet though, a bit tricky if I can't test it 😛

[proven compass]

itd be unfortunate tho bc not all item abilities can be components

[merry falcon]

Custom registry is another solution where one registers… idk something

[gleaming pendant]

checking the component would just be the default impl in IItemExtension

[warm night]

We use Jira as well at work... It is a mixed bag of shit, but also gives a bunch of features that are actually good.

But yeah I also hate that they removed the on prem version

[proven compass]

can all item abilities be components tho

like axe stripping

brush brushing

not server sided

[gleaming pendant]

providing the ability in principle yes, but might not be practical for some items

checking the ability well that requires a check so no

[merry falcon]

Wait till you do ADO. Our code/ticket search was down for over a month

[gleaming pendant]

TBD, might not be a concern

[warm night]

ADO.NET??

ADO.NET??

[proven compass]

ig for the behavior abilities that neo has to check theyll be components eventually anyways

[merry falcon]

AzureDevOps

[proven compass]

like brushing, stripping, etc

[gleaming pendant]

not sure

[proven compass]

the dig ones can be componentized probably as long as theyre never needed on the client, but might some mods need to check on the client?

what was it someone said about only sending it over if its a neo client can we do that

[gleaming pendant]

the client will just have the default component for the item unless it's either talking to a neo server or a really clever vanilla server

[proven compass]

cuz that way a mod that checks on the client is required on both sides anyways

seems like the best course of action

[frank sigil]

we do the task management is PAIN

but mojang is definitely doing ADO because there is an ADO tag on mojira tickets now

like MC-280119 is ADO 1368413

[stiff flicker]

Yea our on prem was so much better than cloud. Jira is w/e but confluence cloud is so bad. It was so much easier to write documentation with on prem.

[stiff imp]

yeah but they can't charge you as much for on-prem

that's no fun

[river mural]

I am heading to sleep. But given you initially PRd the extension for the force ticking to chunkloaded chunks @twilit kernel . So I can make sure that I hook that up properly tomorrow when I finish fixing the chunk manager. The two use cases were:

1. Random ticks
2. Entity spawning

Right? If so, 1. Is now automatically done for the force loaded chunks, and 2. Is what I believe I need to rehook up. But I want to double check that was a feature of it, and it isn’t just that we can remove that override now that vanilla does random ticks

[twilit kernel]

I believe the force load stuff was to ensure that vanilla did random ticks, yes. Basically random ticks, tile ticks, entity ticks, etc, should function normally when being chunk loaded. I don't believe natural spawning ever occurred, i may be wrong though.

I can check a bit later to see if natural mob spawning happened, but my gut says no

[river mural]

Thanks. I vaguely recall you did do so and bypassed the players nearby check. Unless I am just thinking of the chunk of code that had to be patched so that random ticks could happen for forced chunks in dimensions with zero players in them (rather than having the dimension stop receiving ticks)

But if you are right about the natural mob spawning not being part of it, then that drastically simplifies things as vanilla forced chunks now do have random ticks applied

[twilit kernel]

You may be missremembering the empty dim thing, yes. I'll confirm later and let you know, if i forget @ me :)

[river mural]

Sounds good, thanks

[sterile abyss]

it can now

[sterile abyss]

https://snapshots.raintank.io/dashboard/snapshot/jchSrQY7qdgJYuuMsB6Q23Frm7KaeM15 not that many references to _DIG abilities

[dark wasp]

how do I read this?

[sterile abyss]

why is it empty

oh I see wrong snapshot server whoops

https://waifu.neoforged.net/dashboard/snapshot/UqVIxZ2mASjvhYcC8J6XTxcMHy3oCcgb

[river mural]

Did you end up getting a chance to look at it? Or should I try to check it a bit later when I continue working on it

[twilit kernel]

It looks like 1.21.1 did allow chunk forcing to contribute to natural spawning.
(this.level.isNaturalSpawningAllowed(chunkpos) && this.chunkMap.anyPlayerCloseEnoughForSpawning(chunkpos)) || this.distanceManager.shouldForceTicks(chunkpos.toLong()) (ServerChunkCache ln 364, 1.21.1)

Neo appears to add shouldForceTicks to DistanceManager. If your cleaning things up here, afaik, all added methods used to be inside a // Forge block at the bottom, or have // Forge <reason> above them, (i assume there is now a neo equivilent for that comment)

[river mural]

How I was planning on cleaning it up is renaming it from should tick to shouldDoNaturalSpawning or something or asNearbyPlayer (based on what I think might be a cleaner hook position) and then just add it as an extra Boolean to the registered ticket type (which then saves us having to patch in various overloads to a bunch of methods)

But yeah, I will look into it more closely

[twilit kernel]

I trust your ability to weave things here, however is fine really.

[gleaming pendant]

mischief managed I think 😄

[river mural]

should be fixed now, but someone should validate (especially as can't test yet without other things compiling)

[frank sigil]

@sterile abyss where gametest fixes at?

[river mural]

also yay codec fun

[gleaming pendant]

my god 😄

[river mural]

heh, yay App<Mu<TicketStorage>, ...>

initially I had it as P5

instead of App

[gleaming pendant]

oh wtf

[river mural]

but then I ended up folding things into a helper record

(in part given I realized I was structuring things wrongly, but that is just details)

[gleaming pendant]

public record ItemAbilitiesComponent(Set<ItemAbility> abilities) {

set or list?

if set, how to make sure that it serializes in a reasonable way

actually it should probably be a set to make sure that the order is irrelevant

I guess I can xmap to a sorted list

[river mural]

yeah set. Can always have backing impl be a SequencedSet

[dark wasp]

HolderSet<ItemAbility>

[river mural]

just so that the serialization order is consistent

[gleaming pendant]

is there really no SequencedSet.copyOf

[river mural]

nah, it is annoying

closest is Collections.unmodifiableSequencedSet(new LinkedHashSet<>(collection))

[gleaming pendant]

good enough thanks

and of course there is no SequencedSet.of() 😦

oh well, Collections.emptySortedSet()

[river mural]

at least it isn't as confusing as the fact that Map.of() is not actually a SequencedMap . Like not even as an implementation detail... like it literally shuffles stuff just so that it is explicitly not guaranteed to be (even though it trivially could be)

[gleaming pendant]

wait it shuffles stuff

[dark wasp]

it's like when you check out groceries at the grocery store and you move all your cold stuff from the cart to the conveyor belt first but the clerk just distributes them to random bags so they get mixed up with the dry stuff

[gleaming pendant]

yeah it shuffles stuff indeed, but it's for better performance

[frigid sand]

right, you guys get your bags packed for you

[gleaming pendant]

quick @floral mesa count the number of copies

from the codecs you get a nice Collections.unmodifiableSequencedSet(new LinkedHashSet<>(new LinkedHashSet<>(List.of(l.toArray(ItemAbility[]::new)))))

[river mural]

just add a private List<ItemAbility> overload so you don't have to convert from immutable list to array and back to an immutable list

...

(for the codec, not the stream codec)