#adventure

1 messages · Page 2 of 1

wintry canyonBOT
wintry canyonBOT
#
tal5
[KyoriPowered/adventure] Pull request opened: #1267 feature(nbt): getting `BinaryTagType`s by their id

Exposes BinaryTagType#binaryTagType(byte id), to get a tag type by it's byte id.
This is needed if you're writing any sort of custom serialization, as currently you can get the id to serialize, but there's no way to de-serialize.

I also changed BinaryTagType.List TYPES to a BinaryTagType[] - technically hard-coding the size is not great, but seeing as:

  • There haven't been any new types in over 8 years.
  • It's a very easy change to make if any ever get added.
  • It'll error on startup when calling register with any potential new tag type.

it should be fine imo; still, lmk if you want me to revert it to the old list iteration & compare id approach.

Also, maybe it should return null instead of throwing? I just followed what the method already did, but maybe it would be better to change that, idk.

image

wintry canyonBOT
#
kezz
[KyoriPowered/adventure-platform] New comment on pull request: #212 Bukkit - Update MinecraftComponentSerializer for 1.21.6/7

Just for reference for those of you following this PR:

  • The PR itself appears to be functional, you are more than welcome to manually include it in your code/plugin/project if you need to.
  • We have some issues at the moment relating to the recent publishing changes that are currently blocking this PR from being merged that will be worked on when we have time.

We appreciate your patience :muscle:

wintry canyonBOT
#
ImYenil
[KyoriPowered/adventure] Issue opened: #1268 InvocationTargetException Issue

01:21:36 WARN: at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
01:21:36 WARN: at java.base/java.lang.reflect.Method.invoke(Method.java:580)
01:21:36 WARN: at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.executeCommand(CommandHandler.java:217)
01:21:36 WARN: at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.execute(CommandHandler.java:167)
01:21:36 WARN: at io.papermc.paper.command.brigadier.bukkit.BukkitCommandNode$BukkitBrigCommand.run(BukkitCommandNode.java:83)
01:21:36 WARN: at com.mojang.brigadier.context.ContextChain.runExecutable(ContextChain.java:73)
01:21:36 WARN: at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:30)
01:21:36 WARN: at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:13)
01:21:36 WARN: at n...

#
ImYenil
[KyoriPowered/adventure-platform] Issue opened: #220 InvocationTargetException Issue

01:21:36 WARN: at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
01:21:36 WARN: at java.base/java.lang.reflect.Method.invoke(Method.java:580)
01:21:36 WARN: at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.executeCommand(CommandHandler.java:217)
01:21:36 WARN: at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.execute(CommandHandler.java:167)
01:21:36 WARN: at io.papermc.paper.command.brigadier.bukkit.BukkitCommandNode$BukkitBrigCommand.run(BukkitCommandNode.java:83)
01:21:36 WARN: at com.mojang.brigadier.context.ContextChain.runExecutable(ContextChain.java:73)
01:21:36 WARN: at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:30)
01:21:36 WARN: at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:13)
01:21:36 WARN: at n...

wintry canyonBOT
#
nossr50
[KyoriPowered/adventure-platform] New comment on pull request: #212 Bukkit - Update MinecraftComponentSerializer for 1.21.6/7

Just for reference for those of you following this PR:

  • The PR itself appears to be functional, you are more than welcome to manually include it in your code/plugin/project if you need to.

  • We have some issues at the moment relating to the recent publishing changes that are currently blocking this PR from being merged that will be worked on when we have time.

We appreciate your patience :muscle:

Thank you for the update, it is appreciated.

wintry canyonBOT
#
Dawsson
[KyoriPowered/adventure-platform] New comment on pull request: #212 Bukkit - Update MinecraftComponentSerializer for 1.21.6/7

Just for reference for those of you following this PR:

  • The PR itself appears to be functional, you are more than welcome to manually include it in your code/plugin/project if you need to.
  • We have some issues at the moment relating to the recent publishing changes that are currently blocking this PR from being merged that will be worked on when we have time.

We appreciate your patience 💪

Thank you! My users will be very happy to see this has been finished

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
LoneDev6
[KyoriPowered/adventure-platform] Issue opened: #221 Books not opening anymore on 1.21.7

Books not opening anymore on 1.21.7.
Tested on:

Paper 1.21.7-32-main@e792779 (2025-07-16T20:10:15Z) for Minecraft 1.21.7

compileOnly("net.kyori:adventure-api:4.24.0-SNAPSHOT")
compileOnly("net.kyori:adventure-text-minimessage:4.24.0-SNAPSHOT")
compileOnly("net.kyori:adventure-text-serializer-gson:4.24.0-SNAPSHOT")
compileOnly("net.kyori:adventure-text-serializer-gson-legacy-impl:4.24.0-SNAPSHOT")
compileOnly("net.kyori:adventure-platform-bukkit:4.4.1-SNAPSHOT")

This code does nothing on 1.21.7.

 bukkitAudiences.player(event.getPlayer()).openBook(Book.builder()
    .author(Component.text("Kyori", NamedTextColor.AQUA))
    .addPage(Component.text("is amazing", NamedTextColor.DARK_GRAY))
    .title(Component.text("Adventure", NamedTextColor.LIGHT_PURPLE))
    .build());
wintry canyonBOT
#
renovate[bot]
[KyoriPowered/adventure-webui] branch deleted: renovate/adventure
#
renovate[bot]
[KyoriPowered/adventure-webui] branch deleted: renovate/ktor-monorepo
#
renovate[bot]
[KyoriPowered/adventure-webui] branch deleted: renovate/org.jetbrains.kotlinx-kotlinx-serialization-json-1.x
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure-platform] branch deleted: renovate/gradle-and-github-actions
#
jpenilla
[KyoriPowered/adventure-platform] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/me.lucko-fabric-permissions-api-0.x
wintry canyonBOT
#
BlackBaroness
[KyoriPowered/adventure-platform] Issue opened: #222 BossBars cause client crash on BungeeCord

Hi!

When I use net.kyori:adventure-platform-bungeecord:4.4.0 to show a bossbar, client just doesn't render it or crashes after a while. Here is an example of code causing this:

val audiences = BungeeAudiences.create(plugin)

for (i in 1..10) {
    // just an example, i make a delay between tries in a real code
    audiences.create(plugin).player(player).showBossBar(
        net.kyori.adventure.bossbar.BossBar.bossBar(
            Component.text("test $i"),
            1f,
            net.kyori.adventure.bossbar.BossBar.Color.RED,
            net.kyori.adventure.bossbar.BossBar.Overlay.NOTCHED_12,
            )
        )
}

Usually I am able to see "test 1" (first bossbar), then I get kicked.

I tried it on a Fabulously Optimized 1.21.8 client and a 1.21.5 + ViaFabricPlus client. Both crashed with the same error.

[!] That's not a client problem since I was able to correctly display bossbars using the "BossBar" packet from BungeeCord API.

Here is an error:

---- Minecraft Ne```...
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure-platform-mod] New tag created: v6.5.0
#
jpenilla
[KyoriPowered/adventure-platform-mod] New release published: 🌍 adventure-platform-mod 6.5.0

This version of adventure-platform-mod adds support for Minecraft 1.21.6 through 1.21.8, distributing Adventure 4.23.0 for the Fabric and NeoForge platforms. Minecraft versions older than 1.21.6 are not supported by this release.

What's Changed

✨ Features

Full Changelog: https://github.com/KyoriPowered/adventure-platform-mod/compare/v6.4.0...v6.5.0

#
jpenilla
[KyoriPowered/adventure-platform-mod] New tag created: v6.5.1
#
jpenilla
[KyoriPowered/adventure-platform-mod] tag deleted: v6.5.1
#
jpenilla
[KyoriPowered/adventure-platform-mod] New tag created: v6.5.1
wintry canyonBOT
wintry canyonBOT
#
Navio1430
[KyoriPowered/adventure] Issue opened: #1271 SmallCaps format tag in TextComponent

Feature

Add a tag that will format text with SmallCaps style.

Reason

Many servers use the SmallCaps characters for their messages, scoreboards etc.

<img width="652" height="257" alt="Image" src="https://github.com/user-attachments/assets/78cafdf7-0c0e-45c1-989d-b41cb6136bff" />

TinyTextGenerator

Here's the generator that people usually use:
https://lingojam.com/TinyTextGenerator

So now the question is:

Is it possible to add it into kyori adventure? It would be an awesome feature.

wintry canyonBOT
#
MaxNeedsSnacks
[KyoriPowered/adventure-platform-mod] Pull request opened: #211 Implement interface injection on NeoForge

This was relatively easy to implement as ModDevGradle already supports interface injection, though with a slightly different format to Fabric's.

I also had to add an ItemHoverEventSource interface since custom classes with generic arguments (and on top of that an inner class as generic argument) don't work properly yet (see neoforged/JavaSourceTransformer#53).
Because of that, the mixin and fabric.mod.json were changed to that interface, as well.

This change should be able to be backported to older versions as well, let me know if you want me to open a PR for 1.21.1 as well (I want to use adventure on that version, actually)

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
LaserSlime
[KyoriPowered/adventure] Pull request opened: #1272 Add a less verbose way of creating titles

I have complained on the discord before about how creating titles is unnecessarily verbose and multiple people agreed with me. This is my idea to make it a little simpler. I think just specifying the duration in ticks is quite natural. Pretty much all APIs including Minecraft's own commands do it that way, so it shouldn't be confusing to anyone.

Another idea I had was adding a showTitle method that doesn't require a Title object and just takes the params directly but I'm not sure if that goes against adventure's design philosophy or not. I'm of course still open to any other ideas to improve title creation!

wintry canyonBOT
wintry canyonBOT
#
Feniksovich
[KyoriPowered/adventure] Issue opened: #1273 TranslationStore cannot be removed from the GlobalTranslator after it has been mutated

If the TranslationStore was mutated after it was added as a source in the GlobalTranslator it can no longer be removed.

Code To Replicate:

final GlobalTranslator globalTranslator = GlobalTranslator.translator();

final Key key = Key.key("plugin", "whatever");
final MiniMessageTranslationStore translationStore = MiniMessageTranslationStore.create(key);
translationStore.defaultLocale(Locale.ENGLISH);

globalTranslator.addSource(translationStore);

// Mutating translation store
mmts.register("hello.message", Locale.ENGLISH, "Hello!");

globalTranslator.removeSource(translationStore); // returns false

Using net.kyori:adventure-text-minimessage:4.23.0 bundled in Paper API (1.21.8-R0.1-SNAPSHOT).

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] branch deleted: docs/wikivg
wintry canyonBOT
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure-platform] branch deleted: renovate/error-prone-monorepo
#
zml2008
[KyoriPowered/adventure-platform] branch deleted: renovate/junit-framework-monorepo
#
zml2008
[KyoriPowered/adventure-platform] New tag created: v4.4.1
#
zml2008
[KyoriPowered/adventure-platform] New release published: v4.4.1

This is a patch release that adds initial support for 1.21.6/1.21.7.

What's Changed

New Contributors

Full Changelog: https://github.com/KyoriPowered/adventure-platform/compare/v4.4.0...v4.4.1

wintry canyonBOT
#
github-merge-queue[bot]
[adventure:main/4] 6 new commits

e2131d5 chore(deps): Update plugin org.gradle.toolchains.f... - renovate[bot]
266ce8f chore(deps): Update dependency org.junit:junit-bom... - renovate[bot]
4e41273 chore(deps): Update dependency com.google.errorpro... - renovate[bot]
e5d959d Merge pull request #1259 from KyoriPowered/renovat... - zml2008
6ff14bb Merge pull request #1261 from KyoriPowered/renovat... - zml2008
e1e5a66 Merge pull request #1262 from KyoriPowered/renovat... - zml2008...

#
zml2008
[KyoriPowered/adventure] branch deleted: renovate/junit-framework-monorepo
#
zml2008
[KyoriPowered/adventure] branch deleted: renovate/error-prone-monorepo
#
zml2008
[KyoriPowered/adventure] branch deleted: renovate/checkstyle
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] branch deleted: feature/configurable-nesting
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] New tag created: v4.24.0
#
kezz
[KyoriPowered/adventure] New release published: 🌏 Adventure 4.24.0

What's Changed

✨ Features

🐛 Fixes

wintry canyonBOT
#
zml2008
[KyoriPowered/adventure-docs] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
#
kezz
[KyoriPowered/adventure-webui] branch deleted: renovate/gradle-and-github-actions
#
zml2008
[KyoriPowered/adventure-webui] branch deleted: renovate/major-gradle-and-github-actions
#
jpenilla
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/adventure
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] New branch created: fix/properties-spi
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
#
jpenilla
[KyoriPowered/adventure-platform-mod] New tag created: v6.6.0
wintry canyonBOT
#
derklaro
[KyoriPowered/adventure] Pull request opened: #1280 fix invalid url extraction in legacy component serializer

The legacy component serializer currently extracts some invalid urls from an input string, leading to a client disconnect due to the validation performed in net.minecraft.Util.parseAndValidateUntrustedUri(String) (specifically calling new URI() on the input).

An example input where this is happening is: Discord: <https://example.com/>, as this results in an open url action with the url https://example.com/> which is invalid.

To circument this I've made the url regex more strict on the path part (only allowing chars as specified in rfc 3986 section 3.3), and added a validity check by calling new URI() before adding the click event. I'm not sure if the second check is actually required, however, I feel it is better to be safer here than accidentially disconnecting clients by extracting invalid urls.

Please let me know if additional test cases are required, I only added a few to validate the behaviour, maybe a few more would be better.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
vLuckyyy
[KyoriPowered/adventure-platform] Issue opened: #224 Error sending packet `set_action_bar_text`

I'm encountering an error when sending an action bar via the Adventure Platform in my plugin:

I'm using the latest Paper 1.21.8, Adventure 4.24.0, and Adventure Platform 4.4.1. Downgrading Adventure Platform to 4.4.0 resolved the issue.

00:14:11 ERROR]: Error sending packet clientbound/minecraft:set_action_bar_text
io.netty.handler.codec.EncoderException: Failed to encode packet 'clientbound/minecraft:set_action_bar_text'
        at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:62) ~[paper-1.21.8.jar:1.21.8-21-ed31825]
        at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:13) ~[paper-1.21.8.jar:1.21.8-21-ed31825]
        at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:27) ~[paper-1.21.8.jar:1.21.8-21-ed31825]
        at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:12) ~[paper-1.21.8.jar:1.21.8-21-ed31825]
        at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:1```...
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
#
Tanerx
[KyoriPowered/adventure-platform] New comment on issue: #224 Add Support for 1.21.8. Error sending packet `set_action_bar_text`

I'm experiencing the same issue, and although downgrading to 4.4.0 fixes the error, no actionbar messages are being sent

io.netty.handler.codec.EncoderException: Failed to encode packet 'clientbound/minecraft:set_action_bar_text'
        at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:62) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:13) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:27) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:12) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-4.1.118.Final.jar:4.1.118.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(...
wintry canyonBOT
#
NamiUni
[KyoriPowered/adventure] Issue opened: #1282 Add Component#transform for Functional Transformations

Proposal:

This issue proposes the addition of a transform method to the Component interface. This method would allow for functional, chained transformations of components, mirroring a pattern seen in the Java standard library with String#transform.

Motivation

The primary goal is to provide a more idiomatic and functional way to handle component transformations. By introducing a transform method, developers can write cleaner and more concise code, especially when working with modern Java features like the Stream API.

Proposed API

public interface Component {
    // ... existing methods
    <R> R transform(Function<? super Component, ? extends R> transformer);
}

This method would apply the provided transformer function to the component and return the result. Since Component instances are immutable, this operation would be side-effect-free.

Advantages

  1. Functional Programming Approach: transform would enable a more functional style of programming. This...
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
NamiUni
[KyoriPowered/adventure] New comment on issue: #1282 Add Component#transform for Functional Transformations

I'm sorry my last issue wasn't clear enough. You were right that I didn't give a good example. I'm not a native English speaker, so I used AI to help me write it, but the idea was mine. I should have explained it better.

I have a new example from my own library, Doburoku. It shows exactly why I think transform would be useful.

Right now, to transform a Component into a Consumer<Audience>, I have to write it like this:

.add(new TypeToken<Consumer<Audience>>() { }, component -> audience -> audience.sendMessage(component))

This works, but it's a bit complicated to read. With a transform method, it could be written like this:

.add(new TypeToken<Consumer<Audience>>() { }, component -> component.transform(it -> audience -> audience.sendMessage(it)))

I think this second one is much more intuitive and easier for a developer to understand. It just feels more natural and is in line with String#transform.

Do you think we could talk about this again? I really believe this would...

wintry canyonBOT
wintry canyonBOT
#
tal5
[KyoriPowered/adventure] Pull request opened: #1283 feature(api): Allow reading style values from builders

See [Discord](#adventure-help message) discussion.

Makes ComponentBuilder and Style.Builder implement StyleGetter, allowing access to set values before building.
The style builder hols the actual implementation, and the component builder simply redirects StyleGetter methods to its style builder.

For the JD, I used {@inheritDoc} with a changed @since tag to 4.25.0 - this does mean that the JD sometimes refers to itself as e.g. stylable instead of component, but imo I don't think that's a big deal compared to how much cleaner the JD is (also see Discord discussion).

I put all of the getters right above their setters as that seemed to be the convention, but let me know if you'd prefer having them all in one place for less adventure 5.0 merge conflicts.
<img width="1519" height="264" alt="image" src="https://github.com/user-attachments/assets/784b4df9-7a80-4862-9cae-5fbfa60ef375" />

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
Heriptik
[KyoriPowered/adventure] Issue opened: #1284 Adventure API Conflict with Mods on Arclight 1.21.1

Describe the bug
When using Arclight 1.21.1 (https://github.com/IzzelAliz/Arclight), if a mod uses the Adventure Text API (common), it causes all chat output from plugins that also use Adventure (like HuskHomes) to not display anything in the chat, even though the plugin functions correctly in the background.

However, when I remove the mods that use the Adventure Text API, the plugin messages reappear in the chat as expected.

To Reproduce
Steps to reproduce the issue:

Run an Arclight 1.21.1 server.

Install a plugin that uses adventure-platform-bukkit (e.g., HuskHomes 4.4.0).

Install a mod that also uses the Adventure Text API.

Execute any plugin command (e.g., /home from HuskHomes).

Observe that no message is displayed in chat, even though the command works.

Expected behavior
Plugin messages using the Adventure API should be visible in chat, regardless of whether a mod using Adventure is present.

Video demonstration
https://drive.google.com/file/d/1xCCvoMjwlsV1USTTPh9MyRNtp_dfO_...

wintry canyonBOT
wintry canyonBOT
#
ProdPreva1l
[KyoriPowered/adventure] Issue opened: #1285 MiniMessage serializer does not deserialize Item hover events

The minimessage string below does not properly deserialize the show_item hover. Infact it does not do it at all.

<click:suggest_command:'/msg Preva1l'><hover:show_text:'<white>this is a hover... <red>hello!'><bold><green>LIME TART</green></bold> Preva1l <dark_gray>» </dark_gray><italic><white><hover:show_item:grass_block:61:custom_name:"'{\"extra\":[{\"bold\":false,\"color\":\"yellow\",\"italic\":false,\"obfuscated\":false,\"strikethrough\":false,\"text\":\"item\",\"underlined\":false}],\"text\":\"\"}'"><!italic><!underlined><!strikethrough><!bold><!obfuscated><yellow>item

As to why, I couldn't tell you.

wintry canyonBOT
#
vLuckyyy
[KyoriPowered/adventure-platform] New comment on issue: #224 Add Support for 1.21.8. Error sending packet `set_action_bar_text`

I'm experiencing the same issue, and although downgrading to 4.4.0 fixes the error, no actionbar messages are being sent

io.netty.handler.codec.EncoderException: Failed to encode packet 'clientbound/minecraft:set_action_bar_text'
        at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:62) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:13) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:27) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:12) ~[paper-1.21.7.jar:1.21.7-17-b4466ec]
        at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-4.1.118.Final.jar:4.1.118.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:893) ~[netty-transport-4.```...
wintry canyonBOT
wintry canyonBOT
#
kermandev
[KyoriPowered/adventure] Issue opened: #1287 Use module-info instead of manifest

Currently adventure does not declare a module-info and relies on the Automatic-Module-Name, this is bad for people wanting to add adventure as a transitive dependency in their modules as javac will warn about this behavior and provides other problems. As without module info's you are required to requires every path used, instead of its known as a transitive dependency as an API through the base adventure package.

Currently required:

module example {
    requires net.kyori.adventure;
    requires net.kyori.adventure.nbt;
    requires net.kyori.adventure.key;
    requires net.kyori.examination.api;
    requires net.kyori.adventure.text.logger.slf4j;
    requires net.kyori.adventure.text.serializer.legacy;
    requires net.kyori.adventure.text.serializer.gson;
    requires net.kyori.adventure.text.serializer.plain;
    requires net.kyori.adventure.text.serializer.json;
    requires net.kyori.adventure.text.serializer.ansi;
}

Expected:

module example {
    requires net.kyori.adven```...
wintry canyonBOT
wintry canyonBOT
#
indyteo
[KyoriPowered/adventure] Pull request opened: #1288 feat(api): Allow passing parentStyle to Component#compact

Component#compact optimizes the styles of a component tree by assuming this component is the root of the tree. This is fine in most situation, but sometimes, we know the context where the component will be used, and thus the styles could be optimized even further. By providing the initial parentStyle to the ComponentCompaction.compact method, it allows us to provide the additional context required to benefit more from this optimization.

The main use-case is for components that will be used in item lore, were we know the parent style is Style.style(NamedTextColor.DARK_PURPLE, TextDecoration.ITALIC).

An alternative way to do this without this method would be to do:

Component compacted = Component.empty().style(parentStyle).append(component).compact();
// But I just feel like this is way cleaner:
Component compacted = component.compact(parentStyle);

They would both lead to same result thanks to the optimization of compaction when the parent is just empty with only one ch...

wintry canyonBOT
#
zml2008
[KyoriPowered/adventure-webui] branch deleted: renovate/gradle-and-github-actions
#
zml2008
[KyoriPowered/adventure-webui] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure] New branch created: indra-4
wintry canyonBOT
#
Emilxyz
[KyoriPowered/adventure] Pull request opened: #1290 feat(json): add option to prepend https to click event urls

Related PaperMC/Velocity#1630; [discord discussion](#adventure-contrib message)

Since 1.21.5 URIs without a http:// or https:// in a open_url click event are no longer silently ignored but fail parsing and disconnect. Developers still seem to expect these to be valid, because paper mitigates this in their codec.

This pr adds a JSONOption to be able to match papers behavior during (de)-serialization. Also documents this change on ClickEvent#openUrl(String) to inform developers that they should be sending valid URIs.

Tested with:

final GsonComponentSerializer serializer = GsonComponentSerializer.builder()
  .editOptions(options -> options.value(JSONOptions.EMIT_CLICK_URL_HTTPS, true))
  .build();
System.out.println(serializer.serialize(Component.text()
  .content("click me")
  .clickEvent(ClickEvent.openUrl("kyori.net"))
  .build()
));
System.out.println(serializer.deserialize(
  "{\"click_event\":{\"action\":\"open_url\",\"url\":\"kyori.net\"},\"text\":\"click me\"}"
));

output:
json...

wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure] New branch created: unstable/4
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure-platform-mod] New branch created: dev/1.21.9
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure] New branch created: player-head-contents-exp-1
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
jpenilla
[adventure:unstable/4] 13 new commits

511f853 Add PlayerHeadContents - jpenilla
cfccd17 dont clear props on properties(map) - jpenilla
614ad73 allow using SkinSource with builder - jpenilla
fd8a901 Add more property helpers & a test - jpenilla
1c8aabe Add import layout to editorconfig - jpenilla
55924a6 Move ObjectComponent inner classes to top level - jpenilla
e8f91a5 clear existing profile when setting from skin sour... - jpenilla
a9ee9a2 make it build (add javadocs and etc.) - jpenilla
43231d3 Assert PlayerHeadObjectContents is non-empty - jpenilla...

#
jpenilla
[KyoriPowered/adventure] branch deleted: player-head-contents-exp-1
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] New branch created: fix/check-preparsed-name
wintry canyonBOT
#
tal5
[KyoriPowered/adventure] Pull request opened: #1298 `TranslatableComponent$Builder#addArgument`

Additions

  • TranslatableComponent$Builder#addArgument - adds a single translation argument, as opposed to the current methods which only allow setting the entire list.
  • TranslatableComponentImpl#asArgument - converts a single ComponentLike into a TranslationArgument, with an optional int index for extra error info (ignored when -1, from e.g. the new addArgument ^).

Changes

  • TranslatableComponentImpl$BuilderImpl.args - now defaults to null, with:
  • TranslatableComponentImpl$BuilderImpl#args - acting as a getter that defaults it to a new ArrayList if unset and returns its value (similarly to other builders around the API).
  • TranslatableComponentImpl$BuilderImpl#arguments - now initializes args to a new ArrayList of the correct size and adds each argument manually using the new TranslatableComponentImpl#asArgument, so that the list is mutable (unlike the one returned by asArguments) .
  • TranslatableComponentImpl$BuilderImpl#build - now defaults args to Collections.em...
wintry canyonBOT
wintry canyonBOT
#
Pablete1234
[KyoriPowered/adventure] Issue opened: #1299 VirtualComponents don't render when inside translatable components

I'm unsure as to why this was done, but can be seen here:
https://github.com/KyoriPowered/adventure/blob/main/4/api/src/main/java/net/kyori/adventure/text/renderer/TranslatableComponentRenderer.java#L202

if (arg.value() instanceof Component && !(arg.value() instanceof VirtualComponent)) {

The second part of that if, means that virtual components get completely ignored when rendering translatable, making them unusable other than for their fallback.

I'll these are some examples of what you'd expect code to result to:
Works and has correct behavior:

// Renders as "Hello Username" just fine
virtual(Player.class, p -> text("Hello " + p.getName()));

Does not work, has incorrect behavior:

// Assume some.key=Greeting: {}

// Renders as "Greeting: " (no fallback defined), should be "Greeting: Hello Username"
translatable(some.key, virtual(Player.class, p -> text("Hello " + p.getName())));

// Renders as "Greeting: fallback" (a fallback is defined), should be "Greeting: Hello Username"
v```...
wintry canyonBOT
#
TonytheMacaroni
[KyoriPowered/adventure] New comment on issue: #1299 VirtualComponents don't render when inside translatable components

The virtual components I mentioned for MiniMessage translators are not provided by plugins. They are how you specify named arguments, tag resolvers and a target when using MiniMessage translations:

Named arguments - https://github.com/KyoriPowered/adventure/blob/main/4/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/translation/Argument.java#L146-L167
Tag resolvers - https://github.com/KyoriPowered/adventure/blob/main/4/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/translation/Argument.java#L180-L190
Target - https://github.com/KyoriPowered/adventure/blob/main/4/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/translation/Argument.java#L192-L201

Collapsing them to the fallback string would break their functionality.

wintry canyonBOT
#
4drian3d
[KyoriPowered/adventure] Pull request opened: #1300 feat(minimessage): Added support for translatable tags to provide the target as an argument if present

Currently, if you use the <lang> and <lang_or> tags with a custom MiniMessageTranslator with a TagResolver that obtains information from the parsing context, you cannot access the target initially provided when parsing the <lang> tag. This pull request provides support for this.
In addition, a test has been added that provides an example of a real use case for this feature.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
ImYenil
[KyoriPowered/adventure] Issue opened: #1302 UnsupportedOperationException 
[18:55:57 WARN]:        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
[18:55:57 WARN]:        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[18:55:57 WARN]:        at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.executeCommand(CommandHandler.java:217)
[18:55:57 WARN]:        at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.execute(CommandHandler.java:167)
[18:55:57 WARN]:        at io.papermc.paper.command.brigadier.bukkit.BukkitCommandNode$BukkitBrigCommand.run(BukkitCommandNode.java:83)
[18:55:57 WARN]:        at com.mojang.brigadier.context.ContextChain.runExecutable(ContextChain.java:73)
[18:55:57 WARN]:        at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:30)
[18:55:57 WARN]:        at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:13)
[18:55:57 WARN]:        at n```...
wintry canyonBOT
#
ImYenil
[KyoriPowered/adventure-platform] Issue opened: #226 UnsupportedOperationException 
[18:55:57 WARN]:        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
[18:55:57 WARN]:        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[18:55:57 WARN]:        at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.executeCommand(CommandHandler.java:217)
[18:55:57 WARN]:        at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.execute(CommandHandler.java:167)
[18:55:57 WARN]:        at io.papermc.paper.command.brigadier.bukkit.BukkitCommandNode$BukkitBrigCommand.run(BukkitCommandNode.java:83)
[18:55:57 WARN]:        at com.mojang.brigadier.context.ContextChain.runExecutable(ContextChain.java:73)
[18:55:57 WARN]:        at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:30)
[18:55:57 WARN]:        at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:13)
[18:55:57 WARN]:        at n```...
wintry canyonBOT
#
ImYenil
[KyoriPowered/adventure] Issue opened: #1303 InvocationTargetException 
[00:10:59 WARN]:        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
[00:10:59 WARN]:        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[00:10:59 WARN]:        at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.executeCommand(CommandHandler.java:217)
[00:10:59 WARN]:        at MailMe.jar//net.mailme.libs.mf.base.CommandHandler.execute(CommandHandler.java:167)
[00:10:59 WARN]:        at io.papermc.paper.command.brigadier.bukkit.BukkitCommandNode$BukkitBrigCommand.run(BukkitCommandNode.java:83)
[00:10:59 WARN]:        at com.mojang.brigadier.context.ContextChain.runExecutable(ContextChain.java:73)
[00:10:59 WARN]:        at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:30)
[00:10:59 WARN]:        at net.minecraft.commands.execution.tasks.ExecuteCommand.execute(ExecuteCommand.java:13)
[00:10:59 WARN]:        at n```...
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
RaynLegends
[KyoriPowered/adventure-platform] Issue opened: #227 ViaVersion 5 support

ViaFacet currently targets ViaVersion 4.3.0, which is outdated.

Currently running the plugin on a server with ViaVersion 5.4.2 gives this debug log:
Skipped facet: net.kyori.adventure.platform.viaversion.ViaFacet$Chat@3d158e1

Modern clients receive downsampled colors instead of modern ones.

By supporting ViaVersion 5 colored messages should reappear correctly.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
Strokkur424
[KyoriPowered/adventure] New comment on pull request: #1292 feat(minimessage): add sprite tag

Can you consider adding value + signature pair support for heads?

I did consider it, but I decided against it for now considering the logic for that would genuinely turn unmaintainable. I am probably going to be splitting this PR into two, one for the sprite tag, one for the head tag, and I might wait for named arguments before I implement the head tag (as named arguments would make the logic much cleaner).

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
RaynLegends
[KyoriPowered/adventure-platform] New comment on pull request: #228 Feat: ViaVersion 5 support

There was an issue which I believe was present before the update.

Chat components were serialized using the "latest" serializer available in Adventure, this however caused components to have incorrect fields since they would go through the ViaVersion pipeline from Minecraft 1.16 (which of course would then rewrite the components as if they were from that version, even though the serializer wrote them as if they were in latest).

Now components should work correctly in every version, I personally tested:

  • Paper 1.8.8 server, ViaVersion 5.4.2 with 1.8.9 client (colors are downsampled, hovers and clicks work)
  • Paper 1.8.8 server, ViaVersion 5.4.2 with 1.21.8 client (modern colors, hovers and clicks work whereas they didn't before the fix in the commit)
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
tgbhy
[KyoriPowered/adventure] New comment on pull request: #1307 fix(workflows): use Java 21 to build

On https://github.com/KyoriPowered/adventure/pull/1253 the Adventure/5.0.0 use Java 21.
So, when building, the workflows use Java 17 currently so this PR aims to fix that so you can see the real errors to fix to have a functionnal build.
And when everything will be fixed, the CI will be able to work correctly.

I did tests on my GitHub before sending this PR, I just send unnecessary commits so I re-created this fork when everything was good for me.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
4drian3d
[KyoriPowered/adventure] New comment on pull request: #1300 feat(minimessage): Added support for translatable tags to provide the target as an argument if present

Would this change not break existing calls with translatables by inserting the "fake" target argument at the start?

I don't see how it could affect anything. This pull request only modifies the <lang> and <lang_or> tags, where the only arguments it can receive are text. This pull request only inserts a target argument if it is present, and inserts it at the end of the arguments, so it should not change the order or behavior of any previously inserted arguments

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
github-merge-queue[bot]
[adventure:main/4] 35 new commits

4598503 Init ObjectComponent - jpenilla
ae3d6ef Fix atlas nullability - jpenilla
50b1ae9 override examinableProperties - jpenilla
e687b38 Add tests - jpenilla
a64c854 Refactor ObjectComponent to have a Contents - jpenilla
b2117f1 make SpriteContents#atlas non-null - jpenilla
42539c1 jd fix - jpenilla
8aef6e5 Add net.kyori capabilities when group is something... - jpenilla
c687a2e Add PlayerHeadContents - jpenilla
f596ce7 dont clear props on properties(map) - jpenilla...

#
jpenilla
[KyoriPowered/adventure] branch deleted: unstable/4
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
RaynLegends
[KyoriPowered/adventure] New comment on issue: #1085 MiniMessage strips "redundant" tags which does not allow me to set prefixes as I can with legacy color codes

This isn't really a MiniMessage issue but an issue with LegacyComponentSerializer.

If you try to run this test it fails because the serializer "skips" empty strings:

  @Test
  void testToLegacyJustColor() {
    final TextComponent c0 = Component.text("", TextColor.color(0xffefd5));
    assertEquals("§#ffefd5", LegacyComponentSerializer.builder().hexColors().build().serialize(c0));
  }

This causes issues with Component(s) used as a prefix (which I know is not the ideal case, but it could be supported by fixing this).

wintry canyonBOT
#
RaynLegends
[KyoriPowered/adventure] Pull request opened: #1312 Fix: LegacyComponentSerializer skips colors with no text

Fixes KyoriPowered/adventure#1085 (Not 100% sure the issue is related, I can open a separate one if needed ^^)

LegacyComponentSerializer does not serialize colors added to components with an empty text, which causes issues when using components as prefixes.
While this is not really an intended use case, it's unintuitive, causing for example the second of these tests to fail:

  @Test
  void testJustColor() { // Passes (Existing test case)
    assertEquals(Component.text("", TextColor.color(0xabcdef)), LegacyComponentSerializer.legacyAmpersand().deserialize("&#abcdef"));
  }

  @Test
  void testJustColorInverse() { // Fails (Basically the inverse of the first test, does not currently exist)
    assertEquals("&#abcdef", LegacyComponentSerializer.legacyAmpersand().serialize(Component.text("", TextColor.color(0xabcdef))));
    // Actual result: "" (an empty string)
  }

The change in the PR does not change any other behaviour.
I added a specific test (testToLegacy...

wintry canyonBOT
wintry canyonBOT
#
RaynLegends
[KyoriPowered/adventure] New comment on pull request: #1312 fix(text-serializer-legacy): colors with no text are skipped

I understand that this particular use case may not be a goal, but the legacy serializer is really the only one that has this behavior.

I think this really is a bug when you consider that what the legacy serializer is doing is not "preventing" using it to represent prefixes, because you can absolutely do that as long as there is something after the color, but simply refusing to serialize color codes followed by an empty string (which is okay-ish when those colors would not change anything, like for "&a&eSomething" being changed to "&eSomething" -- even though this is also kind of unexpected and something that I would personally not see a serializer doing, this should probably be a job for a compacter/optimizer).

See the following tests:

Minimessage Serializer - Both tests pass

  @Test
  void testColorNonEmpty() {
    final String expected = "<green>Test";
    final Component component = text("Test").color(NamedTextColor.GREEN);
    this.assertSerializedEquals(expe```...
wintry canyonBOT
wintry canyonBOT
#
TheZexquex
[KyoriPowered/adventure] Issue opened: #1314 [Feature Request] Add HTML Serializer

After some discussion in the #adventure-help channel in the PaperMC Discord server about serializing MiniMessage strings to HTML for easy rendering in web based software, we came to the conclusion, that an HTML serializer for Adventure in general could be a great addition to the API.

This would allow web applications to render previews of MiniMessage messages, or even Components in general, without relying on wrapping the webui or implementing a custom serializer, that would need to be kept up to date with the Adventure api.

A few use cases could be:

  • A localization software with a preview of how the messages would look like in game
  • A live chat or colored log on a server website or admin interface, that forwards all server messages
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] branch deleted: fix/properties-spi
#
github-merge-queue[bot]
[adventure:main/4] 7 new commits

ec627a1 Fix defaultValue nullability - tal5
913225d fix invalid url extraction in legacy component ser... - derklaro
be30b8c checkstyle, improve regex readability, support per... - derklaro
c0201ac chore: Check TagResolver#has in more places - kezz
f33182b Merge pull request #1263 from tal5/fix/default_valu_... - kezz
577e740 Merge pull request #1280 from derklaro/legacy-comp... - kezz
6eb526f Merge pull request #1297 from KyoriPowered/fix/che... - kezz...

#
kezz
[KyoriPowered/adventure] branch deleted: fix/check-preparsed-name
#
kezz
[KyoriPowered/adventure] branch deleted: renovate/patch-release-dependency-changes
#
kezz
[KyoriPowered/adventure] branch deleted: renovate/com.diffplug.gradle-goomph-4.x
#
kezz
[KyoriPowered/adventure] branch deleted: renovate/error-prone-monorepo
#
kezz
[KyoriPowered/adventure] branch deleted: renovate/junit-framework-monorepo
wintry canyonBOT
wintry canyonBOT
#
Privatech38
[KyoriPowered/adventure] New comment on issue: #1315 Escaped quotations in arguments cause a tag to be returned as a TEXT token

So it seems I found the underlying issue:
Since the first quote is not escaped an is treated just as a string start it looks forward if it's ever closed. Which according to String#indexOf it is, BUT it does not check if that particular char is also escaped. The code that does this in question:

https://github.com/KyoriPowered/adventure/blob/fe49db381684f32a539b187438b8fa8d771af1db/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/internal/parser/TokenParser.java#L254C1-L261C21

I personally can not think of a solution to this right now due to edge cases like "test\\" and "test\".

wintry canyonBOT
#
Privatech38
[KyoriPowered/adventure] Pull request opened: #1321 fix(minimessage): First pass state not returning to NORMAL from STRING if quote is escaped

Closes #1315

This PR addresses the TokenParser#parseString's problem when faced with an input like <hover:show_text:"Foo\">Bar. The parsed result would be literal text as the parser never returns to NORMAL first pass due to it being mislead by the escaped quote.

While this solution is not the prettiest and adds more complexity it doesn't touch escape logic. Alternatively (which I think would be better) is to drop escape logic in first pass for strings entirely, because IIRC it doesn't really do much.

wintry canyonBOT
#
Phoenix616
[KyoriPowered/adventure] Pull request opened: #1322 Allow creation of a ClickEvent from an Action and Payload

This change adds the method ClickEvent#clickEvent(Action, Payload) which allows creation of new ClickEvent objects from arbitrary Actions and Payloads. This is useful for custom string -> Component parsers like Minimessage or Minedown which in the past used the now deprecated ClickEvent#clickEvent(Action, String) method to easily create new click events from user-supplied action strings.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
Phoenix616
[KyoriPowered/adventure] New comment on pull request: #1322 Allow creation of a ClickEvent from an Action and Payload

Switching would require code like this which is imo. not clean design and also fails to automatically support newly added actions with existing payload types:

    public static ClickEvent clickEvent(ClickEvent.Action action, ClickEvent.Payload payload) {
        return switch (action) {
            case CUSTOM -> ClickEvent.custom(((ClickEvent.Payload.Custom) payload).key(), ((ClickEvent.Payload.Custom) payload).nbt());
            case OPEN_URL -> ClickEvent.openUrl(((ClickEvent.Payload.Text) payload).value());
            case OPEN_FILE -> ClickEvent.openFile(((ClickEvent.Payload.Text) payload).value());
            case RUN_COMMAND -> ClickEvent.runCommand(((ClickEvent.Payload.Text) payload).value());
            case SUGGEST_COMMAND -> ClickEvent.suggestCommand(((ClickEvent.Payload.Text) payload).value());
            case COPY_TO_CLIPBOARD -> ClickEvent.copyToClipboard(((ClickEvent.Payload.Text) payload).value());
            case CHANGE_PAGE -> ClickEvent.changePag```...
wintry canyonBOT
#
Strokkur424
[KyoriPowered/adventure] New comment on pull request: #1321 fix(minimessage): First pass state not returning to NORMAL from STRING if quote is escaped

I don't think I particularly like this solution. Imagine you have a very long MiniMessage string with a lot of escaped and not escaped quotes. From what I see here, this would result in a lot of double-iterating, which is very bad for time complexity.

For the problem which you've shown here <hover:show_text:"Foo\">Bar, I believe a better solution would be to just continue parsing to the end, and if it ends up in string state never being closed, it should throw a parsing exception, seeing as whoever wrote that String probably forgot a " at the end, which we should make them aware of.

What your original issue was trying to show with <tag:\"foo\"> is that the first string is not escaped, which is the bigger issue here. I think you should modify your solution so that it properly escapes the first ", as that should fix it just fine.

wintry canyonBOT
#
Privatech38
[KyoriPowered/adventure] New comment on pull request: #1321 fix(minimessage): First pass state not returning to NORMAL from STRING if quote is escaped

For the problem which you've shown here hover:show_text:"Foo\"Bar, I believe a better solution would be to just continue parsing to the end, and if it ends up in string state never being closed, it should throw a parsing exception, seeing as whoever wrote that String probably forgot a " at the end, which we should make them aware of.

I don't believe this is a good solution as <hover:show_text:"Foo>Bar is a valid mm string (since it never enters string state).

wintry canyonBOT
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] New tag created: v4.25.0
#
kezz
[KyoriPowered/adventure] New release published: v4.25.0

What's Changed

✨ Features

🐛 Fixes

  • Provide the property directly in the properties DefaultOveridePro...
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] New branch created: docs/misc-updates
#
kezz
[KyoriPowered/adventure] branch deleted: docs/misc-updates
wintry canyonBOT
#
jpenilla
[KyoriPowered/adventure-platform-mod] branch deleted: dev/1.21.9
#
jpenilla
[KyoriPowered/adventure-platform-mod] New branch created: mc/1.21.8
#
renovate[bot]
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/me.lucko-fabric-permissions-api-0.x
#
renovate[bot]
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/neoforge
#
jpenilla
[KyoriPowered/adventure-platform-mod] New tag created: v6.7.0
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
Strokkur424
[KyoriPowered/adventure] New comment on issue: #1313 ClickEvent.custom crashes MiniMessage.serialize

It's incredibly low priority considering the fact that MiniMessage is primarily supposed to be a format for easily writing chat components. I doubt there are many people who sit down and think "I need to have NBT payload in my click events". (It does have a use case, yes, but for most simple stuff, people would just make their own little wrapper tag resolver and only ever deserialize from MiniMessage).

I don't think anybody here is directly opposed to having SNBT payload custom click events in the click tag, but somebody would just have to come around to doing it. Feel free to open up a PR, but I almost feel like this is best done after named arguments are merged so that the syntax doesn't get all confused.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[adventure:main/5] 9 new commits

d316898 chore(api): Further refactor (including text packa... - kezz
c5cf917 chore(nbt): modernize and remove deprecated method... - Strokkur424
06c9aab chore(configurate-4): cleanup code - Strokkur424
77945eb chore(minimessage): modernize some code - Strokkur424
6db88bb chore(ansi): replace one switch expression - Strokkur424
1180f89 chore(serializer-gson): modernize gson serializer... - Strokkur424
94f0baa chore(serializer-json): cleanup and modernize json... - Strokkur424
c6a1760 chore(serializer-legacy): cleanup and modernize co... - Strokkur424
595494c chore(serializer-plain): remove deprecated classes - Strokkur424...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[adventure:main/5] 6 new commits

75e444a chore(key): Remove examination and fix module expo... - kezz
15fa91d chore(nbt): Remove examination, fix module exports... - kezz
20fc806 chore(api): Remove examination, fix module exports... - kezz
92ed914 chore(api): Fix checkstyle, build and further misc... - kezz
2b13d04 chore(nbt): Fix checkstyle, build and further misc... - kezz
b9be3f3 chore(misc): Continue work on checkstyle, build, a... - kezz

wintry canyonBOT
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/major-junit-framework-monorepo
#
zml2008
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/gradle.plugin.org.jetbrains.gradle.plugin.idea-ext-gradle-idea-ext-1.x
#
renovate[bot]
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/junit-framework-monorepo
#
zml2008
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
#
zml2008
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/major-checkstyle
#
zml2008
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/major-gradle-and-github-actions
#
renovate[bot]
[KyoriPowered/adventure-platform-mod] branch deleted: renovate/checkstyle
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[KyoriPowered/adventure] New branch created: chore/pre-5-changes
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure] New comment on pull request: #1304 feat(minimessage): named arguments

So a thought on this, why are we creating two different colours of MM tags? I feel like the design would be cleaner if we only had one type of tag, which accepted both named and sequential arguments, same as say with a CLI. For consistency's sake I think it's fair to require all the named args to be at the beginning or end of the tag, but either way there's a bunch of api noise and opportunity for breakages here due to adding named args in as a separate parallel concept.

I'm seeing something like:

<gradient phase=0.4 speed=2 red:green:blue>hi strokkur</gradient>

or:

<gradient:red:green:blue phase=0.4 speed=2>hi strokkur</gradient>

What do you think? Users would just pop named args from the ArgumentQueue same as other items

wintry canyonBOT
#
zml2008
[KyoriPowered/adventure] New comment on pull request: #1327 feat(minimessage): add tag completions

This is pretty hard to review when you've smashing in commits from another PR, please base it off one of the mainline branches (main/4 or main/5) instead.

Feels like there's quite a bit of duplication of parser logic in here as well, try to avoid that.

Is there a way to distinguish between "format" suggestions (so hints, that shouldn't be added to the cmdline literally such as "#RRGGBB") and value suggestions (such as, <c:r suggesting red), where you might want to actually tab-complete those into the command line.

wintry canyonBOT
wintry canyonBOT
#
Rossterd
[KyoriPowered/adventure] New comment on pull request: #1327 feat(minimessage): add tag completions

Hey thanks for the response. yeah its probably not worth spending much time looking at this then. I will wait for main/5 to start successfully building and base it off that.

On the differentiation between hints and concrete suggestions: there is not. While bashing this together I mainly had Brigadier commands on my mind and I don't think those have any dynamic way of showing 'format' suggestions. I will add this (and the tests!) to the todo list for when I get to rebase this PR.

#
jpenilla
[KyoriPowered/adventure-platform-mod] New branch created: feat/modrinth-readme
wintry canyonBOT
wintry canyonBOT
#
Doc94
[KyoriPowered/adventure-platform-mod] New comment on pull request: #223 Add Modrinth backlink to README

What about the title badge here?
https://github.com/PyPylia/Modrinth-Badges/blob/main/README.md

![Modrinth](https://img.shields.io/badge/dynamic/json?labelColor=black&color=grey&label=&query=title&url=https://api.modrinth.com/v2/project/adventure-platform-mod&style=flat&logo=data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAMAAABEpIrGAAAAIGNIUk0AAHomAACAhAAA+gAAAIDoAAB1MAAA6mAAADqYAAAXcJy6UTwAAAJPUExURQAAABvZahWnUha1WAYzGQlHIxvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZahvZah...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[adventure:main/5] 5 new commits

4536524 fix(api): Remove incorrect BossBar$Listener annota... - kezz
37a42fc chore(api): Update since + nbt return type for toB... - kezz
c87ac1f fix(key): Move null/format checks into canonical c... - kezz
103f493 feature(api): Use sealed subclass system for click... - kezz
ae3ad2a docs(api): Add notes about sealed interfaces that... - kezz

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure] branch deleted: indra-4
#
renovate[bot]
[KyoriPowered/adventure] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure] New branch created: chore/5/configurate
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
zml2008
[KyoriPowered/adventure-webui] New branch created: chore/ci-changes
#
zml2008
[KyoriPowered/adventure-webui] branch deleted: chore/ci-changes
#
zml2008
[KyoriPowered/adventure-webui] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
wintry canyonBOT
#
zml2008
[PaperMC/adventure-platform] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
#
zml2008
[PaperMC/adventure-platform] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
zml2008
[PaperMC/adventure-webui] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
Rebble3000
[PaperMC/adventure] Issue opened: #1334 Gradients with negative phases acting weird

I've recently noticed that gradients with more than 2 colors appear incorrectly when their phase is below 0.
I don't think this is an intended feature, since the gradients do appear correctly when their phase is -0.0, but don't when their phase is -0.1.

How to reproduce

Compare the deserialization results of these inputs:
<gradient:#FF0000:#00FF00:#4444FF:-0.0>Hello, World! Lorem Ipsum</gradient> and
<gradient:#FF0000:#00FF00:#4444FF:-0.1>Hello, World! Lorem Ipsum</gradient>

My results both on paper-1.21.4-232 and on webui.advntr.dev:
Image

wintry canyonBOT
#
byquanton
[PaperMC/adventure] Issue opened: #1335 GsonComponentSerializer should allow the payload to be an BinaryTag (main/4)

The GSON Serializer uses the deprecated ClickEvent.custom(Key Key, String data) method and causes a IllegalStateException (Expected STRING but was BEGIN_OBJECT at path $.click_event.payload) when trying to parse a ClickEvent with a custom callback that uses NBT for the payload.

Example Code

try (InputStream stream = Main.class.getResourceAsStream("/example.json")) {
    BufferedReader streamReader = new BufferedReader(new InputStreamReader(stream));
    JsonElement jsonElement = new JsonParser().parse(streamReader);

    GsonComponentSerializer serializer = GsonComponentSerializer.builder()
            .legacyHoverEventSerializer(NBTLegacyHoverEventSerializer.get())
            .build();

    Component component = serializer.deserializeFromTree(jsonElement);
}

{
  "extra": [
    {
      "click_event": {
        "id": "paper:click_callback",
        "payload": {
          "id": [
            1034630811,
            -1696642542,
            -1523289780,
            -15894539```...
wintry canyonBOT
wintry canyonBOT
#
CraziiDust
[PaperMC/adventure] Issue opened: #1336 Add support for waypoints for locatorbar

Hi!
That would be nice if we have support for waypoints for locatorbar.
Based on a waypoint packet, the following methods can be used:

//Track new waypoint
Audience.track(String id, Waypoint waypoint);
Audience.track(UUID uuid, Waypoint waypoint);
//Remove tracked waypoint
Audience.untrack(UUID uuid);
Audience.untrack(String id);
 //Update tracked waypoint
Audience.update(UUID uuid, Waypoint waypoint);
Audience.update(String id, Waypoint waypoint);

and the waypoint class:

Waypoint.empty(); //Empty waypoint

Waypoint.vector(TextColor color, int x, int y, int z); //Vector based waypoint with default style (minecraft:default)
Waypoint.vector(TextColor color, Key style, int x, int y, int z); //Vector based waypoint with style

Waypoint.chunk(TextColor color,  int x, int z); //Chunk based waypoint with default style (minecraft:default)
Waypoint.chunk(TextColor color, Key style, int x, int z); //Chunk based waypoint with style

Waypoint.azimuth(TextColor color,  float angle); //A```...
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[adventure:main/5] 10 new commits

772795b fix: replace all module-level NullMarked with pack... - Strokkur424
e4f2a3d Merge branch 'main/5' into chore/fix-nullability - Strokkur424
a981263 chore: annotated net.kyori.test package as NullMar... - Strokkur424
c9f1dd6 fix(api): start fixing api tests - Strokkur424
c8d181f fix(api): score is no longer flattened, tests shou... - Strokkur424
46a28c5 fix: a bunch of compilation errors and failing tes... - Strokkur424
1707398 chore: bump gson version and fix checkstyle errors - Strokkur424
33ee818 chore: minor changes - Strokkur424
d17e0d2 fix: set interpret default to false - Strokkur424...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[PaperMC/adventure] New branch created: feature/synthetic
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[PaperMC/adventure] New branch created: feature/optional-nbt-payload
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
github-merge-queue[bot]
[adventure:main/5] 9 new commits

eed34fe chore(deps): Update guava monorepo to v33.5.0-jre - renovate[bot]
8b41dd8 chore(deps): Update dependency org.junit:junit-bom... - renovate[bot]
cf2935c feature(api): Make custom payload NBT optional - kezz
e0d7175 feature(minimessage,serializer-gson): Correctly ha... - kezz
508e4de chore(deps): Update dependency com.puppycrawl.tool... - renovate[bot]
f4ea904 Merge pull request #1345 from PaperMC/feature/opti... - kezz
48473fd Merge pull request #1342 from PaperMC/renovate/maj... - kezz
15a3d6e Merge pull request #1341 from PaperMC/renovate/maj... - kezz
1fbe17e Merge pull request #1340 from PaperMC/renovate/gua... - kezz...

#
kezz
[PaperMC/adventure] branch deleted: feature/optional-nbt-payload
wintry canyonBOT
#
kezz
[PaperMC/adventure] New branch created: feature/book-like
wintry canyonBOT
#
kezz
[PaperMC/adventure] branch deleted: feature/book-like
#
kezz
[PaperMC/adventure] New branch created: feature/book-like
wintry canyonBOT
#
kezz
[PaperMC/adventure] branch deleted: feature/book-like
wintry canyonBOT
#
aerulion
[PaperMC/adventure] Issue opened: #1347 MiniMessage Head tag allows for illegal spaces in player names

Expected behavior

The "Head" tag working properly and discarding illegal format.

Observed/Actual behavior

The message results in a RuntimeException because of Player name contained disallowed characters: 'aerulion '
View Exception:
|| [14:00:50 ERROR]: Error sending packet clientbound/minecraft:system_chat io.netty.handler.codec.EncoderException: Failed to encode packet 'clientbound/minecraft:system_chat' at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:62) ~[paper-1.21.10.jar:1.21.10-91-9934c17] at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:13) ~[paper-1.21.10.jar:1.21.10-91-9934c17] at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:27) ~[paper-1.21.10.jar:1.21.10-91-9934c17] at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:12) ~[paper-1.21.10.jar:1.21.10-91-9934c17] at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-4.1.118.Final.jar:4...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[adventure:main/5] 6 new commits

14eddd1 chore(api): Refactor Index from interface to class - kezz
8ee34f4 chore(api): Refactor NamedTextColor from interface... - kezz
f7db98f chore(api): Refactor HoverEvent (and subclasses) f... - kezz
e6c507c chore(api): Refactor ClickEvent and Action from in... - kezz
e9b561e chore(api): Add missing style buildable extends - kezz
e3b5f6a chore(api): Remove UTF8ResourceBundleControl - kezz

#
github-merge-queue[bot]
[adventure:main/4] 8 new commits

c5263b1 feature(api): Add Component#toBuilder and deprecat... - kezz
75fac78 docs(api): Deprecate the "enumness" of ClickEvent.... - kezz
a2fc747 chore(nbt): Make all tag types (and compound tag g... - kezz
0321af2 chore(api): Mark missing non-extendable interfaces - kezz
55847dd chore(serializer-gson): Deprecate builder methods... - kezz
3d2e5dd chore(api): Note the removal of keyed implementati... - kezz
6621182 chore(api): Deprecate UTF8ResourceBundleControl fo... - kezz
7c35f54 Merge pull request #1329 from PaperMC/chore/pre-5-... - kezz...

#
kezz
[PaperMC/adventure] branch deleted: chore/pre-5-changes
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
kezz
[PaperMC/adventure] New tag created: v4.26.0
#
kezz
[PaperMC/adventure] New release published: v4.26.0

Adventure 4.26.0 is hopefully the final release before the full release of 5.0. This release solely contains final changes and deprecations in preparation of the 5.0.

For full information about the 5.0 update, check out the following links:

What's Changed

✨ Features

📚 Documentation

Full Changelog: https://github.com/PaperMC/adventure/compare/v4.25.0...v4.26.0

wintry canyonBOT
#
Turbojax07
[PaperMC/adventure] Issue opened: #1349 Replace BossBarViewer with Audience or use it more.

Currently there is an interface called "BossBarViewer", and it has two uses:

  1. It is used in net.kyori.adventure.bossbar.BossBar#viewers which returns an Iterable<? extends BossBarViewer>.
  2. It defines an activeBossBars function that returns an Iterable<? extends BossBar>.

Given how this interface is not used in the BossBar#addViewer or BossBar#removeViewer, I think it'd be a good idea to either remove the BossBarViewer interface or spread out its use.

To remove the interface, the activeBossBars function could be moved to the Audience interface, which would not be out of line due to Audience already having the showBossBar and hideBossBar functions. Then, the BossBar#viewers function would simply return Iterable<? extends Audience>.

To expand it's use, I think it would be a good idea to move the Audience#showBossBar and Audience#hideBossBar functions to BossBarViewer. The BossBar#addViewer and BossBar#removeViewer functions would also be modified to take a BossBarViewer object as...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
renovate[bot]
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-indra
#
renovate[bot]
[PaperMC/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
#
jpenilla
[PaperMC/adventure-platform-mod] New branch created: dev/1.21.11
wintry canyonBOT
#
jpenilla
[PaperMC/adventure-platform-mod] New branch created: mc/1.21.10
#
jpenilla
[PaperMC/adventure-platform-mod] branch deleted: dev/1.21.11
#
renovate[bot]
[PaperMC/adventure-platform-mod] branch deleted: renovate/neoforge
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
jpenilla
[PaperMC/adventure-platform-mod] New tag created: v6.8.0
wintry canyonBOT
wintry canyonBOT
#
MiniDigger
[PaperMC/adventure] New branch created: debug-workflow
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
zml2008
[PaperMC/adventure] branch deleted: renovate/gradle-and-github-actions
#
zml2008
[PaperMC/adventure] branch deleted: renovate/error-prone-monorepo
#
zml2008
[PaperMC/adventure] branch deleted: renovate/patch-release-dependency-changes
#
zml2008
[PaperMC/adventure] branch deleted: renovate/checkstyle
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
MiniDigger
[PaperMC/adventure] branch deleted: debug-workflow
#
MiniDigger
[PaperMC/adventure] New release published: v4.26.0

Adventure 4.26.0 is hopefully the final release before the full release of 5.0. This release solely contains final changes and deprecations in preparation of the 5.0.

For full information about the 5.0 update, check out the following links:

What's Changed

✨ Features

📚 Documentation

Full Changelog: https://github.com/PaperMC/adventure/compare/v4.25.0...v4.26.0

wintry canyonBOT
#
MiniDigger
[PaperMC/adventure] New tag created: v4.26.1
#
MiniDigger
[PaperMC/adventure] New release published: v4.26.1

Adventure 4.26.1 is hopefully the final release before the full release of 5.0. This release solely contains final changes and deprecations in preparation of the 5.0.

For full information about the 5.0 update, check out the following links:

Note: 4.26.0 was released on GitHub but never deployed and should be considered non existant.

What's Changed

✨ Features

📚 Documentation

Full Changelog: https://github.com/PaperMC/adventure/compare/v4.25.0...v4.26.1

wintry canyonBOT
#
Ontey6
[PaperMC/adventure] Issue opened: #1354 Escaped tags in Serialization

Problem

When calling MiniMessage#serialize(String), all tags are escaped.

Example:

Component deserialized = Component.text("Hello, World", NamedTextColor.GREEN);
String serialized = MiniMessage.miniMessage().serialize(deserialized);

IO.println(serialized);

prints: \<green>Hello, World.

As you can probably see, the green color is escaped.
Then if you deserialize it again, it will be just plain text like <green>Hello, World

Why would you want that?
It especially doesn't make sense, because in the Component, it too, represents a seen color, not its literal name.

Why it's annoying

As everyone knows, you can't really edit a Component like a String, so you sometimes need to convert it to a String.
Then you have a cycle like this: serialize - edit - deserialize.
Then the problem is, that you have a plain String if the component before already had data

Easy solution

I think this should technically work.

Make this simple change in the net.kyori.adventure-text-...

wintry canyonBOT
wintry canyonBOT
#
Ontey6
[PaperMC/adventure] New comment on issue: #1354 Escaped tags in Serialization

No AI used, I can try to make reproduction of the "bug" as clear as possible.
Btw it isn't a bug, it's just implemented that way.

Simple test plugin:

public final class Main extends JavaPlugin implements Listener {
  
   @Override
   public void onEnable() {
      getServer().getPluginManager().registerEvents(this, this);
   }
   
   @EventHandler
   public void onChat(AsyncChatEvent event) {
      event.renderer((source, sourceDisplayName, message, viewer) ->
          // prefix
          Component.text("[", NamedTextColor.GRAY)
            .append(sourceDisplayName.color(NamedTextColor.WHITE))
            .append(Component.text("] ", NamedTextColor.GRAY))
            
            // Message here
            // Just sends the literal output of serialize/serializeOrNull (NotNull)
            .append(Component.text(MiniMessage.miniMessage().serializeOrNull(message)))
            // my personal solution
            //.append(MiniMessageCo```...
wintry canyonBOT
wintry canyonBOT
#
Ontey6
[PaperMC/adventure] New comment on issue: #1354 Escaped tags in Serialization

@masmc05
1. Plain Text Serialization strips colors and everything. If you don't believe me, try it for yourself with the

2. It just doesn't create the same component. I don't know why you think that

Input
{color:"red",text:"Hello, World"}

MiniMessage Serialization
{text:"\<red>Hello, World"}

Plain Text Serialization
{text:"Hello, World"}

As you can probably tell, none of these are the same.

Also @kezz this neither a bug nor not easily reproducable with the Simple Test plugin I already sent, it is a FEATURE REQUEST for you to add:

A method in the MiniMessage class, that serializes a component into a String, which can be deserialized into the same Component simply using MiniMessage#deserialize(String).
That would be handy because right now you would either have to modify the output --> result could vary if there's any change in the API, or access the internal MiniMessageSerializer --> unreadable code, possibly impossible, Change in java version could easily break it.

Btw, it...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
Ontey6
[PaperMC/adventure] New comment on issue: #1354 Escaped tags in Serialization

Just realized I gave a wrong example of this and started at a wrong point - sorry for that.
What I would want is a method which I can deserialize a Component into a String like this:

Component cmp = Component.text("Hello, <green>World", NamedTextColor.RED);
String out = MiniMessage.miniMessage().deepSerialize(cmp);

IO.println(out);

Which outputs: <red>Hello, <green>World, not <red>Hello, \<green>World as serialize does.

So a method that keeps Component formatting without escaping tags in the text unlike the PlainTextComponentSerializer.
This would be pretty useful for editing chat messages

wintry canyonBOT
wintry canyonBOT
#
MiniDigger
[PaperMC/adventure] New branch created: jd-fix
wintry canyonBOT
#
MiniDigger
[PaperMC/adventure-platform-mod] New branch created: jd-fix
#
MiniDigger
[PaperMC/adventure] branch deleted: jd-fix
#
MiniDigger
[PaperMC/adventure-platform-mod] branch deleted: jd-fix
wintry canyonBOT
#
zml2008
[PaperMC/adventure-webui] branch deleted: renovate/adventure
#
zml2008
[PaperMC/adventure-webui] branch deleted: renovate/patch-release-dependency-changes
#
zml2008
[PaperMC/adventure-webui] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
wintry canyonBOT
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle-and-github-actions
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/checkstyle
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/adventure
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/me.lucko-fabric-permissions-api-0.x
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/net.fabricmc.fabric-api-fabric-api-catalog-0.x
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/neoforge
#
zml2008
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-checkstyle
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
PikaMug
[PaperMC/adventure] Issue opened: #1359 Reconsider addition of Conversation API?

Hello, I had suggested the addition of a Conversation API back in 2021 (see #309). Now that PaperMC has deprecated—and intends to remove—the Bukkit Conversation API from Paper (which many plugins do, in fact, rely on), I was wondering if now might be a good time to reconsider? It seems that Kyori is now under the PaperMC organization, but I still feel as though an alternative API could find a home within the adventure project.

The closing note of #309 by zml2008 envisioned this functionality being picked up by the community. It's been over three years since then, but no alternative libraries have been popularized, to my knowledge. The best options I'm aware of are this one developed by @MrIvanPlays and this one worked on by @IllusionTheDev - neither of which has seen wide adoption as of writing.

Given the current circumstances, would the project reconsider adding a Conversation API to adventure?