#1.20.5/6 Snapshots
1 messages Ā· Page 2 of 1
60%
wdym by 60%?
default is 50%, 60% feels too low
love how your PR title is reduce and the comment mentions increasing
more quality means less fuzzy
why change it here instead of in NG
š¤·
this is way easier to test and tweak
only 35 rejects with 60%
@wooden tendon do you prefer the fuzziness to be changed in NG or neoforge? - see PR 602
70% gives 55 rejects
the thing is... a single uncaught misaligned patch is so much worse than having to apply a few trivial patches by hand
1.20.4 -> 24w05a
129 rejects
yeah
before fuzzy we did all of them by hand :P
IMO doing them all by hand is quite reasonable
(unless it was always fuzzy and I didn't realize)
not for snapshots
I feel like the current fuzzy system would not have the problem you've described if we were actively updating to snapshots, but we lack manpower for that right now
it would clearly have that problem
the chance of a patch being misapplied in the first place goes down as the difference in the underlying codebase decreases
for instance 24w05a -> 24w05b should be a perfect match for 99.9% of patches
this kind of stuff is really hard to catch
each version yes, but I would expect that cumulatively, the amount of misaligned patches should be similar?
1.20.4 code for reference
honestly this just looks like the patches not being created with enough context
like why is that even being applied
yes, regardless of fuzziness
50% fuzziness is very fuzzy
and yeah that is the patch lol
this type of patch should not be applied fuzzily
easy to say when seeing the patch
there isn't much you could change around it and safely apply it
I feel like that isn't the case for all patches though
well, what is the probability of a patch being 1) hard to update and 2) handled correctly by the fuzzy patcher?
i.e. what is the actual difficult work
keep in mind that the patches used to be with SRG names, making applying them very hard
now that the patches are direct source patches it should be trivial to apply them
that's true...
I have a curiosity. what if you do 1% lol
I would definitely say preferring missed patches over misaligned patches is probably smart
Especially given that as you've pointed out, it's all Mojmaps now
1 reject
they're probably all misapplied lol
I guess actually that's really the more important data point
not the quantity of rejects/misapplications
they're probably injected in random places
but rather the number of misapplications that would otherwise be rejected
hmmm no there's a problem with the way I am counting the rejects
Misapplied patches are unfortunately basically impossible to count except by hand
there's 1 reject file and 5 classes for which the target could not be found
random injections yeah...
ayo, they broke the negative amplifier jump boost effect trick for disabling jumping?
worse, the broken negative mining fatigue to stop block mining without slowing down attack speed
My existence is threaten!
is it time to patch that back in? /s
an interesting experiment would be to do the updating incrementally snapshot by snapshot with 95% quality and compare the number of rejects to doing one direct
So did we get the big new obvious feature?
hmm yes yes... they now have things working in Vulkan /j
no further big features yet. they seem to be polishing the new structure
probably prereleases next week
Wait okay here's a funky idea: apply patches with a bunch of different fuzzinesses - say, 50 to 100 by 5s or whatever, I don't know how slow that is. Then, you can get a ranked "how likely is this to be misplaced"
Just based on at what point it started failing
that sounds extremely slow
That's more or less what I did but not very scientifically
I don't know how fast patch application is - I'd assumed it was reasonably fast
But I could be wrong for sure. It's not like there's any recomp/decomp to do at least
It's quite fast yes
honestly me neither, but I assume fuzzy patching is an order of magnitude slower than non-fuzzy, just from its nature
But the idea would be that you'd have a report of, basically, patches ordered in order of misplaced-ness when you're done, then just go down the list checking them
Checking each patch is what is annoying
And if you made it automated, you'd just run it once, get the list, then check from most to least misplaced
Basically, for every patch you'd have a system that'd start at 100, go down towards 50, stop when/if it matches, and record what you stopped at. Hmm. Gotta see how hard it'd be to get diffpatch to do that
do it scientifically 
That is to say, do it the same, but come up with a hypothesis before you start and write down the results after
Problem solved
you also need multiple samples, to account for variability
you also need to test in multiple OSs for line endings
no diffpatch uses \n not the system default
ahem
Remembers the issue with vineflower where line wrapping was different depending on the OS
pushed a comparison if you want to have some fun: https://github.com/neoforged/Kits/commits/24w05a-patch-experiments/
60% is too loose
65% is too loose too
70% causes an annoying misalign in ChatScreen, so that is too loose too
this kind of misapplication is quite problematic
will probably be caught by the compiler but 
(this is 80%)
I think 85% is reasonable
š
So the lower bound on what covers recommended
if we get too many misapplications we can always increase it later
you can check https://github.com/neoforged/Kits/commit/f2e5588f242befdccbc8992abadc91d532f30e3e, if you think the misapplications here are problematic we can also do 90%
hmmm there is a record field reordering in CommonListenerCookie 
I am not complaining, I am just stating covers was right it seems
wouldn't hurt to have some double checking
maybe 90% is safer
especially in the cases where we move vanilla logic to CommonHooks
is https://github.com/neoforged/NeoForge/pull/602 still on the table, or is it superseded by a PR to NG?
Will be moved to NG
NG PR to change the default
shall I close, or shall I let Tech close it on his own initiative
when Tech does that, he should add the background on how the new default was chosen in the PR description (or the commit message)
I'll send a PR soon TM, giving it a bit more time to discuss the default value
(otherwise I'll go for 90% if nobody says anything)
Pong me when you have the pr, i will merge it immediately
It is a single value which you tested well
I see no reason to fuck around with that pr
how do you check the changes from snapshot to snapshot like this?
That's just a commit comparing patch fuzzyness over the top of Kits (private NeoForge dev but with source code instead of patches for the initial port to a version, which then get's collated down into a single commit in the main repository)
If you want to actually just compare MC versions then you can use https://github.com/neoforged/snowblower Snowblower, or one of the many other 'mc version compare by git commit' projects (For example https://github.com/WinPlay02/GitCraft)
how do I run/use snowblower?
Creates a git repository with decompiled Minecraft sources - neoforged/snowblower
?
ĀÆ_(ć)_/ĀÆ
I have never used it, don't ask me for support. haha.
I just looked at the main method, it describes what's all needed to run it
gitcraft was very easy to setup and run, idk about snowblower
it's doing every single version
how do I only make it do certain versions
i'm doing ./gradlew run --args="[--only-version=24w05b --min-version=24w05b --max-version=24w05b --mappings=mojmap]"
that doesn't look right
you would want it to compare on the --min-version=last snapshot, right?
./gradlew run --args="[--only-version=24w05b --min-version=1.20.4 --max-version=24w05b --mappings=mojmap]"?
Remove the square brackets
I do ./gradlew run --args="--create-version-branches --mappings=mojmap --min-version=1.20.4 --no-external-assets --override-repo-target=minecraft-repo" for my setup
(I also have some custom stuff setup locally, like generating gradle stuff in the generated repo to list dependencies, so it can be imported into IntelliJ)
how long does it usually take?
Erm, depends on how many versions? A few minutes per version? Also depends on your machine
Mine is pretty slow to decomp compared to what some people here use
The log will tell you what it's doing though. First run will take longer as it downloads libraries it doesn't already have and whatnot
hey, I have ran gitcraft, it generated something, how do I see the differences in the ui like way above?
Pick your favorite tool for viewing git diffs. It's just a git repo like anything else
e.g.?
like what do you use?
gitk? Or GitHub, by uploading it as a private repo? But just use whatever you normally use for git stuff
ok, got it
I wonder if we'll get anything interesting in today's snapshot, or they are ramping down to prereleases
I'm still hoping for brewing recipes and block properties codec
If there is a pre release remember to bump NG first
no frogs so far but, https://vxtwitter.com/gnembon_mc/status/1755249778449916380
there's a strong implication a snapshot is happening?
<@&1067092163520909374>
Added generic.gravity attribute that controls blocks/tick^2 acceleration downward
haha
another (neo)forge attribute obsolete
Hoppers will no longer try to pick up item entities if there is a full block placed above it
yeap
nice, no more need to put composters on them
Beat me to it... finally!
that looks like a revert candidate if that disables picking up items through mud
I was gonna say that they already don't but the important part here is probably "try"
No need for that silliness with sticking certain things above then any more
Mash a hopper minecart in the block 
Reduced amount of data sent by the server during login by reusing parts of the vanilla datapack
Anyone know what this refers to?
And looks like they're still making the change in how data is cased, with a few more things being all lowercase now
Might be that they'll only send datapack stuff if it differs from the vanilla datapack or something 
Wacky
check the code if you want to know 
I should update my gitcraft repo so I can poke around in it
EVEN LESS HARDCODING FOR EFFECTS
hey, tele got his wish
seems like only healing should be left in the hardcoded stuff (we'll see when we have the snowman commit)

Hoppers will no longer try to pick up item entities if there is a full block placed above it
š
(this replaces the Lifecycle in registration)
SCROLL UP

^
I really need to get on my laptop so I can run gitcraft
Cause that looks quite interesting
I find it funny how github still hasn't gotten support for record
block pos nbt is now a length 3 int array

Lifecycles are dead apparently
or at least their usage inside MappedRegistry has changed
yep was mentioned earlier
rip all of DFU that references lifecycles
they still exist, but more indirectly
I've yet to understand what Lifecycle is 
My guess is it is related to whether to show the experimental warning screen window. Unsure if other uses
BlockStates have changed to use an Reference2ObjectArrayMap to store the property->value information
Lifecycle so far as I understand, is a way for them to be able to know if the current state of the game contains anything that isn't finalized design
eg, the experimental stuff in the save loading
but also in a more general sense, to show if the current environment is "stable", "beta", or "experimental"
if anything in the game is experimental, the entire game is considered experimental
I think this change effectively limits you to ~5 properties per blockstate before performance becomes a concern
hmm
but memory stops being a concern?
or is that besides the neighbourhood tables?
this is not the neighborhood tables no
what did they use before?
what does that use inside?
Why the heck would they switch to an array map
It likely makes sense for them if they never use more than 5 props per blockstate
looks like it's a custom implementation...? this code is a mess
looks like the regular one to me
wtf is RegularImmutableMap?! the get impl uses a loop?
oh you mean guava
You know how I update my gitcraft?
this is NOT the place to ask
and no I don't know, I have no clue what gitcraft is
ah, it's just a marker
it's just that every time I read Lifecycle I think about rust lifetimes 
Are there any breaking changes?
There's almost always going to be breaking changes
but they may not affect the average modder much
It's just the extent of them
Mojang is watching me lol
Did they fix synced entity data?
What about registry order for particle types? Given torch blocks. Given iirc they fixed attributes or whatever
Another massive snapshot, too much to scroll through the whole thing
oof
1.20.5 is gonna be interesting
Mojang: finnaly, we can merge those Pr's
we have been staling them for years
What PR
Just like Forge without Lex 
it was a joke
Ah
although a lot more Pr's have been merged since the split...
I mean, afaik, they do work on github and therefore probably do have PRs 
but none years old
Internal ones for mojangs repo that we canāt see
I mean true what do we know
might be, idk
Mojang works on like... a lot of things
and waits until the time is right
I suppose that some things were a few months to years in the works
like the rendering changes in 1.17 and so on
Stream codecs maybe
I mean... mob votes might have been pre determined somewhat, likely
with all the migration, probably 
Well, what is wrong with those?
And those?
it seems like us all
I pinged you for it in FC, similar thing to attributes
Some objects (like TorchBlock) hard-ref a particle type, but register before them
The order has to be updated or the usage has to be supplier-ified
idk what tech's referring to specifically with synced entity data though
Oh, this, right. Don't expect it happening in this release
I believe that entity data values are very fragile due to them getting numeric indices based on registration order, but I don't know if that's what tech meant
There were a lot of weird mixin-application-order issues with that, yeah
Nope Chase Client/Server not RCON
Dunno wtf it is
DediServer its not either
Anyone know what it is?
They are fine for you guys, but the system doesn't make it safe to declare new synced entity data on existing entities if the order isn't consistent on both sides. Something we could of course fix ourselves
and maybe we should
the data value indices can't be synchronized as they exist currently because they have no uniquely identifying name that we can use as the key
and by we i mean you can pr
Well now that attachments aren't so awful (and are synced) its not that necessary
Before that it was the only thing that was able to staple a synced data block to an entity
IMO we just should discourage modders from using those values in thirdparty objects (a modded entity implementing defineSyncedData is fine)
I have such a long list of things to do already
attachments are only synced for items
lol
sigh
I'd propose having a PARALLEL API separate from the data values
bad system 
similar to the vanilla synced data but by name
with completable futures, right?
not that kind of parallel 
wait whytf are they only synced for items
parallel to vanilla
because attachments on items get shoved into the stack when serializing it for packets
no opt-in or opt-out
yes, attachment sync is full of CFs
Well make those synced, problem solvedā¢ļø
ok i'll show myself out
Itās not safe for us modders but fine for you. If the serializers are registered by Mojangās method, forgeās parallel loading can cause the serializers to be out of order on client and server which then causes extremely difficult to diagnose client disconnects. My mod and Ars Nouveau has this issue for so long and took an entire week of big brain modders to figure that one out on what mods are involved and what is happening. Moved to forgeās own registry for entity data serializers which solves that issue
The other issue is people trying to inject add Synced Data Accessor into vanilla entities which then explodes when the synced data accessors fields arenāt classloaded in same order on client as server
Found out what ChaseClient/Server is
its a system where you have a /lead and /follow and basically allows someone to be in the same spot as you but in different game/world
Honestly dunno
Be crazy if they made it sync up player actions, if it did that then I could see it being more useful
Multiworld gametests (spitballing)
is that the first sign of a future datapack items refactor?
That Items class was added a 1.20.3 (When the block codec stuff was first added) and the lead & follow stuff was added when they where redoing world gen
this already existed and has for a while tbf
I thought we only got the Blocks references back then
we got both Blocks and Items?
I wonder what Mojang has in store for us š¤Ø
java21 yet
Pretty please
mojang pls
Perhaps for recording videos/trailers? Place the leader in a Minecart/water stream which isnāt present in the other world
java21 would be nice, but I wonder what the cost is of updating java, like does it mean a certain group of people stop being able to play minecraft?
what PC's can't run 21?
no idea, that was my question :P
this has been in the game for a while...
chaseclient/chaseserver is not new
like, I was just watching a video last night about how a recent VSCode update made people panic, because some people were using VSCode Server as the only way to interact with servers, and those servers used an old version of glibc, and vscode uses a newer glibc now
so you never know how a small update fucks people
I wasnāt trying to imply that it was, just speculating slightly on the usages
oh of course :)
Oh, that's very interesting for FC. What does getValues return now? Map<...> or explicitly R2OAMam<...>? That ImmutableMap has been a massive pain.
tfw ROAM
That's great news for me/FC!
(ImmutableMap isn't meant to be extended, and even a heavily trimmed version is still a pretty big object at that scale. With Map that's no longer a problem)
Java 21 supports the same platforms as 17, but uses newer build tool versions for them as is usual for a new JDK release. https://wiki.openjdk.org/display/Build/Supported+Build+Platforms
In theory shouldn't have any trouble, in practice however... š¤
Hoppers will no longer try to pick up item entities if there is a full block placed above it
š
I think that breaks a bunch of farms
they couldn't pick up items like that anyway, they just tried
AFAIK
you use hopper minecarts to pick up items above the block above
oh then it just improves performance?
I assume so
it sounds like a if (blockAbove.isSolid()) return;, but one would have to check the code
In theory at least, I guess we'll have to wait and see any potential issues that might arise
basically up until this snapshot
to avoid hopper lag you had to put some inventory on top
originally was dispensers or droppers
then it became composters
because they are cheaper to make
the presence of the inventory disabled the AABB entity check
with this snapshot, it seems like a solid block also disables it
hopefully only a full shape block only
and it doesn't break all the farms that rely on having soul sand or such
which are not quite full size
hoppers check blockstate.isCollisionShapeFullBlock
Hopper minecarts seem to also have the new check
yeah... it'd probably be too costly to do anything other than that
since you'd have to do additional math on the sizing and stuff
or some arbitrary rule like occlusion culling or something
you are the third ... people scroll up
Did you know that hoppers now wont check if solid block above?
can someone with the decompiled source look and see if they're doing anything new or clever for the wind charge rocket jump fall damage calculation? I do a fair amount of fall damage cancellation/manipulation
They have a new field named ignoreFallDamageAboveY that is type Double in Player where if the player takes fall damage while the field is set to a value that isn't null the fall damage is instead based on the value of the field
That's... a way to do that I suppose. I guess not that strange
OptionalDouble cries itself to sleep
Is that an actual type that java has? Huh
I mean yeah, that's what I'd do assuming it exists
But... I guess they didn't
yep, avoids null and boxing/unboxing
Well it's still boxing/unboxing
java util has double, long, and int types
It's just in the creation of the optional object instead of the creation of the Double object
But allocation/whatever wise it's going to be equivalent to boxing. The lack of null is the real nice bit imo
i mean, it's a creation of an object, but no gross castchecks if you're doing double myDouble = this.doubleObj;
No, you have to call getOrElse or whatever instead
But I totally agree, that would be more sensible for this use case
anything's better than using a nullable primitive wrapper obj :p
they store it as a Double but when reading it gets the value as a float
Okay that is cursed
...KnownPack looks fun though. Looks like packs are now namespaced, finally!
Lemme know if you want my feedback on any of the changes that'll have to happen to my system for mod packs when you port it. Shouldn't be too bad luckily
But the switch from a string ID to PackLocationInfo lets you express versioning stuff in the pack, which is pretty cool... but probably doesn't quite play nice with mods that have a string for a version
I'll have to think about it mod built-in packs can make use of that at all
But if they could it could drastically decrease what has to be synced, in theory
Packs also declare how they get positioned a bit smarter
But instead of an ID, packs now have a PackLocationInfo that holds:
- an ID
- a title
- the source for the pack
- optionally, info for finding a known pack - which takes an ID again alongside a namespace, and a string version
So actually I'm wrong, we could make mod data/resource packs use that and avoid syncing unnecessarily
Cause the mod version can actually be stored there
We'd just use something like neoforge:modid:modversion for th KnownPack
Gotta think about what you could do with this system more. I can already think of all sorts of stuff I want to add to DynAssetGen
Unrelated to that system - WTF is ClassTreeIdRegistry
Just, counts the use of a class... ah, something in synched entity data. I still don't quite get it to be honest, but alright
Yep, okay, first thing I plan to focus on with 1.20.5 is getting the mod data packs using this system - avoiding syncing stuff unnecessarily with this would be amazing
And if I'm reading it right might just be as simple as providing something for that Optional<KnownPack>
Also the ignoreFallDamageAboveY is still used even if the player didn't go above that y coordinate
Hoppers will no longer try to pick up item entities if there is a full block placed above it
š
hey guys did you know that hoppers won't try to pick up items anymore if there's a full block above em
hey guys did you know that I can ban you all /s /jk
can't ban me if I have a full block above me
The new check for hoppers does also affect hopper minecarts
wait... that might not be intentional... many farm rely on the cart being under the block and picking up items from above
looks to be unintentional, based on https://bugs.mojang.com/browse/MC-268349's continued existence (and assignment to a Mojangsta)
and the "Very Important" priority
Okay poked the KnownPack stuff today with fresh eyes and it still seems cool, so that's a good sign. Gotta think how to abuse this in DynAssetGen... and I'm now very curious how they keep going with this
Thanks for looking into the wind charge code for me. ignoreFallDamageAboveY isnāt as extensible as I would hope, but probably would be useful for making some of what I do feel more natural. Right now I do a lot of cancelling fall damage entirely
Basically: data packs can optionally have a namespace, ID, and version attached. When syncing datapack registry entries, if the datapack entry came from a datapack that the client has (that datapack has one of those ID/versions and it matches), it'll use the one from the client instead of syncing
Now, currently that's just applied to the built in datapacks because only those have a version
ok, so I was right, but not fully 
But it could easily be added to mod datapacks too
I'll also have to use that for my mod
ahhh, so instead of flinging all the vanilla biomes to the client, the client just uses the vanilla biomes it already has
Yep! And they conveniently made the "version" a string instead of an int or something, so it should be comparatively easy to use for mod built-in packs
Which.... yeah I can imagine that'll be a good thing when blocks get datapacked
okay, so datapacks can be loaded clientside now... can we abuse that for fallback tags?
But it's also all optional so stuff from datapacks, or stuff that overrides the vanilla biomes, will still get synced fully
not easily, as tags don't use this system yet. Oh, you mean just for loading the actual fallback tag? I mean yeah probably, I assume it's opening a ResourceManager for data clientside
because the current system is Not Greatā¢ļø
does this mean that datapack content is cached clientside now and doesn't need to be synced every login ?
that seems like a fairly substantial performance improvement
Not... Quite. It's not caching, it just uses local stuff if it has it. Registry entries only right now, and they're the biggest ones probably. Presumably, other stuff could use the system later on but right now doesn't seem to
In non-modded, the only packs this'll do anything for are the built in ones - normal resources, and presumably experimental stuff too if a server has that though I haven't checked
It doesn't cache anything, it just reuses local stuff if it's from the same datapack
But in a modded environment, neo could definitely (pretty easily) make it work with mod datapacks too
Since those also can easily have an ID and version
But to answer your original question: datapack registry entries from vanilla are no longer synced
And in vanilla that's the only difference you'll see currently
aside from that, under the snapshot thread on the Feedback server, a mod confirmed it as an issue
mind you, they aren't devs, but they also probably wouldn't reference it if it was wrong
here
https://github.com/neoforged/NeoForge/pull/26 Is this thing still useful in Minecraft 24w05a?
related bug report: https://bugs.mojang.com/browse/MC-193656
what are they doing to their item transfer API
ahah ok that is actually a cursed bug report
I assume it's related to the change they made for full blocks?
yes
Oh course, because those drop as an item, right?
yep, item entity
prime candidate for a game test
I do wish they would publis the tests they have internally
yea so we can verify that we don't break stuff
i wonder how many tests paper / something that cares less about 1-1 compat breaks
IIRC they do?
Or on bedrock?
I remember I was able to use their game tests thingy at some point
they publish the framework but not the actual tests
Hmmmm
Then maybe on bedrock?
I wonder if they would be willing to setup some sort of endpoint for mod loaders to basically run tests against without having to expose the implementation, just to see what fails (even though I guess that wouldnāt be that helpful without knowing what the failed tests are meant to do)
so we upload our own custom version of mc to their servers, they run it, and we get the result back???
Something, or they somehow send an encrypted set of instructions that can be ran
I donāt know
Was just thinking out loud
they might publish the real tests down the road
I was sort of just thinking how azure and some web based things do tests
Has anyone actually asked if they would be willing to do so, like to not have it that users have to download I understand, but as a separate jar/library it would be quite useful
data driven tests 
I have those for one of my mods
nice
Best yet, the data comes in the form of an image
what does the image look like
Tests what specific slices of the biome space look like after biomes have been injected into them
neat
The JSON defines where the slice is, the png defines what it should look like
hm
neat!
do you also have the created PNG saved for manual comparison, when the test fails?
No, but I have a command in game to export those slices in the first place, plus a debugging web server that can be started to browse around through the entire biome space
So what will be today's world blue yonder they put in the snapshot
there's a snapshot today?
usually one a week, so it's expected
is there a set day of the week?
I thought it was Tuesdays, but that may have changed
usual day is wednesday afaik
i was tuesday at some point but now it is wednesday at ~ 16:00 GMT
back in the day, we also had fridays
those were secret Fridays, no?
no idea
but these were the changelogs from back in the day
they didn't chagne change a lot of the format: https://web.archive.org/web/20140207055427/https://mojang.com/2014/02/minecraft-snapshot-14w06a/
They seem to flick between Wednesdays and Thursdays, depending on whether their ready or not
I have seen mondays as well
just for snapshots
now it seems to be pre releases on monday though
PreRelease/RCs do tend to be Mondays
if nones here to show the diffs, someone just ping me here, I'm so free you wouldn't believe it
people will use Snowman for that 
how do you use snowman? I use gitcraft just because idk how to use snowman
2 things
- pings
- no idea
srry
Snowman is the automated (private) repo, Snowblower is the tool
We have a TeamCity setup which automates it
got it, can I use it on my local computer
is there a guide? maybe I might switch one day
if no one wrote one in the last few weeks then probably just the main class code
A lot of mob AI has changed. This should mean nothing, but may actually mean something. Donāt sit on slimes.
back when did they more jokey/secretive changelogs
today it's going to be 24w06b right?
year 24, week 07, release "a"
got it
yeah that
btw gigaherz can you check the 1.20.4 parchment PR, afaik, you're moderator there
Im a discord moderator there yes, but I don't see myself as a maintainer for Parchment
ok
time to build
<@&1067092163520909374>
A new variant of Skeletons that shoot poisonous arrows
<@&1067092163520909374>
interesting solution to the hopper problem
block tag
Panda sneeze loot table? Funky

ERROR: Class net/minecraft/core/RegistrySetBuilder couldn't be processed.
java.lang.NullPointerException: Cannot invoke "org.jetbrains.java.decompiler.struct.gen.VarType.getArrayDim()" because "varType" is null
...
ERROR: Don't know how to handle non independent org.jetbrains.java.decompiler.modules.decompiler.exps.InvocationExprent
gitcraft better lol
ha I knew it
Snowman built, although VineFlower errored
i'm sure coeh will report it to VF once he's awake
hmmmm
also, I'm starting to be tempted by poking Snowblower to add a command-line option (in some form) to ignore assets
the registry access creates the registry ops now looks like
please do it github becomes laggy with such big commits
how to do it best is a question, hmmm
perhaps an exclusion filter
--exclude assets/?
The tags and other json changes are usually semi relevant
HolderLookup.Delegate is an interface now
someone compile a bulleted list of things to exclude -- paths (and/or maybe extensions)
I feel like it's mainly just .png and .nbt
i think I'm also going to stab the TC config for snowman
Spino could you not?
The new mob
because I hate this "Failed to load build settings from VCS"
nice, new mob
What's the matter?
sorry for that btw
Large flashes of white on my screen suddenly, also the fact that that's quite a bit of code posted in screenshot form
If it's relevant than sure
no flashbangs in the chat 
srry srry srry
Bogged is a new monster, seems to be a new skeleton that shoots poison arrows?
yep that's what the release notes say :P
BlockPathTypes -> PathType
where was this outputted?
so I can link to it
nope
Looks like snowblower failed to decompile it
still there
Yep, I mentioned it above
š i'm going to give the folks at VF a heads up, while coeh's not yet here to investigate it
new field in GameTest
@rigid walrus FYI
MC-267732 - /place jigsaw still caps max depth at 7
š
coeh: Decompilation error in RegistrySetBuilder, see above
the teleport command seems to have changed considerably
LookAt is a functional interface
and a record which holds the teleport position?
Interesting isGridAligned added to Hoppers for bypassing the full block check as well as the new tag, the MinecartHopper sets this to false
Panda based slime farm??
ohh the new kinds of animal cruelty we can do with this
tho it is 1/700 chance for each sneez and you have to get only sneezing pandas...
Those have always been a thing, just too slow to be practical
They dropped slime before, it just wasn't a loot table
booooo ruining my fun yall
Unless you're doing a peaceful only run, then they are the only option
No fun allowed :p
Also I feeeeel like Boged now spawn even if the experimental stuff is disabled...
encaseStructure is interesting
I made my pollen block and item make pandas sneeze when it touches them lol
You can have perpetually sneezing pandas of any type
bumblezone is clearly a game-breaking mod smh
š
so seeing the past snapshots, a bunch of combat changes, which is awesome
pls mojang update combat
gegy please
Hell yeah, that's going to be amazing for tests which check light levels for example, which I have a bunch of and which I currently have to encase in a stone box 
nope it uses barrier blocks
gestures at the general concept of modding
Worst case I mixin the placement and removal in-dev to use something else instead. Or make a PR to make it configurable ĀÆ_(ć)_/ĀÆ
š I mean I mixin to vanilla datagen to pull out the vanilla biome parameters during a gametest, so, not that weird
Yeah pr to just add an overloaded method that accepts the block to surround with
It would have to be an additional parameter to the gametest annotation in addition to that since the method is invoked automatically when the flag is set on the annotation
Ah
Can't you just mark the asset files as generated via .gitattributes, which would still generate them, but not render the diff on GitHub unless you specifically ask it to?
I just want 'em to finally fix BlockPos#betweenClosedStream(AABB)
Ooh that's a thing? I need to look at that
aw hell nah, they added the jungle skeletons from MCD to base MC
Ends up like this
No clue if other git repo viewers support that, I just know GitHub does
yeah, XFact recommended that and I implemented in https://github.com/neoforged/snowblower/commit/107d245fbeac2c33374f45615b43fffa7c2e9339
This attribute tells GitHub to hide those files by default when
viewing the commit diff. Hopefully this reduces the strain when trying
to view a Snowblower-created commit on GitHub.
Whelp, I got sniped 
Oh, you don't need the =true?
I see, I only ever checked the GitHub docs, and those do use =true while the linguist docs don't
Seems like the issue doesn't affect neoform
it's been suggested to me that it might be that Snowblower is using an outdated VF
i'll have to poke that
I think it's still using forgeflower
I screm if so
someone give me the name of an MC class that I can look at which has very long lines (that are linewrapped by VF)
ah, PlayProtocols I think is a good candidate
er. GameProtocols
@frail hatch @misty crow @fallen igloo @spiral radish what are we excluding from Snowman? .nbt and .png?
or any particular directories?
snbt*
There's both
Well, no clue about snowman
Does it run the debug datagen to generate snbt files?
okay, I've pushed out the Snowblower update
i'll be regenning Snowman again
i'll rename the current dev branch to dev-pre-2.0.14, for the sake of keeping Ater's links intact until we decide to yeet it
gametests now have an option for skyAcccess
gametest areas are now enclosed in barrier blocks (excluding the roof if skyAccess is enabled)
The polished andesite has been changed to bedrock
..whoops
forgot about that
oh well.
oh yeah, ought to mention it before I forget
I also paused the other build config for the Releases, so we aren't hammering the server with two decompilations in parallel 
the Hopper interface has a new method named isGridAligned
hoppers will check for a solid block if isGridAligned returns true
I assume they did that so minecarts can pull through solid blocks
BlockPathTypes has been renamed to PathType
looks at Snowman shit.
should I care enough to poke the indentation to 4 spaces
also, yay now GH is more speedy looking at the commit
FYI, seems there's a bit of trouble with the naming of lambda parameters in the Snowman repo
I moved it to VF
I might be missing a command-line option
I'll have to check with NeoForm
also, welcome back Shrimp 
amen 
š
how many did you have to remove because they don't exist from FF -> VF š
I didn't need to remove any, surprisingly enough
just a quick substitution of the dep (and the corresponding string in the Tools class) seemed to work all fine
though I'm still in the middle of understanding Snowblower's layout, and perhaps making some things more simpler if possible
hello shrimp š
hi
I was scrolling twitter and saw discussion of a new mob and I was like "oh, it's snapshot day"
and seeing if we can make the configuration better
tbh it did kinda get spaghetti'd pretty quickly from invention...
the config is very shit
I can agree on that point even when forgetting the entirety of how I (mostly) designed it
yea, I was starting to see that yesterday while poking the code
but I'm sure nothing that a few refactors and redesigns can't handle 
If you want 4 spaces you pass -ind= to vineflower as a single argument
i'll have to remember that when I next poke at Snowblower
the decompiler args are hardcoded, iirc
correct
the fact it is not -ind=" " feels so wrong, how does it know which space to split on
I think there's some automatic quoting going on
err, actually it might be because it's executed not through a shell, so the command-line args are passed pretty much directly
probably ends up as "-ind= "
yea
has to be lol
https://twitter.com/slicedlime/status/1760309382837891566 - no snapshot today
Due to some technical issues earlier this week, we are not releasing a snapshot for Minecraft: Java Edition today. The issues have since been resolved and you can expect snapshots for 1.20.5 to resume next week, barring any unforeseen circumstances.
Until then, happy mining!
Someone deleted the minecraft GitHub repo
junior dev: "Hey! i found out you can silence a lot of git issues by just adding --force to your command! "
branch protection rules 
Sounds like a workplace that doesn't trust their employees. smh. /s
Let the porting begin (https://github.com/neoforged/actions/actions/runs/7991951323/job/21824349414)
@elder swallow The work meeting is still going I can probably start at ~17:30 CET
@slow prism
what happened here?
It tries to find an artifact with the snapshot version twice in its name: neoform-24w07a-24w07a-20240214.192032. The actual artifact only contains it once
does the issue come from NG or the action
neither, it comes from your inputs
you only give it the timestamp of the version
i'll run it again
tech started the workflow not me
well then tech gets a stabby
tech
118 reject files
movement on Kits š
yes it's my bad
I'm gonna join voice in ~20-30 minutes and start with the porting
I'll join in on the fun
joining vc now
who is gonna take the role for porting lead for this one (I'd do it if nobody else wants)
not saying don't or anything, I'm just genuinely curious
I find that role a bit weird personally
it's a bit early to decide anyway, depends on people's availabilities close to the releae
having someone coordinate efforts is a good thing, I think
no please no more porting leads/dictators, ||i still hate the first version of that||
having someone who can give an estimation of the work remaining
a coordinator of sorts
usually the person who's invested the most time in porting, or have regularly been porting
unless every porter is equaly capable of that role, we should have someone to at least be acknowledged as being "the most likely to be that"
anyone can do that
it's a matter of seeing how many rejects are left in the dir and how many compile errors there are
and you can't predict who's going to port "the most" in the first minutes
it's a volunteer role -- someone says "hey, i'll coordinate porting" and unless anyone objects, they have it
and it's mostly informal
and checking the amount of compile errors does need access to Kits and cloning it locally to check
i'd think their main thing would just be keeping this channel up to date on the state of porting
as other porters come and go, and might not remember to poke here with what they've done
the role of subproject leader has given people the dictator power and still is
it's not an on-high appointment that vests them with any sort of dictatorial power
it's essentially the phrase "a private in action outranks a lieutenant at rest"
comparing the role I have in mind to subproject leaders is a bit apples-to-oranges
So what happens if two maintainers port the same thing by mistake due to no coordination?
for one, subproject leaders are explicitly defined in our governance modelm per https://github.com/neoforged/governance/blob/main/core.md#subproject-leads
I have no intention of making a "porting coordinator" role be a subproject lead (or at least, at the moment)
you don't coordinate who ports what
fixing rejects and compile errors is not really a "linear" thing
besides, the reason why subproject leaders effectively are dictators, despite our governance model specifically not allowing that, is more because we don't have any defined and practiced ways to hold their decisions accountable
or don't want to
that is a topic of discussion for governance, which is an area I've bowed out as I've previously indicated
so direct any concerns to Curle if you think the governance model is insufficient, as she wrote the thing
(and is also out of scope for this thread)
not a fan of code ownership myself
If you need to drop a small Todo somewhere: https://hackmd.io/S718YKv-TnWrRKB4nzYV_Q
(big stuff please on the org project)
down to 93 reject files
*81
schurli can't count
schurli didn't pull since xfact pushed
schurli deserves a stab pat
@elder swallow you want to get into VC again? I'm also dabbling around with the networking rejects right now
don't do a 1am vc
Why not? 
happy to join vc in ~30 min
š
will be joining as well for emotional supportā¢ļø
@frail hatch new itemstack method that makes me remove all your copy attachments patches š
how useful
do we still need the patched in Ingredient#fromJson now that everything is codecs?
it's a dp reg now?
it isn't
so that method shouldn't be a problem
gotta setup a workspace
it is now ResourceKey based
use is now useItemOn and returns a ItemInteractionResult
gogogo
ok so
NBTUtils#writeBlockPos now writes blocks with an int array with 3 ints
do we want to keep using that method in forced chunks and break old saves
make a datafixer 
make the old as a fallback for reading
yay one supplier patch less
81
I've got part of those fixed locally
oh good maty is doing overlays
ew we need so many ats
wildcard my friend, wildcard
extendedgui is 
Honestly, comment out ExtendedGui entirely for now so we get something compiling and then we can fix that afterwards, it'll take a bit of finesse to fix that properly. Though, in the end we may be able to yeet ExtendedGui entirely
wait where did screenHeight and screenWidth go
probably a good idea
hmm we probably need a chattype for system
let's see what we're left with after commenting out extendedgui
100 errors
i went up
whoops
that's probably the overlays tho
also who volunteers to make a porting guide
neighborChanged -> handleNeighborChanged
Screen#screenWidth and Screen#screenHeight are now guigraphics methods
also removed fluidstack methods in FBB and added a streamcodec
60
BlockEntityRenderBoundsDebugRenderer is losing me
yeah besides that the only things left are networking errors
(and obv fixing overlays)
and since i'm bored i'm really tempted to look into overlays 
@misty crow I also started working on networkign locally
I wasn't sure what you had done 
Heh, that switch from PoseStack to Matrix4f is going to confuse a lot of people. It should be as simple as making a new PoseStack from the matrix, maybe the event should provide that though
mhh yes
read either, write new
and how is that done
mojang has been wanting to move away from blockpos-as-long for a long time
it is fine to extend
we just need to add a parameter to the .add method that identifies the lambda
oh also RegisterGuiOverlaysEvent ordering was based on current registered overlays so if you wanted to regsiter before another mod's overlay you had to make sure that your listener fires after
qualityā¢ļø
yeah i know
i'm just trying to think of a design that makes sense
as in whether to expose the LayeredDraw and then make it handle sorting
also
another problem
this method
does making the layereddraw have an id make sense or should that method specify an id
uh the original registration system accepted resource locations so you could reference a mod's layer by name... if the event doesn't allow it, the feature was "lost" during the change over
that was supposed to be processed after all mods have had a chance to register....
although topsort is probably overkill
I feel like something has been lost since my initial impl :p
granted, I don't know when it was lost
Should be as simple as this:
PoseStack poseStack = new PoseStack();
poseStack.mulPose(event.getPoseStack());
should i subclass layereddraw or add to it
I'd say add to it
So a datafixer š
hmmmmmmmm
hmmmm
RenderGuiOverlayEvent is also a problem 
this needs a hefty amount of patches
I can poke the new resource pack features as soon as it's all released and PR something to use those for mods if you all would like
ugh add(LayeredDraw) is a problem
this is very annoying
we'd need to fire an event with 3 layereddraw instances
I don't think they are completely done the PoseStack changes, I wouldn't refactor the event yet
did you just yeet an OnlyIn off Layer?
harold didn't notice that
i can't say i love it
but it would get the job done
@elder swallow thoughts? 
IMO add without ID should be illegal
but idk what exactly you are doing
I think you should just preserve the event-based registration
that requires extending, cause mods can use layereddraw themselves
an event-based registration would also mean that we need to massively patch the vanilla add layer calls
which has never lead to issues
since the layereddraws are recreated every time
I don't like any solution tbh
What do you mean it's recreated every time? The Gui gets instantiated exactly once
well I meant it's recreated when a gui is
what I wanted to do was to fire an event with the 3 layereddraws in the ctor
mojang finally makes something sane in their code and manages to screw us. classic
i mean whatever we do it's likely going to be cleaner than the old way of replacing the gui
but still ugly
Gui is the HUD, it is never recreated
it's even final in Minecraft
jesus
Java generics were a mistakeā¦.
Unfortunately, I've seen worse. I've seen generics so bad that IntelliJ thinks they're fine when they're not
Never fun to deal with generics pain
Yeah, Iāve written generics like that before as well, as well once wrote generics that both IntelliJ and Javac thought were fine but the code that Javac produced crashed on execution because it was really really not okay or something (I forget the specifics)
I've caused exceptions in LambdaMetaFactory with code that Javac compiled fine
Though ECJ was smarter and knew it was an error
Yeah this wasnāt even lambda meta factory, just generics with & in them. That produced an error type I had never seen before and on googling stack overflow said it was a javac bug that it even compiles
that is easy because the MH invoke methods are special in the JVM
ECJ is a bit stringent on generics as well that some things valid in IntelliJ and javac it doesnāt allow
For my one, all you need to do is create a lambda with multiple interfaces (a normal thing you can do), but then add a SAM abstract class (not interface) as well
I present: https://github.com/lukebemish/codecextras/blob/main/src%2Ftest%2Fjava%2Fdev%2Flukebemish%2Fcodecextras%2Ftest%2Fpolymorphic%2FPolymorphicSubClass.java#L16. IntelliJ thinks the type arguments are redundant. They're not
Javac doesn't care that it's an abstract class because it's still SAM. But LMF on the other hand actually checks that all supertypes are in fact interfaces
Oh I've had this precise issue
I have that suppressed or redundant diamond expressions in quite a few places in mek
Most places IntelliJ gives you it it's actually redundant. Just not here
I know
I only have it in places where javac fails to compile after IntelliJ said it is fine
IntelliJ just doesn't like how cursed my type parameters get there
I've had a place where IJ gave me a redundant type args warning in Kotlin, but removing the args resulted in the compiler crashing
IntelliJ had the most useless generics errors when I was writing test cases for that system...
But granted I think that's my fault for abusing codecs and lambdas to the degree that I did
@elder swallow networking done, we should be ready to rebase it on the main porting branch and merge it back in
Ping pong
Networking is merged into the main porting branch now
the spawn tag is gone
no the compoundtag
oh
that's fine
it was useless for like 95% of things anyway
Just remove the param and update the coremod then rerun find targets
find targets was never ported to NG btw
we have patches now
?
We don't know yet, we aren't able to compile the whole thing yet
k
3 compile errors
2 of them because registerMapping is gone
the third is interaction events
2 compile errors left in ItemStack
@slow prism you made them
yeah i realised i changed the wrong interactionresult
no but that event is used in 2 places on uses InteractionResult the other ItemInteractionResult
sigh
you're right
fuck the interaction events
well they need splitting that's for sure
the hard part
how do you name them

is it finally time to refactor all the interaction events
we should probably redo the interaction events after the port
but we need a temporary non-bad solution
I have ItemStack and ServerAdvancementManager fixed on my end, I'll push that in a second
-if (e.isCanceled()) return e.getCancellationResult();
+if (e.isCanceled()) return e.getCancellationResult().result();
that makes more sense
I won 
maty the testframework has 30 compile errors



