#adventure-contrib

1 messages · Page 1 of 1 (latest)

dense moss
#

first

winged sluice
#

second

raven sedge
#

fifth

grand granite
#

tenth

iron wave
#

millionth

stuck raft
#

⅞th

#

ok

eternal marsh
drifting shell
#

?th

delicate bay
#

t

copper imp
#

It's a new day

static glen
#

(not) first

copper imp
#

what is there even to do besides internal changes

#

is there even a feature missing

raven sedge
#

the main goal of the merger is more friendly faces :)

copper imp
#

okie dokie

pallid yew
copper imp
#

#1065 eyes_rotated_left, I just realized something else I could be doing because of that potentially.

real gale
#

Indexed mini message when 🥹

frail carbon
#

Wdym by indexed?

real gale
#

Lazy parsing of components that dont have placholders, indexing components that do have placeholders so when you want to replace them you already know where they’re

frail carbon
#

Ah, I see

#

Well, you are in the contributing channel 👀

#

Is there an issue about it?

timber fractal
#

Iirc mini message can get really slow

covert pond
#

How?

frail carbon
#

It's not slow and I have never seen evidence of it being slow. It's not free either tho, if you call it thousands of times per tick it will show up in your profiler of course

wild crane
#

Please do share some profiling or benchmark data if you have any! We can only fix issues we're aware of

#

I've never encountered any performance issues with MiniMessage and boy do we parse a lot of strings every tick haha

shadow dagger
#

What will happen to the old discord

frail carbon
#

There was somebody with a profiler report of a idle server which called MiniMessage way too often so it took like 0.25ms per tick

wild crane
frail carbon
#

But that's just improper usage I guess

wild crane
#

Yeah, still 3.9 mspt average anyway haha

twin ermine
#

Will current repository(-ies) on github move to PaperMC org?

wild crane
#

Yep

warm grotto
#

i dont know if it has been asked already but will the adventure related repos be moved to the PaperMC org eventually?

frail carbon
#

Literally one message up

warm grotto
#

🙃

#

And I was always surprised when that happened…

#

Also nice that non -contrib roles can write here

wild crane
#

It's a smaller project so less need for it, but who knows we might have to change that in the future

near swift
#

Thanks for the great work of adventure

covert pond
lavish monolith
#

Is there by any chance a "contributing.md" or some sort of dev docs? I am having issue with the Gradle build and I can't find any troubleshooting page in the docs

The error in case someone have an idea (I just cloned the project and let IntelliJ import the Gradle project):

Build file 'D:\Programmation\Java\KyoriAdventure\build-logic\build.gradle.kts' line: 19

libs::class.java.protect…omain.codeSource.location must not be null
frail carbon
#

Do you have any weird jdk or something?

lavish monolith
#

I let the IDE decide, but I can change it. Which is the recommanded version?

#

I just tried with Oracle OpenJDK 21.0.2 (which is the one I use when working on most of my other projects) and I face the same issue

#

I'm not used to Gradle tho, I usually with with Maven, so it might comes from a lack of knowledge from my side, thus why I asked for a setup doc

#

Hmm, I found out that IntelliJ have a settings section dedicated to Gradle, with its own JDK setup... It was not using the JDK configured on the project. I changed the JDK there and now it builds (at least it went past the 1st issue, let's hope it continues until the end!)

#

Yay it worked 🙂

frail carbon
#

Great 👍

#

No clue what that is about, haven't seen that before, was just a hunch

high mortar
#

21.0.2 is pretty outdated, there have been some useful fixes in there iirc

lavish monolith
#

Hmm, because both ComponentLike and ComponentBuilderApplicable are @FunctionalInterfaces, making the fist one extends the other and provides a default implementation raised a FunctionalInterfaceMethodChanged.
While I understand this might be a valid concern when dealing with lambdas with the same signatures, this is clearly not the case here: the ComponentLike takes no argument and returns a Component, while the ComponentBuilderApplicable takes the ComponentBuilder and returns nothing.
I see no confusion possible between the two methods.

What do you think about this? Is it a good enough reason not to do it, or is it rather a false positive warning?

#

To give a little more context about what I'm doing, see this message

wild crane
#

I think it's fine to supress that warning in this case

#

I'd prefer if you used this.asComponent().componentBuilderApply(component) though just so we're not repeating ourselves

raven sedge
#

PR time for adventure-nbt?

sleek raven
#

There aren’t any underlying nbt format changes tho right? So it’s just in the conversion between nbt and snbt?

raven sedge
#

ya

frail carbon
#

They said last snapshot they are afraid to touch nbt since that would break tools

fringe pike
#

Which I think is a major copout since they already broke just about everything else, generic nbt file readers are the simplest to fix out of them

fringe pike
#

I'll try implementing some of the snbt changes

#

nvm that seems incredibly annoying omegaroll

raven sedge
#

lmao

fathom void
#

I tried implementing the hover/click event changes and thats also annoying

fringe pike
#

A bunch of the update notes aren't actually changes from the previous version/already work in adventure at least

fathom void
#

show item/entity being inlined is so weird and annoying

fringe pike
#

and I can't say I care to reimplement scientific notation today (or at all). it needs fully manual number parsing character by character

#

... actually a big brain strat would be to just filter out the underscores if they're not at the start/end

fringe pike
#

Three failing tests remain

fringe pike
#

assertEquals(LongArrayBinaryTag.longArrayBinaryTag(1, 2, 3, 4), this.stringToTag("[L; 1l, 2i, 3b, 4]")); didn't do this one yet as it requires more thonkeng, and I definitely don't want to look at escape sequences

wild crane
#

Okay, here's a strange one: https://github.com/KyoriPowered/adventure/issues/974

This is caused by Translator implementations returning a component that does not carry over the children of the calling component. Now, we could chalk this up to an us issue and copy them over in the global translator, but what if you want the children to be removed? Should we even care about that?

The alternative solution is to just slap a notice on the docs saying "be careful not to lose the children", but, is that lazy? Is it good API design to force 99% of people to copy children over manually?

#

granted, 99% of people are not implementing their own translator so maybe it is okay for us to just put the onus on the dev

#

well, our choice is to either make devs not lose children sometimes or make devs not lose children all the time and i think the latter is better

wild crane
wild crane
#

Was thinking a bit about keys for tags and I think a better solution is to just add a namespace to tag resolvers. That way the vast majority of the API surface stays the same whilst only having to add a few optional methods to provide a namespace in some places.

Then we just detect if a tag has a namespace, if it does we ignore any resolvers with a non-matching namespace - ezpz

raven sedge
#

🤮 guess we have to get serious about updating for 1.21.5

frail carbon
#

what can I help with?

raven sedge
#

I think wrapping up the SNBT changes would be a good project, I'm going to dig up my old adventure-nbt DynamicOps as well to see if we can finish that off and embrace the true path

frail carbon
#

oh god, codexs

wild crane
#

ill try and get the last few translation fixes in - lmk if there's any concerns with my new PRs

raven sedge
#

I think they're probably fine, I gave them a brief look

wild crane
#

yeah the unit tests are pretty thorough, was mainly concerned about deprecating such a Big Class, but I think this is a nicer solution in the long run, plus being relatively easy to switch is nice

dense token
chilly summit
#

Btw are there any plans on integrating adventure docs into the paper docs? Would make it easier to organize I'd think

#

Same with the jd, but I feel like somebody had talked about previously already

stark basalt
#

Feels rough to move them to paper docs given adventure is for more than just paper

#

Fabric devs don't need to click themselves through paper docs just to know how to send their fancy messages.

chilly summit
#

What about introducing a primarily Paper-oriented section in the docs? I know there is a very small section already, but I think that could contain a bit more general information

#

Not in the adventure docs, but Paper

#

So that the people from other software still have their raw adventure ones but that Paper devs also have easier and more targeted information available

wild crane
#

I wouldn't want us to treat paper as a first class citizen amongst the rest of the implementing platforms

chilly summit
#

That's fair and makes sense. As my idea is shifting from being adventure specific, I will probably post further thoughts in #docs-website instead

sleek raven
frail carbon
chilly summit
#

What I mean specifically is that under docs.papermc.io/paper/dev, a new section for the specific platform implementation of adventure is added to document stuff like that ItemStack is a HoverEventSource, since not everyone would think of that

#

Same could be done for Velocity. Just that the Paper-specific stuff is also documented. Wherever we have mm stuff to link, we can just link to the existing adventure docs

wild crane
#

Sounds good to me yeah

nimble craneBOT
#

(67dc81226ed5010734cf1c0c) // @tawny wolf (@deivid_028 / 438530829808041984) has been banned by @stark basalt (202850073812402177)
Reason: Quick-banned for sending a message in #adventure-contrib

grim glade
wild crane
#

It can't be no

#

Feel free to open an issue, or even better a PR!

raven sedge
#

yeah, we've got a crowdin account so it should be possible to set things up, just nobody's gotten to it yet

frail carbon
#

Is there that much to translate? It's mostly buttons, that most don't really want to use in the first place

#

I feel like translating the docs for mm would be more helpful?

frail carbon
#

how can I help bring the adventure 1.21.5 PR over the line?

#

should I make the rename changes or do you want to do that @fathom void?

#

I tested the json stuff via the platform PR

wild crane
#

a fork opened by someone with authme work in their repo? inb4 homophobia

fathom void
frail carbon
#

should stlyeSerializer just take jsonoptions directly?

#

mapping those options into random booleans doesnt make much sense to me

#

and for the json options, should we go with MC versions or with a description of the format?

raven sedge
#

I'd rather have a field lookup than a map lookup for querying the options

frail carbon
#

i.e. HoverEventValueMode could be SNAKE_CASE, CAMEL_CASE, VALUE_FIELD vs 1_21_5, 1_16, LEGACY

raven sedge
#

I think the first is better

wild crane
#

First sounds good, being explicit about what the actual difference is is nice

frail carbon
#

inbf SNAKE_CASE_WITH_EXTRAS 😄

wild crane
#

SUPER_MODERN_SNAKE_CASE

frail carbon
#

but that woul dstill be better than super duper modern

chilly summit
#

Make it __ULTRA__LOUD__SNAKE__CASE__

acoustic pasture
#

__WHY__ARE__YOU__SCREAMING__AT__ME__

frail carbon
#

markdown moment

acoustic pasture
#

lol how did you do that without formatting

#

there we go

frail carbon
#

pain, mostly

chilly summit
#

I would also help with the 1.21.5 pr, but I honestly have absolutely no idea what any of anything in there means

#

So I will just keep my nose out of this one giggle

frail carbon
#

oh it for sure did need some time to understand wtf I was looking at

#

I didnt realize adventure had so much pain buried deep down

chilly summit
acoustic pasture
#

JuSt uSe BuNgEe CoMpOnEnT ApI

chilly summit
#

It's probably more realistic for me to port the xray feature patch than to try to understand adventure internals

frail carbon
#

also renamed the json component constants

#

I just saw the PR had a todo list

#

thats too much for tonight, will continue tomorrow

gaunt spruce
#

any idea when adventure will support 1.21.5? guessing it's in work?

flat zincBOT
#
__There Is No ETA__

Updates to Paper do not have any sort of estimate for when they release, ever. Any and all updates will arrive when they are ready, and the only thing to do is wait for them patiently along with everyone else.

frail carbon
#

There's literally discussion about that in the message above yours...

frail carbon
#

ok, lets see about the todos gerry left

#

I guess I need a proper test plugin first

frail carbon
#

ok change page is indeed broken

#

actually that might be a paper issue

#

please hold why I figure out how to fix the broken bungee serializer in paper...

#

(not that this works in spigot)

chilly summit
#

Paper staff using Spigot confirmed??

frail carbon
#

right now I am wearing my kyori hat 🙂

acoustic pasture
frail carbon
#

how does the JSONComponentSerializer.json() figure out the data version?

#

because I think it doesnt

#

oh I guess its supposed to use latest?

#

no its targeting 4174 when latest is 4298

#

love version mismatches, urg

#

juggling 4 projects at once is fun

frail carbon
#

ok, that was one point, lets look at show entity field

#

that just seems to work

#

what did mojang even change there?

#

idk why the old format still works, did mojang add compability there?

#

{action:'show_entity',contents:{id:[I;0,0,0,0],type:'minecraft:pig'}} becomes {action:'show_entity',uuid:[I;0,0,0,0],id:'minecraft:pig'}

#

but adventure still does the former and it works

#

ill get it changed anyways

#

oh wait it works because I am going thru papers adventure codec rn

#

how do you even do this on spigot? lmao

frail carbon
frail carbon
#

how much do we hate this?

#

EMIT_HOVER_SHOW_ENTITY_KEY_AS_TYPE_AND_UUID_AS_ID

#

Whether to emit the hover event show entity action's entity type key as a {@code type} and UUID as an {@code id}, as it was before 1.21.5.

fringe pike
#

I don't have any context open, but why not just use version names there?

frail carbon
#

this isnt really something somebody would actually use

#

they would always go by dataversion

#
GsonComponentSerializer.builder()
              .options(JSONOptions.byDataVersion().at(Bukkit.getUnsafe().getDataVersion()))
              .build()
fringe pike
#

Feels silly to try to describe all of them and future ones by their field name (but also not my project and two devs have already spoken so frogchairdefault)

frail carbon
#

mfw the bungee serializer is wrong

#

it emits the uuid as a string

fringe pike
#

lmao

frail carbon
#

idk how to parse show entity stuff in a way that can read both

#

I guess I could first look at all the fields found and then decide?

#

well, no, its a stream api

#

I think thats the last todo for 1.21.5

deft stirrup
#

Does adventure have a style guide they want for PR's?

drowsy sphinx
#

it's just checkstyle

wild crane
#

I've just opened an issue for discussion around Adventure 5.0, the next major version of Adventure. If you've got any thoughts or comments (even a simple thumbs up would help) please feel free to drop them in the comments of the issue, or we can chat here for larger discussions! https://github.com/KyoriPowered/adventure/issues/1202

GitHub

We're coming up to 5 years since the initial release of Adventure 4.0 and it's about time for us to think about a new major version release to Adventure 5.0. This issue documents our goals ...

ancient vale
#

On the topic of next versions, there’s some things that would be really nice to change but would be super breaking - do we want to aim for breaking changes in 6.x maybe?

wild crane
#

Depends what they are I suppose

warm grotto
#

what are some of the changes that would be nice?

ancient vale
#

Overhauling click/hover events to match current structure, for one

lucid quarry
#

I mean, I'd personally be against anything that would break 90% of existing usages; 99% of the reason we went for adventure was on the hopes of having a stable cross platform solution which would be stable

#

english

ancient vale
#

Not just breaking for the sake of breaking, but click/hover events have changed drastically and it would be good to be able to represent them nicer without having so much cruft

wild crane
#

Swapping class to interface and typing it with some data

ancient vale
#

it is an interface in the api already?

frail carbon
#

Can't we just change internals, deprecate the string methods and add typed ones?

ancient vale
#

it might be possible, but would adding a generic to ClickEvent be breaking? I don’t think it is?

wild crane
#

I don't think so no

#

And I also don't think class -> interface is breaking either

ancient vale
#

Oh it isn’t an interface already

wild crane
#

Very unlike you :p

ancient vale
#

it actually snuck past 4.0.0; I mentioned to @raven sedge how I was surprised it wasn’t an interface a while back

polar orchid
#

cuz invokevirtual instructions can't reference interface methods

main copper
#

Yeah, had the same issue with Cumulus (our form library)

frail carbon
#

we prolly want to get that into a release

dawn python
#

well working tests are missing ;P

#

looks like the order of the hover vs text changed when serializing components to json, weird

frail carbon
#

Order isn't guaranteed in json, is it?

dawn python
#

ah wait, the actual breaking change is that "type" is now "id" in the "show_entity" hover

frail carbon
#

and type is value or action or whatever

dawn python
#

ah, there is the emitKeyAsTypeAndUuidAsId parameter when serializing it. The test needs to be adjusted to test both of these cases I guess

frail carbon
#

Oh you looking at the tests

dawn python
#

oor well, I assume that is set based on HOVER_EVENT_SNAKE vs HOVER_EVENT_CAMEL?

frail carbon
#

And ye, those params are what the or adds

frail carbon
dawn python
#

hm, what data version do the tests use then?

#

(well it seems to be latest seeing as the test breaks but weird that it doesn't explicitely specify it)

#

or hm, guess I have to actually checkout the repo xD

dawn python
#

meh, I can't run the tests directly in IntelliJ :S

dawn python
#

yeah, adjusting the tests to use id+uuid instead of type+id makes it build, not sure if that is correct though (it seems to be according to the wiki but it feels weird to adjust tests lol)

dawn python
#

ok, seems to generally work when compiled though

#

although I of course didn't test all older versions xD

ancient vale
lucid quarry
#

alignment with vanilla?

raven sedge
#

item stack comparisons

lucid quarry
#

Yea ^^

raven sedge
#

less of an issue that things aren't stored as strings

lucid quarry
#

The order used to be raw string comparisions and so the order of output needed to align with vanilla, probably not an issue now with stuff serialised to NBT

ancient vale
#

For modern versions yeah, not sure if we need to maintain it for legacy

raven sedge
#

I guess it should be an option

raven sedge
#

So, trying to wrap my head around how DFU does type coercion here

#

It seems like ListTag/ByteArrayTag/IntArrayTag/LongArrayTag can all be coerced to/from each other

#

there's also the idea of heterogenous lists, where the on-disk ListTag is actually a list of compounds

#

right now the way I'm leaning is to add the option to have like a ListBinaryTag.heterogeneousBuilder() type thing, and a serializer option to unbox heterogeneity, basically making the on-disk format transparent to users

#

I think uniting the byte array/int array/long array is too many tradeoffs though, so in adventure-nbt those will still be the same

#

that's just something the DynamicOps has to paper over i think

#

now, maps

#

maps are mostly easier -- but mojang is a bit inconsistent about where it treats a null/empty/end value like an empty map, and where the only things accepted as prefixes for maps are existing compound tags

#

I'm leaning towards making every map operation in our DynamicOps take an empty()/EndBinaryTag and treat it as equivalent to an empty map

#

map keys are a bit funky -- since keys can be expressed as BinaryTags in a lot of places, the mojang route is, where a method returns a DataResult, they'll error if the BinaryTag key is not a string. where there's no result return value, mojang will SNBT-encode the tag value

#

which like, blah

#

I think that behaviour is something we'll have to emulate maybe? I kinda hate it tbh, it also means our DynamicOps impl can't be a singleton

warped fable
#

Anyways I think the best solution would IMO an optional : after inverse and phase, if those are missing check if the number is a float

#

Specifically a valid float between 0.0 and 1.0

wild crane
#

yeah sounds good to me!

frail carbon
#

Named arguments are such an oversight in MiniMessage :/

raven sedge
#

yeah I think it's come up in some issues before

warped fable
#

damn thats an old issue

#

anyways I think I made something

#

but am wondering about parsing the first number

#

since mine and the issue's idea was to be able to ommit phase and specify saturation, what would be the best way to check if its an integer or a floating point number

#

RegEx might be expensive?

#

one way I was thinking was to check if it contains a . or ends with f

wild crane
wild crane
#

I did some benchmarks and the answer is "yes it's technically faster to check against a nasty regex" but I've instead opted to rework the gradient/transition tags slightly to avoid calling Double#parseDouble unless it knows it needs a double or needs to fail.

#

check how i did it in those tags, i think i reworked the logic a bit

warped fable
#

I think value.endsWith("f") || value.endsWith("F") || value.contains(".") should be enough and let the Float#parseFloat do the rest

wild crane
#

the idea was the colour check is basically free, so check if it's a colour first and then if it isn't you fallback to parseFloat or w/e

warped fable
#

it is indeed a great solution

#

but unfortunately it can't be applied here

wild crane
#

why not?

warped fable
#

well we're checking between two number types

#

if we are to implement [!][phase] and [!][saturation]

wild crane
#

i think it's best to force phase application

#

make you order it

warped fable
#

hmm maybe

#

I don't see a problem with just having an if statement check if it is a float

#

the question that comes to my mind is really: "Will the developer get confused by syntax"

#

zml also adressed this in the issue

warped fable
frail carbon
#

If it looks good enough and is just off by a handful of numbers, just update the expected

warped fable
#

okay

#

I made the test

#

I need advice

#

how do you guys test for syntax errors

warped fable
#

do I need to fork paper to use my version of adventure api?

lucid quarry
#

unless you can relocate it into a plugin for your testing, yes

warped fable
#

uhh don't know what that means to be honest

#

I use implementation dependancy configuration if that is what you mean

#
dependencies {
    testImplementation(platform("org.junit:junit-bom:5.10.0"))
    testImplementation("org.junit.jupiter:junit-jupiter")
    implementation("net.kyori:adventure-api:4.21.0-SNAPSHOT")
    compileOnly("io.papermc.paper:paper-api:1.21.4-R0.1-SNAPSHOT")
}
lucid quarry
#

if you want to use native adventure in paper, then you can't shade in your own version

warped fable
#

I see, so I'd have to build paper with my version of adventure

warped fable
#

anyways, PR is up

frail carbon
#

checkstyle is lame

warped fable
#

hehe

raven sedge
#

I mean the alternative is waiting for a human to say the same thing lol

frail carbon
#

IJ was screaming at me to import the constants statically 😄

raven sedge
#

the issue is wildcards

main copper
#

You can also change your code style to never use wildcards. I've changed my default to that (and some other things)

raven sedge
#

lol adventure-nbt definitely needs a look over to get the method naming in line with the pattern for the rest of the API

#

poor under-loved NBT api

scenic escarp
#

I think the instructions on the adventure docs repo about adding changes isn't really up-to-date?

Because after adding pipenv and running the pipenv install command does it not recognize/find the sphinx-autobuild command when running pipenv run make livehtml

real salmon
#

the docs are going to be intergrated into paper's

raven sedge
#

it's poetry now

#

I updated the contributing page maybe I forgot the readme

raven sedge
#

taking another stab at diagramming component structure, does this sort of layout make sense?

warm grotto
#

Maybe the same word every time?

#

so it looks more like a „step by step“ diagram?

raven sedge
#

what?

#

the ideas is that the boxes are children

#

and the line at the top is the displayed message

warm grotto
#

Yes

#

Did I say something about the boxes?

raven sedge
#

what kind of component is "hello hello hello hello"

warm grotto
#

well you wanted input. I just gave you input.

raven sedge
#

is that a realistic component you'd write in a plugin?

warm grotto
#

I don’t think „Hello bold world, I am green“ is one either.

raven sedge
#

how about "You have given a", "golden shovel", "to", "player238"

warm grotto
#

Im just saying that it could be more understandable if the text would be the same and you just modify that one.

#

So you have the same initial every time

raven sedge
#

That seems like it would be more confusing to me? Since it would be more likely to be interpreted as applying different operations to the same component, rather than trying to explain how style inheritance works

warm grotto
#

Okay, my initial thought when I saw the image was that it is not connected and just shows different components.

#

So I don’t know if you plan to add a „okay, let’s create this component „Hello bold world, I am green“ then it makes sense and the image is good imo.

#

Without the context around the diagram it’s hard to find out if the design is good or not.

pallid yew
#
            [ Hello ]
            color: blue
                 |
     -------------------------
     |                       |
[ world ]               [ jelly ]
inherits color          color: red
  (blue)                     |
                         [ donut ]
                          inherits color (red)
raven sedge
#

hm yeah I think the challenge is i'm trying to capture how components are displayed linearly and their heirarchical behaviour at the same time

pallid yew
#

Flip the tree on its side and gap things out so left to right the boxes say "Hello world jelly donut" but still on different levels to show the tree hierarchy

raven sedge
#

hmm

#

does this make any more sense?

pallid yew
#

Hmm, maybe?

#

I wonder if it'd be better if you put the rendered message above the tree instead of in each node but had each node's word(s) in dashed boxes with dashed lines pointing down to the box that describes them

#

But I'm just giving you more work for random thoughts so feel free to ignore me 😄

#

Kind of like how you had it in your first version but with the dashed/dotted boxes and lines pointing down to the appopriate node just to make sure people get the connection

raven sedge
#

i mean i can see that i think?

pallid yew
#

Probably spaced out so each line down to the node is straight

raven sedge
#

something to toy with tomorrow

warm grotto
#

i think that one looks good

raven sedge
#

cuz it feels like one of the big issues people have with components is understanding how the style heierarchy works

pallid yew
#

Yeah the more I look at it the more I think I link the second one is an improvement over the first at least, I feel like showing an actual tree instead of nested boxes makes it clearer what is happening

#

I don't know if breaking the rendered result out away from the nodes is going to make it better though

#

I wonder if it might be better to have a child on pinecone too though just so people don't think only the last node can have children

warm grotto
#

im not sure but i think the "player Player524" should also include the italic. But i understand that you put an extra and it technically doesnt have it and just inherits that. What im saying is that it should be more clear it is inheriting it from the parent.

pallid yew
#

That was one thing my simpler text diagram did, it mentioned what was being inherited

warm grotto
#

and for me, i can barely see that it is italic. So maybe another color?

pallid yew
#

Which gets messy unless your example is only ever setting one property

raven sedge
#

i just matched the rgb value from MC

#

which like, a more "final" styling would probably try to make it look like the MC chat box

warm grotto
raven sedge
#

right now i'm just throwing things together in draw.io, once I get a layout that makes sense to people I'd like to automate it so it's easy to generate diagrams for the docs, and we can have some sort of website (webui or something else) that shows MiniMessage, json, and a graph side-by-side to visualize components

#

or like (inherited)

pallid yew
warm grotto
#

hm

pallid yew
#

I think you either have to count on the rendered text making the inheritance clear or limit the example to only setting one property and mentioning what the inherited value is (and that it was inherited)

#

Or maybe inheriting one and setting one but more than that and I think you get lost in lists of properties

warm grotto
#

maybe another box next to style or would that also be too much?

pallid yew
#

Well, this example would fit the inherit one and set one rule so it might be okay

raven sedge
#

hm, like Style (direct), Style (inherited)

warm grotto
#

yes

#

or just style and inherited or something.

raven sedge
#

but yeah, docs would keep examples simple

pallid yew
#

I'm just worried putting too much into the boxes is going to make you lose the final result

warm grotto
#

i think in this case its fine since its important.

pallid yew
#

Then you'd need to put the final result above the tree for sure but I'm worried that is going to be too abstract and/or too many arrows flying around to link it all together for people

#

I'm not very good at visualizing this stuff though so without putting in the time to make one and see how it looks it's just down to what @raven sedge feels like playing around with

raven sedge
#

lol me neither, that's kinda why i'm throwing things out

#

and like, i'm way too in the weeds with components to really have a good idea what works for someone new to modding

wild crane
# raven sedge does this make any more sense?

This is very nice, and I think if you stuck a big arrow at the top pointing left to right, with the resulting text on that it could be clear it's more of a "read right to left, but down is children" if that makes sense?

ancient vale
#

nit pick: a colour other than lime green

latent bobcat
#

how about an intense red

#

like those lipsticks hotel receptionists or flight attendants use

chilly summit
#

I think purple would be good

#

dark_purple looks good on both dark and light backgrounds

raven sedge
warped fable
#

Would this be okay to represet the optional saturation argument?

#

Or would it be better to combine the two pictures together

wild crane
#

Yeah that looks good to me! Although it might be worth updating the above - your screenshot is nicer haha

warped fable
#

oh I did it while nigh time lmao

#

will do

lavish monolith
wild crane
#

They aren't different

lavish monolith
#

Huh

wild crane
#

good point tho, might be worth picking too pretty different saturation values as well

warped fable
#

ye was thinking that

#

I was doing some experiments

#

second to last is compared to full sat

#

maybe this

wild crane
#

Yeah that's very nice

warped fable
#

0.8 and 0.65

lavish monolith
warped fable
#

0.65

#

I use that one on my server

lavish monolith
#

The last one from the second to last screenshot, right?

warped fable
lavish monolith
#

Yeah ok maybe I'm just bad at distinguishing colors, but to me, using 0.8 vs 0.5 would emphasis more the difference and the usefulness of that parameter

warped fable
#

yeah thats true, but 0.65 looks the best of all IMO

#

I can do a comparison

lavish monolith
# warped fable

Because I can hardly see the difference on that screenshot (but maybe it's just me, I know we all perceive colors slightly differently)

warped fable
#

completely understandable

#

because it's next to the same text and color

#

hard to distinguish

#

1.0, 0.8, 0.65

warped fable
frail carbon
#

Can you do more extreme values?

#

1 0.5 0.2?

warped fable
#

honestly

#

that doesn't look half bad

#

might use that

frail carbon
#

Maybe not 0.2 but 0.3, but ye

#

The user might not wanna use it that way, but extreme values better illustrate what exactly is happening

warped fable
#

1.0, 0.6, 0.3

lavish monolith
#

That's nice! Anyway that's a good thing to be able to control that parameter (and having it documented!)

warped fable
#

why is it not updating images?

#

like the build directory contains new images

#

I'm guessing my browser's doing?

#

yep

#

final look

chilly summit
#

I wonder whether it actually makes sense to pr that to the docs yet

#

There is currently a WIP PR which merges the adventure docs into the paper ones. Though, as one might suspect, that PR is probably going to be open for a little while, so not sure

wild crane
#

I'd rather we kept the docs up to date yes

chilly summit
#

Okay fair

real salmon
#

strukk just needs to hurry up

chilly summit
#

I am sorry for my PR to be possessed by demons and not compiling for some unknown reason

marsh thunder
#

I don't know if this is the right place to send this, but im running into an issue with the Hover event on the 1.21.5 branch for adventure. I looked into it, and it seems to be emitting the wrong case in the HoverEventValueMode. Might be something that only i am experiencing, but just wanted to give you a heads up, since it seems like you are in the process of merging it into main :)

pallid yew
#

Which platform?

marsh thunder
#

Oh, sorry I forgot that, it is on Velocity

pallid yew
#

Paper needed to update to a prerelease version of adventure to support that but Velocity appears to still be on 4.19 so that might just be a velocity thing

marsh thunder
wild crane
marsh thunder
wild crane
#

No need to apologise! That's why I asked 🫡 I think configuring the JSON serialiser version should be enough!

marsh thunder
wild crane
#

oh heck yea, that's very neat to hear

#

thanks for letting us know 🫡

surreal sorrel
#

hello! anything I can do to help with the 1.21.5 PRs for adventure / adventure-platform?

stark basalt
#

Tho no idea how required every PR in there is looking at the dfu one specifically

wild crane
#

I'm waiting on zml to decide if the dfu/nbt PRs are required, otherwise everything should be good to go

stark basalt
#

PepeSalute perfect

wild crane
#

A few people are already compiling against the 1.21.5 pr and reporting it being good, so I don't think you even need to test it although a second eye is always welcome if you've got the time

surreal sorrel
#

I reviewed/approved what I could in that milestone, sorry can't comment on / review the NBT stuff as frankly I don't think I'm qualified to do so :D

#

the feature flags in the json serialiser look... fun, I am grateful that others have suffered the pain of that so I don't have to 😅

ancient vale
#

@surreal sorrel throwback to 4.0.0 when things were so simple... those were the days 😭

surreal sorrel
#

haha yes

wild crane
#

Thanks for the reviews! Will get onto those comments tomorrow 🫡

warped fable
#

Hey, I was thinking. Why isn't there an API for rainbow and gradient, like minimessage does? I'd be happy to open a PR if its something that'd be welcome

#

Or should I open an issue to discuss this on github

latent bobcat
#

there's a PR already open

#

hasn't exactly been touched in a while

#

but the foundations seemed good

warped fable
latent bobcat
#

yep

warped fable
#

Will read up on it and maybe continue the work

wild crane
#

Yeah that PR was overscoped and has since been abandoned

warped fable
#

cause my original idea at least for rainbow was a builder class since rainbow has optional parameters

wild crane
#

Yes absolutely - imo a gradient builder class would be great

#

rainbows are just a gradient anyway so it'd just be a "preset" if that makes sense

warped fable
#

step as in: defines the amount of chars before the hue resets to 0, wanted to also add a PR for this after my saturation tag would get merged

#

as a follow up, to before. Would it be valid to update my MM PR to also include this step arg?

wild crane
#

yeah definitely

#

wait what's the difference between step and phase?

warped fable
#

as displayed in the web viewer

wild crane
#

So it'd repeat basically?

warped fable
#

yup

wild crane
#

neat

#

sounds good to me

lavish monolith
#

Hi, I was working on the <darken> tag, I have a version working fine here:

<darken:0.0><rainbow>Lorem ipsum dolor sit amet
<darken:0.1><rainbow>Lorem ipsum dolor sit amet
<darken:0.2><rainbow>Lorem ipsum dolor sit amet
<darken:0.3><rainbow>Lorem ipsum dolor sit amet
<darken:0.4><rainbow>Lorem ipsum dolor sit amet
<darken:0.5><rainbow>Lorem ipsum dolor sit amet
<darken:0.6><rainbow>Lorem ipsum dolor sit amet
<darken:0.7><rainbow>Lorem ipsum dolor sit amet
<darken:0.8><rainbow>Lorem ipsum dolor sit amet
<darken:0.9><rainbow>Lorem ipsum dolor sit amet
<darken:1.0><rainbow>Lorem ipsum dolor sit amet

(Note that <darken:0> is useless and <darken:1> is equivalent to <black>)

#

However, the code to do so has something a bit strange:

public class TagDarken implements Modifying {
    private final float factor;

    public TagDarken(float factor) {
        this.factor = 1 - Math.min(Math.max(0, factor), 1);
    }

    @Override
    public Component apply(@NotNull Component current, int depth) {
        TextColor color = current.color();
        if (color == null)
            return current.children(List.of()); // HERE
        return current.color(TextColor.color(
                color.red() * this.factor / 255,
                color.green() * this.factor / 255,
                color.blue() * this.factor / 255
        )).children(List.of()); // AND THERE
    }
}
frail carbon
#

uuh, fancy

lavish monolith
#

If I do not clear the list of children in the if for instance, I get this result for:

<darken:0.5><rainbow>Lorem ipsum dolor sit amet
frail carbon
#

ye stuff isnt really designed for stuff like that, mmh

lavish monolith
#

The fact that the Modifying tag adds the children is strange to me. It should either not touch them, and we handle them ourselves (but that would make stuff unnecessarily complicated) or completely override them imo

frail carbon
#

Maybe this is a new kind of tag

lavish monolith
#

I thougth it was something like:

public Component process(Modifying tag, Component toModify, int depth) {
    List<Component> children = toModify.children();
    Component modified = tag.apply(toModify, depth);
    List<Component> modifiedChildren = new ArrayList<>(children.size());
    for (Component child : children)
        modifiedChildren.add(this.process(tag, child, depth + 1));
    return modified.children(modifiedChildren);
}
#

But apparently it's doing some sort of merging between the children of the modified component and the modifiedChildren

wild crane
#

yeah it is slightly odd

#

not much we can do about it atp without making a new tag type

lavish monolith
#

Why is it like that?

#

It looks like a kind of strange behavior that pretty no one would expect

spring gyro
#

probably want to use hsl or oklab if we have utils for that

acoustic pasture
#

please add oklch

lavish monolith
#

But this was the first draft to validate the interest of such feature first

#

And also, I'd like to evaluate the performances of using HSV (which includes conversions) and staying in RGB

warped fable
warped fable
#

Hmm this contradicts with my saturation argument for rainbow PR

lavish monolith
#

It's different, this affects anything

lavish monolith
#

Basically, you can take any message you want and lighten or darken it

#
<lighten:1><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.9><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.8><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.7><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.6><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.5><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.4><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.3><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.2><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<lighten:0.1><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.1><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.2><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.3><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.4><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.5><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.6><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.7><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.8><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:0.9><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
<darken:1><gray>The <red>red team</red> has unlocked <rainbow>Rainbow Attack</rainbow>!
warped fable
#

Yeah I like your idea a lot. I slept through it thinking is it useful and came to the conclusion definetly.

chilly summit
lavish monolith
#

I was playing a little bit more with the Modifying tag to see whether my attempt at making a simplified TextModifying class was practical or not, and since I saw an issue about small caps, I trying that one and just wanted to share that result. However it would need a bit more work to implement it properly, as I just did it pretty quickly (with hardcoded constants)

the quick brown fox jumps over the lazy dog
<chars:smallcaps>the quick brown fox jumps over the lazy dog
<chars:upsidedown><reverse>the quick brown fox jumps over the lazy dog
#

Obviously, none of that tags work with client-side translated content

<chars:upsidedown><reverse><lower>the quick brown <lang:entity.minecraft.fox> jumps over the lazy dog
lavish monolith
#

As I said in this message #adventure-help message, while experimenting with the Modifying tag (especially with darken and lighten) a few days ago, I came across 3 different scenarios with one being worth discussing.
First, the working case:

<darken><red>Text</red></darken>

Yields Text in dark red. So far so good.
Then, a not working case that (I think) we cannot do better:

<darken>Text</darken>

Does not yield gray Text in chat, it remains white. Or purple, in item lore. Or whatever was the default color in that context. But since we do not know the context (where will the deserialized component shown), we cannot do anything better.
However, as mentioned in this issue, one could "reset" the style to plain white unstyled text, to not be dependent of the context anymore. But this leads to our third case, not working (that we could improve):

<red><darken>Text</darken></red>

Yields Text in normal red color, not darkened at all. And this is because when MiniMessage processes <darken>, the component given to the tag isn't styled red. It has no color at all.
I tried several solutions, but came up to the conclusion that only a modification of MM parsing would solve this problem, for example to pass the parents' styles (merged) to the tag. But that would lead to two concerns: 1. how to get the style of the parents (because its a tree, children are processed first, then parents recursively, more or less) 2. it would affect performances because it would not be needed 99.9% of the time :/
Note that would allow us to not only do this:

<gray>You got a reward! <darken>[learn more]</darken></gray>
<red>We could also imagine <invert>inverting</invert> colors to make accented or contrasted parts!</red>
wild crane
#

tbh this would be an incredibly complicated change

#

Tags would need to "ask" for parsing to be down out->in, or we'd need some system for tags to operate on a "second layer" of rendering

#

something really weird

#

perhaps a new tag type could solve it, some sort of post-processor tag type that operates once we're in a component form

#

even then you'd need to know the entire parent style tree

lavish monolith
#

Using a very simple & stupid implementation, I made it work, but only in "simple" cases, i.e. when the parent style does not come from Modifying tag itself

#

It works for the examples I gave above, but as I said not when the parent style is modified afterwards:

<rainbow>Lorem ipsum <darken>dolor</darken> sit amet
surreal sorrel
frail carbon
surreal sorrel
#

fab, thank you

frail carbon
#

That comment seems like a big oversight from me, lol

#

I tried to simplify the logic but didn't fully pay attention it seems

surreal sorrel
#

all good :)

warped fable
#

do you guys squash PRs?

stark basalt
#

adventure iirc merge commits PogPuke

wild crane
#

feel free to squash your own pr if you want to tho

nimble craneBOT
charred frost
#

Has anyone made a pure JS impl of MiniMessage (or is there a formal spec of the language available that someone else could impl easily?) I know the Web Viewer does some Kotlin-to-JS stuff

wild crane
#

You can just use the API

#

it's not documented but there's an endpoint that turns minimessage to html

charred frost
#

That should work for now, thanks. Eventually I'll need ot deal with custom tags and whatnot, but I'll cross that bridge later!

wild crane
#

it handles simple custom tags too

charred frost
#

WebSocket, interesting! Thank you very much for the info

wild crane
#

tbh we could very easily add a non websocket endpoint

charred frost
#

Looking to use MM for ingame player mail, but also be able to display it on our website in a sensible way, so it's a fun exercise

wild crane
#

sounds fun! we could def add a normal http endpoint if that would be more helpful

charred frost
#

I'm excited. I'm kinda getting back into this after a long time away (I mean, y'all moved servers in the time between, so…)

wild crane
#

haha yep :')

#

let me know if you have any problems with it! always happy to help 🫡

charred frost
#

Thank you!

chilly summit
#

@raven sedge and @wild crane, I would appreciate it if one of you could look over PaperMC/docs#573. These are your docs we are migrating, so it makes sense for you to look over them in case something doesn't fit

wild crane
#

Definitely, I'll add it to my todo list!

ancient vale
chilly summit
ancient vale
#

able to summarize the changes on the PR?

chilly summit
#

The pictures on the mm format page are a bit differently formatted and on each serializer is a new code block because of a bug

#

But otherwise nothing changed

#

But yeah I'll list those tiny things in the desc

wild crane
#

minor complaint, can we have adventure above waterfall xxx

ancient vale
#

100%

wild crane
#

am reviewing the pr now

chilly summit
#

Yay 👍

wild crane
#

How is the ordering of the menu defined?

#

Left two minor comments, my only other comment is that I think the "homepage" should be ordered differently although idk how that's done. I'd suggest bringing MiniMessage much higher as that's where most of our traffic will go and I don't want to confuse end-users with the "getting started" page immediately being code code code

real salmon
#

Text (Chat Components) looks weird

chilly summit
#

But yeah, we can put the sidebar for mm up higher, that's not a problem

real salmon
#

aso as with the other doc pages can the dependency be Gradle Kotlin, Groovy and then Maven?

wild crane
#

could probably get rid of the inline code if it looks better

#

looks fine on chrome at least

real salmon
#

not for me

wild crane
#

got a pic?

real salmon
wild crane
#

that's fine

#

don't need to nitpick too much

chilly summit
#

So don't expect quick changes

#

But yeah, I'd probably remove the inline code. I also think it looks weird

#

...or I could add some padding for that title so that the inline looks better

#

I'll check what I can do

real salmon
#

and something that should probably be done in a later pr is javadoc links

#

also there's mixed usage of @NotNull and @NonNull

chilly summit
#

Yeah valid. But I think that should be part of a separate "cleanup" PR instead of the main move-over PR to make reviewing easier

wild crane
#

agreed

#

plenty of issues with the docs in general haha

chilly summit
# wild crane plenty of issues with the docs in general haha

I am a tiny bit salty about not being able to do inline code syntax highlighting. There is a WIP PR from expressive-code for that, so as soon as that merges, I'll definitely re-add that, but there is nothing we can do about it atm. I did try a lot of various, custom methods, but none worked fully

acoustic pasture
#

<@&748618676189528155>

opaque swift
#

Is someone here already/planning on working on a dialog api/implementation or would that be a pull request worth? I'm currently adding them to ViaVersion and would also do for adventure if no one wants to.

stark basalt
#

I am semi certain

#

Dialoge is wayyyy to volatile to abstract

opaque swift
#

Ah so no dialogs in Paper/Velocity?

chilly summit
#

Ofc they will be in Paper

#

Just not necessarily in Adventure

opaque swift
#

wouldn't adventure make more sense so they can be used in Velocity and Paper?

chilly summit
#

Those are not the only platforms Adventure supports, and as lynx said, they might be hard to abstract into their own thing anyways

opaque swift
#

lol

high mortar
#

Not hard to abstract. Volatile.

chilly summit
high mortar
#

Writing an API likely to be able to handle a 1.21.7 or 1.22 change to dialogs, with them being so very recent and having changed so much in the last few weeks, would be quite the challenge. Publishing an adventure API for dialog that's immediately obsolete would be painful for all involved.
To be clear, this is not an official statement from the adventure team. I'm just elaborating on the earlier comment.

wild crane
#

This is an official statement from the adventure team, mbax is right

#

tbh you can just assume that to be the case when it comes to mbax

verbal widget
#

lool

deft stirrup
lavish monolith
#

Hello,
Just sharing what I was recently working on, and in case some features are interesting for you, I'm open to work a little bit more to integrate them properly in a PR.
I wanted to give a try at a first implementation of component wrapping (for automatic line break in item's lore). My idea was to first "linearize" the component tree, to easily split it on a given character (space, for example), and then estimate roughly the length of each "word" to recreate lines no longer than a given length. It has a lots of (obvious) issues, as I showed in the last examples, but it's still my first attempt at that problem, and aside from the length estimation problem (hard to solve / even maybe unsolvable), and the space formatting issue (technical issue I just didn't had time to tackle), I think the linearization part is "perfect" (= working for all case), and still this naive algorithm can handle most common cases when no translation is involved.

My code: https://pastes.dev/pBth4ODIA9

Here are some examples, with visuals in order:

/test <rainbow>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus eget consectetur lectus, at tincidunt enim. Etiam rhoncus elit enim, ac dignissim orci ullamcorper at.

/test The <i>quick</i> <#964B00>brown</#964B00> <tr_or:entity.minecraft.fox:Fox> jumps over the <b>lazy</b> dog

/test The <i>quick</i> <#964B00>brown</#964B00> <tr:entity.minecraft.fox> jumps over the <b>lazy</b> dog

/test <u>Underlined wrapped spaces are not well rendered

/test <gray>Here is a <rainbow>very-super-mega-giga-extraordinarily</rainbow> long word well over the wrap length limit of 25 characters
wild crane
deft stirrup
wild crane
#

Sounds fair enough then yeah!

deft stirrup
#

Do you have any suggestions on the verbose one? I understand .tag can deserialize compound but if you do .compound you get the error on the first token

#

I could do a functional interface that is used instead because the methods do declare throws which Function would not like, seems overkill for a utility class though.

warped fable
lavish monolith
warped fable
#

I really like the concept though. This would make things so much better in terms of descriptions, I, for example, have over 400 custom items with descriptions and it's definetly a hassle trying to keep the same wrap length

plain basin
#

Hey Adventure guys.

So; ive been using books as a front end for my SQL-lite DB, its working fine but while I was making it, i noticed there is no way in bukkit/spigot/paper/adventure that allows you to map dynamically sized strings directly to pages.

I made an algorithm that takes into consideration pixel width of characters , bold text and more, and this allows me to accurately map strings into pages without over or under flowing the pages.

My solution isn’t perfect, but i am willing to share the code and maybe get it improved and added into adventure? Feels like it should already be a feature

Basically: my algorithm takes in a string, then maps it into a list of strings (pages) and that list can be given to
book.setPage or whatever the function is

#

And it works for mutable, dynamic strings

wild crane
#

How do you generate the pixel width for each character? I've been wanting something like this in adventure for a while but we need it to work like this:

  • a separate module containing up-to-date pixel widths of characters, possibly a separate repo or even just a community maintained project
  • a generic interface to provide the width of a character, given the styling
  • an "algorithm" in adventure api that uses the above interface to calculate the width
eternal hedge
plain basin
#
    final int MAX_LINE_WIDTH = 114;  // Minecraft's approx line width in pixels
    final int MAX_LINES_PER_PAGE = 14;
    private static final Map<Character, Integer> CHARACTER_WIDTHS = Map.<Character, Integer>ofEntries(
            Map.entry(' ', 4), Map.entry('!', 2), Map.entry('"', 5), Map.entry('#', 6),
            Map.entry('$', 6), Map.entry('%', 6), Map.entry('&', 6), Map.entry('\'', 3),
            Map.entry('(', 5), Map.entry(')', 5), Map.entry('*', 5), Map.entry('+', 6),
            Map.entry(',', 2), Map.entry('-', 6), Map.entry('.', 2), Map.entry('/', 6),
            Map.entry('0', 6), Map.entry('1', 6), Map.entry('2', 6), Map.entry('3', 6),
            Map.entry('4', 6), Map.entry('5', 6), Map.entry('6', 6), Map.entry('7', 6),
            Map.entry('8', 6), Map.entry('9', 6), Map.entry(':', 2), Map.entry(';', 2),
            Map.entry('<', 5), Map.entry('=', 6), Map.entry('>', 5), Map.entry('?', 6),
            Map.entry('@', 7), Map.entry('A', 6), Map.entry('B', 6), Map.entry('C', 6),
            Map.entry('D', 6), Map.entry('E', 6), Map.entry('F', 6), Map.entry('G', 6),
            Map.entry('H', 6), Map.entry('I', 4), Map.entry('J', 6), Map.entry('K', 6),
            Map.entry('L', 6), Map.entry('M', 6), Map.entry('N', 6), Map.entry('O', 6),
            Map.entry('P', 6), Map.entry('Q', 6), Map.entry('R', 6), Map.entry('S', 6),
            Map.entry('T', 6), Map.entry('U', 6), Map.entry('V', 6), Map.entry('W', 6),
            Map.entry('X', 6), Map.entry('Y', 6), Map.entry('Z', 6), Map.entry('[', 4),
            Map.entry('\\', 6), Map.entry(']', 4), Map.entry('^', 6), Map.entry('_', 6),
            Map.entry('a', 6), Map.entry('b', 6), Map.entry('c', 6), Map.entry('d', 6),
            Map.entry('e', 6), Map.entry('f', 5), Map.entry('g', 6), Map.entry('h', 6),
            Map.entry('i', 2), Map.entry('j', 6), Map.entry('k', 5), Map.entry('l', 3),
            Map.entry('m', 6), Map.entry('n', 6), Map.entry('o', 6), Map.entry('p', 6),
            Map.entry('q', 6), Map.entry('r', 6), Map.entry('s', 6), Map.entry('t', 4),
            Map.entry('u', 6), Map.entry('v', 6), Map.entry('w', 6), Map.entry('x', 6),
            Map.entry('y', 6), Map.entry('z', 6), Map.entry('{', 5), Map.entry('|', 2),
            Map.entry('}', 5), Map.entry('~', 7)
    );
torn forge
#

Even if you have all the widths, you still can't really predict how some custom font will behave. Maybe some API that accepts a function to determine the width and does somethings related might be useful, but it will not cover the case when a player have default fonts replaced with their own resource pack

wild crane
plain basin
#

Ah. Fair enough

deft stirrup
warped fable
raven sedge
#

we have lives

#

i feel like it triggered a discussion about named arguments too lol

deft stirrup
#

Might need 4.22.1, some methods in TagStringIO are missing thier heterogeneousLists configuration

raven sedge
#

no

#

can't add api

#

in a patch, at least

wild crane
prime basin
#

Key.key("a/b", "a") throws a StringIndexOutOfBoundsException instead of the usual invalid key exception, and the regexp in the error message for the value doesn't include the '/'

wild crane
#

oh wait i see

#

yes

#

ok ill fix that too

prime basin
#

i know but the error shouldn't throw that

#

it hides the real cause

raven sedge
#

thank you #1 adventure team member kezz

deft stirrup
real salmon
#

manual

deft stirrup
#

lovely

raven sedge
#

ah shit that's on my laptop unpiuhed lol

sleek raven
#

did adventure for 1.21.6 add a clearDialog method too?

#

I don't see one, 4.24 incoming?

wild crane
#

heck yea, i can get in the binary tag holder bits too then ig

raven sedge
#

4.99 coming soon

stuck stone
#

Is there a reason for the custom click payload data being marked as not-null? Vanilla allows the data to be nullable

wild crane
#

there is practically zero use case for the data being null but i can bump it up to nullable ig

#

tbh i dont really want to make this change, i cant see any use case for it and there's no reason why you couldnt translate null data to an empty compound tag

#

unless there's something im missing?

pallid yew
#

null data would only be useful if there was just a single use of the click callback

#

If it complicates the API allowing it to be null I wouldn't bother, that's such a weird case odds are anyone who thinks it's what they want are wrong or doing things in a terrible way 😄

wild crane
#

yeah i agree

#

to the point where i wouldn't be surprised if they removed the optional-ness of the tag from the packet

uncut turret
#

would it be a bad idea to let Placeholder#unparsed take anything that can be toStringed

#

or at least numerical types for instance

acoustic pasture
sleek raven
#

Is there smth against adding an adventure Key.minecraft(value)? Kinda annoying to do Key.key(Key.MINECRAFT_NAMESPACE, value)

stark basalt
#

Key.key("hi there") already yields minecraft no?

#

like, it is there implicitly

sleek raven
#

yeah, but I want the value to only be the value, and have no chance of being the ns:value

deft stirrup
latent bobcat
#

no

sleek raven
#

I'll open a pr then

raven sedge
#

needs to be .minceraft tho

wild crane
sleek raven
#

yeah ok, I like this

uncut turret
sleek raven
#

@wild crane this is what I was talking about the other day when I was talking about adventure expanding click callback. I think it'd be nice if there was a ClickCallback that accepted an Audience and a generic payload. or something. Cause we want to do this obviously for dialogs, and this is just a ClickEvent.CUSTOM with an id, but the callback also supplies the inputs from the dialog.

Maybe its out of adventure scope, and we can just do our own thing, idk. https://github.com/PaperMC/Paper/pull/12671/files#diff-06c8439b14f2fcdf4106ab0f587408f158e000a6dde17395f82f8ac069df8d2c

GitHub

Adds 2 temporary methods to show/clear dialogs from a Player. Will be replaced by adventure methods.
Player#tempShowDialog and Player#tempClearDialog.

wild crane
ancient vale
wild crane
#

Ty!

steep drum
urban zephyr
#

I recently started updating my NBT Component Serializer PR and I've almost finished it, however I also saw the dfu codec implementation pr, would my pr still be welcome then? Or should I just abandon it?

latent bobcat
#

are there any plans about adding JPMS module descriptors for v5? or any particular reason for not adding them? non-modular clients would still be able to consume the library normally

wild crane
#

I've got no qualms either way tbh

urban zephyr
#

Why does ClickEvent.Custom use BinaryTagHolder when payload in serialization is just a binary tag?

stark basalt
#

adventures API does not have the concept of a binary tag

urban zephyr
#

Ohhh

#

Right

#

The api does not include nbt by default

#

Thanks

wild crane
#

adventure 5.0 is so yummy

urban zephyr
#

I now feel like my NBT serializer adds so much garbage lol

#

+3.7K additions

deft stirrup
#

Will adventure 5.0.0 change the statics inside of identity, they are quite annoying if you decide to implement it into your own (UUID pointer)

#

oh its getting sealed nvm then

frail carbon
wild crane
#

Ideally you should only be implementing Identified

#

If you've got a use case for implementing Identity directly do let us know

real salmon
#

Kezz, can I continue my jspecify pr after most of the stuff got refactored for v5? So that i don’t have to deal with merge conflicts all the time

warm grotto
#

I think you have to finish it for the current version and then refactor it to v5

wild crane
#

No, we'll migrate to jspecify with v5 not before. Def can wait until everything is done though!

real salmon
warm grotto
#

Yeah I that’s definitely the smarter decision

deft stirrup
fossil mountain
#

What's standing in the way of splitting the Audience interface into sub-interfaces?
I've heard from numerous ppl that this is unwanted, but never why exactly. And with Adventure 5.0 seemingly around the corner, I wanted to ask about this.
I get that the idea is that it its methods are no-op until implemented by platforms, but it seems to confuse a good number devs and creates situation where it is weirdly implemented (see paper's config-state-api pr).

wild crane
#

It's a conscious design choice that makes the entire point of adventure (a cross-platform user interface library) pointless if you're having to instanceof and cast constantly just to send a message or something

fossil mountain
#

huh?
I don't get it, if you keep the Audience interface and move the parts e.g. resource packs, chat messages etc. into their own interface, which are added in Audience what do you need to cast, it is just that specific implementations may only implement some of the sub-interfaces instead of the aio.

lucid quarry
#

Because the breakup just places you into a point where you have a super interface that everything is basically already using that would breal compat with existing things for no real direct adventage

fossil mountain
lavish monolith
#

I don't think 5.0 is "a one big thing that breaks compat"

fossil mountain
#

and potentially a recompile.
that's all that shoudl be needed, as methods which don't work / are no-op shouldn't be used anyway.

fossil mountain
lucid quarry
#

a recompile for the sake of dealing with ABI breaks

#

not a "you're going to have to migrate non-deprecated code"

fossil mountain
#

and why would anyone need to migrate their code with this proposal?
(as long as they do not use any unimplemented methods from e.g. velocity)

lucid quarry
#

Because that would require platforms to change return types to be useful

#

Velocity could not implement the Audience interface if its not implementing all of that stuff

fossil mountain
lavish monolith
#

"methods which don't work" isn't true. They are no-op on purpose. We're using Audiences as a way to designate a bunch of objects with some able to receive some kind of things. When I send a message to an audience, I absolutely don't need to know how and even if the receiver will handle it. Simple example:
Team chat with "announcements" mechanism. All is required is a single audience per team. It is a forwarding audience with online players of the team (so they receive the message instantly), the console for logging purpose, and my storage manager so, if not all players of the team are online, the announcement is stored and they see it when they get back. If all members are online, then this is a no-op. And optionally, the announcement can be shown as a title (big message in the middle of the screen), but the console will just ignore it, and just print the message in the logs: this is fine.
If the console was only a "message audience" and not "title audience", it would have made thing more complicated. If the storage manager was not an audience like the rest of the objects, it wouldn't had fit into the forwarding audience. So much reasons is this simple example to me in favor of keeping the existing system

lucid quarry
#

I have said in the past that I would kinda love if there was a capability mechanism

#

I understand that that does introduce a lot of bleh factor, however

lavish monolith
#

Yeah it could open the possibility for the one interested of knowing, without taking away the ability to stay in ignorance 😄

fossil mountain
#

Alright, yea that makes sense but then why doesn't something like the PlayerConfigurationConnection implement e.g. only resourcepack methods itself instead of returning the audience as method which is mostly just useless?
Because of forwarding audience?
-# probably not that adventure related

lavish monolith
#

Maybe, and also it works out of the box with methods working with an audience to send the resource pack then. I kind of like the way it is right now

#

Except maybe if it could instead of returning the audience, be an audience itself (a forwarding one, forwarding to the one it currently returns)

lavish monolith
#

Hmm, while I understand his point of view, I can see how it could be useful. But better "capabilities" like suggested could maybe help making things clear. I guess this is a good middle point, where we could get the audience if we need to, but it does not claim to be one when it 99% isn't

high mortar
lavish monolith
#

Maybe a more explicit naming however of the getAudience() would clarify this (like getResourcePackAudience() or something better)

high mortar
#

(I dislike the capability stuff here and am in favor of the mono interface as we have)

wild crane
#

and if your argument is "well it's good for common util methods or cross-platform code", what's the downside to Audience in that case? nothing really imo

fossil mountain
#

yea, I get that now.

Alright, yea that makes sense but then why doesn't something like the PlayerConfigurationConnection implement e.g. only resourcepack methods itself instead of returning the audience

lucid quarry
#

Because the entire point is that it allows you to have reusability

honest roost
#

why not make an audience offshoot that is ConnectionAudience and have Audience extend that?

wild crane
#

again, why? that would only work in this one specific example - it wouldn't benefit common util methods, wouldn't benegit cross-platform code, what does it actually do?

urban zephyr
warped fable
urban zephyr
warped fable
urban zephyr
#

how would you use protected for a class?

#

also protected does not even make sense here

#

nothing is extended

warped fable
#

fair enough

verbal widget
wild crane
#

No, we just have priorities and real life stuff that gets in the way

#

We'll get to it when we get to it and there's no use making comments like that

sacred osprey
#

even(t)

wild crane
#

feel free to submit a pr

midnight vapor
#

I just resolved a really really annoying bug which basically goes like this:

Here's what hover usually looks like: <hover:show_text:'<red>test'>TEST

Here's what completely breaks hover: <hover:show_text:'<red>U9G's Island'>TEST. it was of course not easy to find and took debugging but it's kind of dumb that nobody checks for this

I think that if you have a non-escaped apostrophe that is not followed by a ">" inside of an "open string by single apostrophe" there should be an error.

honest roost
midnight vapor
lavish monolith
#

Is it a silent failure even in strict mode?

high mortar
#

What would the error specifically be? How would it specifically be detected?

wild crane
#

how would you detect e.g. your example vs the valid text dogs < cats :') >:

#

or something similar

#

like why would we error on what could be normal text

lavish monolith
#

Maybe in strict mode, a warning could be emitted, at most. Are whitespace allowed in tags? I mean, is < hover :show_text: 'example' > valid?

midnight vapor
midnight vapor
high mortar
#

I'm not an adventure expert but I know that would, at least, blow up on <meow:'hiss':'purr'>

midnight vapor
candid solar
#

does minimessage even error on any text in non-strict mode?
doesn't strict mode only error on unclosed tags/reset tag?

lavish monolith
midnight vapor
lavish monolith
#

I told you that any argument can be quoted (in response to your message "i don't think quoting the second argument is valid"). Then, I added that is was even possible that the tag name (the "first" argument according to your logic) could be quoted, but I was unsure about that (because the tag name has strict limitations on the allowed characters, so quotation appears to be useless, but depending on the way they implemented it, it may still be allowed). I added this to emphasis the fact that you should not make assumption about what's valid or not unless you checked yourself

#

I say "any argument" because the tag name does not count as an argument (when using the tag, for example), but if you consider it to be the first one, then I am 100% sure that all the other ones can be quoted

raven sedge
#

hm @spring gyro if you're doing an adventure version bump to -platform-mod it should probably be a bump to minor not just patch

#

just for like, thoroughtess

spring gyro
#

sure

wild crane
#

dropping this here for thoughts

umbral widget
# wild crane dropping this here for thoughts

Would be a great addition I think unless there’s some downside I don’t know of (and I would love to know because I currently have some extra logic to do this exact behavior 😅 )

gentle briar
#

Just PlainTextSerializer would be great, I just ran into this issue for probably the fifth time. Or make the serializer configurable in the MiniMessage builder?

deft stirrup
worthy mesa
#

Re: https://github.com/KyoriPowered/adventure/pull/1266#issuecomment-3184322920
I'm not super opposed to it or anything, but like, it just seems messier? an instance method being put in a static method basically

CompoundBinaryTag data = getData().createBuilder().remove("number").putInt("num", 16).putString("id", storage.getId())
                             .put("values", oldValues.createBuilder().putString("name", name).remove("needs_update").build())
CompoundBinaryTag data = CompoundBinaryTag.builder(getData()).remove("number").putInt("num", 16).putString("id", storage.getId())
                             .put("values", CompoundBinaryTag.builder(oldValues).putString("name", name).remove("needs_update").build())

Kinda feels as if list.stream() was Streams.stream(list) or something like that imo (especially considering the in-line usage both are meant to allow)

#

Also worse for findability in IDE via completions I suppose

lavish monolith
#

Does CompoundBinaryTag.builder() exist (without parameter)?

#

I think both would be good, as they fit different use cases

worthy mesa
#

Yeah - I guess it makes sense for consistency, but still just seems a lot more annoying to use for everything else

#

Yeah was gonna say, maybe we just have both?

ancient vale
worthy mesa
#

Will go change it either way, but let me know if having the instance method as well is something you'd consider

ancient vale
ancient vale
#

Buildable is considered deprecated, basically

worthy mesa
#

I see, thanks for the link 👍

#

How should it be implemented then? can't really have an implementation in CompoundBinaryTagImpl anymore afaics since it's a static method, so would it be something like this?

  CompoundTagBuilder(CompoundBinaryTag existing) {
    if (!(existing instanceof CompoundBinaryTagImpl)) {
      throw new IllegalArgumentException("Creating builder from an unknown CompoundBinaryTag implementation: " + existing + '/' + existing.getClass().getName());
    }
    this.tags = new HashMap<>(((CompoundBinaryTagImpl) existing).tags);
  }
#

Or maybe expose a CompoundBinaryTag#asMap that returns an immutable tags map, and use that there ^?

#

That might be better actually? cleaner and adds some free extra API functionality along the way as well

lavish monolith
#

Question: I have a (small) feature I made and would like to include in adventure, so I pushed it on a branch on my fork, but before I can open a PR, I'd like to know what are the requirements regarding unit tests (& possibly benchmark if I need to, but I guess not)? Here is what I'm talking about, as you can see there isn't much code, but I'm pretty sure some unit tests would be welcome as well:
https://github.com/indyteo/adventure/commit/86f709f893a93ee21e8a23ea18d0db448df8c24c

steep drum
#

Thoughts on Velocity#1630? Should there be some kind of validation on adventures side of the url, maybe as an option flag on JsonComponentSerializer? Or even a flag to just prepend a https:// the same way paper does it

wild crane
#

Adventure didn't do anything when command click events changed so I don't think we should do anything about this either

#

better to just do it the same way paper does ig

steep drum
#

And that should be done in velocity or adventure? In velocity we're kinda in the same situation as with what we talked about 2 days ago, would require to reconstruct every component to replace something inside a click event

wild crane
#

oh yeah paper can do that in codecs right

#

in that case yeah perhaps an option in the json serializer might be fine then

spring gyro
karmic hull
warped fable
spring gyro
#
    @EventHandler
    public void onJoin(final PlayerJoinEvent event) {
        event.getPlayer().sendMessage(Component.text("Hi ")
            .append(Component.object(ObjectComponent.Contents.sprite(Key.key("block/fire_0")))));
    }
``` updated code with futureproofed api
raven sedge
#

tbh we should publish that with a net.kyori:adventure-* capability just so people don't accidentally end up with both in their dependency hierarchy

spring gyro
#

not a bad idea, but it's already going to be annoying enough to force push the build commit away and re cherry pick it later

#

maybe need to find out a way to make permanent build/ci changes to support this... the indra sonatype plugin being applied breaks publish only pushing to paper iirc

raven sedge
#

maybe logic based on git branch?

spring gyro
#

wen indra 4

raven sedge
#

idk

spring gyro
#

I think it's basically ready but the secrets and actions config isn't setup for the GPP

crisp portal
chilly summit
# spring gyro https://github.com/KyoriPowered/adventure/pull/1291 if anyone feels like contrib...

Well, I went for it. Never once worked with Adventure source code before, so idk if I did stuff even remotely correctly: https://github.com/KyoriPowered/adventure/pull/1292
Imo, the tests are a bit, ehh. I am very much open for suggestions on how to improve them. I am also not sure if the emitter from the tag implementation is correct (as I do not know what it does in the first place 😅) but I am sure somebody will speak up lol

GitHub

Adds a sprite:key tag for inserting sprite objects via MiniMessage.

lavish monolith
raven sedge
#

named args wen

chilly summit
#

So it kinda just slipped my mind

#

But yeah, having that as a first arg if two args are present seems like a solid choice, lemme add that in rq

lavish monolith
chilly summit
#

Yeah I got it, nw

#

Alright, atlas argument is in

lavish monolith
#

Nice!
I don't know if it really matters because it's just unit tests, but there's no minecraft:items atlas in vanilla Minecraft, it's the same as minecraft:blocks

chilly summit
#

I mean, as you just said, it matters not in unit tests

#

I could write a novel in there for all the unit tests care kek

spring gyro
#

not really sure how much it matters but with the current code if you do <sprite:blocks:block/fire_0> and then serialize it'll give back <sprite:block/fire_0>

#

minecraft namespace is already stripped in other tags though so seems consistent

steep drum
chilly summit
#

Truly a group effort project

#

I love open source

steep drum
#

are we sure we want the atlas to be non-null? Font in Style#font is also nullable and doesn't default to Style#DEFAULT_FONT

spring gyro
#

I don't really like it, it feels more like adventure 3 and will cause larger refactors just to add an extra child later

#

(for example)

spring gyro
spring gyro
#

(will need to add mavenLocal in settings)

steep drum
#

Okay I've almost fully updated the serializer pr for 25w35a, the only thing I cannot get working is serializing an empty player head content with configurate (what would be represented as {"player":{}} in json). It doesn't seem to be possible to set a configuration node to empty or null, so we can't represent it that way. Workarounds I've thought of:

  • setting it to an empty string, which on deserialize gets interpreted as an empty name and that has the same effect when rendering the component
  • just leave it how it is, this will serialize only with the hat field and we could then check when deserializing if it contains hat && doesn't contain player to make empty contents

I've actually never used configurate so any input here would be greatly appreciated

raven sedge
#

you should be able to do a node.raw(Collections.emptyMap());

steep drum
steep drum
#

yeah setting to an empty map with #raw worked. I've tried it with #set before and that also works now, turns out the test I was using was faulty which made me believe it wouldn't work. Thank you!

past depot
wild crane
#

aren't you just ignoring asLocale there?

#

was that always ignored?

past depot
#

thats fair, my bad

wild crane
#

nw, that's what reviews are for hehe

spring gyro
#

@chilly summit do you think you will have time to finish your sprite tag PR soonish?

#

we also will probably want one for player heads but idk about the format without named args

chilly summit
spring gyro
#

it can be a separate PR anyways, but yeah idk

chilly summit
#

Okay so I checked the format of the player-type object component (which is hardly documented in the mc wiki). Basically from what I can tell, there are three relevant types: name, uuid, outer_head_layer (names are made up). There is also a properties field, but I could not figure out what one would put in there just yet, I would probably have to check client code for that.

But basing myself off of the latest three, the idea I have is as follows:
Since all three of these properties are optional, we could make it so that it attempts to parse it "smartly".

The tag always attempts to parse the current argument as a uuid, since that is the most specific type. If it does not succeed, it attempts to parse it as a name, if that hasn't been set yet. If either of the two has already been set, it will attempt to parse a boolean type for the outer layer rendering, resulting in the following, possible tags:

  • <head:'<uuid>'>
  • <head:'<name>'>
  • <head:'<name>','<uuid>'>
  • <head:'<uuid>','<name>'>
  • <head:'<uuid>':true|false>
  • <head:'<name>':true|false>
  • <head:'<name>','<uuid>':true|false>
  • <head:'<uuid>','<name>':true|false>

The outer layer toggle should always be the last argument and either name or uuid need to be provided or the tag throws an error. Arguments should not be present duplicate, meaning these should not be valid:

  • <head>
  • <head:true>
  • <head:true:'<name>'>
  • <head:'<uuid>':'<uuid>'>

How does that sound @spring gyro?

lavish monolith
#

Or, simpler (but maybe not better):
<head_name:'name':bool>
<head_uuid:'uuid':bool>

#

(With some variants tu allow both, but the idea being to split in two tags)

#

((At least))

chilly summit
#

I did think about that approach as well, but I think my approach is nicer for the end user

#

Which is more memorable and intuitive than head_name

lavish monolith
#

I agree, and surely my names were poorly chosen, and only the UUID one should be specific, idk. Similarly to lang and lang_or

steep drum
#

I think <head> should also be valid since {player:{}} is valid in vanilla

wild crane
#

what does vanilla render then? just a steve?

chilly summit
#

In that case it'd be valid, yeah. But if it doesn't render anything, I'd almost argue that we should devalidate it on our side to prevent accidents/unexpected behavior

lavish monolith
#

iirc yes it's a steve

#

or alex maybe it's random

chilly summit
#

In that case the empty tag should be valid, sure

wild crane
#

yeah sounds fine to me too

lavish monolith
flat ruin
#

Hello everyone! Are there guidelines for submitting PRs to adventure-platform? I searched in this discord and on github but haven't found anything, I just submitted one and was wondering if it was ok :D

chilly summit
wild crane
#

i dont think it's worth exposing, if you're typing entire base64 or head URLs into MiniMessage you're doing something wrong

wild crane
flat ruin
steep drum
lavish monolith
lavish monolith
#

And also someone should check this, but iirc with the new way profiles are managed by the game, when you give both player name and uuid, the texture won’t be automatically resolved (it will show a Steve or Alex skin). I know it is true for player heads item, but maybe it is also the case with head sprites. And if that is the case, I doubt we want to allow putting both in the MM tag, since without textures it would always lead to Steve / Alex

chilly summit
#

Or tbh I could just do it myself, I am not entirely clueless

latent bobcat
spring gyro
#

it does

#

if name.ispresent!=id.ispresent or properties is not empty, it is a static profile

chilly summit
#

Yeah okay in that case I will not allow for both name and uuid at once, just to avoid devs running into weird issues

chilly summit
#

Hm, slight problem: Since having both a name and an id is perfectly valid for the API-constructed PlayerHeadObjectContents object, how would I emit that as a tag if I do not want to allow for both of them in the tag itself? That would result in inconsistencies

#

I suppose I have to go with my original idea anyways, allowing both uuid and name

steep drum
#

I think it's probably unlikely that someone will make use of supplying both name and uuid anyways, so maybe just mentioning this behavior in the tags docs page or something will be fine

chilly summit
#

Eh, I really do not like such weird inconsistencies, even if they are minor

chilly summit
#

Okay we genuinely need named arguments, this is getting ridiculous.

I have almost 100 code of MM tag parsing logic in here just because of all of the extra-cases that are going on. It is definitely not a nice read and super unclean. Not a fan of my own code. I might be able to extract a bit of that into its own parts, but it is really not great

lavish monolith
#

Which is why we really need to be able to set the textures in a tag (but maybe another one), so we can properly serialize such components

chilly summit
#

(I already have that in btw)

lavish monolith
#

Nice

#

How did that turned out?

wild crane
chilly summit
#

My internet died

#

Cool

#

Pushing my changes

chilly summit
lavish monolith
#

Was just thinking, in fact there are 2 types of heads: static & dynamic. So it makes sense to create 2 tags, the simple dynamic form head (with either name or uuid, and the hat boolean), and the complete static form (maybe custom_head like suggested above) with all the parameters, each optional, but with an empty value instead of completely absent

lavish monolith
chilly summit
#

I mean, there is no distinction between those types in the component form

#

Anyways, a cheeky @spring gyro for feedback so that I can quickly get turned down if it is a horrible hack

#

I kinda like the way it works for the user, but it might be a bit too complex on the impl

#

btw I wrote up a paragraph on how it works kek

#

Oops I did not think it would turn out so big

spring gyro
#

that makes sense to me, it's a bit confusing, but when writing MM input it seems intuitive enough

#

anything better would need named args

lavish monolith
spring gyro
#

but won't be able to round trip a static profile with props

#

which I think is fine

lavish monolith
#

I think we're not talking about the same thing then

spring gyro
#

profile properties are not supported in this afaict

#

like I said

lavish monolith
#

But I need to have a look in-game first to make sure

#

ok yeah that was indeed what I was talking about

#

Which is why I think having 2 tags might help (one for static and another one for dynamic)

#

The static one would be able to handle the texture property

spring gyro
#

the texture override applies to static or dynamic profiles

lavish monolith
#

By "texture override" you mean the fallback texture?

spring gyro
#

no I mean the body texture override in the skin patch

chilly summit
# spring gyro anything better would need named args

Idk if I am leaning myself too far out of the window, but would it be okay if I would attempt to draft up a PR for named args? If so, what should the syntax look like anyways? Would we want it to work something like this <tag:name_one:SomeValue:name_two:AnotherValue>, <tag:name_one=SomeValue:name_two=AnotherValue>, or something entirely different?

#

Ofc a separate PR, but this might just be the push we needed to get around to implement named args

spring gyro
#

check the issue on adventure

#

I think it used something more xml like

chilly summit
#

Ah, didn't know it had an issue

#

ohh that's cool

#

yeah I like that a lot

candid solar
chilly summit
#

Looking at that one rn

#

That might involve heavy modifications into the token parser and what not, but that looks possible

lavish monolith
# spring gyro no I mean the body texture override in the skin patch

Ok it was not documented on the MC wiki yet, and got me confused. Yet, the textures property being the only one to do something in vanilla, and given its value only consist of the texture URL (with some wrapping), I think it would be nice to support it so doing a round-trip would result in the same visual

chilly summit
#

Before I go any further with my one-tag solution (or split it up into multiple, even if I am not a huge fan of that approach), I'd like to give named arguments a try

steep drum
#

it's probably best to split up the tags into separate prs then, I feel like named arguments may be a big enough pr that it might take some time to review

chilly summit
#

named args is its separate pr lol

steep drum
#

no I'm saying splitting <head> and <sprite>

chilly summit
#

I would never put that into the same PR, I do actually know how to do PRs kek

#

I don't think it matters? I am just gonna keep the no named args approach and once the named args goes through, I will switch the head tag

steep drum
#

I honestly havent looked at the head stuff yet, so I guess if that can be done cleanly with backwards compatibility its fine

chilly summit
#

Probably not™, but we'll figure something out

#

The PR is not merged, we will figure it out along the way, no need to rush things

wild crane
#

yes the plan for named args is that they are completely compatible with the numbers structure

#

and that the arguments provided are either/or a queue/named map

chilly summit
#

Yeah, I thought about the best way to do this, and I decided a completely separate interface NamedArgumentMap is the best go

#

Each tag kinda needs to keep track of whether it expects named or unnamed args now, which I guess is fine, but a bit annoying

warped fable
chilly summit
#

I am on it giggle

warped fable
#

does Kyori have an SVG version of it's logo?

chilly summit
#

Yesn't

warped fable
#

I only found the safari pin one

chilly summit
#

Somebody from the community made this a while ago

warped fable
#

hmm, but how is this with the license?

chilly summit
#

I actually have no idea. Tried asking around, but the results were rather unanswered

warped fable
#

yeah thats what bothers me

chilly summit
#

The only one who knows is riley

#

Ask him/ping him at your own discretion, I need to pull back as I've been rather bothersome to him lately

warped fable
chilly summit
#

(more specifically, the kyori logo in general)

#

The svg image is community made, not official

real salmon
#

I believe @vital iron made that SVG?

vital iron
#

Yes!

#

I did :)

warped fable
ancient vale
#

I can’t see the svg on mobile, which is it?

chilly summit
#

The same as the small kyori logo

vital iron
#

yeah thats definitely mine

#

i missed the drop shadow on one of the mountains otherwise its pretty accurate lul

ancient vale
#

Turbotailz made that Kyori logo back in October of 2020

warped fable
#

ic, so would it be fine for me to use this logo on an IntelliJ plugin I'm working on?

vital iron
#

as long as you have the right to use the logo (and i expect you do) you can use my SVG version, it has no license

warped fable
#

-# the plugin isn't published yet, because it's still missing some stuff, but syntax highlighting works

warm grotto
#

What does it do? I remember someone sharing a in code mm parsing plugin a few weeks ago.

chilly summit
#

The named args PR might actually take a few days, it seems to not be a small change considering that a lot is based on the assumption that tags are unnamed

#

I may or may not have underestimated it kek

vital iron
crisp portal
ancient vale
#

It’d be great to get an actual logo for Adventure itself done - Adventure isn’t a Kyori project anymore technically.

warm grotto
#

The logo looks like „adventure“

past depot
chilly summit
# chilly summit I may or may not have underestimated it <:kek:1331322252503027882>

Smol update post because those are always fun.

I have managed to modify the tokenizer to correctly parse named arguments now! They currently do not really do anything, as they are not hooked up yet, but it might not be as far off as I thought. I managed to not break the entire code base yet kek.

The changes required were smaller than I thought, ngl

chilly summit
chilly summit
#

I am trying to debug just one test method (in IntelliJ), but for some reason I am getting exceptions when doing so: https://pastes.dev/agQ4u2yA5o.
I tried to do this both on a semi-recent build of JBR 21 and on graalvm 24 (just to switch up jvm impl) but it always does the same error. What might be the cause?

#

Running the individual method without debug works just fine

lucid quarry
#

Sounds like something fired up the JVM using an unsupported java agent?

#

Well, I guess it's upset because it can't find a kotlin class, busted gradle install or something?

chilly summit
#

Idk, that would be the adventure gradle wrapper then

chilly summit
#

This is all I am doing though, so idk 🤷

#

💀 let me try that fix

#

I don't even have a Kotlin Data View kekhuh

#

Ah okay I fixed it. They changed the property

#

It is in the root Debugger settings and it is called Attach coroutine agent

lucid quarry
#

Yea, I just used the search lol

#

Looks like they have an issue or two attached on their thing, I wonder how reproducable that is

#

Nobody seems to be giving them what they need to start to investigate 😄

chilly summit
#

Yeah, well, thanks anyways

#

Now I can figure out why the parser's broken

lucid quarry
#

apparently not

chilly summit
#

It's passing HyperMiyanoSlamHyperMiyanoSlamHyperMiyanoSlam

warm grotto
#

@chilly summit are you on latest IntelliJ version?

chilly summit
#

I am on a relatively recent one, not fully latest

#

2025.2, built on August 1, 2025

warm grotto
#

The bug got fixed in 2025.2.1

chilly summit
#

Well, okay

#

Don't care, I am not having the bug anymore finger_guns_cool

warm grotto
#

👍🏻