#adventure-contrib

1 messages · Page 2 of 1

warm grotto
#

Just saying

#

I had the same bug when debugging a paper fork that’s why I knew about it.

chilly summit
#

Good to know though

chilly summit
#

Can anybody think of even more tests that I could put here in order to further tighten the wiggle room around named and unnamed (I called them queued arguments, because it is backed by a queue, but it doesn't really matter)? I am really uncreative what comes to tests: MiniMessageNamedArgumentsTest.java

spring gyro
#

I would call it sequential or linear rather than queued

chilly summit
#

I think sequential is nice

spring gyro
#

also maybe a test for <tag :arg> not parsing in addition to just <tag >

spring gyro
#

what do you think about supporting <tag !presence> to set something false

#

also that <styled> tag in the tests is neat, might be worth adding it as <style> or something to the defaults

#

(probably in a separate PR later)

#

click events and more complex stuff wouldn't fit but combining color and bold etc in one tag is nice

chilly summit
spring gyro
#

would need to ret a tristate instead

chilly summit
spring gyro
#

but since it's new API that's fine

chilly summit
#

I am currently doing some clean ups. It is 2am for me, so I will be doing that tomorrow

spring gyro
#

no rush, and nice work so far

chilly summit
#

Thanks MahiruHeart

spring gyro
#

get some sleep

chilly summit
#

I am honestly basically finished with this, dunno what else to really include in this

wild crane
#

incredibly cool work!!

#

I've got some time on Monday to give it a good review :D

chilly summit
#

Yay!

#

I am currently doing a separate PR as well for the <style> tag. I kinda thought of in the tests and jmp liked, which is helping me figure out some missing aspects, so that fits well

chilly summit
frail carbon
#

We have named arguments, til

#

To me that looks way more verbose and messy than just using the short hands from the existing tags

#

Like
<style color=#f00 b i u>Fancy
Vs
<#f00><b><i><u>Fancy

#

And your example is an extreme one

#

Oh I am just reading up now

chilly summit
#

The point is more on the named arguments and not on that one tag kek

chilly summit
#

Tbh even if we decide to not merge it, I might keep the tests, because those are kinda nice

torpid vector
#

Hi! I fixed a regression where 7b025cd caused plugins that relocate gson not to work anymore because the new code simply errored because platform gson didn't equal plugin gson. Previous code before the change took relocated gson properly into account. Please take a bit of your time to review and merge my PR, so that I am able to update advantrure in my plugin. https://github.com/KyoriPowered/adventure-platform/pull/229

GitHub
fix: use unrelocated gson for interacting with unrelocated APIs by ...

This fixes issues where plugins that relocate gson didn't work anymore because the previous changes in 7b025cd were not taking into account that some plugins might relocate gson.

chilly summit
#

@ jmp I have been thinking - should I maybe rebase the named args PR onto the unstable/4 branch just so I can properly rebase the head tag so that we do not have to wait for after named gets merged and you rebase your branch for the head migration to named

spring gyro
#

I think the unstable branch will likely be merged first so rebasing on it is not a bad idea

chilly summit
#

Alright

chilly summit
#

Right, so I now have the following setable properties for the head tag:

  • name
  • uuid
  • hat (show outer layer)
  • textures (a resourcepack key)

What other properties does the head tag need to have exposed?

warped fable
#

isnt that it?

chilly summit
#

That's what I am asking rn kek. There is technically also a way to set a full profile directly (so it does not have to be resolved), with skin url and all, but idk if we care about that, which is why I am asking

warped fable
#

well doesn't the client resolve the profile themselves now?

chilly summit
#

Again, you can just pass the whole profile and the client would not resolve it themselves

warped fable
#

ah

#

hmm, I think since resolving the profile is usually done programmatically anyway, I don't see why people would use the Component if they choose to do it that way

chilly summit
#

Anyways, I have finished migrating #1304 to the unstable/4 branch and even managed to find something I had forgotten to add previously. Furthermore #1305 now uses named arguments, so you can define a head tag like this: ```xml
<head name=Strokkur24 !hat>

lavish monolith
#

I don't think any of the other properties (except hat boolean) matters in that case also

#

So it may be another tag

chilly summit
#

Yeah I thought of that as well

#

No need to put it in a separate tag, since named arguments exist

#

Can just early return

lavish monolith
#

Well, yeah

chilly summit
#

Also I might just do more adventure contributions, these are really fun

#

Maybe the color registry, that sounds like a fun one

frail carbon
#

I am really not sure if I like named params, they are so verbose

chilly summit
#

The issue stems from if you want highly dynamic arguments

real salmon
#

does it have a way to insert just the textures base64?

frail carbon
chilly summit
#

Yes, we do

lavish monolith
wild crane
chilly summit
#

It works wonderfully for the end user, but is horrendous to maintain

lavish monolith
#

With Mojang adding more and more options and configuration for components (which is really nice), yes I think named args makes a lot of sense

wild crane
#

im not sold on adding the style tag but we def need it for the head one

frail carbon
#

Just sharing my perspective of somebody who barely keeps up with stuff and hasn't personally used MiniMessage in half a decade

lavish monolith
#

Idk about the style tag, I guess it's would sound cool for some users, and others might not see the point of it. It really depends how technical the user is

frail carbon
#

I trust you guys to steward the project, lol

wild crane
#

yea, ive got use cases for named arguments in projects i work on

#

i think the biggest part of it is flags actually

lavish monolith
#

Plus, the way named args are implemented allows flags, which is awesome

frail carbon
#

Flags I understand

#

The verboseness of spelling out the param name is what looks iffy to me, but again, I don't need to use this, my opinion is not worth much

warped fable
#

well from what I understand both styles of arguments will exist side by side

#

so you do have a choice still

lavish monolith
#

I've seen only examples of full named tho

frail carbon
#

Oh, so it's like in kotlin? You can use the default order with the existing : syntax but if you wanna skip stuff or be verbose you spell out the names? Thats super fine then

lavish monolith
#

How would named args and anonymous args co-exists?

wild crane
#

no it isn't actually, although i do think it potentially should be

#

although i dont see that working in practice with e.g. the head tag

warped fable
wild crane
#

id give the pr a look over before getting involved in the debate haha

warped fable
#

-# I didn't actually check any code, I just assumed it was implemented this way to allow old mm strings to still work

frail carbon
#

I just have opinions, I never said they are informed kekwhyper

chilly summit
#

If you decide against it, I'd love to keep the tests

wild crane
#

yeah for sure, v good example/test case at least

frail carbon
#

It doesn't hurt to keep, people don't need to use it

chilly summit
# frail carbon Oh, so it's like in kotlin? You can use the default order with the existing : sy...

Yeah it looks if the first argument is annotated as a sequenced (with : syntax) and then sets a parser flag that this tag will be parsed fully sequentially (the old way). If the first argument is a named/flagged one (with a whitespace), it sets a parser flag that the rest of the tag should be parsed with named ones, so : is interpreted literally.

It also allows for tag resolvers for both to exists. So you can have a sequential and a named tag resolver for the same tag name. If no arguments are present, it will prefer the sequential, if named args are present, it uses the name, if sequential, it uses the sequential

chilly summit
warped fable
wild crane
#

actually very impressed with this pr, not that im surprised or anything just that it's really well done

#

i think you kinda cooked here strokkur

warped fable
#

🧑‍🍳

chilly summit
#

That means the world to me

warped fable
#

how do lists work? e.g. for gradients?

chilly summit
#

Old syntax lol

warped fable
#

ahh

wild crane
#

they dont, i dont think we need to reinvent the wheel here either

warped fable
#

so have you considered adding an implementation for something like hover tag?

wild crane
#

why?

warped fable
#

lots of args

wild crane
#

they're all required tho

warped fable
#

not all?

wild crane
#

named tags is better for lots of optional parts

chilly summit
#

Yeah, the named args are mostly powerful with optional arguments

#

Or, well, flags

wild crane
#

yeah

chilly summit
#

Btw, Kezz, could you elaborate on what you mean by default null impl and breaking change?

warped fable
#

but now that I think of it, the way hover works, sequential is better

chilly summit
#

OHHH WAIT nvm I got it

wild crane
#

yeee

chilly summit
#

Dw Kezz I figured it out

wild crane
#

happy to help :p

chilly summit
#

If somebody implements the TagResolver themselves, it, well, uh, kinda does not compile their code anymore

#

Nice catch!

wild crane
#

tbh i wouldnt be against making both of those resolve methods default impls that return null

#

and then having the TagResolver.Sequential/Named ones override without a default impl (is that possible?)

chilly summit
#

I think so?

#

Gimme a sec

wild crane
#

that's similar to how we did it in the translation rendering stuff

chilly summit
#

Oh yeah totally possible

#

Pushed a commit for that 👍

#

Actually, I think I will rebase the named args branch back to main/4. I can keep the commits on the head tag branch so that it compiles, but it technically has nothing to do with the unstable/4

#

It is technically its independent thing

#

@wild crane don't merge it in case you were about to

wild crane
#

yeah dw not gonna merge yet

chilly summit
#

Good, because I was about to force push and that would've been awkward kekw

wild crane
#

would like another eye or two on the pr as a whole but it does lgtm

chilly summit
#

I am sure we can get jmp to review it as well

#

(ahh, fucked things up, nvm that main/4 switch xd, we're staying on unstable/4)

wild crane
#

im gonna pull the style tag out of the 4.25 milestone so we can think about it a bit more

chilly summit
spring gyro
chilly summit
#

What is all required for the profile to work correctly

spring gyro
#

if you pass props then it's a static profile

#

i.e. it will keep the same skin even if the origin player changes their skin

#

thats how you would pass the base64 texture (it's a property)

#

not sure what the tag format would be but I can imagine someone using it in a config

chilly summit
#

Maybe we want to allow setting the deserialized values and then serialize it to base64 manually?

spring gyro
#

I think that would make the syntax even more complicated

#

how would we want to handle list input for a named arg anyway

chilly summit
#

Yeah so that's the thing, idk

#

I mean, we could add syntax like this ```xml
<tag value=[hey, what is going, goodbye]>

spring gyro
#

well, the main benefit is that the parser would handle quoting and escaping

chilly summit
#

Idk, what do you think? Your pick

spring gyro
#

idk, probably better to wait for some more opinions

#

since adding that wouldn't be breaking

chilly summit
#

at this point we can extend the named args syntax as much as we want

spring gyro
#

<tag value=[hey, 'what, is going', "name=textures value='ABSBAHDJFvsvds=='"]> 🤔

#

(the idea there is maybe could expose the argument reader for arbitrary strings to allow nested objects without abusing gson or writing a bunch of manual parsing code...)

chilly summit
#

yeah that's what I think could be cool as well

#

how do we differentiate objects from arrays though>

spring gyro
#

you could just always interpret as an array and then stringify if it's retrieved via the non-list method

chilly summit
#

Maybe we just go the full json-y route and do [] for arrays and {} for objects with named args

chilly summit
spring gyro
#

I just meant for when the value is surrounded by []

spring gyro
chilly summit
#

So it'd be ```xml
<tag value=[hey, 'what, is going', {name=textures value=ABSBAHDJFvsvds==}]>

#

Which, I mean, it feels very jsony, but that's fine I suppose

spring gyro
#

I like it

chilly summit
#

That's gonna be fun to implement crythumbsup

spring gyro
#

don't start on it yet

#

@wild crane thoughts on above?

chilly summit
#

If I do push that through, I request a big fat shoutout kek

warped fable
#

@chilly summit if all you need to pass for head is a list for properties why not use sequentual parsing?

spring gyro
#

you will already get one in the release for named args omegaroll

#

if we add this syntax it may be better for 4.26

#

(if the goal is to get 4.25 out in the coming days)

wild crane
spring gyro
#

thats a different textures than the arg

wild crane
#

yes sorry then properties at the end right?

#

so it's sequential somehow

#

or we just say too bad you just can't do this in mm

#

keep the nice head tag

chilly summit
#

we can do one sequential tag only for textures and one named for the nice looking ones

#

after all, you can have the same name for tags of sequential and named types

spring gyro
#

I don't think that really makes sense with the variety of valid objects

#

if we want a simple version and a complex version, <head:name|uuid> and <head name id texture hat properties(object list)>

#

is my vote

#

a dynamic head from just a name or id is probably the most common case

#

then the named args lets you represent anything

#

without hard to read sequential args

chilly summit
#

Yeah that is perfectly valid

warped fable
#

I'm still on the <head name id textures hat> and <head:properties...> train

spring gyro
#

and textures should

chilly summit
#

But I do like adding complex object and array support

wild crane
#

i just think that might be so icky

#

and nobody is ever gonna use it realistically

spring gyro
#

we can leave out properties(object list) for 4.25 for sure

#

but I still like those two I mentioned for the sequential/named variants

chilly summit
#

yeah we can do that

warped fable
#

can I just ask, Its probably a dumb question, but why would you need the properties value if the textures can be set via a different argument

spring gyro
#

they are not the same thing at all

#

one is the textures PlayerProfile property, one is the texture override in the ResolvableProfile SkinPatch

#

player skin vs texture location

warped fable
#

I see, thanks

spring gyro
#

once we get paper publishing fixed the ResolvableProfile & inner classes javadoc should explain it

chilly summit
#

Right, so I keep everything as I have it, just that I add another sequenced tag purely for the <head:name|uuid:hat> shortcut? Or do we even want to leave out the hat one here?

spring gyro
#

the PlayerHeadObjectContents is kind of a stripped down version of a ResolvableProfile that is strictly for creating components (for display, not data storage or etc)

spring gyro
#

but yes I think we should leave off the hat, a random bool is kind of trash when we have hat and !hat

chilly summit
#

Yeah true. And yes, I think the texture can lack a /, but realistically that is not going to happen

#

Since that would require somebody to put it onto the top-level asset folder, which is stupid

spring gyro
#

I think that's a reasonable assumption then since you can be explicit if you need to

chilly summit
#

Anyways, would you be so kind as to review the named args PR? Kezz already took a look. It might just be mergable if you check it and nothing looks out of order

spring gyro
#

soon tm

chilly summit
#

Oh no, conflicts sadge

#

Urgh, this is awkward

#

Eh, I will resolve those when named is merged. No point in worrying about it right now anyways

lavish monolith
#

Just to share my thought, I think the only relevant profile property here is the textures one (and inside it, only the textures URL matters). This should reduce the problem to a single argument, not a list or a map

chilly summit
#

What about the signature?

lavish monolith
#

It isn't required when unsigned=false isn't present

#

(Which is the case by default, it isn't present)

#

I mean, it's inside the textures property object that you say if it's signed or not, so we just have to say it's not and boom, no signature required

#

(I guess this is only useful for, you know, player skin reporting)

chilly summit
#

Which we don't care about for head object components. I'd like @spring gyro's opinion on this though ^^

lavish monolith
#

The base64-encoded value field only requires {"textures":{"SKIN":{"url":"<URL_HERE>"}}} to display correctly the head

#

Plus, the textures URL must point to Mojang's server, so we might even strip the beginning of it (but I would argue against, as most tools provides the full textures URL)

#

Technically, the only REAL un-computable payload of all this is 7fd9ba42a7c81eeea22f1524271ae85a8e045ce0af5a6ae16c6406ae917e68b5

chilly summit
#

We could do some custom handling for that tbh

#

Full URL or the unique part

lavish monolith
#

Why not, I think tho there might be 2 servers, and idk if one redirects on the other

#

org or com

#

But as I can't find any piece of information about this (the other (older/legacy/deprecated?) domain, it may be wrong

spring gyro
chilly summit
#

👍

real salmon
#

What's the unstable/4 branch for?

chilly summit
slate walrus
#

Is there a dialog API planned?

lavish monolith
#

It depends on what you expect by "planned"

#

There will be one, yes

#

It's not currently in development, because that stuff is fairly recent and was really unstable when it came out (a lot changed quickly)

deft stirrup
#

Has it been decided that v5 will target JDK 25; or are you waiting for the 1.22 drop that will update it to 25?

frail carbon
#

Adventures java requirement isn't tied to Minecraft

deft stirrup
#

Id assume you wouldnt jump ahead of Minecraft though

frail carbon
#

That's unlikely, ye

#

But fwiw paper has done that in the past

raven sedge
#

ya no

#

I think it was between 17 and 21

lucid quarry
#

I don't really see there being any drive to jump to versions which aren't the primary version used by the current community, all it would do is create issues and headaches for little gain

chilly summit
#

I was surprised how many modern language features I use in my code. Java 8 in the adventure codebase is devious lmao

ancient vale
#

adventure has been around since 2017 when java 8 was the latest version released

chilly summit
#

From 8 to 25 in just 8 years, we've come a long way

warped fable
#

<@&748618676189528155>

#

ah okay

warm grotto
spring gyro
#

@chilly summit just fyi gh auto closed the head tag PR when I merged unstable

chilly summit
#

Yeah I know, I am just waiting for named to be merged to repoen it

#

I would've had to do a bunch of git magic anyways

spring gyro
#

ok just making sure you knew

chilly summit
#

On a side note, I have started work on adding registerable colors to adventure. Idk how that is going to turn out considering a lot of TextColor and NamedTextColor logic is interwoven into each other and also kinda dependent on each other, but that's fun I guess

high mortar
#

What would that use case be? Plugins messing with other plugins' tags in minimessage deserialization?

chilly summit
#

Gradients

high mortar
#

And how would you handle one plugin registering elbow as a color and another plugin wanting to use a elbow placeholder?
edit: Changed color to address concern.

chilly summit
#

Can we please not use that as an example color

#

Basically, colors are second-rank placeholders. Taking an example <copper>, if it is registered globally, it would work as any normal tag+be recognized by the gradient tag (and be accessible through normal means in the API as well, wherever you can get a NamedTextColor). As soon as a specific tag resolver for <copper> exists, it overrides the color resolver

#

The color itself still continues to exist though

lavish monolith
#

And what about 2 plugins registering the same color? Are they namespaced?

#

(Of course I mean same name with a different color)

chilly summit
#

Yes, <minecraft:red> for example would explicitly point to the default red. But I am still figuring out a nice way to register colors, because for once I want to have the things be immutable, but I also want some way for plugins to register global new colors which can be used by other plugins as well. Mutability is also kinda annoying, like imagine you start parsing some string, and in the middle of it another plugin registers a new colors which are, and it then suddenly adds the colors in the middle of the tag resolver resolving and it just turns into a mess

#

Idk, I will figure something out along the way, that's how I always do it and it tends to work out fine

near swift
lucid quarry
#

implementing an entire lifecycle thing for adventure just sounds crazy, but, also wouldn't solve too much given the platform lifecycle matters more

frail carbon
#

Stuff would just be registered into the plugins MiniMessage instance? No need to try to make it globally and namespaced and all kinda complicated

real salmon
#

wasn’t there a plan for namespaced placeholders?

lavish monolith
wild crane
#

I've had another look over everything and I'm happy for 4.25.0 to go - @raven sedge do you want to look over anything (maybe the named argument PR specifically?) or are you happy for me to push everything?

lavish monolith
chilly summit
# frail carbon Stuff would just be registered into the plugins MiniMessage instance? No need to...

Registering into the plugin's MM instance via service loading or something might be possible and therefore disregarding any global state. But what about a scenario where a plugin uses another plugin's API and passes a NamedTextColor, which the other plugin cannot work with, as it does not exist. We could also just ignore the existence of NamedTextColor have custom registered colors just be normal TextColors in a map and all of the "named" stuff simply happens on the MM instance

crisp portal
#

I don't think there's many plugins out there making placeholders/colors for use to other plugins, so the latter sounds fine

high mortar
#

There is the mini placeholder plugin, but it could probably handle registration itself

crisp portal
#

besides, if they were to try and do that, they could just expose the TagResolver for others to register on their own instance

high mortar
#

I fear the chaos of a global registry

crisp portal
#

I don't think it should be too much of an issue as long as registration is the only thing that's allowed

high mortar
#

From the plugin support side, I'd be worried about users getting upset when their configured colors don't work because some other plugin is automatically silently registering the same name.

crisp portal
#

well, that's a thing for namespaced placeholders to solve, though I don't love the idea of enforcing namespaces

high mortar
#

(adding clarity; I mean plugin A configured to add global entries. User upset plugin B isn't getting the expected colors because plugin C is silently adding different ones of same name)

#

Yeah, name spacing would really mess with the user experience. I really really dislike that.

crisp portal
#

one could also just add isRegistered method on the MM instance so that plugins can at least do some error handling in cases like you mention (not that they couldn't with the existing methods, it'd just be easier to have a method specifically for that so consumers of the API don't get lost)

high mortar
#

If A registered first and C silently replaced them, that wouldn't solve it. And locking the registration to first come first served and exception on attempt is yuck

crisp portal
#

One would hope they all just use their own instance if it comes down to adding user-configurable colors

high mortar
#

Yep. My worries are about a global registry.

crisp portal
#

it'd be good to figure out a way to enforce that kind of behavior, like only allowing static names to be registered on the global registry

#

I guess it does get a bit convoluted the more one thinks about it so I don't see much worth on it, per-instance modification could be done first and then global registration be looked over if it is something desirable to people

near swift
#

Its just a idea

chilly summit
#

As a side note: I am happy with my custom colors impl now: adventure#1311. I have decided to discard any weird global-mutability, as frankly, it would just be a mess both for users and for the implementation. I have some minimal tests, and there it works fine. If somebody more knowledgable in the inner workings of color parsing could take a look, I'd appreciate it, but from my observations, it works perfectly fine in normal MiniMessage <mycolor>, as a gradient tag argument <gradient:red:mycolor> and in the transition tag <transition:acustom:andanothercustom:0.6>. I've also implemented aliases as a nice way to provide general color aliases, also for <grey> and <dark_gray>, which is neat I think.

#

I am open to implementing some global registry as well, if I see interest from the adventure dev team in that matter (CC: Kezz/zml), but I will not put any effort into something which might get disregarded later anyways

deft stirrup
#

When is adventure getting released for 1.21.9?

desert kraken
#

yes

flat zincBOT
deft stirrup
warm grotto
#

Well it’s coming when it’s coming

#

Simple as that

near swift
#

The adventure-text-feature-pagination artifact got removed from central. Is this already known ?

real salmon
#

don’t think that ever was on a release was it?

near swift
real salmon
#

it’s a snapshot

wild crane
#

It's never had a release

real salmon
#

(new?) sonatype snapshot repo only keeps builds for 90d iirc

near swift
#

Yeah it was a snapshot but now its not longer publlished

real salmon
#

becuase of what I said

near swift
spring gyro
#

if you want it you should publish it to your own repo or copy the code in tree

near swift
spring gyro
#

what

warped fable
warped fable
#

I've got one, will create a PR

warped fable
#

I kindly ask for some discussion on the comment I made on the PR due to two possible solutions.

flat ruin
stark basalt
#

Doubt it, legacy format is uh, not very much a thing we'd wanna like define further I don't think?

flat ruin
#

I'm trying to move away from it but still use it in some places unfortunately

flat ruin
stark basalt
#

Well, I think it isn't so much about like not bugfixing in the legacy serialiser

#

but legacy as a format has very much always been a "Try to represent the actual visual output somehow"

#

Like, the legacy format was never intended to maintain a components internal format or layout, but rather to just describe the visual result

flat ruin
#

Mmhh I didn't know that, so I'm guessing it would be better to make a separate serializer to be used when the format must be kept as-is

stark basalt
#

Well

#

legacy by definition cannot do that

flat ruin
#

Not for any format, just simple cases like serializing text("").color(NamedTextColor.RED); to &c

stark basalt
#

Yea but like

#

You are just making up new formats now if that makes sense

#

Like, obviously you are free to create such a serializer, but I don't think adventure cares to include it

#

Its the kind of change that feels subjective to a format that in its entirety is just subjective

#

So the current vibe is kinda "keep how it works now, don't touch things that are not obvious bugs and let it sit there"

#

And yea, as zml said, adding more opinionated config options to a set of tooling that we already consider legacy is just a non goal

frail carbon
#

Any time spent to make the legacy format work can much better be spent on removing legacy usage

flat ruin
#

Makes sense :), the only thing that keeps bothering me is that the reverse &c to text("").color(NamedTextColor.RED); works, but I guess that's intended then

frail carbon
#

The legacy serializer is lossy because the format is dum and can't represent everything anyways, so the goal always was just visual equality

high mortar
#

Expecting compatibility with a format that was replaced 12 years ago is unrealistic.

flat ruin
flat ruin
high mortar
#

That said, I have a plugin that still has TONS of legacy usage, because it's just really really large. I migrate things when I have time. One of the important changes I made for a major release was renaming every legacy method to end in Legacy, deprecating all of them with 'forRemoval', and ensuring any public-facing stuff also had a Component getter.

lucid quarry
#

The legacy formatter is basically aiming to retain some level of weird middle of the road support for the various other legacy formatters; afaik it's generally in the point that we're as happy with it as we will be without breaking in one direction or the other

#

if this is a personal need, you could always basically repackage the thing for your own usage

flat ruin
#

Yep I've done that, just thought it might have been worth trying to fix it for everyone (it basically causes a tiny issue for plugins using packetevents when sending team packets to super old clients < 1.12, I've seen other people working around the problem by adding a character in the component and then stripping it after getting the serialized string back)

#

So yeah, outdated stuff

wild crane
#

To put it more concretely, it's not a goal of the legacy serialiser to work as anything other than a) a means to one-time migrate data, or b) serialize text in the tiny number of remaining places where components aren't supported

#

As your feature request does not hit either of those two areas, it's not something we want to spend time on

#

Your request is to allow it to work as a style serializer, which wouldn't be good design even back in the day when legacy was all we had

flat ruin
# wild crane Your request is to allow it to work as a style serializer, which wouldn't be goo...

That's basically it, for old versions there are use cases for that (mainly team prefixes which were used to "color" nametags, since unfortunately older versions don't use the team color even though it exists both at the protocol level and in the client), though I get that's not one of the goals (because of bleedthrough not really being a thing in modern versions, thankfully I'd say :D)

median hull
wild crane
#

I won't be able to have time to give it a look over until Adventure 5 is out, but it's on my list!

median hull
#

Okay great! I'm in no rush. and having the java features I am used to would be wonderful 😌
How far out would you say adventure 5 is?

steep drum
wild crane
#

Aiming to have snapshots out by today/early next week

steep drum
#

Speaking of adventure 5, can we maybe revisit adding Font. I would propose making it extend Keyed and changing StyleSetter#font(Key) to accept a Keyed, that should maintain backwards compatibility since Key also extends Keyed

wild crane
#

I think it's in the 5.0.0 milestone no?

#

Current plan is refactor and then new features

chilly summit
#

Speaking of which

#

Kezz, should I keep the named args PR and my named colors PR on the /4 branch or should I rebase them to /5?

#

It seems /5 is going forward much quicker than expected

steep drum
raven sedge
#

I think we can say v4 is feature complete

steep drum
#

I think i saw it mentioned somewhere for 5.0.0 but I couldnt find it anymore

raven sedge
#

there's going to be one more release with any deprecations/small adds for migrating to v5 but that's it

wild crane
#

@slender moat i'm messing about with ClickEvent for adventure 5.0 and im currently experimenting with making ClickEvent.Action a sealed interface instead of an enum

would appreciate your thoughts in regards to your recent gh issue and our surrounding discussion!

#

(open to anyone else who has thoughts!)

dawn python
#

looks slightly better I think but seems to still require a switch on the action? Why not just have a method like <T extends Payload> ClickEvent#clickEvent(Action<T> action, T payload)

#

or is that basically what line 103 in ClickTag is?

#

(I like the overall approach which moves it away from the enum though)

wild crane
#

but you'd need to switch on the action anyway unless you're unsafe casting or whatnot

dawn python
#

true I guess but that might be at a different place/in a different method than when the ClickEvent itself is created

wild crane
#

yeah for sure - so i couldve used that method on line 103 everywhere but it's basically the same difference on the more specific click events

worthy mesa
#

An approach like that makes sense for e.g. Paper not adding Mixins/bundling NBT in my opinion as it's a higher level API, but for adventure-nbt, NBT is basically an implementation detail on its own - a decent bit of use cases for an NBT lib would be low level stuff like working with packets/file storage, wanting to serialize/deserialize/have custom handling of your own for NBT, etc., don't think it makes sense to hide that away in a library for something inherently low level already; maybe document that you should generally avoid this or something, but not hide completely.

If you still prefer to avoid that I respect your decision ofc and will use reflection I guess, but would appreciate it if you could reconsider.

#

(Which is the same sort of use-case that made me PR it in the first place, as I migrated to adventure-nbt from an older lib and ended up using reflection for that)

wild crane
worthy mesa
wild crane
#

tbh i think it's a bit of a non-goal to allow writing custom serializers

#

is it not possible for you to use the serializers we provide?

worthy mesa
#

Well, what we have has already been in use for years, we can't really change it - But I'm not saying it should have full on custom serializer implementations, just this method to enable such usage for people who need it

#

I have to say though, I really don't get the argument against exposing this, NBT is already a low level thing & anyone that's using it is likely working with internals, packets, NBT files, etc. directly, it's basically all one big implementation detail for Minecraft itself.
It makes sense as a design goal for Paper/Adventure text in my opinion, but NBT is low-level/working with an implementation detail regardless in most cases, no one is (or should be, at least) using it and expecting multi-version compatibility or anything

chilly summit
#

Btw is there any interest in having a tag in the standard MM tags which formats text like this (picture taken from #adventure-help) https://cdn.discordapp.com/attachments/1342377752774443008/1427818432619090080/vcEiQ9z.png?ex=68f03f09&is=68eeed89&hm=575d9cd981737a1c3200833bb38e3d49c39ed66985e35f569b740fb580952bd8& ?

I often see this in a lot of servers, usually when doing some season-specific text, like red/white/green for christmas. Maybe a tag <sequential> could be good?

<sequential:red:white:green><b>CHRISTMAS TIME
warped fable
#

I've talked with kezz about step before and they thought it's a cool idea, but is problematic when it comes to MM tags (since gradients and rainbow have very unique approach to args)

#

Here is my custom algorithm for rainbow gradient with step of 1

image.png
chilly summit
#

The more reason to have it in the standard tags is it is hard to achieve

warped fable
#

IMO step is very beneficial as it allows more variations not just step of 1 (1 char is gradient color, the next char is the next specified color etc.)

chilly summit
#

And if it is truly that painful, I feel like a smol rewrite in the internal parsing logic to allow for complex color modifying/complex post-process tags would also not be a bad idea giggle

warped fable
median hull
#

as the problem is the unknown amount of colors in the sequential args I guess?

wild crane
#

my biggest issue with it is that it's ugly and idk if there's any colour combinations which would look pretty

warped fable
warped fable
median hull
#

I dont know that halloween example might be objectively ugly

warped fable
#

again, it's very subjective, while we may not like it, someone may like it. While the example is poor it can be used to make nice stuff

wild crane
#

got some examples?

latent bobcat
#

personally i see switching colours so abruptly on each individual letter is pretty harsh to the eye, i found that text very difficult to read and i didn't realise it was halloween themed as it was too distracting lol, if it was a colour per word that'd be a different story

median hull
#

Yeah a step value of 1 is pretty crazy. But I imagine most people would set it higher

#

something like this is a lot more readable

image.png
wild crane
#

i mean yeah if you made it into a gradient it becomes a lot nicer :p

lavish monolith
#

I think their point was this

#

It doesn't make much sense to add a "sequential" tag, because it doesn't looks good in most cases, but rather improve the gradient tag by adding the "step" argument

wild crane
#

Yep I agree

lavish monolith
#

A value of step=1 being equivalent to sequential, if anyone REALLY wanted that

warped fable
#

but the problem is where to put the arg in MM

chilly summit
#

In that case yeah wait for my named args. I have some pending changes which will improve them further syntax wise and then one that is merged you can implement it in your PR

worthy mesa
#

If not then I understand, thanks for going over all of my PR spam either way haha - would appreciate it if you could give it another thought considering the points above though

gaunt spruce
#

What’s gonna be new with 5.0 if I may ask?

median hull
wild crane
ancient vale
#

@wild crane

Boss bar progress has been removed.
This includes the max/min progress constants and methods to change/get the progress. You should instead be using the percent constants/methods.

#

you have this reversed

#

percent was removed, progress should be used

latent sandal
#

A problem with the module-level NullMarked annotations is that Kotlin completely ignores them.

image.png
chilly summit
#

Report it to JetBrains/IntelliJ lol

ancient vale
#

wheeeee

spring gyro
#

when are we rewriting it in svelte

ancient vale
spring gyro
wild crane
#

You might get some complaints as it sets a global default, but people can override the default in any flatteners they make

#

actually let's be honest nobody is making custom flatteners

spring gyro
#

I have a custom listener for my html serializer

#

but I don't think it would care about this

wild crane
#

yes flatteners

spring gyro
#

thanks

ancient vale
#

@raven sedge

raven sedge
#

now will you let me out so i can have a snack?

ancient vale
raven sedge
#

rattles bars of her cage

chilly summit
warped fable
#

Does this mean future packages will be kyori or paper?

chilly summit
#

There is no desire to change the package

#

At least not for 5.x. Don't know about the future

#

But it is stated as a non-goal for 5.x to change the package

acoustic pasture
#

Changing the package would be so incredibly unnecessary
Even If paper would add bytecode rewriting for that it would still be a huge breaking change without any benefit

#

Not even speaking of other platforms

wild crane
#

No plan to change the package

deft stirrup
#

why is adventure moving its null marked into packages?

#

is it cause of kotlin support?

lucid quarry
#

From what I've seen, yes

wild crane
deft stirrup
#

I wouldnt think that would be an issue since null marked annotations are mostly an ide thing

flat ruin
#

kotlin reads jspecify annotations

wild crane
#

if your ide isn't consuming it as a module then it wouldn't count, and also it seems some IDEs like eclipse struggles with module annotations

wild crane
#

which kotlin doesn't care about

flat ruin
#

yeah I saw the commit ^^

frail carbon
#

It's basically yet another jpms L

deft stirrup
#

Should any new prs for adventure be based on v5 or not

deft stirrup
nimble craneBOT
wild crane
chilly summit
#

We might be cooked

image.png
acoustic pasture
#

the gson module is called com.google.gson i think

chilly summit
#

We had an outdated gson version

acoustic pasture
#

or inside com.google.common? idk

chilly summit
#

I fixed it already

acoustic pasture
#

nice

chilly summit
#

It's com.google.gson though

acoustic pasture
#

what i thought

chilly summit
deft stirrup
#

Any reason that for the action change you just didnt merge the payload into the action?

#

so you could just switch over the clickevent/action and get the payload?

#

Also actions no longer expose the name directly, instead it has to be toString is that intentional?

#

That would also remove the generics that were added cause of this

wild crane
wild crane
wild crane
#

Just an fyi to everyone following, initial 5.0 snapshots are now live! It's not fully complete yet, there's still a few hefty changes we want to make, but any testing/bugs/issues would be greatly appreciated!

acoustic pasture
#

what is the reason behind having methods for each primitive representation of a number in Component#text
why not a simple Number parameter?

#

all of them just convert to string anyway

warped fable
#

I'd assume because primitives are faster

wild crane
#

it's just nicer api

latent bobcat
#

is it tho?

dawn python
#

having to convert all your int to an Integer would be annoying af

latent bobcat
#

i mean, you don't have to?

warped fable
dawn python
#

since when?

lavish monolith
#

It seems personal whether its "nicer" or not

latent bobcat
#

since, like, java 5 ?

dawn python
#

TIL

latent bobcat
#

autoboxing is a thing

dawn python
#

guess I should've learned Java at some point in the last 15 years lmao

latent bobcat
#

not subjectively

wild crane
#

yea

#

ig i could just remove them too

#

idk, i dont really think it's worth the effort thinking about it

lavish monolith
#

To me, it seems kinda unnecessary/redondent to have all those methods, and even one with a Number arg wouldn't be really needed imo, because components are mainly used for text, and doing Integer.toString(n) or even "" + n would work the same

patent pivot
wild crane
#

Yes 21 is our target atm

#

i don't see us going up to 25

#

or 24 or whatever the other lts is

lavish monolith
#

Java 25 is the latest LTS
-# Other LTS are 8, 11, 17, 21

patent pivot
deft stirrup
sleek plover
lavish monolith
#

It still duplicates all text methods

wild crane
#

also bear in mind it's a non-goal of 5.x to do breaking changes that aren't simple e.g. removing deprecations

lavish monolith
#

(This is less duplication that having one overload for each of int, long, float, double, but all of those (plus boolean and char ones) doesn't provide anything really new or hard to achieve or more optimized)

#

Of course, but I don't think we're talking about removing them now in v5, but maybe consider deprecating them for future removal?

deft stirrup
#

cause you can translate between the two

wild crane
#

could you provide some example code as to what you're thinking about?

#

possible im just not seeing the vision

deft stirrup
#

It basically consists of using multiple implementations of ClickEvent instead of a generic impl, but i can make an example

wild crane
#

oh i see

#

im not sure what benefits that would have

deft stirrup
frigid kiln
wild crane
deft stirrup
wild crane
#

yeah

crisp portal
#

funny how v5 is around the corner and it brings up discussions for v6 already lol

wild crane
#

so if you just had click event and no action, you'd have to be pretty messy with switching on string names or smth

#

we could do typed click event, typed action and no payload - but atp we're not really saving any complexity

deft stirrup
wild crane
#

in fact even without payload existing you'd need more work there too

#

i think imo as the user facing api would basically be the same, but we'd be making it harder for serializers, i don't see the benefit

deft stirrup
#

it would make it harder to read but gives guarantees while writing

#

arent components a similar pattern too?

chilly summit
#

@warped fable regarding your issue #1315, I wanted to kinda ask what your expectations are to what it would parse.

Does this mean that you expect ```rb
hover:show_text:'test\'Hello!

To do the same as ```rb
Component.text(
  "Hello!",
  Style.empty().hoverEvent(Component.text("'test'"))
);

Similarly, do you expect ```rb
hover:show_text:t\"est\"Hello!

To parse to ```rb
Component.text(
  "Hello!",
  Style.empty().hoverEvent(Component.text("t\\\"est\\\""))
);

Or something else? This is really hard to figure out from your issue 9800_MonikaShrug

#

Because if this is indeed the case, then my named arguments PR already changes the logic to do exactly that ^^

warped fable
# chilly summit <@1168960618074747001> regarding your issue [#1315](<https://github.com/PaperMC/...

Well my personal opinion is it should be considered as an incomplete string and 'test\' should be passed literally to 'test\'
and t\"est\" should also be parsed literally to t\"est\".

The problem I found is that the first parse shoots itself into the foot, essentially gaslighting itself that the string ends (which it doesn't since it's escaped)

Now how this should be parsed is not really something I decide and should be ideally decided by someone like @grizzled spruce, @wild crane or @raven sedge

grizzled spruce
#

I just wrote the parser, I don't make the decisions on how the parser should behave

warped fable
#

ic

grizzled spruce
#

That wasn't a test case that I designed for, at the very least. But if the new PR fixes it then cool

chilly summit
#

Yay approval by DenWav

grizzled spruce
#

haven't even looked at the PR but yeah lgtm

chilly summit
#

Average PR review experience kek

warped fable
#

where did the backslash go

chilly summit
chilly summit
warped fable
#

doesn't that mean string will continue consuming chars, effectively making an invalid tag?

grizzled spruce
#

So if someone puts a 可 into the string that gets treated as a single character, rather than the iterator only grabbing the first half of it. Probably wouldn't make a difference due to how it's implemented (most characters are ignored) but it seemed less error-prone and easier to reason about

chilly summit
#

This is all happening in the second phase, I didn't even touch the second one

warped fable
#

interesting

#

When I tested with 4.24 it failed to parse

chilly summit
#

Also, if somebody does <tag:'s cool>, I believe that also just literally puts 's cool as an argument

warped fable
#

it consumed the rest of the tag

#

yes correct, but if you escape one then it will continue consuming

chilly summit
#

Can you please give me some example for that with the expected result?

warped fable
#

because the parser before checked if there is a ' somewhere between the start ' and >

chilly summit
#

It is really hard to read between your lines

warped fable
#

my bad

#

one sec

#

this fails

chilly summit
#

Actually wait yeah lmao I forgot to add the this.assertParsedEquals methods to my test I wrote up, so I don't actually know how it behaves

#

Okay yeah I see now what the actual issue is

warped fable
# 
case '\'':
case '"':
  currentStringChar = (char) codePoint;
  // Look ahead if the quote being opened is ever closed
  if (message.indexOf(codePoint, i + 1) != -1) {
    state = FirstPassState.STRING;
  }
  break;
#

This here

grizzled spruce
#

Yeah I don't check if the quote found is escaped

warped fable
#

My PR does that but it adds complexity

grizzled spruce
#

A better approach would be to handle it like how the tags are, but that may be too complex

#

where the tag is attempted to match, but if that ends up failing, it resets back to plain text

warped fable
#

well what I did is just check how many backslashes are before the closing string char

chilly summit
#

Tbh I am already fully touching the second pass, I might as well fully touch the first pass

grizzled spruce
#

in a perfect world the parsing would all be done in a single pass with no back tracking, idk given enough time I could probably get to that point, but the code would be bleh

chilly summit
#

Well

grizzled spruce
#

parser is already fast enough though, a little bit of overhead won't kill it, just makes me sad

#

when I implemented this parser it was like 10x faster than the original regex based parser lol

warped fable
#

damn

chilly summit
#

And there is no world where this should parse

warped fable
#

yes but let's remember MM works a little different

grizzled spruce
#

I had that reaction to a lot of things "this is invalid it can't parse!"

#

but mini and others basically said if it's invalid it should never fail, it should just be text instead of failing to parse

chilly summit
grizzled spruce
#

which is part of why the parser is so much more complex than you'd think it should be - it always wants to go back and pick up failed parts rather than actually throw an error

chilly summit
warped fable
#

sure but why not make the argument invalid instead

chilly summit
#

But why

grizzled spruce
#

if the argument is invalid then that makes the whole tag invalid, the end result is the same

chilly summit
#

Realistically, what do you expect this to parse into?

grizzled spruce
warped fable
#

maybe you're right, the end user will always end up with an unwanted result and as far as I'm concerned this edge case is user error

chilly summit
warped fable
#

honestly might as well keep the current code to keep it fast and if someone has this problem and asks for help someone will notice the unclosed string

grizzled spruce
#

Rewriting the parser from the ground up with the full requirments in mind idk what I'd do tbh. The truth is I didn't understand what mini and co actually wanted when I first started (I originally wrote it as a strict parser, expecting valid syntax at all times)

chilly summit
#

Well, yeah, the lack of an official document specifying the syntax makes this really hard

grizzled spruce
#

the lenient parts of the parser were added after the fact

chilly summit
#

Tbh I think it might be good to write up some actual hard requirements for the MiniMessage syntax. Not just implementation details

grizzled spruce
#

@frail carbon

chilly summit
#

Could even throw that into the adventure docs for people to read in case somebody wants to make their own MiniMessage parser

#

I'd be down to do most of the heavy lifting, but I'd need Mini or someone else to look over it, answer any uncertainties I might have, and just make sure that it fits the need

frail carbon
#

I dont think my input is valuable since i never really used the current iterations of minimessage and havent touched the project in ages

#

But the idea was always to make it hard for users to fuck up

warped fable
chilly summit
#

I think I will just go ahead, write up some docs page about the MiniMessage specifications how I see it, and ping like idk, abby, kezz, and riley about it and hope for some response

#

Nothing user-facing. Developer facing MiniMessage specs

#

Sounds like the best way to go about this

lucid quarry
#

\ is an escape and means that special parsing should be disabled, i.e. it should be a literal ' as part of the string, which then will fail because you're not closing the tag

warped fable
#

that is how it behaves at the moment. @chilly summit I think it's best to just close this as user error

lucid quarry
#

'test\' just makes literal 0 sense

lavish monolith
#

Well, technically you could consider the tag was never open, if it isn't closed

#

And since quoting is optional in MM

lucid quarry
#

that just seems like stupidly unstable behavior

#

if you open the thing with a quote you should close it with a quote

lavish monolith
#

I can see maybe a case were a tag would take idk a prefix and a suffix, and someone could give 's smth as a suffix, and not thinking about this

#

Like, he's not thinking about opening a tag

lucid quarry
#

but what do you do when 'test test's test

lavish monolith
#

(But that's a very very edge case that could easily be solved by doublequoting the whole argument)

warped fable
#

oh it doesnt 😳

lucid quarry
#

My argument here is that the behavior should be fairly predictable and standard rather than imposing weird edge cases

#

I would much rather we be strict than unstable

frail carbon
#

Arent nested minimessages always quoted?

lavish monolith
#

Yeah, following the "best effort" strategy to never fail, it could do that

warped fable
lucid quarry
#

if that's how that behaves with the missing ' at the end that is pretty wild

lavish monolith
#

Just to clarify my position: I'm all in favor of having a stricter syntax. But considering that MM parser in non-strict mode has something like a "best effort" strategy, I would understand if it would parse

grizzled spruce
#

yeah it should fail to parse, which should result in plain text. idk what it does now

#

man now I wanna go back and rewrite this parser but @chilly summit is gonna beat me to it

chilly summit
#

You can still do that after my named arguments PR is merged

#

But no touching it before that, that would be pain and suffering for me

#

Feel free to touch my PR though, I don't have anything against that

grizzled spruce
#

nah I don't have time to work on that, too many other things to do

#

I need to fix mini's hangar DB but idk that might be too hard

#

Makes sense from the perspective of how it's implemented. Honestly don't know what the "best" thing to do is

chilly summit
deft stirrup
#

will adventure v5 start declaring a vaule based annotation on objects like the jdk ValueBased

frail carbon
#

Valhalla wen

wild crane
wild crane
#

also @deft stirrup i've just pushed two commits that address some of your issues in the minestom adventure 5 update - could you explain a bit more about what changed for the nbt toString output and i'll see if i can fix that up too

#

downsampleColors can still be done via the options - it's EMIT_RGB - but i do need to deprecate that on 4.x so good spot

frail carbon
# wild crane what would be the reason/benefit to doing this?

iirc its a marker for stuff that will be turned into value classes once valhalla (well the first jep) lands. its mostly about saying that the class has no identity and I guess the jdk warns if you use them in a synchronized block and stuff?
idk if that annotation is meant to be used in user land tho

latent bobcat
#

it's not, it's jdk internal

wild crane
#

ig we could make our own marker annotation, but we would be effectively annotating the entire api lol

#

feels like it might be better placed to make a note about the "value-ness" of most of the api in the docs if there's no actual impact to making such an annotation

deft stirrup
#

Its probably fine of a change to be fair

wild crane
#

okay! i'll leave it for now then - let me know if you encounter any other problems! :D

main lion
#

Hey there! Is this channel also meant to "showcase" third-party extensions to Adventure, or should I refrain from talking about anything besides actual pull-requests? Just trying to be considerate. I'd like to share my new frontend for Adventure (MiniMessage alternative) with other users for some feedback.

raven sedge
#

this is more for discussing adventure development itself, that's more of a #general thing probably. you'd have the most luck if you PR'd a link to the community libraries page on the docs though

main lion
crisp portal
# 
public Optional<String> next() {
  return this.hasNext() ? Optional.of(this.pop().value()) : Optional.empty();
}

Would you guys be fine with adding this to ArgumentQueue. Just makes some of my code a little cleaner

#

can open a PR if you want, decided to post it here since it was a rather simple method

wild crane
#

why return string?

lavish monolith
#

Maybe rather Optional<Argument> next() and maybe one shortcut Optional<String> nextValue() to do next().map(Argument::value) because it's true it's often the most common case

wild crane
#

maybe popValue ? i like the idea of an optional method but i don't think i like returning String

crisp portal
#

that sounds fine to me, I did String because as teo mentioned above, it's almost always what you want to do anyway but I guess that isn't as future–proof if you end up introducing Arguments that are more than just String

wild crane
#

ideally we would've done pop and popOrNull which is more in keeping with the rest of the api 😭

#

i think popOptional might be best, to keep the api surface similar

crisp portal
#

I don't love the name but I can't come up with anything better either so I'll just use that lol, do you want me to open a PR?

#

popOptionalValue to return Optional<String> 🤑

lavish monolith
#

I think it's fine not to have a shortcut specifically for strings because if we have the optional method, we can just args.popOptional().map(Argument::value) and it's not that bad

#

Especially considering you'll often chain something else at the back of that call, if you wanted to use optionals in the first place

#

Like args.popOptional().map(Argument::value).orElse("My default value")

#

After looking back at the current methods, I must admit I find the name popOr for the variants taking an explicit error message quite strange

crisp portal
#

this was my use-case:

var separator = queue.popOptional()
              .map(Argument::value)
              .map(context::deserialize)
              .orElse(text(", ", GRAY));
// could also do this ig:
var separator = queue.popOptional()
              .map(arg -> context.deserialize(arg.value()))
              .orElse(text(", ", GRAY));

which it initially was:

var separator = queue.popOptional()
              .map(context::deserialize)
              .orElse(text(", ", GRAY));

so, yeah. Not much of a change

lavish monolith
#

Because everywhere in the JDK or librairies for example where you have an optional error message, the overloads where you specify it are named the same as the initial methods

image.png image.png image.png
#

I would expect a variant of a method with a name ending with Or to be different, especially when the initial method can throw an exception, I would expect the or variant to allow giving a default value to not throw

crisp portal
#

I agree with the premise, however I don't see much of a point in changing it now

lavish monolith
#

Yeah yeah, it was more of a remark after thinking about it for a minute

crisp portal
#

though I guess these are probably used by 0.1% of the people using adventure so maybe changing it wouldn't be much trouble anyway

crisp portal
wild crane
#

Posting this here also for additional comments from anyone (even a thumbs up/down react is helpful)!

One of the goals of Adventure 5.0 was to simplify component construction by doing the following:

  • Replace all specific constructors (e.g. text(String, TextColor, TextDecoration)) with a single method that accepts a varargs of StyleBuilderApplicable (e.g. text(String, StyleBuilderApplicable...)).
  • Hide the old methods via a gradle plugin that makes them synthetic - they can still be called by previously compiled code but won't be visible in IDEs to new devs, meaning a simple recompile is all you need to be "up to date".
  • Remove the "hidden" methods in Adventure 6.0 in a year or two.

Does anyone have any thoughts on the necessity of this? If we should or shouldn't do it?

lavish monolith
#

What's the exact difference between StyleBuilderApplicable (SBA) and ComponentBuilderApplicable (CBA)? I mean, I understand the possible difference according to their names, but since SBA extends CBA, maybe it should be interesting to allow a CBA varargs instead? Which classes implements CBA and not SBA?

#

GitHub seems to show me only TextFormat (and of course, Component/ComponentBuilder, obviously)

#

The "major" difference I woul see would be to allow setting children inline alongside the rest, like text("Parent", RED, space(), text("child1", GREEN), space(), text("child2")) resulting in (MM for clarity) <red>Parent <green>child1</green> child2</red>, which could or could not be desirable. I guess it's a matter of preference.

latent bobcat
#

huh

#

Style does not extend CBA thonk

lavish monolith
wild crane
#

I'm not interested in adding CBA methods as that's confusing - I'm specifically only talking about StyleBuilderApplicable here

latent bobcat
#

so what would the final set of factory methods look like? text(String, SBA...), text(String, Style), text() and text(Consumer<TextComponent.Builder>) ? also, what about other translatable factory methods where currently there are SBA... and ComponentLike... args vararg params?

wild crane
#

it'd be text() (for builder), text(String, SBA...), text(String, Iterable<SBA>), text(String, Style), text(Consumer<Builder>) yea

#

idk about the weird translatable ones, some might have to miss out on the varargs SBA methods but that's fine

latent bobcat
#

well, i suppose that's the current case so nothing would be missed on that front

crisp portal
# wild crane Posting this here also for additional comments from anyone (even a thumbs up/dow...

sounds good to me, just the other day I was kind of confused as to why there were factory methods which explicitly take TextColor/TextDecoration when I was making an utiltiy method and StyleBuilderApplicable seemed to fit the bill for the same purpose. I was about to copy the same convention the Component#text methods do just in case I had missed some extraneous use-case but didn't turn out to be the case

lavish monolith
#

Just a small remark on some code of v5. I stumbled across this:

record TextDecorationAndStateImpl(TextDecoration decoration, TextDecoration.State state) implements TextDecorationAndState {
  TextDecorationAndStateImpl(final TextDecoration decoration, final TextDecoration.State state) {
    // no null check is required on the decoration since this constructor is always invoked in such a way that
    // decoration is always non-null
    this.decoration = decoration;
    this.state = requireNonNull(state, "state");
  }
}

https://github.com/PaperMC/adventure/blob/main/5/api/src/main/java/net/kyori/adventure/text/format/TextDecorationAndStateImpl.java

If I'm not mistaken, this could be simplified to:

record TextDecorationAndStateImpl(TextDecoration decoration, TextDecoration.State state) implements TextDecorationAndState {
  TextDecorationAndStateImpl {
    // no null check is required on the decoration since this constructor is always invoked in such a way that
    // decoration is always non-null
    requireNonNull(state, "state");
  }
}
#

It may not be the only record where such simplification could be made, since I suppose that constructor simply wasn't touched after the class was changed to record

deft stirrup
#

It should still probably enforce the invariant check too

lavish monolith
#

Yes of course it works the same (I wouldn't have suggested it otherwise)

#

Oh sorry

#

Misread your message

deft stirrup
#

Yeah putting the invariant checking in the conical constructor is the way to go

lavish monolith
#

Yes

deft stirrup
#

Whats with the changes to move from interface back to class in v5?

Seems like interfaces would provide you the least abi breaks in the future

#

Oh its probably cause there were already classes to begin with :(

wild crane
#

yeaa

#

so they were abi breaking already annoyingly

deft stirrup
#

wonder if there is some hacks you could do with synthetic for that.

Though i think the correct hack would just to asm rewriting cause they really should just be interfaces lol

wild crane
#

Yeah, I just don't want to force every platform to do asm rewriting

#

Nor do I particularly have the time for that too 😅

pale pivot
#

Hey I was gonna make a pr, and the readme says to mention them here before making them. I'm not well acquainted with the code either, so it might help to mention it here.

#

Basically my change would affect the BossBarViewer interface. I was thinking it could possible be modified to extend from the Audience interface, but am unsure at the moment of how breaking that would be.

#

The reason for this change would primarily be to allow the BossBarViewer class to be used to hide a boss bar from the viewer

#

As of now, the BossBar#viewers function returns an Iterable<? extends BossBarViewer>, but you cannot use this iterable to actually hide the boss bar from people

#

I'm pulling the repos down now to see if I can't figure out what this could break, but I think this would be a small but helpful change.

#

To be honest, I also wonder if it'd be possible to completely remove BossBarViewer, and move the BossBarViewer#activeBossBars function to the Audience interface, but I'd assume that to be a more difficult task than my first idea.

crisp portal
#

relevant PR for context, though it doesn't seem to have any explanation as to why it was made a separate interface

pale pivot
#

neat!

pale pivot
#

Hey I understand if this is somewhat off-topic for this channel, but I'm trying to build the adventure-platform project with a custom build of the adventure api. I'm a novice when it comes to large gradle projects such as this, so I'm getting stuck. I cloned the repositories and have added a few lines to adventure-platform/settings.gradle, and adventure-platform/api/build.gradle.
adventure-platform/settings.gradle (Directly underneath the rootProject.name clause)

includeBuild '../adventure'

adventure-platform/api/build.gradle (Replacing api "net.kyori:adventure-api:${rootProject.adventure}")

api ":adventure:adventure-api"
#

I am running ./gradlew :adventure-platform-api:build, getting the error "Could not find :adventure:adventure-api Required by project ':adventure-platform-api'"

#

The adventure project is in the correct location for the relative path to work

#

and I can run ./gradlew :adventure:projects from the adventure-platform directory to see projects in ../adventure, which means they should be linked

lavish monolith
pale pivot
#

yknow maybe if i wasn't blind and saw that I would've

#

my bad lol

lavish monolith
#

No problem, we're all here to help 🙂

warped fable
#

wow @chilly summit , nice work on the language spec, will be great help once I decide to update my IJ plugin to named args

pale pivot
#

Hey is there any way to add tags to an issue? I made an issue and can't find the option.

high mortar
#

Outside of an issue template applying them, that's generally reserved for maintainers.

pale pivot
#

Ah ok

chilly summit
foggy cliff
#

Not sure if this question goes here, but while this is most likely not planned anytime soon, is there a chance we can get the minimessage format ported to javascript at some point in the future?
It would be incredible for creating either text builders or web uis for plugins

lucid quarry
#

We just have a web API, I don't think that there is much interest in trying to maintain two seperate parsers

foggy cliff
lucid quarry
#

Yes

#

it's a spring app but it exposes a web socket

foggy cliff
#

I could use that as a reference for my projects, yh thonk

#

The idea came because sites like https://motd.gg/ are still using the old section format
But yh, beside sites like that one I agree there will not be much interest

frail carbon
#

If you port, you will run out of sync

#

That's why we just call the official impl on the server

#

You could try using the official impl with teavm and wasm, lol

chilly summit
#

To be fair, the current impl of the parser is completely untouched since a few years

#

This might not be the case soon™️ though so yeah, figuring out bindings to the official is much easier than writing your own

crisp portal
#

if you restrict the syntax to only use named arguments instead of sequential ones (aka <tag:arg1:arg2>), you could just use a XML parser

chilly summit
#

Which currently 0% of tags on this world use

crisp portal
#

could easily add ad-hoc support for that

#

the more annoying thing would just be porting all the tags to javascript

frail carbon
azure vault
#

26.1* 🤓

image.png
wild crane
#

Major Minecraft releases don't exist anymore so you can just ignore that

#

obvs we didn't have prescience at the time of that message haha 😅

frail carbon
#

should just say next drop I guess?

deft stirrup
#

the holdout for a drop may give you J25 so it may work in your favor

patent pivot
#

just confirming; the switch to 5.x isn't alongside 1.21.11, right?

wild crane
#

Yep

deft stirrup
raven sedge
#

I don't see that changing adventure's target just yet

dull river
#

With 1.21.11 the DEFAULT_ATLAS in SpriteObjectContents its going to be change? based in how now has two atlas to use... blocks and items

candid solar
#

although actually, that wiki page doesn't seem to have been fully updated

wild crane
#

Has the default changed in vanilla?

dull river
#

i go to NMS and... looks like not still use the blocks

dense token
#

so maybe there should be a way to change the default atlas per minimessage/sprite tag instance?

#

idk how that looks like now, but something like SpriteTag.spriteTag(atlasName) would do

crisp portal
#

you could just register your own sprite tag

dense token
dense token
wild crane
#

The tag itself is very trivial, I don't see much benefit in adding that unless there's a lot of people that want it

crisp portal
# dense token yeah, but there's no reason to reimplement the whole tag when you could only add...

it would just be:

public static MiniMessage miniMessage() {
  return MiniMessage.builder()
                    .editTags(resolver -> {
                      resolver.tag("sprite", (args, ctx) -> {
    var firstArg = args.popOr("An atlas id and or a sprite id is required to produce a sprite object component").value();
    var secondArg = args.hasNext() ? args.pop().value() : null;

    if (secondArg == null) {
      return Tag.selfClosingInserting(Component.object(
        ObjectContents.sprite(
          Key.key("minecraft:items"),
          Key.key(firstArg)
        )
      ));
    }
    return Tag.selfClosingInserting(Component.object(
      ObjectContents.sprite(
        Key.key(firstArg),
        Key.key(secondArg)
      )
    ));
  })
  .build();
}
dense token
#

yeah I mean I was just suggesting things, I personally don't even need it

crisp portal
#

though that of course doesn't have all the serializable resolver stuff that default tags have, no idea what that is for either

#

I also don't know how the parser behaves when there's two resolvers which resolve to the same tag, or rather which takes priority if not replaced

pale pivot
#

Hey I'm trying to use a customized version of the adventure API to build papermc, but am running into an issue with net.kyori.adventure.inventory.Book.java

#

In the latest version of the adventure API, it is a sealed interface and only allows the BookImpl record to implement it. This conflicts with the org.bukkit.inventory.meta.BookMeta.java file in paper's api because BookMeta tries to implement adventure's Book.java

#

does anyone know how I can get around this? I figure I could just no longer seal Book.java but Id rather not do that yet

#

Ok so I noticed I'm building this off of the v5 api which is unfinished so I'm going to try to use a different version

chilly summit
#

Well, nothing was done, but it is explained in the PR description

pale pivot
#

ah ok thanks!

chilly summit
#

Basically from what I can gather, BookMeta simply won't extend the adventure book in the first place

pale pivot
#

that sounds interesting to implement

#

I haven't looked at how much of the current kyori api it depends on so that might be easier than I think

wild crane
#

BookMeta should never have extended Book to begin with, so we now have to workaround some of the issues that causes

crisp portal
#

while looking at this I was thinking what would be the best way to handle it, and I was thinking that maybe a Modifying tag would be best for it. Right now it has the visit method which one can use to inspect the node tree, however it doesn't easily let you modify the tree itself, even though that should be doable wit the current Node API

raven sedge
#

Nah there's no way to have safe user input inline

#

we went over this years ago with whatever the tag was called

crisp portal
#

my line of thought was having to modify visit method to return Node instead of void, and so it'd take the modified Node and apply it to the tree accordingly

#

like, for example if one didn't want a tag to be parsed, they could just check for a TagNode and if it matches one of the tags they don't want, they can simply discard it by returning null on visit

#

the amount of changes necessary to make the above possible is surprisingly not many, one would just modify MiniMessageParser#visitModifying to iterate unsafeChildren and do a set to the respective node

raven sedge
#

not sure what the point is though

crisp portal
#

my question would be, would this be something of interest to the API. If it is then I am willing to PR but if the team decides it isn't worth it then I'll just scrap the idea

raven sedge
#

I'd lean towards no

crisp portal
#

Is it because it exposes mutation to the node tree? I know that part of the API is currently quite unexplored, and I don't know if the team has any plans on restructuring how MM is parsed. I can imagine this adding a soft requirement to things like visit order or just the overall idea of exposing node modification through the Tag API feeling like a bad decision. I would love to know more though

wild crane
#

Yep we had a tag that attempted to solve the issue of inline user input but it was a) very jank and b) didn't work

#

it was <pre> iirc

#

but basically it's bad design to have a way to handle inline user input via some sort of inline indicator that the parse state should change

#

effectively impossible to make it foolproof and coupled with the fact there's a billion safer and easier ways to handle user input via tags

pallid yew
#

I'm thinking that would just be a custom <userinput> tag that you fill in with a component tree that you got from parsing with a different MM instance?

#

oof that's such an old conversation

novel knot
#

alright i'm currently doing some big bad awful stuff to get texture data working in <head>
just wanted to check before i do some more awful stuff, is there a class i can use to ask "hey is this a valid texture data?"

crisp portal
#

All it’d take is a custom tag resolver instead of the built in one

novel knot
crisp portal
novel knot
crisp portal
# novel knot well both

If it is the former, you’d just decode the base64 and check that it contains a link to textures.minecraft.net. You could do the latter by making web requests to Mojang servers to validate the texture link returns an actual image, but I doubt you’d want to do that just for validation since it may just get you rate limited from Mojang servers

#

I’d just validate the decoded base64 is the required format and be content with that

novel knot
#

okay turns out i only meant the former-

stiff basin
vocal wasp
spring gyro
#

is anyone else having issues building adventure locally

# 
* What went wrong:
Execution failed for task ':adventure-text-serializer-gson:checkstyleMain'.
> Could not resolve all files for configuration ':adventure-text-serializer-gson:checkstyle'.
   > Could not download Saxon-HE-12.5.jar (net.sf.saxon:Saxon-HE:12.5)
      > Could not get resource 'https://repo.maven.apache.org/maven2/net/sf/saxon/Saxon-HE/12.5/Saxon-HE-12.5.jar'.
         > Could not GET 'https://repo.maven.apache.org/maven2/net/sf/saxon/Saxon-HE/12.5/Saxon-HE-12.5.jar'.
            > The server may not support the client's requested TLS protocol versions: (TLSv1.2, TLSv1.3). You may need to configure the client to allow other protocols to be used. For more on this, please refer to https://docs.gradle.org/9.0.0/userguide/build_environment.html#sec:gradle_system_properties in the Gradle documentation.
               > Remote host terminated the handshake
acoustic pasture
#

I recently had issues with dependencies from the Apache maven repo too
They generally resolve themselves after a day or so

frail carbon
#

Did Gradle 9 remove tls 1.1 or something and the repo doesn't 1.2?

raven sedge
#

central shouldn't 1.1 either

crimson merlin
#

Would hue interpolation (as an alternative to rgb interpolation) for MiniMessage gradients be a valid feature request/issue?

wild crane
#

yep

#

i much prefer hsv gradients

crimson merlin
#

Great, as do I :)

warped fable
#

Hey @chilly summit , I wanted to revive my rainbow tag upgrade and I've been told that my PR sparked the named arguments discussion kekw . Anyways, would it be cool with you if I PR to your branch?

spring gyro
#

probably best to keep PRs on the main adventure repo and not scope creep

chilly summit
#

That branch hasn't had updates in ages, I need to come back to it, just for that reason alone I wouldn't target it at this time

warped fable
chilly summit
#

That would probably be the best approach

warped fable
#

I see

chilly summit
#

You could alternatively also fork off my branch, still PR to adventure, but keep it as a draft and reference that my PR needs to be merged first

warped fable
#

Wait do I have permissions to mark blocked by?

chilly summit
#

But then you need to deal with a bunch of rebase issues once my PR gets merged

warped fable
#

oh true

spring gyro
chilly summit
#

Probably not, but writing it into the description is enough

spring gyro
#

stacked PRs isn't a thing yet and who knows if it'll work with PRs from multiple repos

warped fable
#

I see

chilly summit
#

That's how I did my head/sprite tag PRs

#

Oh actually those were directly to the 1.21.9 branch, nvm

warped fable
#

btw this JavaDoc reads weird

image.png
chilly summit
#

Btw can someone dismiss kezz's review on on that PR (#1304)? There will be some more changes to it once I return to it hopefully soon, but that approval hasn't been particularly relevant for a while now

#

Is it just me, or are other people also having issues with building adventure atm?

image.png
#

It just stucks at 2.1MB downloaded and doesn't continue

#

Even downloading manually it doesn't seem to want to finish it

image.png
shy sandal
chilly summit
#

That's certainly interesting

#

It just doesn't want to complete for me

#

Maybe this is a sign for me to finally go make dinner. It's 11:20pm

shy sandal
#

i would take that as a sign to take a break and continue tomorrow

chilly summit
#

Silly me for updating my named-args branch

gray granite
#

I think there's something going on with the internet in the EU or in some datacenter in the EU? thonk
Im getting random DNS failures as well

shy sandal
chilly summit
#

I've also had other very random issues today. Like I oftentimes use a wifi extender to have a more stable connection, but for some reason discord, github, and paypal weren't connectable anymore. Once I disconnected the extension, I could access them again shrug

raven sedge
warped fable
#

Hey so what is the preferred way to deal with invalid arguments? Throw an exception or use a default value?

wild crane
#

Throw an exception

#

and make sure you document (unless it's nullability)

warped fable
#

I provide all there is: error message, throwable and the args

crisp portal
warped fable
#

oh okay I use that already, thanks

pale pivot
#

Hey so I made a pr and the first comment was about how the existing methods I changed need to be marked as deprecated in 4.x. I'd like to make another change to implement this, and wanted to know what branch I should edit for that. I think it should either be main/4 or next/4 but I don't know the purposes of the branches.

#

lookin line main/4

warped fable
#

Hey @raven sedge , am I correct in assuming that AbstractColorChangingTag#preserveData runs before the colour advances, and therefore it is perfectly acceptable for me to reverse the calculations to obtain the provided arguments?

warped fable
#

any advice on how to debug if the values are hashed?

image.png
wild crane
#

toString should produce nice output on all adventure things - make an issue if it doesn't

#

otherwise, use your debugger

warped fable
#

@wild crane StyleImpl does not appear to have toString method overriden anywhere

wild crane
#

feel free to open an issue

#

assuming it's not a record right

warped fable
#

alr

warped fable
chilly summit
warped fable
latent bobcat
#

i think it would be fine for waypoint style and data to be mutable, just, have a platform listener system like bossbars do for automatically updating viewers rather than manually having to call updateWaypoint or w/e
not that i'd expect many people to update existing waypoints as frequently as one would update bossbars, but still better than manually having to diy all the scaffold to allow for that nicety

chilly summit
warped fable
deft stirrup
#

Jdk 25 or not?

chilly summit
wild crane
#

It's a good question, and I think we're going to stick with 21. There's no benefits for us for bumping to 25 (plus i think it's not yet supported in vanilla?), so might as well stay on 21.

deft stirrup
chilly summit
#

Yeah, 25 is great

#

I mostly love the unnamed lambda params tbh

wild crane
#

I don't think we'd have much of a use case for either honestly, they'd be nice but not worth conflicting with vanilla for

lucid quarry
#

Vanilla jumps to 25 for 26.x

deft stirrup
#

vanilla is going to be 25 within a few months

wild crane
#

Hm, we could then, although, meh, idk if it's worth the hassle

#

Plus I think Velocity would have to update

lucid quarry
#

I generally kinda like the idea of stuff like platform libs holding back a tiny but just so it can save some headaches; velocity is also in need of a major bump but also needs a bunch of time finding for it, sooo 🙁

deft stirrup
wild crane
#

I'd be surprised if the legacy platform libs were updated immediately anyway

#

the mod platform doesn't matter as it's not intended to be backwards compatible which is nice

charred frost
#

Wouldn't moving to JDK25 only really matter on the impl side anyway? Are there any features that would be relevant on the interfaces?

wild crane
#

Well it'd matter for consumers of the API as they would obviously require 25 or higher

chilly summit
#

For record, you can use Adventure with Java 25 perfectly fine already

charred frost
#

My bad!

wild crane
#

Ah yes exactly my point too!

deft stirrup
#

You guys do know that PlayerHeadObjectContents.DEFAULT_HAT can never be changed as its value is inlined into user code?

#

Hope mojang doesnt change this...

wild crane
#

It's not got anything to do with the Mojang constant, just a constant we have set

#

doesn't matter that it's inlined

deft stirrup
#

Too bad you cant make NamedTextColor a record cause of abi since it was a class instead of an interface

frail carbon
#

You are looking at decompiled code, that's the compiler doing stuff

#

But yes, not really relevant for adventure

#

Wait maybe I am dum

#

I'll go to sleep

deft stirrup
#

good night

lucid quarry
#

They mean that anything referencing that will have the value inlined, meaning that if adventure changed it anything referencing that would use the hard older value

crisp portal
#

it should be fine since javac won't produce inlined references like that, and I don't think the JIT would be that aggressive to inline a constant that is unlikely to be called enough times to warrant it, even if it were the case it'd only be an issue if you used an AOT cache where that happened so eh

#

though I guess the sampling data from the AOT cache doesn't guarantee the same inlining behavior

pallid yew
#

Inlining at runtime (or AOT cache) shouldn't matter, there are guards to detect if that's going to go off the rails

wild crane
#

It also doesn't matter if it doesn't change

deft stirrup
#

You can observe this behavior with any decompiler

warped fable
echo oracle
#

hi I'd love to contribute a Gradient API that includes formats like HSV (with configurable strategies), this is the API I've developed, there was a PR that had concerns about the API, please share feedback so I can do this correctly before PR-ing

image.png
#

(what the code does)

image.png
lavish monolith
#

HEYTHEREHELLO

#

Would your implementation be compatible with shadow color?

#

I guess the interpolation part is done in a component-agnostic part of the code (Interpolation), but the actual Gradient.apply seems to affect the text color, how would one do to apply it to the shadow color instead?

crisp portal
rotund ravine
#

what is the advantage of having interfaces but sealing them to a single implementation over just having one implementation to begin with?

acoustic pasture
stark basalt
#

Also allows you to freely move and change your impl without any nasty breaks

wild crane
#

Case in point: the entirety of the 5.0 update basically

ashen galleon
#

i feel like the minimessage head tag should allow urls OR this portion of the official texture urls

image.png
crisp portal
ashen galleon
#

interesting, where can i see this?

crisp portal
deft stirrup
#

heads up 26.1 introduces fallback component on the object component

chilly summit
#

Oh that sounds useful

#

I am guessing that's for when it fails to resolve, like an invalid player on head or non-existent sprite?

crisp portal
tight valve
wild crane
#

I'm not interested in backporting this fix to 4.x

tight valve
vocal wasp
warped fable
#

Probably, the maintainers are focused on 5.0.0 rn tho

vocal wasp
#

this would be a 5.0 change

wild crane
#

5.0 is now feature complete and I don't want to do any more changes for it

#

I do agree that the separate BossBarViewer class is pretty stupid and that it should be Audience instead, but we'd need to have it be deprecated for a longer period of time anyway rather than just snap removing it in 5.0

acoustic pasture
wild crane
#

Yes that is what I meant

warped fable
#

Hey, question.
-# Disclaimer: I'm not asking for faster review
Would it be beneficial if I implement the Waypoint API on a platform like Paper to see if it works?

frail carbon
#

that sounds like a good idea

deft stirrup
#

5.0.0 wen ❤️

flat zincBOT
pale pivot
wild crane
#

Leave it all for now, I'll have more time to spend on everything soon and will give things a bit of needed love and attention

glad pebble
#

any plan for named translation arguments?

raven sedge
#

no

deft stirrup
deft stirrup
#

Also for any other contributors, jSpecify cannot be used as compileOnlyApi as its annotations are marked for retention at runtime. Found this issue when updating to 5.0.0 aswell.

chilly summit
deft stirrup
warped fable
latent bobcat
#

is the current approach incompatible with non-minecraft namespaces?

warped fable
#

Yes

#

Oh wait im stupid

#

You can just put them in quotation marks

latent bobcat
#

what

warped fable
#

I documented the behaviour here

latent bobcat
#

right

warped fable
#

And when looking at the source code it just takes _componentKey_ and passes it to Key#key

#

TLDR; False alarm it works fine. If you need non minecraft namespace you just put the key in quotation marks

fiery meadow
#

Hi Adventure Contributors !
I was asking about the Dialog API of Paper here #paper-dev message

And so, I was wondering if the Dialog API was going to be worked soon by Adventure or if it's still an idea for now.

Thanks in advance ;p

warped fable
fiery meadow
#

Oh okay, can I get an idea of what you're waiting ?

#

I mean, what's your expectations on theses changes

warped fable
#

Well this statement was made when Dialogs were just released, I'm just repeating what the maintainers said

#

from my standpoint, it could potentially get its own API now, it's comparable to the waypoint feature whose API implementation was approved to go ahead and be made

fiery meadow
#

Okay ! Thank you very much, appreciate your help

#

Very interesting tho, I really love this idea, I wouldn't be able to tell why but ye, I really like all of this

warped fable
#

having a Dialog API?

fiery meadow
#

part of, mostly the fact that the community is working sort of hand in hand with Mojang for the game and ye, all of this dialog API, I find it really cool and there is so much ideas which could becomre real with this

warped fable
#

it is cool!

wild crane
latent bobcat
#

i mean, the uses changes look fine, the one thing i'm "worried" about is this

the behavior is slightly changes as Services0 uses ServiceLoader(clazz, clazz.getClassLoader()) Which should no longer be needed as it uses the same class loader as the thread that initializes the class.
while in regular, proper, deployments this is not a problem, it is a problem for plugins shading adventure unless they change the ctx cl before and after calling into adventure for service loading, but that gets annoying because those happen lazily as it is not centralised (and cannot reasonably be due to the nature of multiple modules)

also, some of the changed ServiceLoader.load calls do pass the type's classloader and some don't (using the context classloader)?

wild crane
#

what would be the "proper" solution for those then? i was kinda under the impression that the service loader load would just work fine assuming you're not doing weird classloader stuff

#

but then would it have even worked anyway if you were?

deft stirrup