#1.20.5/6 Snapshots

1 messages ยท Page 4 of 1

elder swallow
#

we can't do that in 1.20.5 since we'd be changing vanilla behavior

true jacinth
#

Yeah but fix it for the pastโ„ข๏ธ

elder swallow
#

needs to be fixed all the way back to 1.14 kekw

true jacinth
#

v good attribute impls we have here

elder swallow
#

I don't care that much about the past heh

#

for 1.20.5 I'll remove our patch

true jacinth
#

Honestly I wonder how it hasn't come up as a bug yet

elder swallow
#

just open a mojira report if you're not happy ioa

elder swallow
true jacinth
#

nobody ever use a slowfall potion on a galacticraft moon?

#

not a single human in the universe

elder swallow
#

is GC even ported to 1.14+?

true jacinth
#

There's similar mods

#

ad astra or w/e

elder swallow
#

the best part is that the slow falling code checks for deltaMovement() <= 0

#

so you're not even going up smoothly

#

one tick you go up, one tick you fall

true jacinth
#

wonderful...

elder swallow
#

at 0.04 base value you're just floating

elder swallow
fallen igloo
#

I'm generating a clean 24w09a from main that we can rebase onto

elder swallow
#

wait what

#

can we please squash 24w07a

fallen igloo
#

idk if squash and rebase and just rebase make that big of a difference here but sure when you are done make a new branch and squash everything after the snow-lance commits

elder swallow
#

the workflow I had in mind was:

  • squash 24w07a
  • rebase on top of the latest 1.20.x changes and fix conflicts
  • update to 24w09a
fallen igloo
#

yea that works too I guess

rigid walrus
#

and then fix everything broken by item components

fallen igloo
#

fun

fallen igloo
elder swallow
#

yeah

#

and I'll be sure not to forget the co-authors this time ๐Ÿ˜”

fallen igloo
#

we can rebase the squash onto the 24w09a branch (I killed the workflow before it did the update)

elder swallow
#

ok yeah I see

#

still not sure about FBB/RFBB

fallen igloo
#

what's to do there?

elder swallow
#

in configuration phase, it should be safe to use RFBB from configuration tasks

#

currently the API only allows FBB codecs for config phase

#

this means that you can't send an ItemStack with a config payload, for example

#

I think we'll patch it so that you can always use RFBB for config phase, but with an empty registry access initially, with only the static registries once these are synced, and with all registries once the datapack registries are synced as well

rigid walrus
#

why isn't the src entry in the projects/neoforge/.gitignore need to be commented out for command line git for the 24w07a branch?

fallen igloo
#

git add --force

#

--force bypasses gitignore

#

and changes are tracked for all checked in files

fallen igloo
elder swallow
#

not really

#

we can do our own RFBB wrapping based on the current state without going through mojang's protocol system

#

an unbound state is dangerous, we risk disconnecting the client if we happen to receive a packet (e.g. keepalive)

#

oh ok, so there is a check that prevents configuration packets from being received outside of the modded configuration phase

fallen igloo
#

huh serverbound is always FBB and never RFBB

rigid walrus
#

Just found out that by default eclipse tracks changed files that are ignored as long as they are already in the index

fallen igloo
elder swallow
#

probably because vanilla didn't need it

#

that's quite problematic

fallen igloo
#

so we have to patch that generic type everywhere Thonk

elder swallow
#

not everywhere

#

we just need to wrap the bytebuf

rigid walrus
#

jgit doesn't seem to support force add

elder swallow
#

ok time to squash

#

the registry sync task is now before vanilla's datapack sync task

#

it runs before the modded configuration phase hence it needed a special check in the server config listener

elder swallow
rigid walrus
#

Should the MC sources be in the gitignore when it's on the kits repo?

elder swallow
#

it works fine

#

I like it because it means that we don't have to change the git ignore; only git add --force and git rm -r --cached

fallen igloo
#

when you have squashed push the new branch we have to do a bit more than just rebase onto the other branch (we need to update that branch to 24w07a first before we can rebase the fixes)

elder swallow
#

I'll rebase on top of 1.20.x now

#

actually I'll join vc for a while

#

ok that's not too bad

elder swallow
#

this suuuucks

wooden tendon
#

LOL

#

So sneak prevents you from falling if the height downwards is more then half your step height

#

That is the definition?

elder swallow
#

yes

#

it's stupid

wooden tendon
#

Seems reasonable

fallen igloo
#

@mojang a solution everyone would be happy with: make players not even go down stairs or slabs when sneaking

elder swallow
#

if you have a step height of 10 and 1 heart you will die

spiral radish
white frigate
fallen igloo
#

no that is serious because it is a fix for the reported "bug"

white frigate
elder swallow
#

I bet they didn't even try it

#

just got some generic "works as intended"

fallen igloo
azure sparrow
#

Yes

#

It works as implemented - I personally agree that it this behaviour sucks, but if itโ€™s a change thatโ€™s made, it shouldnโ€™t be tracked as a bug

elder swallow
#

okay, thanks

kind sable
#

The amount of questions we have for the mojank team we should just get a slack invite /s

foggy steeple
#

Microsoft owns Mojang

Slack instead of Teams

elder swallow
#

@rigid walrus did you forget to add the method content back?

kind sable
#

I.... Don't want to work at a place that uses teams....

#

๐Ÿคฃ.

elder swallow
#

this vineflower bug is unacceptable, I don't understand how it hasn't been fixed yet

dry stumpBOT
#

Successfully scheduled reminder on <t:1709333467:F> (<t:1709333467:R>)!

rigid walrus
elder swallow
#

<insert rant about unreleasable dev branches>

stiff galleon
#

harold I push broken code to my dev branches all the time

frail hatch
elder swallow
#

fuck ๐Ÿ˜„

blazing valve
#

BTW I do wonder what a pain in the ass it was for Mojang to keep that massive branch with the ItemStack component system up to date during its lifespan

kind sable
blazing valve
#

The previous iteration was practically unusable

#

The new one graduated to "ok"

kind sable
foggy steeple
#

Force push obv smh

kind sable
#

What kind of branch management they use....
And when are they gonna merge:

  • feature/modding-api
  • feature/new-cool-dimension
frail hatch
#

The modding api is datapacks

fallen igloo
#

yep the feature/modding-api branch is just datapack blocks and items

restive raft
#

Data pack version 33 in snapshot 24w09a introduces a massive change to how item stack data is represented! Here is your ultimate guide to all the changes! #minecraftemployee

slicedlime works as a Tech Lead for Minecraft at Mojang, but the YouTube and Twitch channels are personal projects run entirely in his spare time. This is an unofficial upd...

โ–ถ Play video
kind sable
lean anchor
#

let 'em cook

stiff galleon
#

the big portal in the ancient city goes to the other end

true jacinth
# elder swallow BRUH

@stray bay Guess you get to open that other bug about it being a fall and not a true step down

#

And I guess I have to write a mixin somewhere, bc that's a stupid ass decision

fallen igloo
#

rejects down to 3 hunks in 2 files

#

if someone wants to help me fix KeyBindsList and WalkNodeEvaluator it would be appreciated

frail hatch
naive hound
fallen igloo
#

down to 2 hunks in 1 file

#

and I have no idea how to fix WalkNodeEvaluator this time

stray bay
#

it occurs to me that they probably could limit fall damage based on the step height, there's already some sort of hook that limits fall damage based on your original height when jumping with wind charges

fallen igloo
stray bay
#

anyway, while a proper step down would be useful, it also seems like it might be difficult to implement

frail hatch
#

now that I am back I will look briefly via github to see if I can figure out where the patch stuff for the other hunk should go

#

also ignore the fact apparently I linked base for both instead of from the neoforge project I guess

fallen igloo
#

well then it's 1 hunk in 1 file

kind sable
stiff galleon
#

eye of under

fallen igloo
#

hmm maybe it should use the cache

frail hatch
#

the only reason I am unsure about the cache part is given if you look in WalkNodeEvaluator#checkNeighbourBlocks vanilla still has the type -> other type thing going on

#

I also don't know if we need an overload as just adjusting the method in the context also will affect things like WalkNodeEvaluator#getBlockPathTypeStatic

fallen igloo
#

the problem is that the blockpos now is inside of the PathfindingContext so inaccessible for the calls

#

added a package private getter for the mutable pos

frail hatch
#

hence why I was suggesting moving the patch

fallen igloo
#

down to 9 classes with compile errors

#

35 errors in 5 files left

#

and now to watching forgecraft

elder swallow
#

DataComponents are supposed to be immutable

#

(on stacks at least)

#

Do we want them to be immutable on BEs etc too?

#

Or should we say "Item stack ones are immutable and WILL be copied directly to multiple stacks. Other data component holders will not be copied and may safely be mutated."

#

@frail hatch what do you think? Situational mutability is annoying, might be the lesser evil though.

frail hatch
#

idk, mutability is nice, but also for the most part I only really attach stuff to items (and sometimes entities)

lime galleon
#

do data components support "serialize on save" semantics (i.e. time dependent serialization)? I'm gathering just from reading they're codec-serialized-only, so probably?

reef parcel
fallen igloo
#

tech lets finish the current stuff and think about expanding it later

#

all compile errors that are left relate to data components

rigid walrus
fallen igloo
#

oops forgot to push the last one

true jacinth
dry stumpBOT
#

[Jump to referenced message](#builds message) in #builds

Version

24w09a-20240301.223831

Build Branch

1.20.5-dev

Minecraft Version

24w09a

rigid walrus
#

Fixed some more lambdas #builds message

elder swallow
elder swallow
#

btw this sucks

fallen igloo
#

yes it does, my idea, just codec and stream codec it and remove INBTSerializable

#

or patch in the lookup provider

elder swallow
#

codec it is

#

where did our NBT patches go for the item stack codecs?

fallen igloo
#

I did the other one because it actually is easier

fallen igloo
elder swallow
#

still, we need to patch in some way to read additional components...........

elder swallow
#

I have the codec done

fallen igloo
#

did you also patch the uses?

rigid walrus
elder swallow
#

not for recipe outputs, no

elder swallow
#

we don't need test to compile to be able to run the game

#

patching in the holder lookup won't work very nicely with attachments

#

hence the codec

#

looking at NBTIngredient now

fallen igloo
elder swallow
#

yes, it needs propagating through IAttachmentSerializer and AttachmentHolder

fallen igloo
#

yep done that

elder swallow
#

ok

#

vc?

rigid walrus
elder swallow
#

I know I could use ecj but I don't want to ๐Ÿ˜›

elder swallow
#

hotbar blur looks disgusting

quiet condor
#

you can change the blur in the accessibility settings

#

the amount of*

elder swallow
#

I suppose

#

but it looks really bad out of the box

#

looks cool for the game background though - just not for the UI

quiet condor
#

will probably be changed in 24w10a

rigid walrus
#

javac compiles this::addRenderableWidget to a lambda body

elder swallow
#

why though

#

generics?

rigid walrus
#

yes

#

almost all decompile errors are caused by generics as well

summer furnace
#

they used box blur for performance I guess

#

and it's ... not pretty

elder swallow
#

where is my gaussian blur ๐Ÿ˜ญ

fallen igloo
slow prism
#

only 29 pass? lol

#

there's 90 tests

elder swallow
#

blame the critical error ๐Ÿ˜›

blazing valve
#

It is shader based blur I hope

misty crow
#

It's a post-processing shader, yeah

analog ledge
#

it doesn't calculate the average weights properly compared to the 1.7 version of the shader

#

will probably be fixed

fallen igloo
stray bay
#

apparently specifically they used a box blur because it's easy to make the radius configurable with a uniform

elder swallow
#

well that tweet uses a gaussian blur

#

predictable ๐Ÿ˜„

analog ledge
#

even the linear blur is decent

#

someone fixed the blur to not be bugged

stray bay
#

yeah box blur has specific high frequency artifacts with certain inputs that make it a bad choice for minecraft

solar zephyr
#

my eyes do not like box blur

stiff galleon
#

yeah I'm turning that blur off forever when I play 1.20.5+

clear bane
#

unless they fix it harold

quiet condor
#

which they probably will

analog ledge
#

The second image is what it is meant to look like to be clear

#

the first image is unintentional

clear bane
#

ah

#

so yeah, I bet they will release it next week then

analog ledge
#

it's a one line fix

stiff galleon
quiet condor
foggy steeple
#

The blur on one is more boxy and artifact filled

#

On mobile so I canโ€™t easily get images to scale properly

fallen igloo
#

were AttributeMap and DefaultAttributes never null safe? the tests currently crash with a NPE because the test entity type in forgeSpawnEggTest does not have attributes

magic sierra
fallen igloo
# true jacinth null safe for what?

well for thet test there are no attributes registered for the entity type so the AttributeSupplier is null and throws in AttributeMap#getValue because of that

true jacinth
#

That sounds expected

#

there are minimum attribute registration requirements

#

No children of LivingEntity are permitted to have a null attribute registration

fallen igloo
#

ok then @slow prism fix the test

fallen igloo
#

@elder swallow @true jacinth don't merge the PR on Kits (even if it is done) that should only get merged after the update is pushed to main

elder swallow
#

we will have to merge it before

true jacinth
#

Retargetting it again will be a headache, i think

elder swallow
#

yes

#

because we need to make more networking changes in 1.20.5 anyway

fallen igloo
#

still a networking refactor should never happen in the squashed version port

elder swallow
#

we don't have the choice

fallen igloo
#

we do... don't merge until after the final squash

elder swallow
#

that completely freezes networking development on the snapshots

fallen igloo
#

we should NEVER do any bigger changes that are not necessary because of MC changes hidden in the update squash

wooden tendon
#

Agreed

#

This has been discussed before,

#

Unless it is functionally required

elder swallow
#

it is required to fix the current state of the snapshot networking

wooden tendon
#

?!?

true jacinth
#

Well as it stands networking is broken on the head of 24w09a

wooden tendon
#

The flattening is under no circumstances required for snapshot netgworking

#

Neither are all renames

#

Not saying that the PR is bad

#

Just that I agree with schurli

elder swallow
#

no, but it is difficult to separate them

fallen igloo
wooden tendon
#

What?

#

It is not difficult to seperate them for one bit

#

Because he made the PR against the public repo

elder swallow
#

I mean that it is very annoying to redo the PR on top of more changes

wooden tendon
#

So all changes in that PR are not strictly needed

#

Yes

#

But that is what he has to do

#

He opened the pr unsolicited

true jacinth
#

It took as long to rebase it as it did to write it, lol

wooden tendon
#

Yes

elder swallow
wooden tendon
#

Yes

elder swallow
#

I told him to do it in 1.20.5 because the networking already had a number of changes

wooden tendon
#

Yeah and there are now 2 maintainers telling you that that was wrong.....

elder swallow
#

and there are 2 maintainers telling you that merging the PR might be ok

true jacinth
#

What exactly are you concerned about losing if it gets squashed?

fallen igloo
#

he can update his PR on the Kits state he just can't merge it there before the final squash

true jacinth
#

I don't fiddle with the private repo much

wooden tendon
#

It is a transparency issue

#

We want these kinds of structural changes public

elder swallow
#

it's annoying for people browsing the repo if they get massive changes into one commit

wooden tendon
#

On the publicrepo

#

Because as you yourself pointed out, you already missed a review window for the original PR for several reasons

#

And now you are depriving any reviewer outside of the core maintainer team from doing anything!

elder swallow
#

it is the core team for a reason, after all ๐Ÿ˜›

true jacinth
#

We can reflect any changes requested on the public facing one

#

(if any are requested... I get the feeling they won't be)

elder swallow
#

potentially we can merge the PR right after the final squash, but that means squashing the PR itself to be able to update and apply it reasonably

wooden tendon
# elder swallow it is the core team for a reason, after all ๐Ÿ˜›

Yes, but the sole argument he has for making these opinionated (there is not a single functional change in his original PR, and that is fine) changes was because he did not get any input with the original team that designed it. Again fine he was busy.

But that in turn means that he can not and should not go in the private repo and get his stuff merged there, were even less (not even all maintainers) can see his changes

fallen igloo
elder swallow
#

the PR will have to be rebased

wooden tendon
#

Then so be it

#

That is the deal with making PRs

elder swallow
#

which will be much easier after it is squashed

wooden tendon
#

You make PRs you maintain them

#

If you can't be bothered to keep your PR up to date, and rebased

#

Then it does not deserve to get merged

elder swallow
#

Orion we work as a team. You can stop with that attitude please

wooden tendon
#

WTF

fallen igloo
wooden tendon
#

I am just pointing out that he had a good reason for making this PR

#

Which is that he wanted input on the design

#

And that that is completely fine

true jacinth
wooden tendon
#

And that we will judge his contribution on its merrits

#

But that he can not use the same fucking argument to have his changes merged in the private repo!

elder swallow
#

the only reason not to merge the changes in the private repo is because it leads to an obscure final public commit

#

which is fine by me

slow prism
wooden tendon
true jacinth
#

Is keeping the public-facing PR up to date with the internal PR not an acceptable solution?

wooden tendon
fallen igloo
#

I think it is the maintainers/neo team that has access

wooden tendon
#

And double the review work

#

But it is doable

true jacinth
#

Well reviewers don't need to look at both of them

elder swallow
#

well no - we review the private one and assume that it's in line with the public one ๐Ÿ˜›

fallen igloo
wooden tendon
#

Yeah as long as you do not merge the private one

#

You are basically good I tink

#

Unsure

#

Git is not my strong suite

true jacinth
#

That's if the history lines back up for it to work

wooden tendon
#

So no idea how this looks

slow prism
true jacinth
#

Basically I don't know what the state of the repo will look like when it is time to apply the changeset

elder swallow
slow prism
elder swallow
#

in any case we have a problem with the current workflow because we don't really have a window to make changes that are 1) in separate commits but 2) are all part of the initial release

#

e.g. the removal of Event.Result will also be one single commit that will need to be applied after the final squash

true jacinth
#

Yeah that is a bit of a workflow issue

slow prism
#

e.g. removing attachments in favour of components should also be one singular commit with no prior releases

elder swallow
slow prism
#

e.g. renaming mods.toml should also be one singular commit with no prior releases

fallen igloo
elder swallow
#

it's not fine because it's not scalable

#

and it sucks

#

I had to rush the capability rework PR rebase in the 30 min that I had between the squash was done and I had to leave

#

and that was a single PR

#

we're already talking about 3-4 potential PRs

fallen igloo
#

tech these are the technical limitations of our transparency policy and private porting process

elder swallow
#

The workflow I would think makes sense is that at some point we squash an intermediate port commit, and then apply larger commits on top of that

#

The only question is how to deal with work that happens in the mainline at the same time. Potentially cherry-pick

true jacinth
#

Does the porting process need to be private anymore now that patches are actually like, legible

fallen igloo
elder swallow
#

e.g. you might see in the final update commits:

  • Port to 24w09a
  • Networking refactor
  • Remove Event.Result in favor of more specific enumerations
  • Port to 1.20.5-pre1
  • Replace data attachments by vanilla's component system
  • Port to 1.20.5
#

Schurli you are too focused on the existing workflow

elder swallow
fallen igloo
elder swallow
#

I am discussing a hypothetical workflow that would be better for large changes

fallen igloo
elder swallow
#

oh come on

#

that doesn't prevent discussing the changes

#

and I don't see how it requires the council, the fuck

fallen igloo
#

policy changes are council stuff

slow prism
#

next up: article 1, section 2b of the federal constitution of neoforge prevents each state from modifying law d

elder swallow
#

it requires maintainer consensus because it is a change in maintainer workflow

#

and that's it

true jacinth
#

I don't even think we're losing transparency here, so long as we write down things and make it visible

All three of my staged 20.5 release changes are visible on public rn

slow prism
#

(my point is don't overly involve votes and 3 specific people)

elder swallow
#

we can btw push the port commits to a public branch with that workflow - hence making the update process more transparent

true jacinth
#

If we make major deviations from those public views and do not document it, then we have a problem

fallen igloo
slow prism
#

at this point the private repo can be pushed public just fine

#

and maybe we should

elder swallow
#

I think it would make sense to freeze mainline development and publish already (on github, not maven) the port once the prereleases land

#

maybe RCs, pre-releases is a bit early

true jacinth
#

isn't the vanilla src in /projects visible atm

slow prism
#

push a comit to remove it and squash

true jacinth
#

squishy repo

#

anyhow parts of a good discussion here - it is 2 am and I should sleep

Do try to spare my sanity from rebasing that pr if possible :p

slow prism
#

sleep is fo rthe weak

#

(go sleep)

elder swallow
#

I suppose it could be on a port/1.20.5 branch for example, to avoid triggering releases

#

so the idea is that:

  • once the first 1.20.5 prerelease or RC lands we freeze 1.20.4 PRs
  • we remove MC sources, squash and publish kits to a public port/1.20.5 branch (public but not released/published)
  • impactful PRs can target that branch
  • once 1.20.5 releases, we push another update commit to port/1.20.5 for that update
  • we rebase the entire branch into 1.20.x (should be a fast-forward because of the feature freeze)
fallen igloo
elder swallow
#

removing the sources is part of the squash

#

should be a fast-forward merge because of the feature freeze
meaning that commits get added without a merge commit ๐Ÿ˜›

#

it's equivalent to a rebase merge if the target branch is strictly outdated

#

but yeah on the github UI it would likely be rebase and merge

fallen igloo
elder swallow
#

yeah that's what I mean

fallen igloo
#

so the full new workflow for an update would be:

  1. start kits branch with action
  2. fix rejects
  3. fix compile errors
  4. fix tests
  5. run tests
  6. fix test failures
  7. update to next snapshot (when released)
  8. repeat 2 - 7 until first RC
  9. once the first RC lands freeze PRs on main
  10. remove MC sources
  11. squash
  12. publish the kits branch to a public port/<version> branch
  13. PRs can target that branch (if they are impactful they get merged there)
  14. once MC releases, we push another update commit to the port/<version> branch on main for that update
  15. we rebase-merge the entire branch into the current version branch on main (should be a fast-forward because of the feature freeze)
elder swallow
#

yes

#

RC is too late I think, potentially we do it one week before the expected release date

#

for 1.20.4, RC was on the 6th of decement and the release was on the 7th

#

ah but 1.20.4 was a hotfix, right

slow prism
elder swallow
#

late pres or RCs should be fine yeah

#

I wouldn't codify the exact merge freeze time - just check with the rest of the team

prisma locust
#

why can't we just only use kits for the purpose of fixing rejects

#

and as soon as we have something compiling (i.e. what we have now with 24w09a) remove MC sources and move it to a public branch

#

and repeat that for each snapshot we decide to port to (not necessarily all)

#

patch generation is no longer torturous to sit through

elder swallow
#

if we are not careful we will mess up the linearity of the git history

#

that is the reason why I propose a mainline freeze

summer furnace
#

keeping history pretty should literally not be a priority over keeping the process sane

#

that's the whole point merge commits exist: to indicate the merging of two lines of work that have happened concurrently

#

use them.

#

that doesn't mean we shouldn't hold PRs that will be annoying to merge later, though, just no need to enforce a complete freeze

elder swallow
#

I think that a complete freeze of ~1 week makes sense

median wasp
slow prism
#

it would mean that there's more than 20 people that can release mods for new versions early

fallen igloo
clear bane
#

I have seen the trees they have here....
yeah, I can se why that would be hard

fallen igloo
summer furnace
#

but ๐Ÿคทโ€โ™‚๏ธ ultimately I'm not the one doing the bulk of the work for this, so whatever feels the least headache inducing to you

prisma locust
#

ok, this is going to sound like a dumb question, but what is the exact reason, legally, we cannot have the patched source files available publicly?

#

because we already publish a decompiler and the patches necessary to make the decompiled code compile again

summer furnace
#

public sources means we are doing the copyright infringement every time someone clones the repo

#

the patches + decompiler is "clean-ish"

#

we provide development tools but not the actual game files

#

which is a very clear line we can avoid crossing

prisma locust
#

if I published sources but symmetrically encrypted them using a hash of the Minecraft client JAR, would that also be copyright infringement?

wooden tendon
#

Yes

prisma locust
#

hm

summer furnace
#

if anyone can access it we become a public distributor of copyrighted material. there's a sort of "implicit agreement" that what we do is ok based on the fact mojang has never contacted the forge project (or any other mod loader project) to complain about this kind of development process, but we could not expect that allowance to extend so far as to include the wide public in this development process

fallen igloo
#

if you provide the sources in any way it is a violation, if you only provide the tools you are in the clear

median wasp
#

Using patches also allows people to easily see the changes

prisma locust
#

so providing a reversibly encrypted version of the sources is equivalent to providing the sources, but providing patches is not?

fallen igloo
prisma locust
#

to be clear, I'm not advocating for breaking the rules, I'm just trying to understand them

summer furnace
elder swallow
#

sharing with close friends is ok

summer furnace
elder swallow
#

depending on how you view it, the repo can be considered legal as long as it remains private - it's on github servers though so idk about that

fallen igloo
summer furnace
#

I don't know if this is specific to spanish laws or to the whole of the EU

#

but eg, wrt music

#

legally speaking if your neighbours are hearing you play music

#

you are doing a public performance and are subject to broadcast licensing fees

fallen igloo
summer furnace
#

(but in spain copyright infringement is only punishable to the extent of the (intent of) monetary gain -- which is zero in the case of loud music, hence no one would try to go after you legally)

slow prism
blazing valve
elder swallow
#

I mean legally

blazing valve
#

That is exactly why you shouldn't. You might not like the answer.

elder swallow
#

actually you are right, there is an exception for computer programs under Swiss law

#

so you can watch movies together but not play paid games ๐Ÿ˜›

median wasp
#

A benefit of doing porting in the open would be that people get to read PR comments fully

#

Because Discord cuts those off

#

E.g. #neoforge-private message

wooden tendon
#

@true jacinth or @elder swallow Why does the Network PR do away with phase specific listeners?

#

The whole point of the phase specific listeners is that during configuration you have a proper way of marking a phase completed, without having to capture a bunch of stuff.

#

On top of that this introduces weird handling related to the sending player (now being sometimes null, instead of an optional)

#

On top, we need to reintroduce versionless channels

true jacinth
#

Why do we need versionless channels

wooden tendon
#

They are required to be able to communicate with any other platform other then NF

#

Which was the whole point of us fixing the protocol in the first place

#

No other platform other then (Neo)Forge has versioned channels

#

So if you want to support a plugin from a client side mod

true jacinth
#

Why is versionless required though? Versioned optional works

stiff galleon
#

if you want to version your channels, bump your mod's version harold

wooden tendon
#

You need support for version less channels baked in by default

wooden tendon
#

Versioned optional as such does not work

#

Because you hard code the check

true jacinth
#

Then that's a bug, it should permit versioned optional to connect to versionless

#

Anyway back to the original question

wooden tendon
#

I would suggest simply reverting that change

#

The concept to require a version is not great anyway

#

And having versionless channels was explicitly requested by modders and the other loaders

#

I don't see a reason to un do this

true jacinth
#

Do you know why it was requested? Is it not for the same goal that optional channels serve?

#

Providing a version should be a good habit instead of an afterthought

wooden tendon
wooden tendon
true jacinth
wooden tendon
#

And that different handler had for example the ability to mark the current running task as complete

true jacinth
#

The main IPayloadContext retains this capability

#

See IPayloadContext#finishCurrentTask

wooden tendon
#

Yeah but you should not be able to complete a configuration task from a play payload handler

true jacinth
#

and you aren't, because it will throw :p

wooden tendon
#

And what does that do for play phases? crash?

true jacinth
#

it says as much

wooden tendon
#

Wtf

#

Why?

#

Just create the compile time safety

#

If you have a payload for the configuration phase

#

Just have it have a specific handler

true jacinth
#

It was already absent - the method was present on the clientside for configuration handlers, but threw in that environment

wooden tendon
#

Yes because we could not figure out a way to send a consent payload back yet sanely

#

But it is / was planned

#

And it would only cause a crash in a situation where the payload handler was already broken

#

Now a play payload handler can invoke this at any time

true jacinth
#

The very slight compile time sanity does not justify the cost of maintaining two separate paths here - you won't have a ConfigurationTask.Type in the context of a play payload anyway

wooden tendon
#

The Type is generally a public static final field

#

On the ConfigurationTask it self

#

So in 100% of all cases the modder will simply have access to it

true jacinth
#

We should be able to make a reasonable assumption that people can read the javadoc here - @throws UnsupportedOperationException if called on the client, or called on the server outside of the configuration phase.

#

The cost of two paths for one method's worth of segmentation is too high

#

as is evident by the previous implementation

wooden tendon
#

We discussed this with more then 4 people

#

An we agreed that it is worth it

#

To have a compile time safe API

#

If we can do this without too much overhead, and we can.

#

You just need to maintain a decent interface and context implementation

#

Which is really not hard

#

Mojang does it for their listeners

#

And you are telling me that we can't maintain a class hierarchy that is made up out of three types?

#

Seriously?

true jacinth
wooden tendon
#

I don't understandยด

true jacinth
#

That's the reason you had so much copypaste in the first place

wooden tendon
#

You can make a proper OOP design without a lot of duplication.

#

I left a review requesting changes for now

#

Some of the PR is really nicely done

#

The staticness of NetworkRegistry is very nice

true jacinth
#

Okay, top level here: The two paths require introducing a subclass of IPayloadContext and IPayloadHandler
IPayloadRegistrar#configuration then has to be updated to be generic and take ? super IConfigurationPayloadHandler
#play stays as-is
#common stays as-is, but users of common now need to downcast on their end to access IConfigurationPayloadHandler (instead of just checking the protocol and invoking finishCurrentTask)

NetworkRegistry#handleModdedPayload has to be updated to construct a context based on the listener's concrete type instead of just the context, needing two more context impls

wooden tendon
#

I am not sure why I did not do that from the beginning

true jacinth
#

It was longstanding for it to be instanced

#

I think you just went with it

wooden tendon
#

Which would probably work very nicely

#

If you split up the NetworkRegistry into smaller pieces

#

With each their own functionality and scope

#

The code duplication would then be extremely minimal

#

Maybe even none existent

true jacinth
#

Bleh, and I have to de-record-ify ClientPayloadContext and ServerPayloadContext to make them extensible

wooden tendon
#

I will point out that you started this without asking anyone from the networking working group that have worked on this topic for nearly half a year now.

#

We have been were you are right now

#

We have not come to this somewhat idiotic API by accident

#

I agree that some stuff (like the subsystem specific context system, where each subsystem is its own type) is very opinionated

#

And might/should be changed

true jacinth
#

I still think it is worth trading one method's worth of compile time safety for a single path

#

if there was more code relating to the other path, there would be more reason to have two paths

wooden tendon
#

Not from the discussions we had

#

It was already problematic that we threw an exception on the client side

true jacinth
#

or if we guaranteed that finishCurrentTask was callable on both sides - but we don't have that either

wooden tendon
#

People climbed the barriers and wanted us to introduce a "NeoForge" Ack payload

true jacinth
#

So ultimately we still place a burden on the reader in both cases

dry stumpBOT
#

Quote #1777 added.

plucky brook
#

thinkies maty has to fix stuff

true jacinth
true jacinth
#

it has its own flaws:

  1. Impossible to register a non-configuration handler for a configuration payload without registering it as common [might be a non-issue, should anyone really be doing that?]
  2. NonExtendable override introduced in IConfigurationPayloadHandler
  3. Very long generic declaration for DirectionalPayloadHandlerBuilder due to the introduction of H
#

plus the code volume (which adds a maintainence burden)

elder swallow
#

Most mods probably don't provide a version at all, right now

true jacinth
#

I'm pretty sure versioned optional channels can be made to work in whatever method non-versioned channels were working before

#

there is no real basis for them to be unable to

stiff galleon
#

why should mods provide versions

#

if I introduce an incompatibility, I bump the mod version

true jacinth
#

the mod version is not checked

#

only channel versions are

stiff galleon
#

if we don't have a good way to say "the version of this mod on the client is not compatible with the version of that mod on the server" then should we look into that?

#

rather than having versions on specific channels

true jacinth
#

Your network version is not directly comparable to your mod v ersion

elder swallow
#

Software design is all about tradeoffs. And here we have a well documented contract. Not everything can be proven at compile time - it is a trade-off between catching bugs earlier and not making the code too hard to read/write

stiff galleon
#

Your network version is not directly comparable to your mod v ersion
yours isn't, mine is

true jacinth
#

i.e. you may have pushed a fix, but it was only relevant to the client - needing a new version

stiff galleon
#

there's a specific digit I bump whenever I break network compat

true jacinth
#

Well then you have a network version :p

#

use that as your channel version

restive raft
#

you could tie in your mod version to your network version

true jacinth
#

doneโ„ข๏ธ

stiff galleon
#

I thought channels didn't have versions anymore

true jacinth
#

Right now (1.20.4) they optionally have versions

#

in my (1.20.5) refactor, they are required to have versions

In both cases, the channel may still be optional

slow prism
#

neo itself uses non strict channel version, so no, channels have to be versioned or not at all

true jacinth
#

Yeah, it's effectively always versioned

#

just you may have a blank version

#

how can I even check that cross-loader channels work? Do I need to spin up a fabric mod somehow?

#

If I'm understanding the setup correctly, non-neo channels are stored in ATTRIBUTE_ADHOC_CHANNELS via register payload

#

these do not interact with channel versions whatsoever

#

so the version is irrelevant for any consumers that are not Neo

elder swallow
true jacinth
#

Thus, version can be mandatory for registration without having any impact on Bukkit/Fabric/whatever cross-connections

true jacinth
elder swallow
#

Might be available in the description of his PR from ~3 weeks ago

elder swallow
true jacinth
#

Ye that has come up a couple times now

#

it was also the case with the isConnected naming

#

as the rationale for the name is rooted in future work that only makes sense after that future implementation

#

now I have to figure out how to setup a snapshot fabric env to check this against, screm

#

screm the test mod has to be ported as well bc fabric api changed

elder swallow
#

Well yeah, vanilla did change ๐Ÿ˜›

true jacinth
#

so guess that needs some looking at...

#

Also not sure if this is a me artifact or was just broken on 20.5 as-is

#

ah wait nevermind

#

I forgot to do an optional reg on the server

true jacinth
restive raft
#

gotta love those off by one errors

blazing valve
true jacinth
frail hatch
#

I just set it to the artifact version of my mod container

shut wraith
true jacinth
#

Well at least I can make you think about it

shut wraith
#

stabolb you cannot

#

It we be set to something and promptly forgotten /hj

elder swallow
#

how am I supposed to access the Connection from a payload handler?

fallen igloo
#

what do you need it for?

stiff galleon
#

they want to noop the handler in singleplayer

#

(which begs the question, "why do you want to noop the handler in singleplayer?")

fallen igloo
#

also if the player is null and it uses the Minecraft.getInstance().player then the connection in the minecraft instance should also be null since that call is delegated to the player afaik

elder swallow
#

good point

#

the problem was that the player shouldn't be cached then

#

see #maintenance-talk

fallen igloo
#

on another note, it's snapshot day ๐Ÿธ

elder swallow
#

true

clear bane
#

what wonders will they give us this week harold

jagged yoke
#

component crafting ๐Ÿ˜Ž

clear bane
#

remind me...
were you part of Mojang, or not thinkies

jagged yoke
#

Nah lol

naive hound
#

I think at this point, Misode has them on speed dial lol

magic sierra
elder swallow
#

along with a much needed Ingredient refactor

magic sierra
elder swallow
#

wait

#

wtf Misode

jagged yoke
elder swallow
#

jeez ๐Ÿ˜„

#

from the twitter post?

clear bane
#

super secret mojang discord ofc

naive hound
#

potion recipe jsons when?

jagged yoke
#

Slicedlime's tweet is more than an hour old, we've had time to analyze xD
But also it was one of the options we suspected when he said this in his stream:

I've been working on a massive thing, that's kind of ended up on top of all the item components stuff, that hopefully we'll see soon. It should be pretty exciting for pack makers. And that's a very big new thing.
https://youtube.com/clip/UgkxyWThjY6oNV3FeXLzDt0FbSLVbQCrB2gP?si=jpuFovDP-t80aAJQ

stiff galleon
#

probably talking about datapack items/blocks

quiet condor
elder swallow
#

NBT crafting but with the new component system instead

stiff galleon
quiet condor
#

oh

#

sounds cool

fallen igloo
clear bane
#

its Mojang, don't tempt the mojang harold

stiff galleon
naive hound
#

๐Ÿค” so we just need to leverage that phenomenon to get what we want in vanilla. foolproof /j lol

wild pine
stiff galleon
#

Added variants of Wolves
Better than Wolves reportedly inconsolable

#

Spotted Wolf - A variant that spawns in a new location for wolves - the Savanna Plateau biome, in larger packs of 4 to 8
Striped Wolf - A variant that spawns in a new location for wolves, the Wooded Badlands biome, in larger packs of 4 to 8
wait those are just hyenas

#

vanilla recipes can now set itemstack data of the result

#

cooking recipes still can't set the count, weirdly

misty crow
#

Banner patterns are a datapack registry now

slow prism
#

<@&1067092163520909374>

open kindle
white frigate
#

not worth it for a debug tooltip ?

open kindle
#

eh, if commands are worth it, so are debug tooltips

white frigate
#

most commands are meant to be used by players ig

#

๐Ÿคท

open kindle
#

I'd argue the same for advanced tooltips

blazing valve
#

Yeah yeah, there are better ways, it just is

stiff galleon
#

wolf variants are a datapack registry

#

when a wolf spawns, it iterates over the loaded wolf variants, until it finds one that matches the spawn biome, and uses that

#

so you get at most one wolf type per biome

#

but the wolf variants specify a biome holderset, so you can easily add them for custom biomes

open kindle
#

what happens if there's no variant? cancelled spawn?

spiral radish
#

So how many mods do you reckon we'll get fixing that

stiff galleon
#

if there's no variant for that biome, it uses the default/old/pale wolf

prisma locust
stiff galleon
#

"why are my taiga wolves clown-themed"

analog ledge
#

just gives pale wolf

short cove
#

It's too limiting

#

Mojang seems to forget multiple datapacks can be enabled

stiff galleon
#

wouldn't findAny just do the same thing

short cove
#

I was under the impression from reading the javadoc it finds a random one

stiff galleon
#

no

#

it's just not guaranteed to be deterministic

#

the underlying implementation is free to decide which thing to return

short cove
#

aw

stiff galleon
#

but, if you're non-parallely iterating over a list, which we are, that implementation is still just gonna be "grab the first one"

open kindle
#

so findFirst does actually make sense

#

since it's grabbing the first match from the first (= top-most) datapack

short cove
#

Overriding can still work

stiff galleon
#

well, only the topmost datapacks' wolves are going to be in the registry anyway

short cove
#

You just override a specific wolf

stiff galleon
#

no I mean

#

if you make a datapack that overrides the vanilla spotted wolf with a clown texture

#

the registry has the clown spotted wolf, and not the vanilla spotted wolf

short cove
#

Well yes

#

If overridden

stiff galleon
#

okay, good, everyone agrees then

short cove
#

But if you want to add the clown spotted wolf and keep the vanilla one, it should pick randomly

#

imo

stiff galleon
#

anyway if mojang wanted a random wolf

#

the correct implementation would be to first make a filtered list of valid wolves for the given biome, and then randomly select one from that

median wasp
#

Is there a .shuffled() on Java Streams?

spiral radish
#

Nope

median wasp
#

Util.getRandom on .toList() would work then

stiff galleon
#

yeah that's faster than shuffling

median wasp
#

Meh

#

It's O(n) either way

#

A bit faster maybe

#

But we're talking much less than a millisecond

fallen igloo
#

and now to waiting for NeoForm

quiet condor
#

oh yeah all tools have the same damage and attack speed now

stiff galleon
#

IIRC that was a bug

quiet condor
#

was?

stiff galleon
#

from the previous snapshot

foggy steeple
rigid walrus
#

Only 1 new compile error

digital drum
#

qq: components essentially replace nbt right?

quiet condor
digital drum
fallen igloo
#

the format probably not but itemstack nbt is "gone" (it is moved to components and the custom_data component)

naive hound
#

Since i absolutely love the attachmentTypes that Neo had and this is basically that same system i'm super excited for this vanilla change

fallen igloo
reef parcel
#

love that enchantments don't have to be deserialized every single time they need to be accessed for any reason on itemstacks

plucky brook
fallen igloo
lean anchor
#

So, how DO components work now, in code? Something like EnchantedBook.enchantments(stack).level(Enchantment.POWER)?

#

Similar to how data attachments work?

reef parcel
#

kinda, yeah. stack.get(DataComponents.ENCHANTMENTS).getLevel(Enchantments.POWER)

median wasp
#

And they're stored as the difference between the stack's components and the item's default components

lean anchor
#

oh, derp. I crossed two ideas in my head, sec

#

fix'd

#

but question answered

reef parcel
lean anchor
#

I see this quickly turning interface-based... like IEnchantableItem having an enchantments method that reads values

#

So your common stuff is abstracted away

reef parcel
#

what lol

lean anchor
#

That's what I do in CM6 now, anyway

reef parcel
#

if you want your item to have enchantments, you just give it the component

lean anchor
#

like, this but with components.. the common code vanishes and all you need is to add an interface

median wasp
#

Here's an example from their code:

public static int getItemEnchantmentLevel(Enchantment enchantment, ItemStack itemStack) {
   ItemEnchantments itemEnchantments = itemStack.getOrDefault(DataComponents.ENCHANTMENTS, ItemEnchantments.EMPTY);
   return itemEnchantments.getLevel(enchantment);
}
lean anchor
#

Oh. Yeah, that's ๐Ÿ”ฅ

#

That'll reduce SO much code, it'll be hillarious

reef parcel
#

yeah, if they went the interface way, it would be pointless

median wasp
#

Well getOrDefault is actually on DataComponentHolder, which is an interface

#

Which means we might get it on other objects ๐Ÿ‘€

reef parcel
#

that's not what I mean lol

median wasp
#

It would be neat if we could also have it on entities

#

Yeah, Ik, but still

lean anchor
#

It'll come to blocks/block entities long before entities, lol

jagged yoke
#

Blocks as well, would be nice if copy_components in a loot table actually did that

median wasp
#

Blocks don't really have a way to store components, unless there's a separate map of BlockPos to component inside a chunk, serialized to disk

#

At which point it's just a slightly lighter-weight BE

jagged yoke
#

I meant block entities, my bad

median wasp
#

Ah, I thought you said blocks and block entities

#

Well

#

I thought Nano did

digital drum
#

what are slot ranges?

median wasp
#

armor.* is for all five armor slots

digital drum
#

ok kinda getting it

lean anchor
#

Wonder if we can convince 'em to use range format (hotbar.[1..3])

#

Meaning, any of the first 3 hotbar slots

lean anchor
#

Mojang has eyes and ears better_eyes

reef parcel
#

boo!

stiff galleon
slow prism
#

also reminder to sync the component types reg

fallen igloo
#

it's a normal registry do we need any additional logic there?

shut wraith
#

Whoa, didn't look at today's snapshot yet. Bunch of interesting stuff here

true jacinth
#

Hopefully the networking changes don't have that many rejects

solar zephyr
slow prism
fallen igloo
#

well we do reg id sync for all registries anyway so that is also not a problem

slow prism
#

no?

fallen igloo
#

wdym no? yes we do have reg id sync

slow prism
#

it's not for all registries

elder swallow
#

any reason why we don't sync all of them?

fallen igloo
#

idk I added the reg to be synced

elder swallow
#

@slow prism why not sync all of them?

stray bay
#

if i understand correctly from what people have been saying

slow prism
#

and synced registries mandate that the contents of the reg are the same on the client and on the server

elder swallow
#

hmmm true, syncing recipe serializers would be pointless for example

foggy steeple
stiff galleon
#

worldgen structure registry isn't syncable anyway harold

#

or not able to be made syncable

#

not without substantially rewriting how the datapack registries are synced

foggy steeple
#

Structure type registry is not a datapacks registry

#

So if one makes that synced, me throw hands

stiff galleon
#

ah I thought you were talking about structure jsons nvm

stray bay
#

huh they added item component output to the furnaces specifically, did they add it to the crafting table in a previous snapshot?

#

also datapackable banner patterns (and wolf types - kind of makes me wonder if they'll go back and do it to other animal variant types / add more)

quiet condor
#

I think they also added it to crafting tables in the snapshot

edgy arrow
#

I'm waiting for datapackable paintings iirc

frail hatch
#

@elder swallow I realized a potential issue with immutable components. How will say energy handlers etc we try to attach to stacks work given the whole concept of those is that they are mutable

elder swallow
#

they just attach a new component on the stack

#

I REALLY want to make an immutable subclass of ItemStack and FluidStack

#

components should really be immutable

prisma locust
elder swallow
#

they replace the previous instance yes

prisma locust
#

isn't that going to be a complete disaster performance wise

elder swallow
#

no

prisma locust
#

i haven't actually read 24w09a in detail yet

elder swallow
#

potentially it's just allocating a single Integer every time the energy level in an item changes

#

which is completely negligible

prisma locust
#

this does not spark joy

elder swallow
#

it really doesn't matter

prisma locust
#

for that use case no

blazing valve
#

It will be less nice for AE2 portable cells

prisma locust
#

but in general you're telling me every component has to be copied on write?

blazing valve
#

OTOH those changes would only happen on user interaction

elder swallow
#

it's actually quite cool, it makes stack copies very cheap

prisma locust
#

oh because you just shallow copy components

#

true

#

hmm

elder swallow
#

because they only copy the component map lazily

#

well, lazy copy + shallow copy yes

blazing valve
#

yeah and those item stack copies happen... a lot

prisma locust
#

yeah I didn't consider the savings there

elder swallow
#

it also makes access to the data much cheaper than NBT access

blazing valve
#

did you already port fluidstack over to components or is that something for after the minimal port?

elder swallow
#

I kinda want to do it in the port

blazing valve
#

Aight. BTW. are components guaranteed to have equals/hashCode?

#

Or how do they handle it?

elder swallow
#

they should implement equals

#

idk about hashcode

blazing valve
#

Okay mods will 100% fuck that up ๐Ÿ˜„

#

But they'll probably notice if their stuff doesn't stack at all

#

I wonder if we should check in dev that two "default" instances of a component are equal (if there is such a concept, but since they are serializable I'd assume so)

elder swallow
#

yeah they should also implement hashcode

#

there is no concept of a default instance for arbitrary components

prisma locust
#

in theory one could use reflection to check for that

#

in dev

blazing valve
#

But we can copy components... how? Serialization / Deserialization?

elder swallow
#

they are immutable

#

you just make a shallow copy of the backing map

blazing valve
#

Ah, so no copy to begin with ๐Ÿค”

elder swallow
#

indeed

#

serialization/deserialization happens with codecs

blazing valve
#

But they still have serialization/deserialization requirements, so we could make a copy

elder swallow
#

there is the concept of a "default" component set that is provided by the Item

blazing valve
#

I am just spitballing how we could avoid the footguns

#

or rather, help modders avoid them

#

Didn't Guava have some testing util to test equals/hashCode or am I dreaming that up

elder swallow
#

some reflection could work

#

but it sucks ๐Ÿ˜„

#

could probably check the components directly when they get added to a stack

frail hatch
elder swallow
#

for example here you can check if the T param implements equals and hashcode

blazing valve
#

Well whatever check we add for dev it should not completely kill the perf in dev either ๐Ÿ˜„

#

but it'd certainly be useful to come into this version with some constraints so we don't get a complete buggy mess of a version

elder swallow
#

can only check once per class and in-dev, yeah

#

BTW I introduced a bug in the port

#

FluidStack#equals does not check for the amount lol

#

so it is not even suitable as a component as is

prisma locust
#

on the other hand

#

if you don't implement equals and hashCode properly will your component even work

elder swallow
#

well, unless you're AE2 or a similar mod I'm not sure you'll care about that

elder swallow
#

what if you only forget hashCode

blazing valve
#

Isn't there an ItemStack set in Creative Tabs?

#

It would certainly break net.neoforged.neoforge.common.util.ItemStackMap ๐Ÿ˜„

#

But in real subtle and hard to debug ways...

elder swallow
#

I just saw some COMPONENT_INTERNER.intern(this.components.build())

prisma locust
#

if(a.equals(b) && (a.hashCode() != b.hashCode())) throw new YouJustLostTheGame();

elder swallow
#

there is no default to instantiate

blazing valve
#

It would be nice if we could determine if a component class is immutable or not via reflection

#

And if someone really wants to make their component mutable, force them to implement a marker interface or some-such

#

At the very least mods like AE2 could still optimize all cases where immutable components are used then

prisma locust
#

if all vanilla components are immutable we should probably try to enforce the same

elder swallow
#

we should yes

#

my god

#

btw I'm redoing fluid stack entirely and I'll send a PR with that

prisma locust
elder swallow
#

well cause you generally don't want the count in there

prisma locust
#

oh yeah

#

so, count is the last mutable field on an itemstack?

#

(mutable without some amount of copying, at least)

elder swallow
#

๐Ÿ˜›

prisma locust
#

popTime

#

it's literally used for the animation in the GUI and nothing else from what I can tell

elder swallow
#

wtf is this now

prisma locust
#

what executor are they running the accept task on

elder swallow
#

mainThreadExecutor

#

could be worse

prisma locust
#

can't wait for someone to do async observer lines from 1.12 but with player heads

blazing valve
#

I mean, the skull block entity seems to do some real cursed shit too

prisma locust
#

indeed

elder swallow
#

oh the 24w10a port wasn't finished...

elder swallow
#

comments welcome

elder swallow
#

it is very close to ItemStack with count -> amount and item -> fluid

digital drum
#

optically

elder swallow
#

I would also prefer if we changed FluidStack amount to count...

#

because having two names for the same thing is annoying and pointless

elder swallow
#

and if we want a shared Stack abstraction for transfer later it would be very helpful to have the same name already

digital drum
elder swallow
#

maybe, not sure about the name

#

potentially IResourceStack or whatever

digital drum
#

actually this sounds nice, because mods like mekanism can simplify their ChemicalStack impls

elder swallow
#

that too yeah

#

the question is how much value it really adds to the entire ecosystem if the only mod that benefits from this is mekanism

#

since potentially we could patch getAmount on ItemStack if necessary

digital drum
#

not sure how many of those to argue for this to be added

elder swallow
#

I think that unifying fluid and item transfer has a lot of value

digital drum
lime galleon
#

so something like a fluid or item handler item, now has to copy the inventory on all modification because of immutability?

#

or the inventory has to be external and referred to by some instance-specific key

true jacinth
#

Something of that sort

#

But the idea is that it makes ItemStack a cheap-to-copy type

#

since you can shallow copy all the Components

#

So with that the burden of copy-on-write for an inventory is much smaller

fallen igloo
prisma locust
stray bay
#

as long as we don't add anything mutable to itemstacks

#

just define a class called ItemStackItemStackHandler that takes care of the copies automatically

elder swallow
#

@rigid walrus do you also have compilation errors?

rigid walrus
#

only a single compilation error that is exclusive to ecj

fallen igloo
elder swallow
#

What the hell

#

Might have been trying to run the tests hmm

fallen igloo
#

MC-268727 just got assigned

spiral radish
#

Is that the race condition one?

boreal flint
fallen igloo
dreamy crystal
#

Did it get deleted by accident? Or did it just... not get decompiled and added?

summer furnace
#

it's definitely used there

stiff galleon
#

gradle flub?

summer furnace
#

also used in the Wolf class

#

so there's 0 chance it's an oversight by mojang

#

this is a decompilation / repo setup issue

elder swallow
#

I think that schurli forgot to add new files under base and neoforge when he genned the sources

summer furnace
#

forgetting git add seems likely

elder swallow
#

he probably did git add

#

but he should have done git add -f

dreamy crystal
#

gitignore only applies to untracked files IIRC, so yeah

summer furnace
#

oh there's a gitignore on the folders we have files in? ew.

fallen igloo
#

I did git add --force projects/base/src and git add --force projects/neoforge/src

dreamy crystal
#

spooky

summer furnace
#

do you have a WolfVariant java file?

fallen igloo
#

wth git

dreamy crystal
#

let me guess: it checked only the immediate children

elder swallow
fallen igloo
#

I blame the intellij console

dreamy crystal
#

rip

magic sierra
#

MC-172289 fix & MC-92484 fix are still useful?

stiff galleon
#

you did the thing where you didn't explain what you're talking about again

#

why do you keep doing that?

magic sierra
#

the fix of this

#

and this

#

are still useful?

fallen igloo
#

if it is not fixed by mojang then we are gonna leave the fix in

#

but since we are removing our attributes idk if the fixes are even still possible

magic sierra
#

the fix: /attribute @s minecraft:player.entity_interaction_range base set 4.5
or
/attribute @s minecraft:player.block_interaction_range base set 3

elder swallow
#

the fixes were removed if they were part of our massive GameRenderer reach patch

#

that's a behavior change though

restive raft
#

it can come off as quite random if you ask questions like that out of the blue