Fix "Overload resolution ambiguity" compiling rpk-characters-bukkit

[dmccoystephenson]

Origin

Mirrors RP-Kit#666 — "Fix "Overload resolution ambiguity" error occurring upon compiling rpk-characters-bukkit module" (opened 2024-07-01 by dmccoystephenson). This fork's tracker is the working copy; the upstream issue is authoritative and is not modified or closed by our work.

Surfaced concretely in our CI by run 31342495454 on PR #4, once the ProtocolLib version bump let dependency resolution succeed.

The upstream thread contains a maintainer scope decision. renbinden (project owner) wrote:

I think we just go 2.5 and gut the nameplate functionality, it only causes problems and is doable with placeholders I think

There is a feature to update player nameplates to character names. It only worked on the specific combination of ProtocolLib and Minecraft it was designed for each time it was updated, and each update was a huge pain

So upstream's chosen resolution is removal of the nameplate feature, not a patch to the ambiguous call. Upstream PR RP-Kit#669 ("Removed nameplate functionality from rpk-characters-bukkit", dmccoystephenson, opened 2024-07-10, still open) already implements that: 8 files, 0 additions, 208 deletions.

Localization

File	Why it's implicated
bukkit/rpk-characters-bukkit/src/main/kotlin/com/rpkit/characters/bukkit/protocol/Protocol.kt	Line 77 — the ambiguous PlayerInfoData(...) constructor call, confirmed as the sole compile error in CI
bukkit/rpk-characters-bukkit/build.gradle	Declares the ProtocolLib dependency that introduces the overload

Module: rpk-characters-bukkit

Current behavior

createAddPlayerPacket in Protocol.kt:76-86 constructs a PlayerInfoData passing a bare null as the 7th argument. ProtocolLib 5.3.0 exposes two 7-argument constructors distinguished only by that parameter's type:

PlayerInfoData(UUID!, Int, Boolean, EnumWrappers.NativeGameMode!, WrappedGameProfile!, WrappedChatComponent!, WrappedProfilePublicKey.WrappedProfileKeyData?)
PlayerInfoData(UUID!, Int, Boolean, EnumWrappers.NativeGameMode!, WrappedGameProfile!, WrappedChatComponent!, WrappedRemoteChatSessionData?)

An untyped null matches both, so Kotlin cannot select an overload and compilation fails:

e: .../protocol/Protocol.kt: (77, 26): Overload resolution ambiguity

This is the only remaining compile error — the other 70 modules build cleanly (119 Gradle tasks executed).

Expected behavior

rpk-characters-bukkit compiles.

Acceptance criteria

• ./gradlew compileKotlin completes for rpk-characters-bukkit in CI
• The chosen approach is consistent with the upstream maintainer's stated direction, or the divergence is explicitly justified
• No behavioural change is introduced beyond what the chosen approach implies

Verification plan

CI (.github/workflows/build.yml) is the anchor — the local Gradle build cannot run on the development device (no JDK 17). Green Compile on the PR is the evidence. There is no unit test for this path; it is a compile-time defect, so compilation succeeding is the signal.

Out of scope

• The dependency version bumps themselves (PR Repoint PlaceholderAPI and bump ProtocolLib to resolvable versions #4)
• Opening or updating anything on RP-Kit/RPKit — including upstream PR Removed nameplate functionality from rpk-characters-bukkit RP-Kit/RPKit#669

Assumptions and open questions

This needs a human decision; two approaches diverge materially and I am not choosing between them autonomously.

1. Port upstream PR Removed nameplate functionality from rpk-characters-bukkit RP-Kit/RPKit#669 (remove nameplate functionality). Matches the maintainer's stated decision and reuses work already written. Deletes 208 lines across 8 files, drops the ProtocolLib dependency entirely, and removes a user-facing feature plus its config.yml keys. Sizeable, and a product decision.
2. Disambiguate the constructor call. Roughly one line — an explicitly typed null. Preserves the nameplate feature, but contradicts the maintainer's direction, and picking which overload changes runtime behaviour on a code path that cannot be exercised without a live Minecraft server. I have no way to verify the choice here, so I will not guess at it.

Recorded rather than resolved, per this loop's rule against inventing a resolution the upstream author did not ask for.