Adventure 5

[4drian3d]

No description provided.

[levi-lloyd]

When will be merged?

[4drian3d]

When will be merged?

Personally, I'm waiting for more plugins to update to Adventure 5 on their own, since there are changes that break compatibility with existing plugins, some of which need to be recompiled to work with the new version, while others require a compatibility layer to work with both versions (Adventure 4 and 5)

[electronicboy]

I think that they're looking to address the ABI breakage

[Tim203]

Generally people update when the platform that implements it updates, so for us we're going to revert the update to Adventure 5.0 until Velocity updates

[WouterGritter]

Should be safe to merge since 5.1.0, right?

https://github.com/PaperMC/adventure/releases/tag/v5.1.0

I think that they're looking to address the ABI breakage

Looks to have been addressed by the following change

Fix ComponentBuilder#build ABI compatibility by @ kezz in PaperMC/adventure#1407

[R00tB33rMan]

Since Adventure's Facet platform is now deprecated, maybe it's worth considering an alternative, similar to: GemstoneGG#883, @4drian3d?

[kezz]

Since Adventure's Facet platform is now deprecated, maybe it's worth considering an alternative, similar to: GemstoneGG#883, @4drian3d?

I'd rather this was included/PR'd into adventure-api. It serves literally zero point for an implementing platform to have a type pointer when you can just instanceof.

Also, Velocity didn't have these type pointers before so the deprecation of adventure platform has absolutely nothing to do with this.

[WouterGritter]

Velocity didn't have these type pointers before so the deprecation of adventure platform has absolutely nothing to do with this.

What do you mean by this exactly? Velocity does currently resolve FacetPointers.TYPE to FacetPointers.Type.PLAYER and CONSOLE through pointers().

It seems strange that this was ever the case, as net.kyori.adventure.platform.facet is an unsupported API that really should never have been used in the first place.

This makes the deprecation of platform-facet and the likes put Velocity in quite a predicament... Removing the dependency could break plugins relying on it, but continuing to use a deprecated library/API also doesn't seem like the right solution.

I'd rather this was included/PR'd into adventure-api.

Getting net.kyori.adventure.platform.facet into adventure-api does seem like the proper solution, but I don't know if they'll want that. Another solution would be to provide these classes in proxy/deprecated/adventure-facet, similar to configurate3 that currently lives there.

[Emilxyz]

As you've already mentioned, these pointers are marked as internal by adventure-platform. They're also not actually provided as a dependency by velocity-api and only required by velocity-proxy, which is not even published. So plugins using these is extremely unlikely and also unsupported anyways.

I'm also assuming that this pr will come with a velocity version bump, due to the other breaking changes in adventure 5. So I think just doing a clean cut and dropping adventure-platform-facet should be fine. Maybe mention it in an update announcement.

[electronicboy]

My understanding is that the major ABI breakage has been resolved, I think that there might be a thing or two in the pipeline pending on people actually reporting them with valid usecases, but I think that adventure is as ready to go as it's going to get in the immediate future; Anything blocking this as-is?

[electronicboy]

Will try to merge tomorrow morning or so