what mbax said, but for an official project statement:
no
2811 messages · Page 3 of 3 (latest)
what mbax said, but for an official project statement:
no
Minecraft's dialog feature is not available for servers below 1.21.6, which adventure still supports to my knowledge. Still, thanks for your consideration.
why not? it's definitely a queer-adjacent identity, and it's low-risk and low-maintenance to add one more flag
why not? it's definitely a queer-adjacent identity, and it's low-risk and low-maintenance to add one more flag
This term has a very suggestive connotation, and we do not want to have 12-year-old kids look up the keyword they learn from Minecraft on the internet. Hopefully, I hope this is not what you want.
we aren't prudes here, grow up
2084a0e chore: resolve usage of internal api - zml2008
There is no reason why these methods should be package-private; making them public costs nothing (it does not break backward compatibility) and allows for the implementation of external compression types (e.g., Zstd).
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
This pull requests implements the Hytale platform for Adventure. I wrote the HytaleComponentSerializer while being optimistic that Hytale would eventually improve their message format to support further advanced messages in the base game.
261d014 Initial update for 26.1-snapshot-4 - jpenilla
Most likely not going to be merged due to being unfit for this repository - moved to https://github.com/ArikSquad/adventure-platform-hytale
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.
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
We intentionally don't support other compression types.
54caac9 chore(deps): Bump gradle errorprone plugin version - zml2008
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```...
This will allow for Endermux to forward rich log messages over the socket.
How worried are we about the unconditional extra allocations from capturing new Runnable instances for every log method? I'm used to most logging libs being very concerned about allocations, but i'm not sure how real that impact is in modern JVMs
I think it's a valid concern, I've inlined the scope management.
a926295 feature: Initial work on Open API documentation - kezz
This includes swagger and redoc docs generated using annotations and the describe dsl.
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:
We will not be doing this. Mixing formats is a non-goal of MiniMessage.
Closed in f27065cec8c34bb75fd2f1e1d043789674021193.
Passing an HSVLike instance with hue set to 1.0 to TextColor#color returns an incorrect color value with a hue that is off by 60 degrees.
For example: TextColor.color(HSVLike.hsvLike(1.0f, 1.0f, 0.5f)) should yield #7F0000, but actually yields #7F007F.
This pr should address the issue.
It would be nice to be able to use HSV interpolation for gradients as an alternative to the current RGB interpolation.
<img width="634" height="86" alt="Image" src="https://github.com/user-attachments/assets/1958d26e-76cb-4af1-bcc3-a5292087356a" />
Simply removes the BossBarViewer class and moves its one function over to the Audience class. All references to BossBarViewer have been made compatible with the Audience class.
Original Issue: #1349
nitpicking, but is this the proper name? we call it adventure-webui and minimessage viewer elsewhere.
not that I would have a better name, adventure-webui api sounds dum too, lol
The existing methods need deprecation in 4.x.
I don't think I can do that on this pr, so I'll make a second one in to add the deprecation warnings. I'll link it here when it's been made.
The net.kyori.adventure.text.format.StyleImpl does not override Object#toString method resulting in the default Object#toString returning the class name and hash value.
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)
SoundImplDecorationMapAbstractTranslationStore (missing name and defaultLocale)AbstractTranslationStore.TranslationGlobalTranslatorImplLegacyFormatChange the <head> tag to simply try and parse a UUID instead of using a (v4 only) regex.
Fixes an issue raised by a user on [discord](#adventure-help message)
Just to be safe, it'd be better if this was as close to the UUID.fromString call as possible
@kezz implemeted the creation methods
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
}
This is no different than the code that was there before, Kezz pointing out the try-catch should surround the fromString call as closely as possible
Ah, the try/catch was narrowed deliberately? Then the current code is fine.
I was able to get Endermux working with this PR:
<img width="1930" height="1245" alt="image" src="https://github.com/user-attachments/assets/0f1e46b8-19e5-4671-91e9-46b442673972" />
Perhaps we could add it by adding a prefix such as base64; or texture;
A secondary PR for #1370 that deprecates functions associated with BossBarViewer in version 4.
Just made a pr that deprecates functions on the main/4 branch
#1376
This PR adds API for the waypoint feature.
Closes #1336
I've chosen to use generics instead of polymorphism with interfaces (e.g. AzimuthWaypoint, ChunkWaypoint and VectorWaypoint) to reduce code duplication (since all of these would need an impl).
return new BookImpl(List.copyOf(pages));
But that would differ from the implementation that uses title and heading?
https://github.com/PaperMC/adventure/pull/1372/changes/BASE..72c514caecead58b55a5774c7d433463301bb181#diff-e53679b6b60ce973af41cc3176ab2aae6dc79f264b24d4101fc1322184595de1R56-R58
Closing because I made a pull request for this and it's been inactive for 3 months
3 months over a busy winter holiday period is not that long - no need to close issues.
My bad, I thought it should be closed due to the prs being open. I think I saw a way to automatically close it with the prs so I'm gonna try to do that
Closes #1349
Just doing this to help with cleanup later.
Never mind, github docs say it only works with the main branch, and I may also need some permission for it.
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" />
Hi, it seems you have a typo in your URL, it should not be a § symbol but a & (near the end). Therefore MiniMessage should stop complaining about it.
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...
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_...
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.
@zml2008 I think the Mojang API is more stable now. If not, you can always add an experimental API.
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...
Great idea. <head> should accept more data formats like base64 or a MineSkin UUID. This would make heads even more useful, with some interesting tricks to customize simple textures without needing a resource pack.
173cebc why didn't this show up originally? - zml2008
42e99e9 chore(build): Avoid directly referencing the proje... - zml2008
<img width="972" height="518" alt="Image" src="https://github.com/user-attachments/assets/79d7e043-dee2-4626-b0d4-65498786a3e9" />
Commit
<img width="1699" height="670" alt="Image" src="https://github.com/user-attachments/assets/2aa2818b-5945-4d4b-822a-d2b489449484" />
and then....
<img width="1908" height="540" alt="Image" src="https://github.com/user-attachments/assets/9a62bf09-a8b7-423a-84b0-b84d20721230" />
It breaks..
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```...
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:
SequentialHeadTag.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.
The UUIDv4_PATTERN constant was removed, but java.util.regex.Pattern is still imported in this file. This will trigger unused-import checks (and may fail checkstyle/formatting). Please remove the unused import, or reintroduce a non-version-specific UUID precheck that actually uses Pattern.
We do not intend to push a new release in the 4.x series.
As evidenced by recent publicity around an """""exploit""""" in Paper servers, MiniMessage could do with an improvement to allow developers to access really simple "safe" presets. This PR introduces such a system via addition of a Preset enum that contains a standardised configuration for builders.
Personally, I'd maybe move this to the top of the file just so it's easier accessible (all fields at the start).
Includes the following changes:
plain property to NBT components, mutually exclusive with interpretfallback property to object componentsBarring the remaining three PRs in the 5.0 milestone, 5.0 is now considered complete. I'll close this PR now, but any more issues can be made directly on the repo!
Barring the remaining three PRs in the 5.0 milestone, 5.0 is now considered complete. I'll close this issue now, but any more issues can be made directly on the repo!
We might also want to make us of the fallback property of object components in ComponentFlattener
Maybe we can also add a object(ObjectContents, ComponentLike) overload?
* @sinceMinecraft 26.1
Small nitpick, would also apply to the other tags on the 2 methods below
I think it's fine as is, I don't really think anyone is ever going to use the fallback property anyway and there are other cases where we don't make static constructors for uncommonly used properties.
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.
It would improve my javadoc browsing experience if the use option could be enabled, typically enabled with https://docs.gradle.org/current/javadoc/org/gradle/external/javadoc/StandardJavadocDocletOptions.html#use(), but would require a change to indra if it has to go through that
what does that do? got any examples?
It allows viewing every spot where a class is used as a method parameter, return type, field type, etc. which is useful for finding how to obtain an instance of something and where you use it, paper's javadocs can be used as an example https://jd.papermc.io/paper/26.1.1/org/bukkit/inventory/class-use/ItemStack.html
To fix this mistake:
@@ -226,6 +226,6 @@
/**
* Get the alpha component of the shadow colour.
*
- * @return the blue component, in the range [0x0, 0xff]
+ * @return the alpha component, in the range [0x0, 0xff]
* @since 4.18.0
*/
It's a dumb GitHub issue, but it still needs to be fixed — otherwise the world might stop spinning
I have a Mojmap Implement which works on 1.21.6+ .
The point is to use com.mojang.serialization.JsonOps.INSTANCE as ops.
Also there's some improvement on my implement:
This pull request adds tryParse equivalents for the key methods, this both solves the issue of needing to suppress PatternValidation every time and allows for providing a default value in case parsing fails, while still forcing developers to properly handle invalid keys whether by checking #ifPresent or explicitly using #getOrThrow.
d0d8bca Build with 26.1.2 and re-enable PermissionsApiInte... - jpenilla
This version of adventure-platform-mod adds support for Minecraft 26.1 through 26.1.2, distributing Adventure 4.26.1 for the Fabric and NeoForge platforms. Minecraft versions older than 26.1 are not supported by this release.
Full Changelog: https://github.com/PaperMC/adventure-platform-mod/compare/v6.8.0...v6.9.0
d7d228e fix(minimessage): Add missing pride tag to formatt... - kezz
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:
This may now be documented somewhere and I may be blind, but a lot of my tests have failed after updating to 5.0.0 saying that Mockito cannot mock org.bukkit.entity.Player anymore. Is this a known thing?
Can you share the error? I doubt this has anything to do with us, probably something Java update related, but sharing the error would help know that for sure.
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...
Well that's a super helpful exception haha, really narrows it down 😅
There are removals of methods in Audience in the 5.0 update, which may be erroring if you're mocking Paper, which hasn't yet updated to remove the overrides?
Oh actually yes, that could be it. To be fair it's nothing breaking as I can disable the tests for now until I have time to properly look.
I am also glad you agree with the helpful exception 😂
There's no reason to desync your Adventure version from that included by platforms you are compiling against anyway, so best to avoid that regardless.
I'll go ahead and close this for now but if you do have anything more concrete feel free to reopen or make a new issue.
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.
5.0.0 changed the hover tag resolution by replacing item display SNBT deserialization with an exception say its not supported.
This change was introduced with commit 77945ebbe09c7701020d368571fd792e7ed99364.
Reverting the change will resolve this issue.
Specifically, the it seems to be the following lines: https://github.com/PaperMC/adventure/blob/main/5/text-minimessage/src/main/java/net/kyori/adventure/text/minimessage/tag/standard/HoverTag.java#L135-L137
Also gets rid of the checkerframework annotations, which were still present in configurate4 (oops)
1060f13 chore(build): Publish aggregate javadoc jar - kezz
Minor additional changes:
8368405 chore(build): Bump runtime version to 25 for nicer... - kezz
60a4a48 chore(build): Toggle use on for javadoc generation - kezz
60a4a48 chore(build): Toggle use on for javadoc generation - kezz
c9bac5e chore(docs): Fix incorrect docs for ShadowColor#al... - kezz
bac24ca chore(docs): Remove incorrect annotations from For... - kezz
Implementing classes will already know to override audience as it doesn't have a default.
The audiences method also shouldn't be deprecated as it is not unusable and won't be removed.
7f4e2ed chore(docs): Update Javadoc overview, title and re... - kezz
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/.
Full Changelog: https://github.com/PaperMC/adventure/compare/v5.0.0...v5.0.1
This PR reverts to the previous behavior where it allowed SNBT to be passed as an argument for item display. The commit changed that behaviour by throwing an exception instead, marking it as deprecated and removed.
Closes #1397
Adds a support for serializing components as NBT Binary Tags.
Resolves https://github.com/PaperMC/adventure/issues/995
This PR is a fork of https://github.com/PaperMC/adventure/pull/1084
I want to bring this feature to release, as it is very much needed by many non-NMS server software developers (Minestom, Jet, Cherryngine).
The current version of adventure-platform is not compatible with the latest adventure.
At least, i found the issue with BungeeComponentSerializer: it uses an old GsonComponentSerializer APIs that aren't there anymore.
Also, since the latest adventure is targeting java 21, this project have to go with it as well
Noticed this flag was missing from the list, and it's one of the more common forms of general pride flag.
On a personal level, I also find this flag fairly beneficial for intersex awareness as it creates conversations around what it means. Whether that can happen in the very "low information density" form of MC text colours is another question :P
I'm going to go ahead and close this in favour of the other PR linked in my previous comment.
[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...
Is this an issue before 1.21.5? I know Mojang changed how they handle URLs in click events then, so I assume this error is only thrown then. In which case, I'm happy to leave this as-is, we do have constructors that accept a URL if you are parsing untrusted input that you should be using instead.
Thanks for the PR! Just made a few changes to simplify a bit of the logic here.
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).
980c9e8 fix(api): Add explicit override for component buil... - kezz
72c514c test: add tests for pages only constructor - Privatech38
d7b0f0a Add intersex inclusive pride flag to PrideTag - me4502
359d4ca Fix formatting of intersex inclusive color entry - me4502
4aa8675 dry for book logic - kezz
621e48e Merge pull request #1405 from me4502/patch-1 - kezz
898722f Merge pull request #1372 from Privatech38/feat/boo... - kezz
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_```...
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...
a49d086 fix(minimessage): Restore missing negated shorthan... - kezz
3ca30ae fix(gson): Emit value for event payloads when usin... - kezz
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
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?
7f89235 feature(key): Disallow .. as a namespace - kezz
331ce29 feature(api,minimessage): Add validation for playe... - kezz
* As of 1.21.9, the profile will be resolved if the name or id is present without any properties.
minor typo
.name(name)
another small thing, this could use the already trimmed argument
206eaf6 typo fix and reuse trimmed argument - kezz
Thanks for the review @Emilxyz!
0f6dbb2 feature(api): Simple validation click events on cr... - kezz
76989cf feature(api): Add validation for negative change p... - kezz
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!
.. as a namespace by @kezz in https://github.com/PaperMC/adventure/pull/1416Adventure 5.x is not consumable via Maven — only via Gradle. This is a regression from the 4.x line, which resolves cleanly from both.
$ 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.
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 —...
97af41d fix: Simplify logic for patching API jar and fix p... - kezz
Should be fixed in https://github.com/PaperMC/adventure/commit/97af41dafe56af7f691100896db3f199ea912c62.
I'll push a 5.1.1 release now but do let me know if you're still encountering issues.
Adventure 5.1.1 is a bug-fix update to correct the publishing setup for Maven consumers.
Full Changelog: https://github.com/PaperMC/adventure/compare/v5.1.0...v5.1.1
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.
e2febc6 feature(api): Easier way to create object componen... - kezz
Closing this as it is out-of-date.
Progress now being tracked in a separate repo: https://github.com/PaperMC/adventurex
Thanks for the PR! However, we are going to continue work on a dfu module in-house over at https://github.com/PaperMC/adventurex.
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:
net.kyori:adventure-platform-neoforge:6.9.0 as a dependencyClient disconnected with reason: Internal Exception: java.lang.ExceptionInInitializerErrorExample 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)
Maybe drop the an since the noun is in plural
* Something that can be represented as {@link ObjectContents}.
Why are you checking if the contents are an instance of SkinSource and not adding any extra logic, but rather duplicating code? Couldn't you just call skinSource.asObjectContents() or perhaps even shorter:
requireNonNull(objectContentsLike, "objectContentsLike")
return object(objectContentsLike.asObjectContents());
FYI: We have more than one SPI service to load in dev environment.
<img width="1464" height="863" alt="Image" src="https://github.com/user-attachments/assets/851d44ec-a577-4a1b-81a5-0c9ccbdbdb34" />
The KyoriPowered GPG key (6F5FA671802022946C77C01550E021B142D5CDAB) which is used to sign the Adventure releases expired on 2025-05-13.
(this issue extends to all Kyori projects that use this key)
d6c3b2a chore: change gpg key - MiniDigger
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?
Thank you for the quick response, this doesn't really block me in any way. With the number of supply chain attacks recently I have been trying to be a bit more careful and setup at least some verification.
Since you are swapping keys from Kyori to paper the prefix should also be changed
https://github.com/PaperMC/adventure-platform-mod/blob/d9b97e0e81414e64360d2c71f69e7a2f218add27/build.gradle#L45
Since you are swapping keys from Kyori to paper the prefix should also be changed
https://github.com/PaperMC/adventure/blob/2e719c4325fd6f79f5467bbdc122603c744b4369/build-logic/src/main/kotlin/adventure.base-conventions.gradle.kts#L23
Resolve method is called twice, once in the preprocess pass and once in the normal pass. If resolvers could hint at the type of tag they are providing, we could skip this.
You accidentally committed and unresolved merge conflict.
Pure style, but I wouldn't inline the for-loop body.
for (final BossBar bb : audience.activeBossBars()) {
bossBars.add(bb);
}
I would generally just make it @Unmodifiable instead of a view, since you do not really want people to modify the backing Iterable and except it to change the currently active boss bars.
@Unmodifiable
This is not a view. The method returns a new HashSet with the values copied over.
default @Unmodifiable Iterable<? extends BossBar> activeBossBars() {
This PR needs rebasing for the main/5 branch, which includes removing/replacing the Jetbrains nullability annotations with JSpecify ones.
Based on the implementation, this actually returns a view. I would mark it as such.
@UnmodifiableView @NotNull Map<String, BinaryTag> asMap();
This needs a rebase to the main/5 branch.
This PR needs to be rebased to main/5
Adventure 5.x was recently published. If these methods are to be deprecated, they should instead target version 6.0.0. You should also rebase this PR to main/5.
My bad, this bit looks out of scope for the PR so I'm just going to delete the change
Awesome, thanks for the reviews! Sorry that I missed that merge conflict, I'll double check the implementations again to make sure I didn't miss anything else. About #1376, I'll rebase that soon.
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.
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:
Iterable<? extends BossBar> bossbars = Audience.activeBossBars()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...
Ah that makes sense. Thanks for explaining it!
Redid #1376 for the main/5 branch. Sorry for the separate PR, but I figured this would be a LOT cleaner than rebasing the old commits
Rebasing due to adventure v5 releasing. New PR here: #1425
Hey thinking about making the BossBar#viewers and Audience#activeBossBars functions return Sets instead of Iterables. Is anyone opposed to this?
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.
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.
This one is weird for sure. I have nothing to do with Sponge, so I will not say anything here.
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...
aefa9d0 Update to Adventure 5 - jpenilla
Adventure 5 seals Identity and SignedMessage.Signature, so remove the GameProfile and MessageSignature mixins and use conversion methods instead. Also remove examination dependency and deprecated sendMessage overrides.
Currently on Fabric, calling openBook on a ServerPlayer does nothing. The exact same code works just fine on Paper, but fails silently on Fabric.
This PR fixes that by sending the three necessary packets as a bundle. This is 1-1 exactly how it works in CraftPlayer for the Paper implementation, so it should be a suitable fix here!
Currently on Fabric, calling openBook on a ServerPlayer does nothing. The exact same code works just fine on Paper, but fails silently on Fabric.
I proposed a simple fix to make the implementation consistent with Paper in PR #259
On Fabric 26.1.2, try to call
player.openBook(book)
with any Book or BookBuilder, nothing will happen.
Created issue #262 so hopefully this doesn't get lost in the automated PRs 🤞
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...
f2035bd Update Fabric Loom run config DSL - jpenilla
1afe036 Copy openBook packet sequence from Paper - jpenilla
The diff doesn't appear to be "1:1" with the Paper code, more a hybrid. Was it tested? I will manually copy the Paper code for now.
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:
net.kyori:adventure-* to 5.1.1 and remove examination (examination-api, examination-string) from dependency management and shading.GameProfile, MessageSignature, and SignedMessage.signature mixins/injected interfaces and switch to conversion helpers (MinecraftAudiences.asAdventure/asNative).sendMessage(Identity, Component, MessageType) overrides from audiences and adjust chat delete/signature usage accordingly.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/...
signature() now allocates a new Adventure SignedMessage.Signature every time it’s called. This can lead to repeated allocations when the same PlayerChatMessage is inspected multiple times (e.g., tagging + sending), so it’s worth caching the converted signature per-message.
0d56bf9 Add Modrinth badge to README - jpenilla
fbdd13e chore(deps): Update dependency org.jetbr... - renovate[bot]
eb62334 chore(deps): Update dependency gradle.pl... - renovate[bot]
84ee8dc chore(deps): Update dependency org.junit... - renovate[bot]
0793f62 chore(deps): Update gradle and github actions - renovate[bot]
b353906 chore(deps): Update dependency com.puppy... - renovate[bot]
f0f1e81 Merge pull request #...
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.
Full Changelog: https://github.com/PaperMC/adventure-platform-mod/compare/v6.9.0...v7.0.0
Was this really fixed?
I'm getting this on Paper 26.2 dev builds which are on adventure 5.1.1
java.lang.NoSuchMethodError: 'net.kyori.adventure.text.BuildableComponent net.kyori.adventure.text.TextComponent$Builder.build()'
Component.text().build();
This is a different issue. Feel free to open a new issue if you have more information.
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?
09f7add Add back BuildableComponent - jpenilla
It skips a method call and is similar to how it's done in other areas of the codebase.
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.
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.
This version of adventure-platform-mod updates the distributed version of Adventure to 5.2.0.
Full Changelog: https://github.com/PaperMC/adventure-platform-mod/compare/v7.0.0...v7.1.0
Plugin is compiled against some 4.26.1 adventure, running on paper 26.2 (adventure 5.2)
Similar to https://github.com/PaperMC/adventure/issues/1431 i think
Turning a component flattener to a builder is a pretty niche use case for the API and, imo, this issue it not worth the time to fix. Would welcome other comments/thoughts before I close this.
ComponentFlattener.basic() contains a lot of functionality that we would have to replicate if we cannot use ComponentFlattener.basic().toBuilder() any more
If you explain your use case fully then I can suggest alternatives and we can look into this further.
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 ....
Far from a common or standard use case, so not something that we are interested in maintaining backwards compatibility for.
I have the exact same issue on NeoForge 1.21.10+
81dcc97 fix(neoforge): align service provider classloading - jpenilla
8d080c3 build: Disable config cache, nexus plugi... - jpenilla
Will this be fixed for 1.21.10+ too and not only 26.2 though?
This patch fixes Adventure service-provider classloading in NeoForge development environments (#255), aligning development runs with production behavior.
Full Changelog: https://github.com/PaperMC/adventure-platform-mod/compare/v7.1.0...v7.1.1
No promises on any backports.
You can fix it yourself with
val adventurePlatform = implementation(
"net.kyori:adventure-platform-neoforge:6.9.0"
) {
exclude(
group = "net.kyori",
module = "adventure-platform-mod-shared"
)
}
jarJar(adventurePlatform)
compileOnly("net.kyori:adventure-platform-mod-shared:6.9.0")
or similar
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.
I don't plan on continuing this, but I suppose someone else could
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...
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:
64415de feat: introduce MiniMessageContext to di... - kashike
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.
Maybe instead a VirtualComponentRenderer#translatable(VirtualComponent) returning a boolean would be better? Then other api usages could indicate if the component is translatable, with a default method always returning true, while minimessage always returning false
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.
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)
The naming of such a marker interface is difficult - do you have any suggestions? Keep in mind that this is, currently, only applicable when the VirtualComponent is a TranslatableComponent argument.
This PR introduces a system property intended for use by advanced users who are confident that they are using valid minimessage tags.
This has a very small usecase but a pretty major impact.
https://spark.lucko.me/Aqo35xCxyT?hl=8160
As seen in this spark at the linked method call, its allocation rate is about 650kbps which is quite high for what the call does and adds up.
That looks like a problem with GraalVM. Can you provide a spark profile using HotSpot/C2?
If there is a problem with excessive allocations, I think it would be better to implement the validation manually instead of relying on Pattern. Skipping the validation for performance is a somewhat flawed idea imo.
Here's with just C2 via Zulu.
https://spark.lucko.me/iAnMKIsXbP
A very slight improvement.
TranslationOpaque sounds like a good fit
What about just adding a method to VirtualComponentRenderer? Something like:
default boolean skipRenderingWhenUsedAsTranslationArgument(final VirtualComponent component) {
return false;
}
If there is a problem with excessive allocations, I think it would be better to implement the validation manually instead of relying on Pattern. Skipping the validation for performance is a somewhat flawed idea imo.
Agreed. I'm going to close this because of that.
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.
gson is an exposed dependency in the text-serializer-gson API and is made available to consumers of the maven module, so the module descriptor should reflect that transitivity
How is mojang doing from your standpoint ? A few major releases have passed, did the api change ? If not it might be time to implement it when you have time. It would be an amazing feature for many proxy-plugins (e.g. Auth, Settings, ...)
Thanks for the work already put into adventure ! It's really pretty to use !