#adventure

2811 messages · Page 3 of 3 (latest)

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-webui] branch deleted: renovate/ktor-monorepo
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-webui] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

It is currently impossible to alter single translationss after they have been registered without removing the entire key with all translations
My use case for this is a command to register translations during runtime
example:
/translation add <key> <locale> <translation>
/translation remove <key> <locale>

/translation add hello-world en-US Hello World!
/translation add hello-world en-US Hallo Weltt!
/translation remove hello-world de-DE # because of typo
/translation add hello-world de-DE Hallo Welt! # fix spelling

TranslationStore#unregister(String) unregisteres all translations tied to hello-world in this instance even though I only want to remove/override the german translation

wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New branch created: mc/26.1
wintry canyonBOT
wintry canyonBOT
#

Yeah, it appears to be reversing the gradient's color order. as well as introducing a strange offset.

The offset also becomes more obvious if the second line has the colors reverse order.

<gradient:#000000:#00ff00:#0000ff:#ff0000:0>╒═════════════╕</gradient> Phase: 0<newline><gradient:#ff0000:#0000ff:#00ff00:#000000:0>╘═════════════╛</gradient> Phase: 0

<img width="367" height="43" alt="Image" src="https://github.com/user-attachments/assets/a7207d50-cacc-471d-b39c-ccfa0713f3ca" />

<gradient:#000000:#00ff00:#0000ff:#ff0000:0.1>╒═════════════╕</gradient> Phase: 0.1<newline><gradient:#ff0000:#0000ff:#00ff00:#000000:-0.1>╘═════════════╛</gradient> Phase: -0.1

<img width="392" height="47" alt="Image" src="https://github.com/user-attachments/assets/155458f4-807c-4360-9ff4-fbba230fb32a" />

note on the first line how the blue shifted slightly to the left in the second image compared to the first, where as the second line just jumps all the way to the right.

wintry canyonBOT
#

After searching through issues and pulls to see if anyone has mentioned anything similar, I saw a closed issue and a merged pull from several years ago that might indicate that there was a reversion at some point.

https://github.com/PaperMC/adventure/issues/889
https://github.com/PaperMC/adventure/pull/896

In them they mention that gradients with more than two colors bugs out the phase offsets.

After checking it, two color gradients work perfectly fine with negative numbers.

<img width="388" height="108" alt="Image" src="https://github.com/user-attachments/assets/fefebcf1-480b-4538-bb4f-34183d10405e" />

gradients used: #000000:#ff0000 and #ff0000:#000000

wintry canyonBOT
#
[PaperMC/adventure] branch deleted: renovate/gradle-and-github-actions
#

looks like it's time to make some changes to stylecheck, whee:

Caused by: java.lang.NoSuchMethodError: 'com.puppycrawl.tools.checkstyle.api.Scope com.puppycrawl.tools.checkstyle.utils.ScopeUtil.getSurroundingScope(com.puppycrawl.tools.checkstyle.api.DetailAST)'
        at ca.stellardrift.stylecheck.FilteringWriteTag.visitToken(FilteringWriteTag.java:106)
        at com.puppycrawl.tools.checkstyle.TreeWalker.notifyVisit(TreeWalker.java:389)
        at com.puppycrawl.tools.checkstyle.TreeWalker.processIter(TreeWalker.java:462)
        at com.puppycrawl.tools.checkstyle.TreeWalker.walk(TreeWalker.java:327)
        at com.puppycrawl.tools.checkstyle.TreeWalker.processFiltered(TreeWalker.java:211)
        at com.puppycrawl.tools.checkstyle.api.AbstractFileSetCheck.process(AbstractFileSetCheck.java:101)
        at com.puppycrawl.tools.checkstyle.Checker.processFile(Checker.java:341)
        at com.puppycrawl.tools.checkstyle.Checker.processFiles(Checker.java:300)
        ... 55```...
wintry canyonBOT
#
[PaperMC/adventure-webui] branch deleted: renovate/patch-release-dependency-changes
#
[PaperMC/adventure-webui] branch deleted: renovate/ktlint
#
[PaperMC/adventure-webui] branch deleted: renovate/org.jetbrains.kotlinx-kotlinx-serialization-json-1.x
#
[PaperMC/adventure-webui] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
#
[PaperMC/adventure-webui] branch deleted: renovate/ktor-monorepo
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle-and-github-actions
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle.plugin.org.jetbrains.gradle.plugin.idea-ext-gradle-idea-ext-1.x
wintry canyonBOT
#
  • add internal ComponentLogContextInjector and ComponentLogRecord types for forwarding raw component log metadata
  • extend ComponentLoggerProvider.LoggerHelper with backward-compatible delegating(..., injector) overload
  • wire Handler.LoggerHelperImpl to construct WrappingComponentLoggerImpl with optional injector
  • wrap all enabled log paths in WrappingComponentLoggerImpl with injector scope begin/close, swallowing injector errors and preserving existing output behavior
  • add tests for raw record capture, throwable forwarding, scope close lifecycle, and injector failure tolerance

This will allow for Endermux to forward rich log messages over the socket.

wintry canyonBOT
#
[PaperMC/adventure] branch deleted: renovate/major-gradle-and-github-actions
#
[PaperMC/adventure] branch deleted: renovate/error-prone-monorepo
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-webui] New branch created: feature/open-api
wintry canyonBOT
#

Add <legacy> tag to MiniMessage, which could handle legacy ampersand-based color codes

Example:
<legacy>&l&cSome legacy text</legacy> -> (effectively would display as) -> <bold><red>Some legacy text</red></bold>

Example scenario, Why this would be useful to some:

  • User has a 1.8-based server, so they have a 16 char nametag limit.
  • They want to use the same rank meta for the nametag prefix as in somewhere where only MiniMessage is supported
  • They can easily just wrap it with the <legacy> tag
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-platform] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
#

This PR adds back some toString implementations that were dropped with the removal of the examination api on classes that were not converted to records.

Unless I missed something, everything that was previously implementing Examinable should now be either a record or have its own toString (except StyleImpl, which is covered by #1373).

(The links take you to the old examinable implementation on main/4)

wintry canyonBOT
wintry canyonBOT
#

This is a minor thing, but you might as well remove the if-statement and move the return block into the try block directly. That also saves you from having a mutable uuid variable floating around.

    try {
      final UUID uuid = UUID.fromString(argument);
      return Tag.selfClosingInserting(Component.object(
        ObjectContents.playerHead()
          .id(uuid)
          .hat(outerLayer.toBooleanOrElse(PlayerHeadObjectContents.DEFAULT_HAT))
          .build()
    } catch (final IllegalArgumentException ignored) {
      // If UUID parsing fails, try other options
    }
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

Hello! I've discovered a small bug in MiniMessage: MiniMessage warns that legacy color codes aren't supported in the <click:open_url:'[url]'</click> style descriptor.

This shouldn't happen, as MiniMessage doesn't process styles inside links.

As a result, MiniMessage simply spams the console with warnings:

<img width="1010" height="68" alt="Image" src="https://github.com/user-attachments/assets/22ba7e58-4eba-4f1a-8cfb-568cd7db60f0" />

wintry canyonBOT
wintry canyonBOT
#

feet vs eyes

If you just call the public void playSound(final net.kyori.adventure.sound.@NotNull Sound original) on an audience, it'll grab their position via createPosition which in BukkitFacet just turns the target player's location into a vector. This means that in effect, the sound will play at the feet of the player.

The craft places the listener for the audio at the eye height of the player. This means if the volume if the sound is 1f, and we assume a non shifting eye-height of 1.62f; we can expect up to a 0.10125 consistent error in volume. Instrumenting the (1.8.9) game to measure this, the picture becomes clear:

<img width="1800" height="900" alt="Image" src="https://github.com/user-attachments/assets/91d39a9c-0de0-4103-bab4-9b070abe84df" />

(the x axis is the volume of the sound played, and there were 100 sounds played over the 0-1 range)

The error is apparent and makes itself very known by the time it reaches 1f volume, it being 10% quieter than it should be, and all...

wintry canyonBOT
#

Hey,

the following mini-message strings are not deserialized and then serialized back to an string correctly.

before de-/serialization: <white>[<gradient:#e83920:#ffe5dd>ABCDEF<white>]

Result of the component: TextComponentImpl{content="", style=StyleImpl{obfuscated=not_set, bold=not_set, strikethrough=not_set, underlined=not_set, italic=not_set, color=NamedTextColor{name="white", value="#FFFFFF"}, shadowColor=null, clickEvent=null, hoverEvent=null, insertion=null, font=null}, children=[VirtualComponentImpl{content="", style=StyleImpl{obfuscated=not_set, bold=not_set, strikethrough=not_set, underlined=not_set, italic=not_set, color=null, shadowColor=null, clickEvent=null, hoverEvent=null, insertion=null, font=null}, children=[TextComponentImpl{content="", style=StyleImpl{obfuscated=not_set, bold=not_set, strikethrough=not_set, underlined=not_set, italic=not_set, color=null, shadowColor=null, clickEvent=null, hoverEvent=null, insertion=null, font=null}, children=[TextComponentImpl{content="B", styl_...

wintry canyonBOT
#

Adventure 5.0 has support for JPMS and should be able to use the uses keyword in its module-info for it platform services API. See https://dev.java/learn/modules/services/. This does not replace the service files in most implementations as they are required if the user application runs in the unnamed module. (Using JPMS erasure like shadowJar or fatjars)

Also it seems you might be missing the java.modularity.inferModulePath = true option in Gradle for JPMS which could explain why module annotations didnt work.

Would love to see this before 5.0 is released.

wintry canyonBOT
wintry canyonBOT
#

Since https://github.com/PaperMC/Paper/pull/13585 the SkinSource of Player and OfflinePlayer uses the whole profile and not only the player id. Due to this change (which is correct, the full profile should be used) the serialization to a MiniMessage string is no longer possible due to java.lang.IllegalStateException: Unclaimed component ObjectComponentImpl.

Without profile properties in the SkinSource this is working fine and it makes sense it's not working as there is no mini message tag to create player head object contents using only the profile properties. It's not a big deal, just avoid using the Player or OfflinePlayer as SkinSources if you want to serialize it. The proper fix for this would be to have the head tag support all possible skin sources, however this may take some time as this is not planned until named arguments are supported iirc. Maybe there is some way to just ignore the additional arguments that can't be handled by the head tag for now?

This example fails durin...

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-gradle-and-github-actions
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/org.jetbrains-annotations-26.x
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle-and-github-actions
#
[PaperMC/adventure] branch deleted: renovate/patch-release-dependency-changes
#
[PaperMC/adventure] branch deleted: renovate/error-prone-monorepo
#
[PaperMC/adventure] branch deleted: renovate/org.jetbrains-annotations-26.x
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

Ive noticed these methods were showing up in my profile report (Custom GUIs heavily use colors to pass data to custom shaders).

Both of these used slow methods (weird append) & String#format, in JDK 17 HexFormat was introduced, which is way faster for this task.

Another optimization that could be made for NamedTextColor (storing its hex string), but ideally you should store the name instead of the hex string. I havent done this in this PR.

Below are some benchmarks for TextColor similar methods, benchmark class here. (Only tested TextColor based methods & alternatives). I have not tested ShadowColor but its likely way faster just on preliminary benchmarks of a normal String#format.

Benchmark                            Mode  Cnt   Score   Error  Units
AdventureBenchmark.adventure         avgt   30  24.434 ± 0.211  ns/op
AdventureBenchmark.hexFormat         avgt   30   5.393 ± 0.047  ns/op
AdventureBenchmark.hexFormat2        avgt   30   5.487 ± 0.185  ns/op
AdventureBenc```...
wintry canyonBOT
#

Pull request overview

Backports a fix to text-minimessage’s sequential <head:...> tag parsing to rely on UUID.fromString rather than a UUIDv4-only regex, improving compatibility with non-v4 UUIDs.

Changes:

  • Removed the UUIDv4-only regex check in SequentialHeadTag.
  • Added UUID parsing via UUID.fromString and re-used the parsed UUID when building the head component.

💡 <a href="/PaperMC/adventure/new/main/5?filename=.github/instructions/*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.

#

Using UUID.fromString(argument) inside a try/catch means non-UUID inputs (names/textures) will throw and catch an IllegalArgumentException on the common path, which is relatively expensive during parsing. Consider adding a cheap format guard (e.g., length/hyphen positions/hex check, or a precompiled non-version-specific UUID pattern) before calling UUID.fromString, so exceptions are reserved for truly exceptional cases.

wintry canyonBOT
#
[PaperMC/adventure] New branch created: feature/tag-presets
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure] New branch created: version/26.1
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

We might also want to make use of the fallback property of object components in ComponentFlattener

I'm also fine to leave the current behaviour as-is. If we get any real-world requests for this we can reconsider then, but for now I think it's fine to ignore the fallback in this example.

wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/net.fabricmc.fabric-api-fabric-api-catalog-0.x
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New tag created: v6.9.0
wintry canyonBOT
#
[PaperMC/adventure] branch deleted: version/26.1
#
[PaperMC/adventure] branch deleted: feature/tag-presets
wintry canyonBOT
#
[PaperMC/adventure] New tag created: v5.0.0
#

Adventure 5.0.0 is a major update to the Adventure library, including an updated Java version, removal of deprecations, and other breaking changes. The 5.0.0 update represents a major milestone in the development of the Adventure library, with 7,000+ additions and 12,000+ deletions across over 500 files.

[!IMPORTANT]
Although we have tried our hardest to avoid unnecessary breaking changes, we do expect this update to contain bugs or unintentional breaking changes and the Adventure team is prepared to release hotfixes as needed. Please report any issues that you find and reach out for help in the #adventure-help channel of the PaperMC Discord if you need to.

Please read the migration information on the Adventure documentation for full information about the changes made in this update and notes about migrating from the 4.x series to 5.x.

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

Wh...

wintry canyonBOT
#

Mockito cannot mock this class: interface org.bukkit.entity.Player.

If you're not sure why you're getting this error, please open an issue on GitHub.

Java : 25
JVM vendor name : Microsoft
JVM vendor version : 25+36-LTS
JVM name : OpenJDK 64-Bit Server VM
JVM version : 25+36-LTS
JVM info : mixed mode
OS name : Linux
OS version : 6.17.0-1010-azure

You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc.

Underlying exception : org.mockito.exceptions.base.MockitoException: Could not modify all classes [interface org.bukkit.Nameable, interface org.bukkit.entity.Damageable, interface org.bukkit.entity.AnimalTamer, interface net.kyori.adventure.identity.Identified, interface org.bukkit.attribute.Attributable, interface org.bukkit.metadata.Metadatable, interface org.bukkit.entity.HumanEntity, interf...

wintry canyonBOT
wintry canyonBOT
#

Previously, these will fail because utils doesn't declare uses on every provider. The simple fix would just to add this to the uses, but this would just be a hack. Instead, we should pass through the service provider of the module so it has the correct module information so we can declare uses in the correct modules that uses them.

All previous services methods have been deprecated in favor of this. Also, the behavior is slightly changes as Services0 uses ServiceLoader(clazz, clazz.getClassLoader()) Which should no longer be needed as it uses the same class loader as the thread that initializes the class.

Should also resolve https://github.com/PaperMC/adventure/issues/1384, didn't realize it would be an issue before then.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure] New branch created: feature/mega-docs
wintry canyonBOT
#
[PaperMC/adventure] branch deleted: feature/mega-docs
#
[PaperMC/adventure] New branch created: fix/shadow-jd
#
[PaperMC/adventure] branch deleted: fix/shadow-jd
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure] New branch created: chore/remove-sfa-deprecation
#
[PaperMC/adventure] branch deleted: chore/remove-sfa-deprecation
wintry canyonBOT
#
[PaperMC/adventure-platform] branch deleted: renovate/major-gradle-and-github-actions
wintry canyonBOT
#
[PaperMC/adventure] New tag created: v5.0.1
#

5.0.1 is a bugfix update containing a fix for leftover checker annotations and some minor edits to the Javadocs. We are now publishing an aggregate Javadoc for all core Adventure libraries (in this repo) available on the standard PaperMC Javadoc portal at https://papermc.io/javadocs/.

What's Changed

🐛 Fixes

📚 Documentation

Full Changelog: https://github.com/PaperMC/adventure/compare/v5.0.0...v5.0.1

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

[15:19:01 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.11.jar:1.21.11-DEV-c5a2736] at net.minecraft.network.codec.IdDispatchCodec.encode(IdDispatchCodec.java:13) ~[paper-1.21.11.jar:1.21.11-DEV-c5a2736] at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:27) ~[paper-1.21.11.jar:1.21.11-DEV-c5a2736] at net.minecraft.network.PacketEncoder.encode(PacketEncoder.java:12) ~[paper-1.21.11.jar:1.21.11-DEV-c5a2736] at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107) ~[netty-codec-base-4.2.7.Final.jar:4.2.7.Final] at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:827) ~[netty-transport-4.2.7.Final.jar:4.2.7.Final] at io.netty.channel.AbstractChannel...

wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure] New branch created: fix/nsme-component-build
#

Users upgrading to 5.x encountered NoSuchMethodError: 'net.kyori.adventure.text.Component net.kyori.adventure.text.TextComponent$Builder.build()' when running code compiled against version 4.x.
This occurred because 5.x removed the intermediate Buildable and BuildableComponent interfaces. While ComponentBuilder still provides a build() method, leaf interfaces (like TextComponent.Builder) no longer explicitly overrode it. In the absence of an explicit override, the Java compiler seems to not generate the necessary bridge methods (covariant return type metadata) in the leaf interface's bytecode that 4.x-compiled code expects.

This PR adds explicit @Override declarations for the build() method in all leaf component builder interfaces which force the Java compiler to generate bridge methods in the resulting class files, thus restoring binary compatibility (i think).

wintry canyonBOT
#
[PaperMC/adventure] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
wintry canyonBOT
#

It appears that ClickEventValueMode.CAMEL_CASE creates a "clickEvent" with the value "command" rather than "value" breaking backward compatibility with clients prior to version 1.21.5.

Previously, if "emitCamelCaseClick" was passed to StyleSerializer, a separate component was created for backward compatibility with "value":
https://github.com/PaperMC/adventure/blob/main/4/text-serializer-gson/src/main/java/net/kyori/adventure/text/serializer/gson/StyleSerializer.java#L417-L429

Now the same component is always created with "command":
https://github.com/PaperMC/adventure/blob/898722f8a9cbcfa0c12c58fb0d3aaee104306220/text-serializer-gson/src/main/java/net/kyori/adventure/text/serializer/gson/StyleSerializer.java#L420-L428

How to reproduce:

public class Test {

    private static final GsonComponentSerializer GSON_SERIALIZER = GsonComponentSerializer.builder()
            .options(JSONOptions.schema().stateBuilder()
                    .value(EMIT_CLICK_EVENT_TYPE, JSONOptions.ClickE_```...
wintry canyonBOT
#
[PaperMC/adventure] branch deleted: renovate/guava-monorepo
#
[PaperMC/adventure] branch deleted: renovate/io.freefair.aggregate-javadoc-io.freefair.aggregate-javadoc.gradle.plugin-9.x
#

06478cf fix(all): Fix SPI when using modules. - kermandev
95b809c chore(api): Update version to 5.1.0 - kermandev
55a11a5 chore(api): Update forgotten version to 5.1.0 - kermandev
227f7eb fix(all): Update ServiceLoader to use class loader... - kermandev
50555fc revert(api): Use Services for api module only as i... - kermandev
fea4cbf deprecate the old methods for service loading - kezz
75614f7 use the classloader for api services - kezz
a7b5a60 Merge pull request #1396 from kermandev/fix/spi - kezz...

#
[PaperMC/adventure] New branch created: fix/negated-tags
#
[PaperMC/adventure] New branch created: fix/gson-camel-value
#
[PaperMC/adventure] branch deleted: fix/negated-tags
#
[PaperMC/adventure] branch deleted: renovate/error-prone-monorepo
#
[PaperMC/adventure] branch deleted: fix/gson-camel-value
wintry canyonBOT
#

lang json:

{
    "steampipe.test": "%2$s %1$s"
}

minimessage: <lang:steampipe.test:'<red>123456':'<lang:steampipe.test:'<green>123456':'123987'>'>
result:

<img width="655" height="48" alt="Image" src="https://github.com/user-attachments/assets/89225dfc-6655-4b8b-b2cc-7f0efe99302e" />
expect:
<img width="258" height="26" alt="Image" src="https://github.com/user-attachments/assets/8fb90af2-7036-4e5e-9f30-5a33c4b69adf" />

#

The correct MiniMessage string would be <lang:steampipe.test:'<red>123456':"<lang:steampipe.test:'<green>123456':'123987'>"> or <lang:steampipe.test:'<red>123456':'<lang:steampipe.test:\'<green>123456\':\'123987\'>'> as you just prematurely are closing the single quotes. I would recommend you using https://webui.advntr.dev/ for such tests

Another question, if we need to nest three layers, is it impossible to express it?

wintry canyonBOT
#
[PaperMC/adventure] New branch created: feature/invalid-namespace
wintry canyonBOT
#
[PaperMC/adventure] New branch created: feature/username-validation
wintry canyonBOT
#
[PaperMC/adventure] New branch created: feature/url-validation
wintry canyonBOT
#
[PaperMC/adventure] branch deleted: feature/url-validation
#
[PaperMC/adventure] branch deleted: fix/nsme-component-build
#
[PaperMC/adventure] New branch created: feature/no-negative-change-page
#
[PaperMC/adventure] branch deleted: feature/no-negative-change-page
#
[PaperMC/adventure] New tag created: v5.1.0
#

Adventure 5.1.0 is primarily a bug-fix update for some unintentional breaks caused by the 5.0 release.

This update also includes stricter validation for key namespaces and click event construction, and also adds new methods to check the validity of click event payloads. Although the validation added is generally stricter than older Minecraft versions, the validation is still correct for all versions. If you have issues with the validation added, please open an issue!

What's Changed

✨ Features

wintry canyonBOT
wintry canyonBOT
#

Adventure 5.x is not consumable via Maven — only via Gradle. This is a regression from the 4.x line, which resolves cleanly from both.

Repro

$ curl -s -o /dev/null -w "%{http_code}\n"         https://repo.maven.apache.org/maven2/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.pom
200

$ curl -s -o /dev/null -w "%{http_code}\n"         https://repo.maven.apache.org/maven2/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0.jar
404

$ curl -s -o /dev/null -w "%{http_code}\n"         https://repo.maven.apache.org/maven2/net/kyori/adventure-api/5.1.0/adventure-api-5.1.0-patched.jar
200

Concretely, any Maven build that pulls adventure-text-minimessage:5.1.0 fails with:

Could not find artifact net.kyori:adventure-api:jar:5.1.0 in <repo>

even though Maven Central serves the POM with a 200.

Root cause

The POM at .../adventure-api-5.1.0.pom declares the artifact as a normal jar packaging (no classifier), so Maven resolves it to adventure-api-5.1.0.jar —...

wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure] New tag created: v5.1.1
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New branch created: chore/no-platform-api-dep
wintry canyonBOT
#

Thanks for the PR. Unfortunately I'm going to go ahead and close this. From a discussion with the team and implementing platforms, it's been decided that a raw NBT serializer is not going to be used by many (if any) large implementing platforms and as no native implementing platforms would use it, the maintenance burden will be too high on the Adventure team.

Now that Adventure 5 is released, we're likely going to spend time revitalizing the DFU-related PR, which will be extension bring in an indirect method of NBT serialization. This is mainly because a DFU module would be used by native platforms, thus decreasing the maintenance burden on the team.

You're more than welcome to continue this PR as your own non-official library, and we will welcome PRs to the community libraries page.

wintry canyonBOT
#

adventure-platform-neoforge 6.9.0 cannot join a single-player world in the development environment, using either the ModDevGradle or Arch Loom toolchain.

Step to reproduce:

  1. Add net.kyori:adventure-platform-neoforge:6.9.0 as a dependency
  2. Sync Gradle project
  3. Run client
  4. Create a single-player test world
  5. Got an error: Client disconnected with reason: Internal Exception: java.lang.ExceptionInInitializerError

Example repository for reproduction:
https://github.com/qyl27/sturdy-waddle/tree/mdg for ModDevGradle, use the :runClient task.
https://github.com/qyl27/sturdy-waddle/tree/arch-loom for Arch Loom, use the :neoforge:runClient task.

P.S.: It works fine if I launch a production game with adventure-platform-mod mod. (From https://modrinth.com/mod/adventure-platform-mod, file id: MlvIVAQU)

wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: chore/no-platform-api-dep
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure] New branch created: MiniDigger-patch-1
#
[PaperMC/adventure-platform-mod] New branch created: MiniDigger-patch-1
#

hey, thanks for the heads-up, seems like you are the first to actually care about these, lol. Kinda surprised nobody (as in maven, gradle, artifactory, nexus, maven central) cares to verify this.
I opened https://github.com/PaperMC/adventure/pull/1423 and https://github.com/PaperMC/adventure-platform-mod/pull/256 to change them to the new PaperMC key I created a few weeks ago.
Does this block you in any way? as in, should we make a patch release or something? or can we just wait for the next properly planned release?

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

Sorry, rechecking this, and figured it should be reopened.

Wouldn't @UnmodifiableView be the correct annotation for the Audience#activeBossBars function @Unmodifiable is for if the contents of the collection never change, but the active boss bars of a player can change, which is why @UnmodifiableView was used.

Sorry about the confusion, I haven't used the jetbrains annotations for very long.

wintry canyonBOT
#

Sure, but the contents of the return value do not change.

The "view" is dependent on whether the object returned by the method will be able to change. Think of it like this:

  1. I call Iterable<? extends BossBar> bossbars = Audience.activeBossBars()
  2. I add a boss bar to the audience.
  3. I now iterate through bossbars. Does it contain the newly added boss bar?

If 3 is true, then it is a view. If it does not contain the newly added boss bar, then it's not a view, but a copy.

Generally, the question on if you want to use a view or not depends on what you expected. In immutable design, which the adventure library mostly follows, I personally generally expect the return values of methods to not be mutable/change.

In the ForwardingAudience implementation of the activeBossBars method, you create a new set and add all other audience's boss bars to that set. It is inherently impossible to provide a view, as addAll copies the collection entries, it doesn't keep a reference to...

wintry canyonBOT
#

I've been looking a lot at the BossBar api and wanted to propose a few changes.
I'm not one to figure out when things should be deprecated/removed, but I can throw out deprecation in v5, removal in v6 as a plan.

  1. Converting BossBar to a class and removing BossBarImpl.
    • BossBar is currently a sealed interface with BossBarImpl being its only permitted implementation.
    • I don't think that there are any plans to make another implementation of BossBar (correct me if I'm wrong).
    • This won't break any of the main implementations of adventure. The Paper, Velocity, Sponge, Fabric, and NeoForge implementations not only still use the adventure 4 api, but they all use BossBar instead of BossBarImpl.
    • It can also reduce confusion between BossBarImpl and BossBarImplementation, as they have similar names.
  2. Remove HackyBossBarPlatformBridge.
    • Only the Sponge API uses this class, and it's used to make BossBarImpl implement their BossBarBridge class.
    • The mixin can eas...
wintry canyonBOT
#
  1. Basically all adventure API types are interfaces, so I don't think there exists any reason for why BossBar specifically should not be an interface either. Furthermore, changing it at this point would result in binary incompatibility. The reason being that when you call a method on an interface, the JVM bytecode does an invokeinterface call. If it were a class, the JVM bytecode would actually be an invokevirtual call, which is different. Thus plugins using the old API would no longer work.

  2. This one is weird for sure. I have nothing to do with Sponge, so I will not say anything here.

  3. I don't necessarily have a strong opinion on whether Iterable or Set is better. I personally would probably also choose Set, as I generally expect the values to be unique, and it provides some better utilities regarding "hey is this Audience inside the viewers?". However the wildcard generic should be kept. The difference between BossBarViewer and ? extends BossBarViewer is that the second (and cu...

wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New branch created: mc/26.2
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/junit-framework-monorepo
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/fabricloader
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/vineflower
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle-and-github-actions
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/net.fabricmc.fabric-api-fabric-api-catalog-0.x
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New branch created: dev/adventure-5
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

I’d like to suggest considering CodeRabbit as an optional supplemental reviewer for pull requests in this repository, and possibly PaperMC more broadly if it proves useful.

I'm going to preface this straight away by stating that I am not in any way affiliated or sponsored by this company. I just like the product given my own use cases and think it would be beneficial here - and is free for OSS.

This tool should obviously never replace the eyes of actual humans, or dictate coding principles within PaperMC as a whole, or Adventure specifically. The hope is that it should reduce some of the repetitive review burden and give contributors earlier feedback before a maintainer has time to spend on their PR(s).

Some background from me:
Background:
||I've been involved with the Minecraft development community for over 10 years, working on my own servers, developing for other servers, publishing plugins, etc.
The Minecraft community is a large part of...

wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle-and-github-actions
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
#

Pull request overview

This PR updates the project to Adventure 5, removing now-incompatible mixins (due to sealed Identity and SignedMessage.Signature) and replacing them with explicit conversion methods, while also dropping the examination dependency and deprecated sendMessage overloads.

Changes:

  • Bump net.kyori:adventure-* to 5.1.1 and remove examination (examination-api, examination-string) from dependency management and shading.
  • Remove GameProfile, MessageSignature, and SignedMessage.signature mixins/injected interfaces and switch to conversion helpers (MinecraftAudiences.asAdventure/asNative).
  • Remove deprecated sendMessage(Identity, Component, MessageType) overrides from audiences and adjust chat delete/signature usage accordingly.

Reviewed changes

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

Show a summary per file:
||| File | Description |
| ---- | ----------- |
| mod-shared/...

wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: dev/adventure-5
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-adventure
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: feat/modrinth-readme
#
[PaperMC/adventure-platform-mod] New tag created: v7.0.0
#

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

What's Changed

Other

New Contributors

Full Changelog: https://github.com/PaperMC/adventure-platform-mod/compare/v6.9.0...v7.0.0

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

The following code compiled against Adventure 4.26.1 (Paper 1.21.11)

Component c = Component.text().build();

no longer works when running on Adventure 5.1.1 (Paper 26.2)

java.lang.NoSuchMethodError: 'net.kyori.adventure.text.BuildableComponent net.kyori.adventure.text.TextComponent$Builder.build()'

Bytecode:

INVOKESTATIC net/kyori/adventure/text/Component.text ()Lnet/kyori/adventure/text/TextComponent$Builder; (itf)
INVOKEINTERFACE net/kyori/adventure/text/TextComponent$Builder.build ()Lnet/kyori/adventure/text/BuildableComponent; (itf)

I'm not sure if it's possible to fix this since the bytecode directly references a removed class?

wintry canyonBOT
#
[PaperMC/adventure] New branch created: fix/expand-legacy-component-builder-abi-fix
wintry canyonBOT
#
[PaperMC/adventure] branch deleted: MiniDigger-patch-1
#
[PaperMC/adventure] branch deleted: renovate/junit-framework-monorepo
#
[PaperMC/adventure] branch deleted: feature/easy-object-component
#
[PaperMC/adventure] branch deleted: renovate/org.ow2.asm-asm-9.x
#
[PaperMC/adventure] branch deleted: fix/expand-legacy-component-builder-abi-fix
#
[PaperMC/adventure] New tag created: v5.2.0
#

Adventure 5.2.0 is primary a bugfix update to restore a break in binary compatibility for users compiling against 4.x but running against 5.x.

This issue was caused by the removal of BuildableComponent, which would cause a MethodNotFoundException for those using component builders. BuildableComponent will remain deprecated and will be fully removed in 6.0 with no replacement. The only use of BuildableComponent in 4.x was to turn a component into a builder (which involved casting to BuildableComponent), but this is now solved by the promotion of the toBuilder method to the root Component class.

The fix for this restores the interface to the component hierarchy and adds another compile-time synthetic bridge to fix code compiling against 4.x. The bridge methods will be removed in 6.x so we still encourage everyone to update to 5.x.

What's Changed

✨ Features

#
[PaperMC/adventure] tag deleted: v5.2.0
#
[PaperMC/adventure] New tag created: v5.2.0
#

Adventure 5.2.0 is primary a bugfix update to restore a break in binary compatibility for users compiling against 4.x but running against 5.x.

This issue was caused by the removal of BuildableComponent, which would cause a MethodNotFoundException for those using component builders. BuildableComponent will remain deprecated and will be fully removed in 6.0 with no replacement. The only use of BuildableComponent in 4.x was to turn a component into a builder (which involved casting to BuildableComponent), but this is now solved by the promotion of the toBuilder method to the root Component class.

The fix for this restores the interface to the component hierarchy and adds another compile-time synthetic bridge to fix code compiling against 4.x. The bridge methods will be removed in 6.x so we still encourage everyone to update to 5.x.

What's Changed

✨ Features

wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New tag created: v7.1.0
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: MiniDigger-patch-1
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

Its a serializer for our custom legacy format that is a bit different to the general legacy format. For serialisation to this format we use the following, the only diference to the basic flattener is that in urls the ampersands should ne kept as they are while in text contents it should be doubled to avoid misinterpretation as color codes:

    private final static ComponentFlattener FLATTENER = ComponentFlattener.basic().toBuilder().mapper(TextComponent.class, c -> c.clickEvent() != null && c.clickEvent().action() == Action.OPEN_URL && c.clickEvent().payload() instanceof Text s ? s.value() : c.content().replace("&", "&&")).build();
    private final static LegacyComponentSerializer SERIALIZER = LegacyComponentSerializer.builder().character('&').hexColors().hexCharacter('x').flattener(FLATTENER).build();

I think the best way would be that we just copy the code vom ComponentFlattenerImpl that initializes the basic flattener so we can start with an empty builder and avoid ....

wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New branch created: fix/neoforge-dev-service-providers
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] branch deleted: fix/neoforge-dev-service-providers
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/patch-release-dependency-changes
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle-and-github-actions
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/net.fabricmc.fabric-api-fabric-api-catalog-0.x
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-mod.publish.plugin
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/major-gradle-and-github-actions
#
[PaperMC/adventure-platform-mod] branch deleted: renovate/gradle.plugin.org.jetbrains.gradle.plugin.idea-ext-gradle-idea-ext-1.x
wintry canyonBOT
#
[PaperMC/adventure-platform-mod] New tag created: v7.1.1
wintry canyonBOT
wintry canyonBOT
#

Plain RGB interpolation makes many gradients pass through muddy gray/brown midpoints. This PR adds an optional color space as the first argument to the gradient tag:

<gradient:oklch:red:blue>hello world</gradient>
<gradient:hsv:#ff0000:#0000ff:0.5>phase still works</gradient>

Supported spaces are rgb, hsv, oklab, and oklch.
Intentionally minimal and does not add public API unlike #1063.

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

Hey, I noticed a small bug with the regex pattern for the namespace pattern in @KeyPattern that was introduced in this commit.
The new regex now ends with a dollar sign which forces the end of the line after all characters matching the previous set were matched.
This matching behaviour works fine with the existing @KeyPattern.Namespace and @KeyPattern.Value annotations but it breaks the @KeyPattern. The regex for @KeyPattern consists of the namespace regex and the value regex. But due to the newline it wont match keys in the format namespace:value (e.g. minecraft:dirt) anymore.
This is because the full pattern now resolves to (?:(^(?!\.\.$)[a-z0-9_.-]+$:)?|:)[a-z0-9_\-.\/]+ which expects a end of line after the namespace. Because a namespace always has to be followed by a colon but also must end with the end of the line (according to the regex) this creates a condition which is i...

wintry canyonBOT
#

Hi,
this PR aims to fix #1435.
I removed the ^ and $ at the start and end of the regex respectively as they are already enforced by the usages of the regex itself. The regex is not used in a way that it could only match a part of the pattern.
If I only remove those the regex would match .. again as valid to prevent that I added a non-capturing group inside the negative lookahead to make it compatible with a full key of the form namespace:value.
This non-capturing group does accept the end of the line or a colon as the end the namespace and therefore works either for matching the namespace or a full key.
All tests still pass and the warnings for @KeyPattern align with the expected test results as far as I can tell.

Any feedback is welcome :slightly_smiling_face:

wintry canyonBOT
#
[PaperMC/adventure] New branch created: feat/minimessage-context
#

We currently prevent rendering VirtualComponents through TranslatableComponentRenderer when they are used as arguments to a TranslatableComponent. Supporting them requires extending the renderer and overriding renderTranslatable to restore that behavior, which is not ideal.

I'm open to suggestions for a better name than MiniMessageContext. It feels more specific than necessary, and ideally the API should be generic enough that it isn't tied to MiniMessage.

wintry canyonBOT
#

Thing is, more than if the virtual component is translatable or not, the thing in question is if it can be rendered at all, or if its just a piece of context that shall remain untouched when inside translatable components, so that a translator (minimessage's translator in this case) can take care of it.

In these cases, it does make sense that the context type is a dummy class because its explicitly being marked as cannot-and-shouldnot-render-this, the context type isnt needed.

I do think a more generic name for this context type could be used but i can't come up with anything better.

wintry canyonBOT
#

I still consider that forcing a specific context type for virtual components that are such data holders is wrong. Some may want this renderer to ignore the component, while a different non-adventure renderer to still render it. And also in the future if a new adventure renderer would need to handle them differently again this approach would force either both ignored or none.
A different solution to this if the method isn't good would be a marker interface. If the renderer implements it then it would be ignored (and all minimessage ones would implement it)

wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#
[PaperMC/adventure-webui] branch deleted: renovate/patch-release-dependency-changes
wintry canyonBOT
wintry canyonBOT
wintry canyonBOT
#

This fixes an issue in modular environments when using the JSONComponentSerializer directly (as opposed to GsonComponentSerializer) where it fails to find a service provider for JSONComponentSerializer.Provider so it falls back to the dummy impl which only throws exceptions.
A similar case applies to the data component value converter, but in that situation all providers are collected so the gson one is skipped and its converters are not registered.

wintry canyonBOT
wintry canyonBOT