Well the issue is that we consider the resources identity to also include the components
#1.20.5/6 Snapshots
blazing valve
lean anchor
Also, Tech, you're the major pusher for unifying fluids and items
I think they should be seperate concepts, tbh
blazing valve
we're really talking about the keys equals method corresponding to stackability in inventory (ignoring maxStackSize for a second)
elder swallow
the main goal is that people need to learn a single set of abstractions instead of two
"you know IItemHandler? well IFluidHandler is the same thing"
that kind of stuff
blazing valve
They are separate concepts with some commonality
lean anchor
Understandable -- I've been wanting a general "Resource" concept for CM for a while
Defining what a resource is and how to handle it
elder swallow
that is one aspect
the other aspect is to give modders better control over how to store e.g. a map from "item types" to amounts
and in general to fix the viral mutability of stacks for people who are willing to move away from some of their usage of ItemStack
blazing valve
Defining what a resource is and how to handle it
Yeah to start with that at all, you do need some common root interface/class that encapsulates which resources are considered equal
Ultimately I suppose a Tuple of (Type, Components[])
@elder swallow Does vanilla in 1.20.5 generally only allow stacking when all components are strictly equal?
blazing valve
Good
elder swallow
suppose we have ItemStack and ImmutableItemStack - how much value is there in having a shared interface between the two?
you'd be able to do something like
public boolean isEnchanted(ItemView itemView) {
return !itemView.isEmpty() && !itemView.getOrElse(DataComponentTypes.ENCHANTMENTS, ItemEnchantments.EMPTY).isEmpty();
}
lime galleon
ItemStack extends ImmutableItemStack would be the most convienient (to use, not to implement), imo.
elder swallow
the problem is that you'll be forced to call .immutable() every time you want to store one, and that is quite error-prone
lime galleon
in what respect? If you're storage is required to be immutable, then type it to ImmutableItemStack
elder swallow
say
private final Set<ImmutableItemStack> stacks;
public boolean addToFilter(ImmutableItemStack stack) {
stacks.add(stack);
}
// Evil code
var stack = new ItemStack(Items.DIAMOND, 2);
addToFilter(stack);
stack.shrink(2);
ah, I was switching the inheritance in my head. both have issues I see
elder swallow
yeah
the main advantage of the new component system however is that it is quite cheap to convert between representations
blazing valve
suppose we have `ItemStack` and `ImmutableItemStack` - how much value is there i...
IMHO there should be an interface for these stacks to get the resource, components and amount
Unless we do introduce a class to encapsulate resource type + components (what you call [Fluid,Item]Variant)
elder swallow
could have something like
public interface IResource {
boolean isBlank(); // check if this is air, empty, etc...
}
public record ResourceAmount<T extends IResource>(T resource, int amount) implements IResource {
public boolean isEmpty() {
return amount <= 0 || resource.isBlank();
}
}
public class FluidResource implements IResource, DataComponentHolder {
public boolean isBlank() { return getFluid() == Fluids.EMPTY }
public Fluid getFluid() { ... }
// We inherit .get(DataComponentType<T>, T) etc
}
public class FluidStack implements DataComponentHolder {
public static FluidResource of(FluidStack stack) { ... }
public FluidStack(FluidResource ) { ... }
public FluidStack(ResourceAmount<FluidResource> resourceAmount) { ... }
public FluidStack(Fluid, int amount) { ... }
// Other constructors
public int getAmount() { ... }
// Other getters
public void setAmount(int amount) { ... }
public <T> T set(DataComponentType<T> type, T component) { ... }
// Other setters
}
Is resource amount your immutable version? IDK if we need that
elder swallow
it's nice to have - I need it to implement NeoForge's FluidHandlerItemStack (fluid handler that stores its content in the "NBT")
but in general I suppose you'd have separate function parameters for resource and amount
blazing valve
interface IResource<T> {
T getResourceType();
... component getters ... (but not setters :P)
}
interface IResourceStack<T> {
IResource<T> getResource();
int getResourceAmount();
}
class ItemStack implements IResource<Item>, IResourceStack<Item> {
IResource<T> getResource() { return this }
}
class FluidStack implements IResource<Fluid>, IResourceStack<Fluid> {
IResource<T> getResource() { return this }
}
isAbsent as in it's a resource signifying the absence of a resource?
elder swallow
```java
interface IResource<T> {
T getResourceType();
... component ge...
that means that you can't trust any IResource you receive to be immutable
blazing valve
well you can specify that on the interface contract. this is unlikely to be implemented by every cobble gen mod under the sun 😛
elder swallow
`isAbsent` as in it's a resource signifying the absence of a resource?
it's just a resource with Items.AIR or Fluids.EMPTY
elder swallow
```java
interface IResource<T> {
T getResourceType();
... component ge...
you're also missing the immutable version of the resources here
blazing valve
I don't know if we need those in the base API
elder swallow
OTOH this is the minimum separation between mutable and non-mutable stack "views"
elder swallow
say
```java
private final Set<ImmutableItemStack> stacks;
public boolean addToF...
you still have this problem though with that design
blazing valve
yes, it is questionable if the stacks themselves should implement the resource type
elder swallow
I also don't think that having an IResourceStack<T> abstraction is that valuable
summer furnace
it would be if we could pull logic into it, but we can't exactly do that
so yeah I agree
elder swallow
the main benefits of a generic abstraction are:
- less code duplication
- generic transfer code
but generic transfer code needs very little abstraction, you only need a way to check if a resource is "empty"/"nothing"
fallen igloo
tech can you move that to another thread since it is not strictly related to porting
reef parcel
Like. Specifically in neo or mojang erroneously marked it as fixed?
magic sierra
Specifically in neo
stiff galleon
is the bug present in neo in 1.20.4?
magic sierra
Okay, now it works... weird
stray bay
see this is the kind of thing where my idea of using an immutable advisory interface (i.e. where all concrete objects are mutable but you have to cast to actually modify it) like Component would help.
just having an indication in the type system of when you own the object and when you don't is useful enough, we don't necessarily need runtime enforcement and the design problems that come with that
summer furnace
if you can cast to mutable, people will, and it will break things in horribly annoying to debug ways in big modpacks
prisma locust
Getting the following error when running neoforge:publishToMavenLocal on the 24w11a branch:
> Task :neoforge:createUnixServerArgsFile FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':neoforge:createUnixServerArgsFile'.
> Could not copy file 'NeoForge-20.4/server_files/args.txt' to 'NeoForge-20.4/projects/neoforge/build/platform/platformJoined24w11a-20240314.182754/steps/createUnixServerArgsFile/args.txt'.
> class org.codehaus.groovy.runtime.GStringImpl cannot be cast to class java.lang.String (org.codehaus.groovy.runtime.GStringImpl is in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @4bec1f0c; java.lang.String is in module java.base of loader 'bootstrap')
is anyone else able to reproduce?
wooden tendon
Getting the following error when running `neoforge:publishToMavenLocal` on the 2...
Run it with J17
prisma locust
same issue
I set JAVA_HOME=/usr/lib/jvm/java-17-openjdk which should force the Gradle daemon to use 17
elder swallow
well it's true that you can't cast a GString to a String
prisma locust
adding a toString after setting the project version fixes this
project.version = "${project.neoforge_snapshot_next_stable}.0-alpha.${project.minecraft_version}.${(new Date()).format('yyyyMMdd.HHmmss', TimeZone.getTimeZone('UTC'))}".toString()
OK I reproduced it locally
prisma locust
the next question I have is why groovy does this
elder swallow
I suppose that it's not happy about the version being a GString
adding .toString() at the end of line 15 in the main build.gradle might fix it
prisma locust
adding a `toString` after setting the project version fixes this
```
project.v...
that's what I did here
I can confirm it works
weird bug
prisma locust
userdev is still broken because of the log4j thing
looking at the stacktrace I wonder if Gradle is somehow dragging in 2 incompatible log4j versions?
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:222)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:140)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:123)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:117)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:149)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.LogManager.getLogger(LogManager.java:599)
at MC-BOOTSTRAP/[email protected]/org.apache.logging.log4j.LogManager.getLogger(LogManager.java:585)
prism pulls 2.22.1 so thats probably it
weird, I changed log4j_version in Neo's gradle.properties but it's still using 2.19 in userdev for some reason
fallen igloo
We have 4 PRs for 1.20.5 should we update those to target the port branch
https://github.com/neoforged/NeoForge/pull/699
https://github.com/neoforged/NeoForge/pull/679
https://github.com/neoforged/NeoForge/pull/588
https://github.com/neoforged/NeoForge/pull/542
prisma locust
adding toString is just a workaround
is it ok to push that workaround for now with a comment, so that the branch is buildable?
digital drum
We have 4 PRs for 1.20.5 should we update those to target the port branch
https:...
I mean I can port mine now
elder swallow
I don't think it's time to start accepting BCs
fallen igloo
not to merge them but I mean porting is fine
true jacinth
Guess I need to rebase network changes again main repo branches soonish
stiff galleon
Moving while sneaking is impossible with high generic.step_height attribute
true jacinth
lmao
how is it that we have had this attribute for so long and ironed out all the issues and then mojang just blows it up™️
stiff galleon
Isn't that the same bug as this one? https://bugs.mojang.com/browse/MC-268917
no, one is about it being too easy to move, the other is about it being too hard to move
magic sierra
oh
fallen igloo
well it's the 2 edge cases of the same impl
rigid walrus
Seems like you can't have client-side only components
plucky brook
was client side only NBT possible?
elder swallow
NBT should always be synced entirely because of how creative mode works
plucky brook
That's my point, I don't feel like anything is lost by not having client side only components
deep spoke
Something I noticed with enchantment components: There's no order anymore. e.g. Enchant an item with enchant A and then enchant B, and for another of that item reverse the order of enchants, then reload the world. Now both enchant lists are in the same order. Anyone know if there's an existing bug report on the jira for this?
magic sierra
Something I noticed with enchantment components: There's no order anymore. e.g. ...
it's WAI
deep spoke
Thanks
plucky brook
why would even want that
fallen igloo
<:thonk:932605815221788672> why would even want that
yea the bug in that is probably that it is not already sorted on enchant and only changes on save and load
rigid walrus
That's my point, I don't feel like anything is lost by not having client side on...
I was thinking about if a client side mod wanted to store a component based of information that a server that accepts vanilla clients sends
fallen igloo
I was thinking about if a client side mod wanted to store a component based of i...
that wouldn't even work with nbt because stacks are overwritten by the server
median wasp
What happens if a client receives an unknown component?
Doesn't it just drop it?
Or does it disconnect?
fallen igloo
component types is a registry so you wouldn't be able to connect
median wasp
So I guess server-side mods are stuck to CUSTOM_DATA
Or it uses custom components which get encoded into CUSTOM_DATA on send, then decoded on receive
Which sounds like something that would be in Polymer
rigid walrus
that wouldn't even work with nbt because stacks are overwritten by the server
I meant as a cache for parsing data stored with the item stack
fallen igloo
NeoForge registers a component type 🙃
that is a problem
we could special case that registry
plucky brook
yea the bug in that is probably that it is not already sorted on enchant and onl...
That's fair
The mojira report isn't for that, but the "only sorted after world reload" might actually be something that should be reported
elder swallow
we could special case that registry
or maybe we remove ours
people who want to use ItemStackFluidHandler and ItemStackFluidHandlerSimple will have to make their own data component
stray bay
we could do a thing like milk where we only register it if at least one mod requests it to be registered
magic sierra
HEY WAIT A SECOND
magic sierra
1: https://bugs.mojang.com/browse/MC-259587 this is not fixed in NeoForge
- Why do I have the impression that two bars are rendered instead of one?
pin this pls
elder swallow
interesting
magic sierra
Note: The command is /give @s minecraft:iron_helmet[minecraft:damage=10000] in 23w11a
plucky brook
I wonder why they wouldn't just limit that on load since they already do validation
stiff galleon
people who want to use `ItemStackFluidHandler` and `ItemStackFluidHandlerSimple`...
we could do something like requiring mods to manually enable the milk bucket 
restive raft
i wonder if we'll consider more features that might need to be enabled in that way (by a mod, in Java code)
and if so, if it's worth investing in a better way to do it than adding new methods to NeoForgeMod/NeoForge (or whereever the hook lives now) and calling it a day
naive hound
could make it part of the forge config. there's also the case where a user may want to use milk like a fluid without a specific mod reason
royal stone
Even if there's a config option mods should still probably be able to force it on if they have a hard dependency on milk existing
elder swallow
damn I forgot about ExtendedGui.leftHeight and rightHeight and nuked them entirely 
... we have to patch those back in Gui
summer furnace
new snapshot today, I presume. I wonder if it will still be snapshot, or prerelease
fallen igloo
snapshot probably because the race condition bug is not fixed yet and it is marked Important
elder swallow
I expect a snapshot with some changes around Codecs
Given all the DFU commits from yesterday
summer furnace
what race condition is that? not been keeping up
elder swallow
summer furnace
ah, fun
fallen igloo
Given all the DFU commits from yesterday
ooh that's a big one
dispatch now requires MapCodec instead of Codec as the result of the function
optional fields are now strict by default
elder swallow
yeah
it's very nice
BTW the vanilla gui layers are not enough - I have to chop them up again 😭
fallen igloo
also assumeMap is gone
fallen igloo
that's gonna be interesting
slow prism
why is that
elder swallow
fuck me really
slow prism
(tech)
elder swallow
this is a single layer
slow prism
yes
elder swallow
and renderPlayerHealth handles health, armor, food, air bubbles
slow prism
I mentioned the sublayering before lol
boreal flint
I love when they compartmentalise by putting a whole bunch of stuff in one compartment
fallen igloo
this is a single layer
request a problem causer to split it up
elder swallow
well do they care
we can split it up ourselves, it's just annoying
this time we'll patch it in Gui
fallen igloo
well do they care
some of them are (former) mod devs
slow prism
gegi doesn't need that level of control for LT smh
elder swallow
well tbh I'm gonna be splitting up the main offenders
we can simply let people request more splits if necessary
fallen igloo
gegi doesn't need that level of control for LT smh
we could just ask Gegy
elder swallow
@slow prism I want to add a test for gui layers
is there no way to do test.isEnabled()?
fallen igloo
is there no way to do `test.isEnabled()`?
there is an on enabled hook
elder swallow
that's inconvenient, I want to check within a gui layer
ok there is test.framework().tests().isEnabled(test.id())
slow prism
@elder swallow so did you decide on whether you'll remove attachments and replace them with components or remove stack attachments 
elder swallow
stack attachments are gone and I don't see a reason to add them back
and I think we'll keep attachments on the other kinds of objects
replacing attachments by components is problematic for 2 reasons:
- immutability sounds like a bad idea for large attachments (imagine immutable level attachments)
- components cannot capture a reference to their holder
might be a solution for the gui layer stuff
prisma locust
might be a solution for the gui layer stuff <:thonk:932605815221788672>
that last one looks like a recipe for an incorrect patch on an MC update
what's the advantage of this approach over patching in if() blocks around each part of the function?
elder swallow
that would work here
unfortunately for renderPlayerHealth there is no such possible fix
technically if blocks are also a recipe for incorrect patch updates
stiff galleon
stack attachments are gone and I don't see a reason to add them back
I see my days of only using vanilla apis for itemstack data are coming to a middle 
elder swallow
well, components are closer to attachments than NBT 😄
slow prism
I see my days of only using vanilla apis for itemstack data are coming to a midd...
components are vanilla apis tho
stiff galleon
exactly
can probably revert bag of yurting to the original implementation too, where it just stored the blocks in the itemstack, now that copying itemstack data is supposed to be faster
a long time ago somebody PRd some code to it that had the itemstack store a reference id to saved blocks in world data and I accepted it because it's good for performance but never really liked it because I don't like having other people's code in my mods
summer furnace
just keep messing with it until it stops feeling like someone else's code :p
I store items in the stack in toolbelt, has never been an issue for that use pattern
stiff galleon
the problem is, bag of yurting stores blocks and blockentitity data, and the blockentities can be chests, which can have shulker boxes with toolbelts in them
summer furnace
oh yeah
in Packing Tape I have a hard limit
for data size
someone was crashing when trying to pack huge chests XD
now it goes "too big!"
fallen igloo
backpack mods now use reference based storage so soaryn can't dupe stuff
summer furnace
I'd rather people dupe than entangle :p
short cove
Are the bugs they're fixing rn going to be in today's snapshot
stiff galleon
Are the bugs they're fixing rn going to be in today's snapshot
wait n' see
fallen igloo
Are the bugs they're fixing rn going to be in today's snapshot
I think the Fixed status is when they get merged into the branch for the next snapshot so probably
short cove
nice
elder swallow
ARGHHH
slow prism
hi tech
elder swallow
the order between the air bar and the mounth health has been fucked on forge forever I think
slow prism
do i need to call 112
elder swallow
I'll manage thanks 😛
short cove
Only 8291 bugs on Mojira
elder swallow
vanilla doesn't even draw the overlays in the right order
short cove
I thought it'd be higher
elder swallow
it's so dumb
vanilla draws:
- armor
- health
- food
- air
- mount health
but the correct order is: - health
- armor
- food
- mount health
- air
lean anchor
Distance from hotbar
short cove
ah
elder swallow
vanilla computes the distance in ugly ways so its exact order doesn't matter
but we have leftHeight and rightHeight, so it's essential that overlays are drawn in the right order
lean anchor
Armor is above health, but drawn before health
fallen igloo
vanilla draws:
- armor
- health
- food
- air
- mount health
but the correct orde...
report it (or ping gegy)
short cove
Ask her to fix it sneakily
🎶No one has to know🎶
Aren't they all for fixing the codebase these days
Why does Neo have left and right height fields?
fallen igloo
Why does Neo have left and right height fields?
it's for the cumulative height or the elements on the left/right of the exp level number
short cove
ic
is it mean to be used like "put my bar at leftHeight + 5 pixels"
to add it to the top
elder swallow
yes
short cove
nice
so ic why mojang doesnt need them, they know exactly what bars they're adding
but
depending on how long it'd take to reorder the bars I still think that would be a change they could make
just for niceness purposes
fallen igloo
can we make hud elements something proper? with size and position and a draw method?
elder swallow
not really
fallen igloo
why?
elder swallow
we do a little testing
elder swallow
can we make hud elements something proper? with size and position and a draw met...
cause 1) vanilla doesn't do it and 2) it's kinda pointless
currently it is only a draw method
open kindle
cause 1) vanilla doesn't do it and 2) it's kinda pointless
I disagree with that
twin elk
make them batched /j
fallen igloo
I literally have a library that does it (and makes some of them configurable)
misty crow
can we make hud elements something proper? with size and position and a draw met...
How would that even work with something like additional bars since you cannot know the final position?
elder swallow
not quite there yet
open kindle
How would that even work with something like additional bars since you cannot kn...
Positions could be specified relative to another GUI element
fallen igloo
How would that even work with something like additional bars since you cannot kn...
instead of absolute positions I'd use relative with some kind of anchor system
elder swallow
it is such a headache to patch vanilla elements already to correctly support leftHeight and rightHeight
we're not going to patch all of them to support arbitrary relative movements
open kindle
if implemented properly, this would be great
fallen igloo
it is such a headache to patch vanilla elements already to correctly support `le...
manually setting fields in your elements is sooo error prone tho
open kindle
unfortunately it's relatively challenging to achieve
elder swallow
okay I think it works
elder swallow
manually setting fields in your elements is sooo error prone tho
it's not the worst part of the gui code
I don't think there's really a problem to solve
open kindle
no problem != no space for improvements
elder swallow
doing gui.xxxHeight += <element size> + <padding>; is definitely not the end of the world
misty crow
instead of absolute positions I'd use relative with some kind of anchor system
That's absurdly overcomplicated for little to no reason in my opinion. The kinds of things done with the overlay system are so varied that a generic anchoring system will most definitely conflict with some of those use cases. If you need fancy relative positioning and all that, then that's better suited to a purpose-built library IMO
stray bay
what if we just used awt layout managers to position hud elements
fallen igloo
~~what if we just used awt layout managers to position hud elements~~
I have a 3 letter answer: mac
elder swallow
I have a single symbol answer: 🍎
stray bay
i do think it'd be nice if each gui overlay could declare the area it intends to use, and if they overlap they could push each other out of the way - like, currently, we don't really have a solution except for above-hotbar decorations, do we?
dapper hornet
probably offtopic but what does mac/apple do w.r.t awt
stray bay
probably offtopic but what does mac/apple do w.r.t awt
awt works fine on mac, it doesn't work with opengl
something about event loops in the main thread
elder swallow
i do think it'd be nice if each gui overlay could declare the area it intends to...
indeed we don't have a solution - "pushing elements" is of course non-trivial
I'd rather add more mutable variables in the same style as leftHeight/rightHeight for common placements
spiral radish
awt works fine on mac, it doesn't work *with* opengl
There's also some Macs which don't have AWT at all
iirc Curle has ran into it a couple of times
fallen igloo
mac only allows 1 thread to do any drawing so awt + lwjgl is bad
stray bay
eh, that doesn't really work since you don't know if two elements at the top left corner should be placed side by side or vertically, a 'push' system could make the decision based on their shapes
but yes it would be difficult to implement
what might be useful
fallen igloo
well at least screen based guis are getting layout managers
elder swallow
eh, that doesn't really work since you don't know if two elements at the top lef...
you'd probably do a simple enough approximation
stray bay
would be a simple anchoring system that doesn't attempt to prevent overlapping but simply provides the configurability for pack makers to move stuff around in a standardized way
elder swallow
you don't understand just how dynamic these elements are
fallen igloo
would be a simple anchoring system that doesn't attempt to prevent overlapping b...
5 parameters + size:
relative to
anchorA
anchorB
offsetX
offsetY
stray bay
the alternative is to impose something like "there are 5 boxes you can stack elements vertically in, one at each corner and one at the top center and each has its associated height variable" and anyone who wants to place anything anywhere else is out of luck
7 counting the ones above the hotbar i suppose
except a lot of mods want to place things near the cross hairs too, stuff like create's goggles
elder swallow
I'm not talking about restricting placement
I'm talking about potentially helping modders avoid overlap in common cases
stray bay
i guess, but 'you get a system you can't benefit from unless you work within this paradigm' is still a soft restriction
elder swallow
keep in mind that having 4 "crossbar huds" like create's is going to look ugly no matter what
misty crow
except a lot of mods want to place things near the cross hairs too, stuff like c...
I have a set of overlays that technically consist of two boxes, one on the right of the crosshair, one right above the status bar. You would not be able to do dynamic pushing or overlap avoidance with those unless they are split apart (which is annoying and there's no reason to do so)
stray bay
design the system now so that it has two passes of events, one that gathers sizes and the other that tells things where to draw, so even if all we implement is a dead simple stack layout now we've got the flexibility of 'each thing is placed with the knowledge of the size of all active elements' to improve in the future without changing the api
that also means the actual mutation of height variables or whatever happens internally instead of each overlay being in charge of it
idk
elder swallow
we're not going to compute placement and size information about all the vanilla overlays
red beacon
i do think it'd be nice if each gui overlay could declare the area it intends to...
LayoutElements have something like that already: ScreenRectangle
It seems they're not used much in vanilla, though
clear bane
it makes me wonder
will they release it, the second that I am on the bike back home, or wil they do it when I am sitting on my chair
magic sierra
new snapshot
spiral radish
restive raft
it begins
clear bane
decent change
slow prism
mojang made everything components
digital drum
mojang made everything components <:harold:932605815406342174>
every single thing?
I'm not checking the source so idk
slow prism
MINECRAFT:RARITY
Controls the color of the item name
Format: enumerated value, one of:
common (default): white name, or aqua when enchanted
uncommon: yellow name, or aqua when enchanted
rare: aqua name, or light purple when enchanted
epic: light purple name
e.g. rarity=rare
Special items such as Golden Apples have an implicit default value
magic sierra
Minecraft 1.20.5: components update
slow prism
MINECRAFT:TOOL
Controls the behavior of the item as a tool
Format: object with fields
rules: list of rule entries
blocks: single block, list of blocks, or #-prefixed block tag to match
speed (optional): float, overrides the mining speed if present and matched
correct_for_drops (optional): boolean, overrides whether this tool is considered 'correct' if present and matched
true will cause the block to mine at its most efficient speed, and drop items if the targeted block requires that
default_mining_speed: float, mining speed to use if no rules match and override mining speed (default: 1.0)
damage_per_block: non-negative int, amount of durability to remove each time a block is mined with this tool
e.g. tool={rules:[{blocks:"#mineable/pickaxe",speed:4.0,correct_for_drops:true}]}
Vanilla tool items will have an implicit default value based on their tier and tool type
spiral radish
digital drum
so essentially is nbt being completely removed?
mental fox
There will be blocks you can't mine with tools if the tools are too powerful.
digital drum
There will be blocks you can't mine with tools if the tools are too powerful.
huh?
if they're too powerful?
restive raft
so essentially is nbt being completely removed?
they're not going to remove NBT
clear bane
Hippo, these are tags
mental fox
if they're too powerful?
Too high grade.
I don't know how to put it.
And I haven't tested it yet.
dapper hornet
> `Over-Overkill` - Deal 50 hearts of damage in a single hit using the Mace
**FI...
I thought they were going to nerf the mace a bit because of its high one shot potential. Ig mojang is scaling damage now
mental fox
Hippo, these are tags
So is needs_<material>_tool.
restive raft
but move things to data components, which can be lazily serialized to NBT, offer faster access, and facilitate better datapack/command syntax
red beacon
Hippo, these are tags
there can be, not necessarily that they'll add that
it does open up some interesting possibilites for map makers though
digital drum
but move things to data components, which can be lazily serialized to NBT, offer...
so it works parallel to nbt?
reef parcel
Oh wow. So item properties just basically wraps common components now huh
lean anchor
Oh, minecraft:tool ought to be interesting
restive raft
so it works parallel to nbt?
eh. more on top of NBT
NBT is still how things are serialized to disk
digital drum
Oh wow. So item properties just basically wraps common components now huh
code?
maiden prairie
> `Over-Overkill` - Deal 50 hearts of damage in a single hit using the Mace
**FI...
You can do this pretty easily if you put an entity at the bottom of a mountain and jump off. Probably the hardest part is just timing the hit. The damage of the mace can scale really high
restive raft
it's just that data components are better, more performant representation of things which used to be stored in NBT and had to be extracted from NBT tags directly (like, PotionUtils having to read the item stack's tag)
mental fox
There will be blocks you can't mine with tools if the tools are too powerful.
If my assumption is correct, I can see someone creating a datapack where blocks can only be broken with the minimum tool needed to break it. (E.G. Stone can only be broken and collected with a wooden pickaxe.)
median wasp
I will say the name "components" is indicitive of something else as well
Component-based game engines
restive raft
entity components
median wasp
Yep
elder swallow
no way
median wasp
And we already know they seem to be working on datadriven blocks and items
elder swallow
what's happening
hexed sonnet
Any item can be a tool now
median wasp
Or edible
restive raft
all of ems, they be tools
median wasp
Reminds me of that time I made every item edible
mental fox
Edible Tools Datapack
restive raft
can't wait to nom on my obsidian
elder swallow
WTF they are moving item properties to components
restive raft
I remember the Bear Grylls mod
elder swallow
median wasp
Yep
mental fox
They could have at least made the breaking changes in a major release instead of a minor release.
median wasp
This isn't a hotfix version
"Minor" versions are tech updates
"Major" versions are content updates
mental fox
Ok I have amended my message.
summer furnace
smh.
median wasp
Why limit it to 99?
mental fox
<:crushed:747530659513237504>
CanDestroy tag is dead.
summer furnace
they had a chance to make stacks bigger, chose not to
median wasp
They made it so that it can go to the integer limit just last week
summer furnace
Why limit it to 99?
cos it's the biggest 2 digit number
white frigate
they had a chance to make stacks bigger, chose not to
that'd kinda destroy a lot of worlds I think
mental fox
They could've at least capped it at the signed byte limit.
white frigate
every item filter would probably break lol.
summer furnace
no it wouldn't
misty crow
Interesting
summer furnace
items would still be 64 by default
mental fox
that'd kinda destroy a lot of worlds I think
Mojang: Destroyer of Worlds
median wasp
The only reason it can't go to 2 billion is because of the component limit
white frigate
items would still be 64 by default
I thought you meant increase the default stack size
summer furnace
no no
median wasp
They raised the limit technically from 127 to 2 billion last week
white frigate
Ah yeah I complained about that as well, it's definitely just UI things
elder swallow
now this is funny
wooden tendon
Lol
median wasp
Yeah probably
median wasp
They could fix that. Or do what some mods do, which is show it with metric suffixes
summer furnace
nit enough space for it
elder swallow
it's quite funny that the max stack size is part of the stack itself
summer furnace
3 digits already overlap the next slot
blazing valve
it's quite funny that the max stack size is part of the stack itself
I suppose: Items declare "default" components, right?
blazing valve
Isn't this just a step in the direction of having a generic Item that takes in the default components as a parameter and thus can be made datapack customizable?
elder swallow
yeah pretty much I think
blazing valve
So technically they are on the stack, yes
white frigate
cant wait for fully custom items :p
elder swallow
it's quite unexpected for me
blazing valve
but they'll likely mostly take them from the item defaults
elder swallow
modders would never have used caps/data attachments for that
fallen igloo
Why limit it to 99?
don't worry we'll patch it probably
elder swallow
why would we do that 😄
blazing valve
All the more reason for ItemVariant combining a concrete set of components 😄
elder swallow
which kind of item variant? the transfer kind?
blazing valve
Ya
elder swallow
do it mojang 😄
blazing valve
You can't just patch item stack size without finding all places they still serialize it as byte 😄
and potentially broken UI
fallen igloo
why would we do that 😄
because 128 stack size
elder swallow
blazing valve
64 is such a programmer number
elder swallow
99 is a shit number though
blazing valve
99 is the de facto default max item count for many MANY games 😄
elder swallow
make it 100!
elder swallow
😩
fallen igloo
hmmm, edible anything...
blazing valve
Finally, edible AE2 storage cells
mental fox
<:oreo:896865548967739432>
Err... that's an Ice Cream Sandwich.
median wasp
It's an Oreo
open kindle
hmmm, edible anything...
well we already had that, though only in code
food was already on Item, something like FoodItem was not a thing before either
also why
why is that an empty object and not a boolean
clear bane
They could have at least made the breaking changes in a major release instead of...
they changed the way they do versions
fallen igloo
well we already had that, though only in code
I mean making an existing item edible required mixins now you just give it the food data
open kindle
existing items yes
fallen igloo
that's what I meant with edible anything
also it seems they are converting item properties to components
reef parcel
why is that an empty object and not a boolean
Based on existence. Doesn't need data, if it's there, it's fire resistant. A boolean would be redundant
reef parcel
An actual boolean component stands for 3 states. If it doesn't exist, do some default operation. If it exists and is true, do something, if it exists and is false, do something else
That said, are there any boolean components?
fallen igloo
there are and they don't stand for 3 states as they use a default
reef parcel
I only see enchantment glint, it is in fact used as 3 states
restive raft
i concur with Ratatosk; I see only enchantment glint as a component that is a single boolean, and it does have three states (absent means default behavior, present and true means force glint, present and false means force no glint)
also, according to the MC wiki at https://minecraft.wiki/w/Item_format/1.20.5#creative_slot_lock, there's a minecraft:creative_slot_lock component which is interally used by the creative inventory, which according to the entry make an item that "cannot be taken out of its slot"
I feel like there's a possible usecase for map devs
think limited inventory
deep spoke
also why
Now what we need is an explosion resistance component for emulating the nether star. Or better, a general damage resistance component.
fallen igloo
now we wait for NeoForm... pls ping when it's done (as long as that is before midnight CET)
reef parcel
wonder what the heck this packrat stuff is for. at first glance, it looks like it's for commands, possibly for suggestions to item components
open kindle
Based on existence. Doesn't need data, if it's there, it's fire resistant. A boo...
I might want to disable netherite being fire resistant though?
reef parcel
then remove the component on the itemstack
open kindle
hm
true jacinth
replacing attachments by components is problematic for 2 reasons:
1) immutabilit...
is (2) a problem for the weird way item fluid handlers work? iirc those needed a reference to the parent
kind sable
This snapshot is really interesting....
with these you can almost fully add a custom item with data packs:
- Custom crafting
- Custom model data
- And behave like a pick with durability
boreal flint
gonna have so many modders refuse to update cus of the extent of the changes lol
clear bane
eh, another type of 1.8.9 players
eh, they won't be missed
boreal flint
more like the 1.19.2/1.19.4 players/devs
kind sable
from the end users perspective there is now no noticeable difference between the obsidian pickaxe made with a datapack and made with a mod...
boreal flint
pretty cool
summer furnace
I intend on updating all my mods
boreal flint
mcreator in shambles rn
summer furnace
but I will almost definitely be whining a lot while doing it
specially when it's time to port JsonThings
because I'll have to figure out a way to define item components in json
clear bane
mcreator in shambles rn
I expect them to have shit updated on github within 3 weeks
many people contribute these days
summer furnace
summer furnace
they'll haveto rename it DCreator
clear bane
I mean....
fallen igloo
because I'll have to figure out a way to define item components in json
they have codes so...
clear bane
and the person behind it is also in this server 👀
summer furnace
they have codes so...
I don't use codecs in JsonThings though ;_;
boreal flint
rip
clear bane
hold up
I know I am bringing it off toping here
but Mcreator is getting a debugger??
dapper hornet
wouldnt this make mcreator kinda viable now ? if it simply becomes a frontend for datapack creation
fallen igloo
I mean....
!mcreator
dry stumpBOT
!mcreator
Making mods with MCreator
There is little to no support here for MCreator. We recommend you to check out MCreator-specific Discord servers or official support page for help:
https://mcreator.net/wiki/unofficial-discord-servers https://mcreator.net/support
clear bane
boreal flint
wouldnt this make mcreator kinda viable now ? if it simply becomes a frontend fo...
yeah except I don't see them going the datapack route
so it'll still be generating the same god-awful code
rigid walrus
#builds
boreal flint
but now it'll not only be god-awful code, but completely unnecessary
clear bane
eh, it has improved a lot over the years
yes, still not good
but shitty coders are using it, and making shit addons they don;t even understand
but hey, it is getting a debugger
so there is that
dapper hornet
tbh some kind of frontend/gui helper for gigaherz's json things to quickly create datapacks would be kinda awesome. (getting a bit offtopic :P)
boreal flint
that's like saying it's not mcdonald's fault it's unhealthy food - it's because unhealthy people are buying it lol
fallen igloo
let us stay on topic
summer furnace
someone was trying to implement support for jsonthings files in some datapack creation tool
no idea if it ever happened
clear bane
(sorry )
elder swallow
is (2) a problem for the weird way item fluid handlers work? iirc those needed ...
Yeah you wouldn't really store the fluid handler item directly
You'd instantiate one when you need it
fallen igloo
<#911717039079579708>
errant lion
Ping?
clear bane
what ping?
you have the snapshot alarm role
and a ping has been made, like... 4 hours ago
red beacon
wait, this isn't Squirrels
rigid walrus
now we wait for NeoForm... pls ping when it's done (as long as that is before mi...
Done
#builds message
elder swallow
I can fix the Gui patch tomorrow
fallen igloo
hmmm were loot tables always a registry?
boreal flint
no
not in 1.20.4
they're just loaded arbitrarily from the folder into a manager
with statically cached RLs in a class for referencing them
stiff galleon
hmmm were loot tables always a registry?
shut wraith
Given all the DFU commits from yesterday
Speaking of which, you see this?
Require MapCodec for key dispatch
This avoids the need for special treatment of MapCodecCodec. Any caller desiring the old behavior of the
valuesub-field should construct afieldOf("value")MapCodec.
Finally, KeyDispatchCodec is more sensible!
And that's the least of it
Tons of cools stuff here
Either.unwrap is a godsend
And Codec.dispatchedMap is amazing
stiff galleon
dispatchedMap is weird
shut wraith
Plus all the lazy stuff seems to exist in DFU now, instead of just being in the extracodecs class
Oh yeah, and there's withAlternative too
stiff galleon
it's like recordcodecbuilder but sideways
shut wraith
This is going to make half of my codecutils helpers obsolete
stiff galleon
instead of every field having a different codec and different type, every field has a different codec but the same type
shut wraith
it's like recordcodecbuilder but sideways
It's basically an unboundedMap crossed with a KeyDispatchCodec
stiff galleon
it's a codec for a Map<K,V> but the codec for each V depends on its K
stiff galleon
I don't understand the use case
fallen igloo
Dynamic registry?
yes MapDecorationType too
elder swallow
Speaking of which, you see this?
> Require MapCodec for key dispatch
>
> This ...
I saw! Very nice indeed
I suspect we're going to see MapCodec a lot more often
Hopefully ExtraCodecs is gone
Strict validation by default is amazing
elder swallow
yes MapDecorationType too
Hmmm ok. Will be annoying for our loot table patches
shut wraith
I don't understand the use case
Probably stuff where the keys are registry object locations, and the values are some sort of configuration data whose codec is stuck in the registry entry
shut wraith
Hopefully ExtraCodecs is gone
JavaOps are now in DFU itself too
They've singlehandedly, in this DFU update, removed the need for most of ExtraCodecs and most of my own codec utility library, except maybe the Asymmetry stuff of mine
shut wraith
Strict validation by default is amazing
Oh yeah that's awesome, isn't it - wasn't someone complaining about that here just a few weeks ago?
fallen igloo
Hmmm ok. Will be annoying for our loot table patches
yep
shut wraith
Yet another thing I can remove from my own utilities
I'll be left with only the few things that I can never imagine getting added to DFU itself, this is great
They haven't actually updated what MC uses yet it seems, so I guess we'll have to hope they do that for the next snapshot or so
fallen igloo
true jacinth
Dynamic registry?
Oh does mojang finally have a proper dynamic (reloadable) registry? I wonder how it compares to mine
slow prism
stiff galleon
did they make dynamic registries reloadable?
true jacinth
Probably not the worldgen registries
shut wraith
Presumably they're getting ready to make some registries reloadable at least
Should be exciting
This goes well with the more efficient datapack registry syncing stuff they added
fallen igloo
advancement and recipe registry when?
true jacinth
It is difficult for recipes to be a registry
since being a registry means tag support
and recipes depend on tags
slow prism
reloadable regs are janky
true jacinth
I was looking into it for my own uses
it appears to be possible but difficult due to some things being strongly-typed to Holder.Reference
So you would need a horribly cursed unbindable subclass of Reference
slow prism
no no, their impl is janky
rigid walrus
I wonder how much tier sorting is going to need to be rewritten
median wasp
I don't understand the use case
Components and sub-predicates are ones I can think of
The key is the sub-predicate ID, and the value is the sub-predicate args
rigid walrus
I wonder how much tier sorting is going to need to be rewritten
Currently tools have a list of Tool.Rule where the first time a block is found it uses the rule it was found in which determines the mining speed and whether it can drop the items
rigid walrus
And tool tiers are done by excluding the blocks from higher tiers
reef parcel
so, atm, the data component type registry event is fired far too late. in vanilla registration order, it's near the end, yet items depend on them. are porters aware of this and waiting to see whether vanilla fixes it first or has it been missed?
shut wraith
Is it just another case of the actual registry classload order not lining up with the listed registry order? There's a few of those. Which ordering does neoforge use again? Is it the classload order or freeze order?
true jacinth
We use the declared order by vanilla
But fix it as necessary
Vanilla has an explicit bootstrap order but due to static init the order is ignored when necessary
mental fox
so, atm, the data component type registry event is fired far too late. in vanill...
Should that go on the Feedback Site, Bug Tracker, or just be patched?
reef parcel
it's not important to vanilla, since they static init
true jacinth
Vanilla doesn't take non-player-facing issues
reef parcel
yeah, that
mental fox
So patches then.
reef parcel
well, no
neo determines when they fire registry events, they just try to adhere to vanilla's order
until it breaks things
true jacinth
patches to neo, technically™️
true jacinth
just not patches to vanilla, which is what we generally call "patches"
reef parcel
this wouldn't need a patch, just a single line with a short explanation right here. hopefully that's all at least, most of the data components seem to use holders, so it should be fine that other things like enchantments and mob effects are initialized later
mental fox
Well, some sort of modification to accomodate.
rigid walrus
Currently there is an entity sensitive version of the getFoodProperties method which wouldn't work with the food component
true jacinth
well the Food component is just an override
so in theory we should take the component as the source-of-truth if present
(as it is unlikely to be present in the general case)
rigid walrus
when registering a food item the FoodProperties is a component
median wasp
Vanilla doesn't take non-player-facing issues
Yes they do. The number of times I've seen this exact comment on fixed issues in the past year has been significant
Maybe they don't fix them as often, but they absolutely do fix them
rigid walrus
So ReloadableServerRegistries exists now
true jacinth
Yeah I'm curious as to why honestly, since its only loot tables and not the others
its also exceptionally convoluted
shut wraith
Probably WIP still
short cove
yeah except I don't see them going the datapack route
unfortunately I asked about switching to addons and datapacks and received no response...
rigid walrus
The remaining rejects are for food and tiers
true jacinth
what's the issue with tiers?
If the tier sorting registry is inoperable I think we can accomplish a redesign
its mostly internal code anyway
The goal of the creation is not complex, just place the tiers into an ordered or equivalent list, but the current mechanism is imo overcomplicated
boreal flint
unfortunately I asked about switching to addons and datapacks and received no re...
not surprised in the slightest lol
rigid walrus
The Tier interface now includes a method which returns a tag that says what blocks that Tier canNOT mine
The Tier interface also includes a method named createToolProperties which allows you to create a Tool instance which let's you specify a list of rules where the first time a certain block is found in the list of rules determines whether you get drops from it as well as the mining speed
true jacinth
what in the world
rigid walrus
also vanilla doesn't use ints anymore for levels so the wooden pickaxe tag includes the tags: needs_stone_tool, needs_iron_tool, and needs_diamond_tool
short cove
whats the usecase
summer furnace
if I understand, the real check now is inverted, so the stone tool has a list of blocks that require iron and up
fallen igloo
the can't mine tag includes the can mine tags for all highter tiers and the can't mine tags are used in the tool
summer furnace
incorrect for stone tool = requires iron | requires diamond
do they have an "incorrect for no tool at all" though?
I don't remember
in any case, it works the same as the tier sorting registry, just using tags explicitly, which makes it super annoying to handle for mods
true jacinth
That seems super backwards imo
boreal flint
summer furnace
That seems super backwards imo
since the tags are "requires X tier" testing tiers via "is it included in a higher tier's tag" makes sense. that way the highest tag wins. if it's in diamond and netherite, it is considered netherite.
errant lion
Can ItemStacks now be > 64?
In latest snapshot?
Saw they did some changes to components again
rigid walrus
itemstacks can stack up to 99 now
summer furnace
yes, but only until 99 which is like WHY
(the answer is because the GUI can only display 2 digits without overlapping)
errant lion
How does one do it
NF could make a patch I suppose to fix that?
Due to being useful for modders
Unless its not a simple thing
COULD also goto Mojang and see if they choose to fix that themselves
rigid walrus
Would the tier sorting registry still be needed? because you could add to the tag for lower tier tools and for higher tier tools you can avoid adding to their tag
fallen igloo
we need something to ensure the compat between mod A and mod B
errant lion
Huh I managed to do it with Mixins 😄
Something prevents it from rendering over 99 in some cases
Or idk
Some hardcoded stuff tho preventing it from going over 99 in some odd cases
fallen igloo
Huh I managed to do it with Mixins 😄
I will patch it to 128 instead of 99 (since a 1 in the first place does not have the overlap issue)
spiral radish
128 is too big iirc, Isn't it sent as a byte in several places?
Also is this something we should be patching, won't it cause issues with vanilla compat?
or was it a short
slow prism
it was a byte and please don't patch it
servers will be able to send big stacks and clients will crash
elder swallow
Yeah don't patch it without discussion, I don't see the point
Just finished the book I was reading, I'll fix the Gui patch in a moment
slow prism
now you need to read a book to be able to patch guis?
elder swallow
The old-style guis
rigid walrus
Anyone else noticed the changes to Enchantment?
clear bane
now you need to read a book to be able to patch guis?
You need to read a book to understand Maty gists /S
twin elk
Anyone else noticed the changes to `Enchantment`?
Oh what changed?
median wasp
128 is too big iirc, Isn't it sent as a byte in several places?
Also is this som...
It is no longer sent as a byte since last week's snapshot
But if you're going to patch it, please set it to 999. However, it's an inlined constant used all over the code base
clear bane
Still should not be changed without discussion imho
median wasp
So a lot of patches would be involved
median wasp
Still should not be changed without discussion imho
No it definitely shouldn't
blazing valve
Was it patched before?
clear bane
The new stack limit?
Vanilla changed to 99
Now our friendly neighbourhood @fallen igloo wants to patch it to 128
elder swallow
Anyone else noticed the changes to `Enchantment`?
I only noticed that many subclasses are gone
blazing valve
Why should it be patched now if it wasn't patched before? Without good reason, I mean 😛
blazing valve
Certainly not as part of porting, I hope
clear bane
It should not be done without discussion
fallen igloo
But if you're going to patch it, please set it to 999. However, it's an inlined ...
the reason I said 128 is that that does not yet overlap outside of a slot in the ui
elder swallow
why not 199 then
fallen igloo
why not 199 then
because that is just as stupid of a number as 99 for the maximum
elder swallow
well, as stupid as it might be I don't think we should change it 😛
I anticipate that most mods will continue using 64
(as long as vanilla continues to use it)
fallen igloo
hmmm when are we switching to the deinliner version of neoform
twin elk
Imo don't change it at all? I don't se a reason to change this vanilla limit
elder swallow
hmmm when are we switching to the deinliner version of neoform
the unpicked version?
we have to test the neoform build that coeh sent a while ago with some unpicked constants
fallen igloo
yes
elder swallow
feel free to do it 😄
fallen igloo
if coeh could make a build next week for the next snapshot then I can test it
rigid walrus
What about for the current snapshot?
rigid walrus
With it being on the snapshot maven
elder swallow
why do I have this compile error?
did the removed sources not get uncommitted?
that might be a problem with the action workflow
spiral radish
It is no longer sent as a byte since last week's snapshot
You certain about that? From memory and a quick search of Snowman commit, it looks like they didn't really touch Networking in this snapshot, unless they have already done that change previously / I missed it at some point, there's still code there that uses byte to represent it
elder swallow
why do I have this compile error?
OK I see what happened
it's simply not tracked, so git didn't know what to do with it and kept it in the checkout
median wasp
You certain about that? From memory and a quick search of Snowman commit, it loo...
I said last week's snapshot
elder swallow
ok, git clean -x -f projects/neoforge/src/main/java did the trick
median wasp
Or maybe it was the week before that actually
fallen igloo
codec is ExtraCodecs.intRange(1, 99) and stream codec is ByteBufCodecs.VAR_INT
elder swallow
the reloadable registries stuff is interesting
slow prism
it's messy
elder swallow
doesn't seem messier than the rest of the registry inheritance soup
errant lion
"ItemEntity" Would be an interesting idea, BlockEntities but for Items
If Im understanding this correctly they are trying to design Items to be more like blocks
Where there is a set of "properties" that can be used
Immutability basically
summer furnace
not quite
it doesn't work like blocks, it's a set of immutable objects that get attached
errant lion
Yeah
elder swallow
"ItemEntity" Would be an interesting idea, BlockEntities but for Items
that's called ItemStack
errant lion
ItemStack is Immutable though for Components
median wasp
codec is `ExtraCodecs.intRange(1, 99)` and stream codec is `ByteBufCodecs.VAR_IN...
That's the codec for the max stack size component. ExtraCodecs.POSITIVE_INT is the codec for the actual stack size
Also I think you can have a higher default max for your item than 99, since the default is never serialized
Not even over the network
errant lion
This doesnt seem right?
elder swallow
damn you fix things as I am about to commit them 😛
fixing NeoForgeDataMapsProvider
only the GLM left for the game to launch in theory
made it to main menu
ok, made it in world too
[14:14:37] [Netty Server IO #1/WARN] [minecraft/ServerConfigurationPacketListenerImpl]: Ignoring unexpected custom payload received outside of the modded configuration phase: minecraft:brand pretty funny since we are the ones sending it
[14:14:31] [Render thread/WARN] [minecraft/MinecraftServer]: Missing data pack mod:neoforge a bit weird too
fallen igloo
only the GLM left for the game to launch in theory
using direct probably won't work because that only does inline not from the registry
blazing valve
vanilla seemed to be using `DIRECT_CODEC` in more places
What does DIRECT_CODEC do?
elder swallow
What does DIRECT_CODEC do?
it's used for values not linked to the registry
what is this crap
fallen igloo
the new tool stuff
errant lion
Ah huh
elder swallow
better but still off by one
ok fixed
good thing I already had to debug this yesterday and wrote a nice test 😄
elder swallow
@fallen igloo should I squash and push to the neoforge repo?
fallen igloo
did you gen patches?
elder swallow
now yes
there is still the DiggerItem patch reject, but I think we'll have to reconsider the entire system anyway
summer furnace
All fixed, now can make it go past 99 in an inventory
and that itself shows why Mojang decided not to support it :p
prisma locust
couldn't that easily be solved by switching to half scale for the font rendering when the size exceeds 999
kind sable
On mojangs side they are not gonna do that for UI / UX accessibility reasons
for us? we could
errant lion
and that itself shows why Mojang decided not to support it :p
Yea xD
But could be a life saver for mods like RS/AE2/Simple Storage/etc
Then they wouldnt HAVE to do any annoying stuff, just to show a larger number
blazing valve
But could be a life saver for mods like RS/AE2/Simple Storage/etc
No, it really couldn't
And this is not at all related to the Snapshot. So in the spirit of Schurli: Let's keep it on topic 😛
summer furnace
/me looks at Ender-Rift code using longs for quantity
errant lion
xD
median wasp
My mod with infinite item stacks just uses its own class
Plain and simple
Making the component infinite doesn't really make anything simpler
Also InfiniteItemStack in my mod uses long, so it can have more than 2B items in a stack
Which is useful when there's at most one stack per item per container
reef parcel
i'd just make a new component and mixin to ItemStack for getting count and max
is there anything that can break by extending ItemStack? It is final, so I would expect that there's some intrinsic reason to not extend it, like specific checks for the class or something
elder swallow
magic sierra
GUI patch is broken?
elder swallow
seems fine to me
magic sierra
At last it's not working properly
magic sierra
wait
No, it works...
wait... WHY
I'll try to compare with Minecraft Vanilla
It's also happening with Minecraft Vanilla... even though it's a bug that's supposed to be fixed...
why mojang
fallen igloo
what bug?
elder swallow
well we only move the rendering code around but do not change how things are rendered in the Gui
stray bay
the entity-sensitive getFoodProperties method is also stack-sensitive, so it's easy enough to change the default implementation to use the component if it doesn't already. presumably the vanilla method has been made stack-sensitive now so it'll need to be rewritten anyway since it delegates to the vanilla method
trivial compared to whatever's going to have to happen with tools
[the question i suppose becomes whether we should allow mod overrides to take precedence over the component, but that's really more of a mod design issue]
shut wraith
What stops mods from just using the component?
stray bay
nothing - i don't think it's a real issue either way, the question is just whether mods overriding it will need to manually check for the component
true jacinth
Mods with custom items do not necessarily need to support the component
fallen igloo
the entity-sensitive getFoodProperties method is also stack-sensitive, so it's e...
I in fact already did that
blazing valve
So, what is the best way to figure out what the version for the latest snapshot release of NF is? 🤔
Poke at the maven?
Oh. They are not available from [...] our Maven repository.
reef parcel
yep. you have to build it locally (for now)
blazing valve
@elder swallow Do we plan to publish to the snapshot repo at some point? I am a lazy man and I just want to plug this into AE2 😛
wooden tendon
<@298082405745426433> Do we plan to publish to the snapshot repo at some point? ...
Not really
fallen igloo
Not really
we can publish it to a separate repo like we do for PRs
shut wraith
Presumably there might be stretches of time where it just doesn't build
reef parcel
I mean, they only push it to the neoforge repo after they get it building
prisma locust
<@298082405745426433> Do we plan to publish to the snapshot repo at some point? ...
you can depend on a build from mavenLocal with 20.5.0-alpha.24w12a.+ to avoid hardcoding a timestamp, but you'll still need to arrange for your CI to compile it from source before doing anything with your actual mod
blazing valve
Well, I just don't want to get constant GH Action build failures in case I do decide to push it to GH (which I will)
And I really don't want to add a NF compile step into my own repo 👀
prisma locust
blazing valve
Disgusting 😄
I may even do it
But they should really just be published to https://maven.neoforged.net/snapshots/
prisma locust
We need to make the timestamp stable to do that
blazing valve
Do we?
prisma locust
Unless you want a local build to have a completely different version from what's on Maven
which I think is wrong
blazing valve
I find that acceptable for snapshots
Well in any case I think I should probably record my porting steps
elder swallow
Well in any case I think I should probably record my porting steps
Please do - that will be very valuable for the blog post
true jacinth
One of the major pain points right now is buildscript updates
and "just reference the MDK" is not a good enough answer
I basically need to extract the work done in this commit to text https://github.com/Shadows-of-Fire/Placebo/commit/cb8db7cb2156c0f93a9106ab52629d35985dfb5e
Organized in the following steps:
- Changes to the
pluginsblock (FG -> NG userdev, remove mixin plugin) - Changes to the
minecraftblock (removal of... basically everything, tbh) - How to apply parchment (this is described on NG's readme and in the MDK as well)
- Run configs (migrating from
minecraft/runsblock to top-levelrunsblock) - The MC dependency in
dependencies(changing from FG'sminecraftartifact) - Removal of reobf (any uses of
finalizedBy 'reobfJar', AT updates, Setting mixin remap=false) [We should publish a mixin AP with implicit remap=false] - Changes to
mods.toml
blazing valve
Yes, we do not have any real docs on that
elder swallow
Organized in the following steps:
1. Changes to the `plugins` block (FG -> NG us...
It's probably easier to start from scratch using the MDK
blazing valve
I disagree for large mods
fallen igloo
It's probably easier to start from scratch using the MDK
did you for ae2?
blazing valve
Nope
fallen igloo
case and point
blazing valve
Then again, I started working on NeoGradle when I started porting to it 😛
elder swallow
case and point
No? shartte knows a lot more about gradle than the average mod
Myself I just "diffed" my build.gradle against the MDK's and removed stuff that didn't seem useful
blazing valve
Oooof. Adding HolderLookup.Provider to practically every method that touches NBT is very annoying 😄
But it's the price we have to pay for datapack defined items and blocks 😄
shut wraith
Unless you want a local build to have a completely different version from what's...
Why not just publish it as a SNAPSHOT version?
Otherwise though: timestamps should not be used in builds, like, in almost any scenario. Among other things, it'll mess up build caching if you're building multiple times locally
Can use the commit timestamp instead
rigid walrus
if coeh could make a build next week for the next snapshot then I can test it
#builds message
On the snapshot maven
blazing valve
So far I have had to write practically no StreamCodecs 😅 But I like the system
StreamCodec.of/ofMember make the porting a lot smoother
elder swallow
ok so what do we do for the tier sorting
true jacinth
uh
we could just toss it until someone needs it 
I'm not sure if anyone is actually inserting tiers between vanilla tiers anymore
Really the only mod that even comes to mind is like Iguana Tweaks from way way back
elder swallow
well the other thing is that we want mods that add tiers to work with each other
true jacinth
Why do we need the sorting for that?
i.e. what does "work together" mean
The only thing I would really like preserved is a registry of Tier(s) for naming them because I use such functionality for a config option (I would like to see one for ArmorMaterial as well tbh)
but with vanilla's tags being source-of-truth we might just have to live with that
elder swallow
I mean that ideally multiple mods could add blocks that require "tier 5" mining level
true jacinth
We could provide c: tags or a standard for levels incrementally beyond netherite?
really though I have no clue what lunatic decided that a tier would supply the incorrect blocks rather than the correct blocks
elder swallow
well the main advantage is that the ordering is in tags instead of in code
but this means that we cannot do any ordering ourselves
unless we add fucking blacklist tags
true jacinth
The best we can do is establish a convention for "tier above netherite" and see if people can sort their shit out
because that is the model vanilla has given us
elder swallow
c:incorrect_for_level_5_tool
true jacinth
well the main advantage is that the ordering is in tags instead of in code
it still could have been by establishing the order incrementally and having the next tag be a superset
but I suppose there are less blocks you need to list this way
the majority of blocks are breakable with the lowest tier
so I can understand the approach
because otherwise you need this "mineable with wood" tag that contains practically everything
Regardless, I still think it's crazy, the datagen could have been defined in terms of this inverse set for sanity and then generated to a proper forward syntax
but we're stuck with it I guess
So incorrect_for_level_X_tool convention it is
Still really kinda lost on the structure because there are now both needs_x_tool and incorrect_for_x_tool tags
and it doesn't make any sense for both to exist because they should never be disjoint (as who knows what nonsense that would entail)
Based on usages, it looks like dynamic tool mods would still like to be able to determine the relative strength of a tier.
elder swallow
the former only exists for backwards compat I'm pretty sure
so they wouldn't have to redo their datagen
true jacinth
why didn't they just use that tag then, screm
just add the stupid needs_wooden_tool tag and superset them to eachother
elder swallow
So `incorrect_for_level_X_tool` convention it is
Fabric has an API like this already, we should check the exact format
true jacinth
It will become effectively mandatory that mods adding custom tiers just use the vanilla tags though unless they are above netherite
We can just check fabric's conventions and add the TagKey(s) for a couple levels (maybe 5/6/7?) to our declarations
elder swallow
the module was disabled during the port
elder swallow
I suppose it makes sense 😛
true jacinth
lets go through the methods...
public static synchronized Tier registerTier(Tier tier, ResourceLocation name, List<Object> after, List<Object> before) gets deleted
getSortedTiers() can stay, but has to determine the order from the loaded tiers (and thus can only be called while a server is live)
I would prefer we keep the ID->Tier "registry" so the objects are named
elder swallow
the entire registry gets deleted and rewritten from scratch
true jacinth
pretty much
and injecting between vanilla tiers is no longer possible
I think a bunch of the util methods become unnecessary
i.e. the isCorrectToolForDrops override
and the entire network setup we have going on there becomes unnecessary (which, oh no, merge conflicts for network refactor, screm)
true jacinth
The thing that really irks me here, right
is that the tags are defined in reference to the needs_x tags
not the other incorrect_for tags
and because mojang has either not finished the transition from needs_x or is not going to transition from those tags
the logic for making a tier above diamond (netherite has no actual tier logic) is... "weird"
elder swallow
that's what I mean by "the module was disabled during the port"
this still needs fixing
true jacinth
Can we just supply level_x tags up to 7 and propogate them down the chain correctly?
because atm incorrect_for_diamond and incorrect_for_netherite aren't even linked
elder swallow
they have no reason to be linked
true jacinth
No, but if we support ordering they should be linked as netherite is a strict superset of diamond
elder swallow
if you want to add a level 7 block you need to add all the incorrect_for_xxx tags until level 6
true jacinth
No it's the opposite
you have to go back through all the vanilla tags and add your block to those
elder swallow
that's what I mean
true jacinth
which is just awful
let me map out the structure of the vanilla tags here - adding your block to 6 tags because you need to make it breakable by netherite only is miserable
true jacinth
gold is equivalent to wood
so we just have to make note that gold is level 0
I think we might end up with having a sideloaded set of level_x tags
elder swallow
well the biggest problem is that we're trying to be less flexible than vanilla
true jacinth
I mean, yeah, but ultimately that is the actual desired usecase when mods have to make Tier objects
Vanilla defines
0. wood, gold
- stone
- iron
- diamond, netherite
But vanilla never needs to compare if a tier is better than another tier (a common usecase in modland)
elder swallow
no it's
- 0 wood, gold
- 1 stone
- 2 iron
- 3 diamond
- 4 netherite
true jacinth
netherite and diamond have nothing different from a "things this tool can break"
elder swallow
they do
true jacinth
the tags are both
{
"values": []
}
maybe not with vanilla blocks specifically
fallen igloo
no it's
- 0 wood, gold
- 1 stone
- 2 iron
- 3 diamond
- 4 netherite
yes but some mods want gold to be its own tier
true jacinth
I know mods will expect netherite > diamond
I was just listing the vanilla definitions as a baseline
elder swallow
which mods????
true jacinth
Any of them doing tool ordering, lol
elder swallow
why would they change a vanilla tier
true jacinth
There are mods that make blocks only breakable by netherite
i.e. explicitly setting a level 4 classification to netherite
elder swallow
yes that is a relatively common use case
true jacinth
oh you were talking to schurli
i have no idea who wants gold to be its own tier, lol
but that's fine, gold can be lv1
@elder swallow does anything use the needs_x_tool tags other than these tag definitions?
We have to determine if those are still relevant and need to be "correct"
because that is going to really complicate things...
fallen igloo
each material has its own incorrect_for tag
true jacinth
I'm aware
elder swallow
<@298082405745426433> does anything use the `needs_x_tool` tags other than these...
they're only used in datagen
true jacinth
okay, so they don't need to be correct. We can probably deprecate them in code
So we should establish an authoritative set of sideloaded tags for the "ordered" levels
fallen igloo
do we have selective removal tag entries?
like: this tag contains everything that was in her but not this
looking at the vanilla system I'd say just nuke it for now and add a system when needed
true jacinth
Nuking the ability to compare tiers represents a major feature regression
fallen igloo
Nuking the ability to compare tiers represents a major feature regression
that is what vanilla did so ¯_(ツ)_/¯
true jacinth
vanilla never had this ability
it was always stapled onto it
just our existing method of stapling is not applicable
so we need new staples™️
fallen igloo
but that ability in vanilla is gone
true jacinth
?
elder swallow
the blacklisting is so incredibly stupid
true jacinth
agreed
fallen igloo
there is no more order there is just tags
true jacinth
there was never any order in vanilla schurli
elder swallow
in practice there is still an order
fallen igloo
there was never any order in vanilla schurli
it was an enum
true jacinth
it was an enum
it still is an enum
plus the enum was never representative of the order
elder swallow
it means that if you want to make a "gold tool only" block you have to blacklist EVERY SINGLE OTHER TAG
true jacinth
gold is after diamond
Ye its awful
Give me like 10 mins
I can put together a better level_x solution with laddering, I think
But I will need to make invariant that the needs_x_tool tags are just total junk
elder swallow
well the problem is that laddering will be the only thing it supports
true jacinth
That is acceptable, imo - I do not know of nor could I find anyone inserting new tiers inbetween the vanilla tiers
there are more than enough vanilla "levels" for sensible game design
fallen igloo
it means that if you want to make a "gold tool only" block you have to blacklist...
yes but for vanilla blacklist removes the need to sort
true jacinth
yes but for vanilla blacklist removes the need to sort
No it doesn't
it only removes the need for certain contexts
certain contexts where it really wasn't an issue already
Kits is holding the snapshot atm, right?
I can work there
rigid walrus
Does anyone want to test the unpick build in #builds on the snapshot maven?
elder swallow
it removes vanilla's own need of sorting