#adventure-contrib
1 messages · Page 1 of 1 (latest)
second
fifth
tenth
millionth
third
?th
t
It's a new day
(not) first
the main goal of the merger is more friendly faces :)
okie dokie
#1065
, I just realized something else I could be doing because of that potentially.
Indexed mini message when 🥹
Wdym by indexed?
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
Ah, I see
Well, you are in the contributing channel 👀
Is there an issue about it?
Iirc mini message can get really slow
How?
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
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
What will happen to the old discord
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
Nothing for now, we'll remove the old channels at some point I imagine. Kyori has more than just adventure anyway so it'll still hang about
But that's just improper usage I guess
Yeah, still 3.9 mspt average anyway haha
Will current repository(-ies) on github move to PaperMC org?
Yep
i dont know if it has been asked already but will the adventure related repos be moved to the PaperMC org eventually?
Literally one message up
🙃
And I was always surprised when that happened…
Also nice that non -contrib roles can write here
It's a smaller project so less need for it, but who knows we might have to change that in the future
Thanks for the great work of adventure
Yea, the contributors from kyori don't have a role here, so that seems a good solution for that
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
Do you have any weird jdk or something?
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 🙂
21.0.2 is pretty outdated, there have been some useful fixes in there iirc
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
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
https://www.minecraft.net/en-us/article/minecraft-snapshot-25w09a a bunch of SNBT changes in this snapshot
PR time for adventure-nbt?
There aren’t any underlying nbt format changes tho right? So it’s just in the conversion between nbt and snbt?
ya
They said last snapshot they are afraid to touch nbt since that would break tools
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
lmao
I tried implementing the hover/click event changes and thats also annoying
A bunch of the update notes aren't actually changes from the previous version/already work in adventure at least
show item/entity being inlined is so weird and annoying
https://pastes.dev/jzFb5aPTye I thought I maybe had an easy way out by using the java number parsers first, but there's cursedness like 1_2_3_4 being a valid int...
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
Three failing tests remain
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
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
I went with the latter solution: https://github.com/KyoriPowered/adventure/pull/1181
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
🤮 guess we have to get serious about updating for 1.21.5
what can I help with?
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
oh god, codexs
ill try and get the last few translation fixes in - lmk if there's any concerns with my new PRs
I think they're probably fine, I gave them a brief look
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
any thoughts on https://github.com/KyoriPowered/adventure/issues/1189 ?
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
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.
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
I wouldn't want us to treat paper as a first class citizen amongst the rest of the implementing platforms
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
this is my thoughts on docs #docs-website message
Need to be strict with terms here, do you mean papermc docs (as in docs.papermc.io) or do you mean the paper docs (as in, the paper section on the PaperMC docs, as the PaperMC docs already contain more than just Paper, i.e. velocity)
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
Sounds good to me yeah
(67dc81226ed5010734cf1c0c) // @tawny wolf (@deivid_028 / 438530829808041984) has been banned by @stark basalt (202850073812402177)
Reason: Quick-banned for sending a message in #adventure-contrib
Can minimessage viewer be translatable? I redirected some users to this website, but they seem know nothing about English
MiniMessage Viewer is a web interface to help generate and edit MiniMessage strings.
yeah, we've got a crowdin account so it should be possible to set things up, just nobody's gotten to it yet
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?
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
a fork opened by someone with authme work in their repo? inb4 homophobia
yes you can edit the pr if you want
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?
I'd rather have a field lookup than a map lookup for querying the options
i.e. HoverEventValueMode could be SNAKE_CASE, CAMEL_CASE, VALUE_FIELD vs 1_21_5, 1_16, LEGACY
I think the first is better
First sounds good, being explicit about what the actual difference is is nice
inbf SNAKE_CASE_WITH_EXTRAS 😄
SUPER_MODERN_SNAKE_CASE
but that woul dstill be better than super duper modern
Make it __ULTRA__LOUD__SNAKE__CASE__
__WHY__ARE__YOU__SCREAMING__AT__ME__
markdown moment
pain, mostly
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 
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

JuSt uSe BuNgEe CoMpOnEnT ApI
It's probably more realistic for me to port the xray feature patch than to try to understand adventure internals
is this what you had in mind https://github.com/KyoriPowered/adventure/pull/1168/files?
also renamed the json component constants
I just saw the PR had a todo list
thats too much for tonight, will continue tomorrow
any idea when adventure will support 1.21.5? guessing it's in work?
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.
There's literally discussion about that in the message above yours...
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)
Paper staff using Spigot confirmed??
right now I am wearing my kyori hat 🙂
Show me one person using bungee component system 😂
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
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
oh I forgot about this already, I cant test on spigot 😂
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.
I don't have any context open, but why not just use version names there?
^ discussion starts here
this isnt really something somebody would actually use
they would always go by dataversion
GsonComponentSerializer.builder()
.options(JSONOptions.byDataVersion().at(Bukkit.getUnsafe().getDataVersion()))
.build()
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
)
lmao
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
rest should be good to go now https://github.com/KyoriPowered/adventure/pull/1168
Does adventure have a style guide they want for PR's?
it's just checkstyle
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
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?
Depends what they are I suppose
what are some of the changes that would be nice?
Overhauling click/hover events to match current structure, for one
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
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
I think this should be possible without any API surface changes
Swapping class to interface and typing it with some data
it is an interface in the api already?
Can't we just change internals, deprecate the string methods and add typed ones?
it might be possible, but would adding a generic to ClickEvent be breaking? I don’t think it is?
Oh it isn’t an interface already
Very unlike you :p
it actually snuck past 4.0.0; I mentioned to @raven sedge how I was surprised it wasn’t an interface a while back
it breaks compiled code
cuz invokevirtual instructions can't reference interface methods
Yeah, had the same issue with Cumulus (our form library)
anything missing here? https://github.com/KyoriPowered/adventure/pull/1168
we prolly want to get that into a release
well working tests are missing ;P
looks like the order of the hover vs text changed when serializing components to json, weird
Order isn't guaranteed in json, is it?
ah wait, the actual breaking change is that "type" is now "id" in the "show_entity" hover
and type is value or action or whatever
ah, there is the emitKeyAsTypeAndUuidAsId parameter when serializing it. The test needs to be adjusted to test both of these cases I guess
Oh you looking at the tests
oor well, I assume that is set based on HOVER_EVENT_SNAKE vs HOVER_EVENT_CAMEL?
And ye, those params are what the or adds
It's set based on data version
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
meh, I can't run the tests directly in IntelliJ :S
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)
ok, seems to generally work when compiled though
although I of course didn't test all older versions xD
It is something that we need to do, I forget why but there’s a reason for it - @raven sedge might remember
alignment with vanilla?
item stack comparisons
Yea ^^
less of an issue that things aren't stored as strings
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
For modern versions yeah, not sure if we need to maintain it for legacy
I guess it should be an option
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
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
yeah sounds good to me!
Named arguments are such an oversight in MiniMessage :/
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
tbh, we have space in the "spec" for them - tag names can't have spaces so we can do <tag arg='':positional>
this came up before, i can't remember what our solution was
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
you used resolveColorOrNull, this can't apply here
I think value.endsWith("f") || value.endsWith("F") || value.contains(".") should be enough and let the Float#parseFloat do the rest
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
why not?
well we're checking between two number types
if we are to implement [!][phase] and [!][saturation]
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
🙁
If it looks good enough and is just off by a handful of numbers, just update the expected
do I need to fork paper to use my version of adventure api?
unless you can relocate it into a plugin for your testing, yes
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")
}
if you want to use native adventure in paper, then you can't shade in your own version
I see, so I'd have to build paper with my version of adventure
anyways, PR is up
checkstyle is lame
hehe
I mean the alternative is waiting for a human to say the same thing lol
IJ was screaming at me to import the constants statically 😄
the issue is wildcards
You can also change your code style to never use wildcards. I've changed my default to that (and some other things)
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
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
the docs are going to be intergrated into paper's
taking another stab at diagramming component structure, does this sort of layout make sense?
what?
the ideas is that the boxes are children
and the line at the top is the displayed message
what kind of component is "hello hello hello hello"
well you wanted input. I just gave you input.
is that a realistic component you'd write in a plugin?
I don’t think „Hello bold world, I am green“ is one either.
how about "You have given a", "golden shovel", "to", "player238"
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
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
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.
[ Hello ]
color: blue
|
-------------------------
| |
[ world ] [ jelly ]
inherits color color: red
(blue) |
[ donut ]
inherits color (red)
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
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
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
i mean i can see that i think?
Probably spaced out so each line down to the node is straight
something to toy with tomorrow
i think that one looks good
cuz it feels like one of the big issues people have with components is understanding how the style heierarchy works
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
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.
That was one thing my simpler text diagram did, it mentioned what was being inherited
and for me, i can barely see that it is italic. So maybe another color?
Which gets messy unless your example is only ever setting one property
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
maybe do it with dashed lines for the box styling?
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)
Too many lines flying around
hm
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
maybe another box next to style or would that also be too much?
Well, this example would fit the inherit one and set one rule so it might be okay
hm, like Style (direct), Style (inherited)
but yeah, docs would keep examples simple
I'm just worried putting too much into the boxes is going to make you lose the final result
i think in this case its fine since its important.
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
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
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?
nit pick: a colour other than lime green
how about an intense red
like those lipsticks hotel receptionists or flight attendants use
I think purple would be good
dark_purple looks good on both dark and light backgrounds
you're not wrong, but also i'm working more the layout/visual language rather than the specific content of an example component
Would this be okay to represet the optional saturation argument?
Or would it be better to combine the two pictures together
Yeah that looks good to me! Although it might be worth updating the above - your screenshot is nicer haha
I don't get the difference between the 2 outputs on that 2nd screen?
They aren't different
Huh
good point tho, might be worth picking too pretty different saturation values as well
ye was thinking that
I was doing some experiments
second to last is compared to full sat
maybe this
Yeah that's very nice
0.8 and 0.65
What's the saturation of the last one?
The last one from the second to last screenshot, right?
this picutre's last is 0.5
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
Because I can hardly see the difference on that screenshot (but maybe it's just me, I know we all perceive colors slightly differently)
completely understandable
because it's next to the same text and color
hard to distinguish
1.0, 0.8, 0.65
I think this picture would be the best, shows the difference
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
1.0, 0.6, 0.3
That's nice! Anyway that's a good thing to be able to control that parameter (and having it documented!)
why is it not updating images?
like the build directory contains new images
I'm guessing my browser's doing?
yep
final look
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
I'd rather we kept the docs up to date yes
Okay fair
strukk just needs to hurry up
I am sorry for my PR to be possessed by demons and not compiling for some unknown reason
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 :)
Which platform?
Oh, sorry I forgot that, it is on Velocity
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
Yes, I know that they are on a different version. I compiled adventure from the 1.21.5 branch, and changed my local Velocity version to use the 4.21.0-SNAPSHOT version of adventure.
The weird thing is that the ClickEvent works, but not the HoverEvent. That's led me to suspect theres an issue in adventure causing this. But again, not too sure, just thought it was strange 🤷
Can you show what the output is, and what the output you're expecting? I'm also assuming you actually updated your local velocity version to properly emit the correct data, rather than just updating the dependency and calling it a day
Sorry, I am not all that confident with the adventure and velocity projects, and was only out to fix that hover event problem seen in velocity, so I had missed that you needed to configure adventure in velocity.
Im sorry if I wasted your time with this, and am looking forward to the full release of Adventure :)
No need to apologise! That's why I asked 🫡 I think configuring the JSON serialiser version should be enough!
Yeah, i looked into it and found the configuration, was a very straightforward process to update it. Now it seems to work as i want it to :)
hello! anything I can do to help with the 1.21.5 PRs for adventure / adventure-platform?
I wanna say https://github.com/KyoriPowered/adventure/milestone/31 is the milestone for .5 cc @wild crane
Tho no idea how required every PR in there is looking at the dfu one specifically
I'm waiting on zml to decide if the dfu/nbt PRs are required, otherwise everything should be good to go
perfect
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
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 😅
@surreal sorrel throwback to 4.0.0 when things were so simple... those were the days 😭
haha yes
Thanks for the reviews! Will get onto those comments tomorrow 🫡
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
there's a PR already open
hasn't exactly been touched in a while
but the foundations seemed good
yep
Will read up on it and maybe continue the work
Yeah that PR was overscoped and has since been abandoned
would you reccommend a new PR with a smaller scope?
cause my original idea at least for rainbow was a builder class since rainbow has optional parameters
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
I suppose so, but I do want to implemet saturation like I did with the MM tag and possibly the step as well
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?
well curently the color changes based on the text length, step would override the length value
as displayed in the web viewer
So it'd repeat basically?
yup
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
}
}
uuh, fancy
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
ye stuff isnt really designed for stuff like that, mmh
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
Maybe this is a new kind of tag
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
yeah it is slightly odd
not much we can do about it atp without making a new tag type
Why is it like that?
It looks like a kind of strange behavior that pretty no one would expect
probably want to use hsl or oklab if we have utils for that
please add oklch
There's HSVLike class yes
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
There was a PR for a lot of color spaces but sadly was overscoped and abandoned
Same with <lighten>
Hmm this contradicts with my saturation argument for rainbow PR
It's different, this affects anything
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>!
Yeah I like your idea a lot. I slept through it thinking is it useful and came to the conclusion definetly.
And now, add a <brightness_gradient> tag 
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
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>
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
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
@frail carbon any objection to me updating https://github.com/KyoriPowered/adventure-platform/pull/206 ?
this depends on KyoriPowered/adventure#1168
No, go ahead, I have no clue about platform stuff, just wanted to get the ball rolling
fab, thank you
That comment seems like a big oversight from me, lol
I tried to simplify the logic but didn't fully pay attention it seems
all good :)
do you guys squash PRs?
adventure iirc merge commits 
feel free to squash your own pr if you want to tho
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
You can just use the API
it's not documented but there's an endpoint that turns minimessage to html
That should work for now, thanks. Eventually I'll need ot deal with custom tags and whatnot, but I'll cross that bridge later!
it handles simple custom tags too
it's a websocket to /api/mini-to-html , you send one of these Packet implementations as json and it spits back a ParseResult with the dom or an error message
WebSocket, interesting! Thank you very much for the info
tbh we could very easily add a non websocket endpoint
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
sounds fun! we could def add a normal http endpoint if that would be more helpful
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…)
Thank you!
@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
Definitely, I'll add it to my todo list!
is it 1:1 matching the old docs now, content-wise?
Some very tiny changes had to be made, but written text wise and pages wise, yes
able to summarize the changes on the PR?
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
minor complaint, can we have adventure above waterfall xxx
100%
Yeah ofc
am reviewing the pr now
Yay 👍
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
Text (Chat Components) looks weird
The sidebar is manually declared, the topic thingies at the index pages is alphabetically afaik
But yeah, we can put the sidebar for mm up higher, that's not a problem
aso as with the other doc pages can the dependency be Gradle Kotlin, Groovy and then Maven?
could probably get rid of the inline code if it looks better
looks fine on chrome at least
not for me
got a pic?
https://i.imgur.com/Cb5NxdB.png chrome
https://i.imgur.com/cwOZJ2t.png firefox
sure. As with all changes, I can only do those once I get home in like 2 hours
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
and something that should probably be done in a later pr is javadoc links
also there's mixed usage of @NotNull and @NonNull
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
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
<@&748618676189528155>
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.
Adventure won't have one for 1.21.6
I am semi certain
Dialoge is wayyyy to volatile to abstract
Ah so no dialogs in Paper/Velocity?
wouldn't adventure make more sense so they can be used in Velocity and Paper?
Those are not the only platforms Adventure supports, and as lynx said, they might be hard to abstract into their own thing anyways
lol
Not hard to abstract. Volatile.
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.
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
lool
Would adventure-nbt/snbt accept a change that allows it to read embedded tags (Tags that exist with extraneous trailing data) read/write any binary tag?
I have an verbose exmaple of what it could be here
https://github.com/kermandev/adventure/commit/916f78f5ca25bb3b2eb549a5e9d24e317a9bc3e4
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
I don't see a problem with it, although I'm not sure what the use case is?
Looks very neat!
I was going to use the embed features to read command arguments instead of having to do group counting to split them; And the arbitrary tag reading is useful for reversing the new method added in 4.21 that allows you to write any BinaryTag
Sounds fair enough then yeah!
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.
Looks really cool, also just one edge case, maxLength should really have a check if below 0, either throw an exception or use the @org.jetbrains.annotations.Range
Yeah I didn’t actually checked any of the parameters yet, it is more of a « proof of concept » for now, but yes that’s true
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
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
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
I have to update this but i do have this
https://github.com/Owen1212055/mc-fonts
So i cant say if currently its “paper production ready” but here is the code:
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)
);
character pixel widths from:
https://www.reddit.com/r/technicalminecraft/comments/e8i34i/maximum_length_of_text_per_page_in_books/
there is also a guthub repo with them here:
https://github.com/ADP424/MinecraftBookConverter/blob/main/pixel_widths.py
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
Yep, this is why the API needs to be designed like this ^
Ah. Fair enough
Ive gone ahead and create a PR for this https://github.com/KyoriPowered/adventure/pull/1239
I hate to annoy people, but my PR has been ready for 2 months now and it just keeps getting moved to a later milestone. Is there any reason behind it?
https://github.com/KyoriPowered/adventure/pull/1210
https://github.com/KyoriPowered/adventure-docs/pull/210
Might need 4.22.1, some methods in TagStringIO are missing thier heterogeneousLists configuration
Nice spot, feel free to submit a PR!
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 '/'
You cant have forward slashes in the namespace - that's not valid
oh wait i see
yes
ok ill fix that too
thank you #1 adventure team member kezz
How long does it take for javadocs for adventure to update? https://jd.advntr.dev/ is missing 4.23.0
manual
lovely
ah shit that's on my laptop unpiuhed lol
did adventure for 1.21.6 add a clearDialog method too?
I don't see one, 4.24 incoming?
heck yea, i can get in the binary tag holder bits too then ig
4.99 coming soon
Is there a reason for the custom click payload data being marked as not-null? Vanilla allows the data to be nullable
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?
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 😄
yeah i agree
to the point where i wouldn't be surprised if they removed the optional-ness of the tag from the packet
would it be a bad idea to let Placeholder#unparsed take anything that can be toStringed
or at least numerical types for instance
Formatter#number
Is there smth against adding an adventure Key.minecraft(value)? Kinda annoying to do Key.key(Key.MINECRAFT_NAMESPACE, value)
yeah, but I want the value to only be the value, and have no chance of being the ns:value
.minecraft goes against their method naming scheme though
no
I'll open a pr then
needs to be .minceraft tho
There's a PR for a sort of "key factory" that would be much better suited for this
yeah ok, I like this
oh sorry im dumb
@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
got some github jank and that's not linking to anything specific, what's the file I should be looking for?
it links to the DialogActionCallback class
Ty!
Would appreciate some input on this: adventure#1227(comment)
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?
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
I've got no qualms either way tbh
Why does ClickEvent.Custom use BinaryTagHolder when payload in serialization is just a binary tag?
adventures API does not have the concept of a binary tag
adventure 5.0 is so yummy
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
What's your use case for implementing it yourself?
Now is the time to raise your voice so it can be considered
Ideally you should only be implementing Identified
If you've got a use case for implementing Identity directly do let us know
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
I think you have to finish it for the current version and then refactor it to v5
No, we'll migrate to jspecify with v5 not before. Def can wait until everything is done though!
I had it for v4 but stopped updating it due to merge conflicts the whole time, and since it was going to be for v5 anyway
Yeah I that’s definitely the smarter decision
my only usecase was this to not have an identity object if im already tracking a uuid & already have a pointer supplier to the uuid, as it doesnt make alot of sense at that point.
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).
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
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.
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
yea, not directly but e.g. would benefit the config-state-api and advtr 5.0 seems like the one big thing that breaks compat anyway.
https://github.com/KyoriPowered/adventure/issues/1202
Non-goals
- A complicated update for developers. We want a migration to be as smooth as possible for developers, only requiring the removal of deprecated methods and potentially a recompile.
I don't think 5.0 is "a one big thing that breaks compat"
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.
it is in the sense that you need to recompile, but yea I worded that badly.
a recompile for the sake of dealing with ABI breaks
not a "you're going to have to migrate non-deprecated code"
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)
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
Ahhhh, didn't think of that
"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
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
Yeah it could open the possibility for the one interested of knowing, without taking away the ability to stay in ignorance 😄
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
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)
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
As long as its tristate! YES NO MAYBE so there's no requirement to implement 
Maybe a more explicit naming however of the getAudience() would clarify this (like getResourcePackAudience() or something better)
(I dislike the capability stuff here and am in favor of the mono interface as we have)
Yeah, but why? Would velocity implement the specific bits instead of audience? Probably not right.. So what would? Just the config phase bit? Well why wouldn't it just copy the specific methods it needs? I mean there's a decent argument for that, doesn't require adding a bunch more unused boilerplate to adventure
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
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
Because the entire point is that it allows you to have reusability
why not make an audience offshoot that is ConnectionAudience and have Audience extend that?
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?
https://github.com/KyoriPowered/adventure/pull/1084
Now it's updated, finished and tested. Let me know what you think.
Is there any reason why you don't use access modifiers?
because I want to keep some stuff internal
then use protected?
how would you use protected for a class?
also protected does not even make sense here
nothing is extended
fair enough
it feels like you are being collectively ignored 😭
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
even(t)
feel free to submit a pr
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.
just do \' or useing " works too i think?
hindsight is 20 20, it’s easy when I say what the bug is, it’s much harder when you have to debug it yourself. I’m just suggesting a new error be added to minimessage
Is it a silent failure even in strict mode?
What would the error specifically be? How would it specifically be detected?
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
Maybe in strict mode, a warning could be emitted, at most. Are whitespace allowed in tags? I mean, is < hover :show_text: 'example' > valid?
you wouldn't error on normal text...
the error would be that if what's decided to be the closing apostrophe is not immediately followed by > then throw an error
I'm not an adventure expert but I know that would, at least, blow up on <meow:'hiss':'purr'>
a) i don't think quoting the second argument is valid
b) even if it is you can just make this apply to the third argument of click and hover which are both quoted and can be checked this way
does minimessage even error on any text in non-strict mode?
doesn't strict mode only error on unclosed tags/reset tag?
You can quote any argument (maybe even the tag name, but I never tried it, so maybe it's not possible, idk)
why reply if you don’t know?
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
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
sure
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 😅 )
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?
https://github.com/KyoriPowered/adventure/issues/1287 hopefully this can become a blocker for 5.0.0 as its updating to a more recent jdk.
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
Does CompoundBinaryTag.builder() exist (without parameter)?
I think both would be good, as they fit different use cases
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?
we used to do it the way you had originally, but any new methods we add are the way I requested
Would you be open to having both options? I get the consistency/API design argument, but imo it feels worse from an intuitivity point of view, having to find and call a separate static method vs just doing it on the instance you already have
Will go change it either way, but let me know if having the instance method as well is something you'd consider
we're not wanting to have the old-style methods, so it would be a no - sorry!
@worthy mesa some context: https://github.com/KyoriPowered/adventure/pull/770#discussion_r885291247
Buildable is considered deprecated, basically
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
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
(And for context on "why", it is based on an old discussion here: #adventure-help message)
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
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
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
oh yeah paper can do that in codecs right
in that case yeah perhaps an option in the json serializer might be fine then
how is it possible?
New feature in a recent snapshot, was a big discussion in #general some time ago
@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
https://github.com/KyoriPowered/adventure/pull/1291 if anyone feels like contributing a <sprite> minimessage tag or serializer updates feel free to PR to this branch :D
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
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
maybe logic based on git branch?
wen indra 4
idk
I think it's basically ready but the secrets and actions config isn't setup for the GPP
Couldn't Contents be ComponentLike so it is less verbose to construct object components
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
Adds a sprite:key tag for inserting sprite objects via MiniMessage.
Is it deliberate that you did not incorporated a way to specify the atlas? (as a second optional argument for example, or as the first one if a second one is present)
named args wen
(I will be perfectly honest, I do not know a whole lot about the sprite component lol)
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
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
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 
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
had some time so I worked on the serializers, hope it's fine it's all in one pr but can split it up if need be https://github.com/KyoriPowered/adventure/pull/1293
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
I also like this idea
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)
this is how vanilla represents it as well, originally I modeled after the serialized format but that caused round tripping tests in paper codecs to fail
also you can test in game with https://github.com/KyoriPowered/adventure-platform-mod/pull/216 ./gradlew :adventure-platform-fabric:runTestmod<Server/Client>
(will need to add mavenLocal in settings)
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
hatfield and we could then check when deserializing if it containshat&& doesn't containplayerto make empty contents
I've actually never used configurate so any input here would be greatly appreciated
you should be able to do a node.raw(Collections.emptyMap());
Oh.. I didn’t try that, but that would be ideal. I’ll try it when I’m home again later
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!
https://github.com/KyoriPowered/adventure-platform/pull/225
I have done a PR for the issue reported [here](#adventure-platform-mod-help message). Let me know if you have any problems.
thats fair, my bad
nw, that's what reviews are for hehe
@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
Yeah sure, I'll look into finishing it today. Player heads is an interesting one, indeed. Introducing named args seems out-of-scope for the PR, but it generally seems required.
I will try to think of something.
it can be a separate PR anyways, but yeah idk
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?
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))
I did think about that approach as well, but I think my approach is nicer for the end user
As you can just write head:Strokkur24 and it would work fine
Which is more memorable and intuitive than head_name
I agree, and surely my names were poorly chosen, and only the UUID one should be specific, idk. Similarly to lang and lang_or
I like this a lot 👍
I think <head> should also be valid since {player:{}} is valid in vanilla
what does vanilla render then? just a steve?
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
In that case the empty tag should be valid, sure
yeah sounds fine to me too
Btw the "properties" field can be used to specify textures directly, using a base64-encoded JSON containing the URL to the texture file from Mojang's server. It is very powerful, but also very "opaque", so maybe it should be a different tag dedicated to "custom heads"
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
Tbh that is a bit of a problematic idea, because nobody is about to type base64 encoded strings into a tag arg. I wonder if one could simply the args to use urls instead and then encode it into the expected format instead
i dont think it's worth exposing, if you're typing entire base64 or head URLs into MiniMessage you're doing something wrong
adventure-platform is on life support really so it might take a while to get reviewed and merged
alright I understand that, no problem ^^
I last tested this in 25w35a and there it was a steve yes
However, if unsupported by MM, it would custom head tags would be lost
I think this would work, exposing only the texture URL and doing the reformatting internally
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
If somebody from the dev team could fact check this, I'd appreciate it ^^
Or tbh I could just do it myself, I am not entirely clueless

it should work the same way, yes
it does
if name.ispresent!=id.ispresent or properties is not empty, it is a static profile
Yeah okay in that case I will not allow for both name and uuid at once, just to avoid devs running into weird issues
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
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
Eh, I really do not like such weird inconsistencies, even if they are minor
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
It could very well be the case, especially when creating such component from an online player, to create a static component of the head with already resolved textures, and both name and uuid
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
(I already have that in btw)
If it's easier I'm really not against splitting it up into a head_custom as well
- HeadTag.java
- HeadTagTest.java for example usage
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
I'll have a look in a second, thx
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 
Oops I did not think it would turn out so big
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
Hmm, but why are you considering the textures to be a key?
it is
I think we're not talking about the same thing then
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
the texture override applies to static or dynamic profiles
By "texture override" you mean the fallback texture?
no I mean the body texture override in the skin patch
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
https://github.com/KyoriPowered/adventure/issues/1296
there's an older issue too iirc
Looking at that one rn
That might involve heavy modifications into the token parser and what not, but that looks possible
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
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
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
named args is its separate pr lol
no I'm saying splitting <head> and <sprite>
I would never put that into the same PR, I do actually know how to do PRs 
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
I honestly havent looked at the head stuff yet, so I guess if that can be done cleanly with backwards compatibility its fine
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
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
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
lol yeah I think named arguments are really needed
I am on it 
does Kyori have an SVG version of it's logo?
Yesn't
I only found the safari pin one
Somebody from the community made this a while ago
hmm, but how is this with the license?
I actually have no idea. Tried asking around, but the results were rather unanswered
yeah thats what bothers me
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
Mr. @ancient vale , sorry for bothering you, but do you have any clue what hte licensing situation around this svg image is?
(more specifically, the kyori logo in general)
The svg image is community made, not official
I believe @vital iron made that SVG?
sure, but does it have a license attached to it, since Kyori has Apache 2.0
^^
I can’t see the svg on mobile, which is it?
The same as the small kyori logo
yeah thats definitely mine
i missed the drop shadow on one of the mountains otherwise its pretty accurate lul
Turbotailz made that Kyori logo back in October of 2020
ic, so would it be fine for me to use this logo on an IntelliJ plugin I'm working on?
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
https://github.com/Privatech38/intellij-minimessage
I hope having an MIT license should work. I will ofcourse credit the logo to you and Kyori
IntelliJ plugin for supporting the MiniMessage format - Privatech38/intellij-minimessage
-# the plugin isn't published yet, because it's still missing some stuff, but syntax highlighting works
What does it do? I remember someone sharing a in code mm parsing plugin a few weeks ago.
Well let’s move to #general for this
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 
integration with @Language for strings would be cool
I think powercas really agrees with what you just said
It’d be great to get an actual logo for Adventure itself done - Adventure isn’t a Kyori project anymore technically.
The logo looks like „adventure“
.
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
.
The changes required were smaller than I thought, ngl
Just a heads up, I have split up the sprite tag PR into two now:
- feat(minimessage): add sprite tag for the sprite tag
- feat(minimessage): add head tag for the (incomplete) head tag
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
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?
Idk, that would be the adventure gradle wrapper then
This is all I am doing though, so idk 🤷
💀 let me try that fix
I don't even have a Kotlin Data View 

Ah okay I fixed it. They changed the property
It is in the root Debugger settings and it is called Attach coroutine agent
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 😄
Its already fixed no?
apparently not
It's passing 


@chilly summit are you on latest IntelliJ version?
The bug got fixed in 2025.2.1
👍🏻

