FastMachines repeatedly triggers Mojang profile lookups for a fake/legacy head owner (CS-CoreLib), causing continuous HTTP 429 errors and console spam on Paper 1.21.10.

[wickidcow]

Checklist

• You are using official version downloaded from Blob Builds (https://blob.build/) or Guizhan Builds (https://builds.guizhanss.com)
• You checked the checksum of the downloaded file, and confirmed that the file is complete
• You did not modify the jar file
• You searched existing issues, and could not find any existing bug report on this

Description

Environment

Minecraft: 1.21.10
Server: Paper 1.21.10 (build 130 / latest as of report)
FastMachines: Latest with Shapeless Recipe Fix
Slimefun: Any/Final

Proxy: none (direct join)

Java: 21

Online mode: true

Symptoms

After server startup completes, the console begins spamming:

https://mclo.gs/issaKEs

Couldn't find profile with name: CS-CoreLib
MinecraftClientHttpException: Status: 429

Spam continues indefinitely while the server is running
Occurs even with no players online

Increasing FastMachines tick-rate reduces frequency but does not stop it

Removing FastMachines.jar completely stops the issue

Stacktrace (trimmed)
CraftMetaSkull.getOwningPlayer
Bukkit.getOfflinePlayer("CS-CoreLib")
FastMachines.utils.items.ItemExtKt.quickNotEquals
FastMachines.utils.items.ItemExtKt.isSimilarTo
FastMachines.core.items.ItemWrapper.compareTo
FastMachines.utils.items.ItemExtKt.countItems
FastMachines.core.recipes.loaders.SlimefunMultiblockRecipeLoader.beforeLoad

What appears to be happening

FastMachines compares ItemStacks containing a player head

During comparison, SkullMeta.getOwningPlayer() is called

The head’s owner name is CS-CoreLib (legacy Slimefun placeholder)

Paper attempts to resolve this via Mojang’s profile API

Mojang rate-limits the server (HTTP 429)

FastMachines repeats the comparison continuously, causing endless lookups

This does not come from playerdata (playerdata/*.dat verified clean).
The head appears to be generated or cached internally during Slimefun recipe loading.

Expected behavior

FastMachines should not trigger Mojang profile lookups during item comparison, especially for skulls.

Suggested fix

During ItemStack comparison:
Avoid calling SkullMeta.getOwningPlayer()
Compare PlayerProfile UUID or textures directly
Or ignore skull owner entirely when checking recipe similarity
This seems especially important on Paper 1.21+, where getOwningPlayer() forces profile resolution.

Reproduction Steps

Start paper with 1.21.8+ with fast machines,

Expected Behavior

Fast machines works but makes console unsable

Server log

https://mclo.gs/issaKEs

Error report

No response

Server Software

Paper

Minecraft version

1.21.10

Slimefun version

Slimefun 17ab784-Beta

Plugin version

git Build #55

[ybw0014]

wow, paper 1.21.9 changed the behavior of getOwningPlayer() to request profile each time getOwningPlayer() is called, unlike in previous versions SkullMeta contains the profile uuid or name already.