lan_actions.rs: clear the old body's potions (main), then respawn with
the tick context (this branch). hub.rs: keep main's effect and chunk
tracking reset before this branch's vanilla respawn sequence.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every PR of the startup batch adds a different tools/profile_client_startup.py,
so any two of them conflict. This one becomes tools/profile_shared_json.py; its
guide and tools/profile_gameplay_decode.py follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Loading the eight carried-over mods in the game (not only the probe) showed
two limits real packs reach. Block textures past 2048 layers are another PR;
this one handles block states and measures a pack.
- Chunk sections store a block state in 16 bits. Vanilla 26.3 has 35,723
states; Macaw's four mods add 36,154, the eight 41,389. Past 65,536 ids
wrapped onto other blocks (a trapdoor became a hanging sign).
mod_content::build now refuses a set of mods past MAX_STATES and names the
states per mod; the game then starts without content mods, as for any
refused content.
- tools/mod_port_harness.py probes each mod on its own against vanilla, as a
player adding it would load it.
- tools/perf_bench.py --game neoforge: Minecraft 1.21.1 on NeoForge 21.1.259
with --mod-jars and --deps, driven by a dev-only NeoForge port of the bench
mod (mods/horizon/src/neoforge-bench); --port-work loads a work folder's
carried-over mods into Horizon. tools/neoforge_oracle.py installs the
client once under .local/neoforge-oracle (the installer, then the vanilla
libraries it inherits, sha1-checked) and builds the driver. A NeoForge
start that crashes before the driver loads (FML reading fml.toml while
creating it) is retried once.
Measured (docs/modpacks.md): six ported mods in Horizon against the same
mods on NeoForge, Mac mini M4 Pro, 2 games per row on a loaded machine. The
world is ready 3.1x sooner at 8 and 16 chunks, the flights run 1.7x and
3.6x the frames, and Horizon's RSS is not lower (+1.1 GB with the mods).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Right-clicking a furnace as a guest did nothing: the host only handed
chests, barrels, hoppers, dispensers and shulker boxes over. It now opens
the furnace's own menu (minecraft:furnace, blast_furnace or smoker),
runs the guest's clicks through the host's AbstractFurnaceMenu (fuel slot,
take-only result, shift-clicks by recipe and fuel, a new input restarts
cooking) and keeps the client's progress arrows in step with
ContainerSetData. The dedicated server harness now opens a furnace and
smelts an ore in it on both servers.
Fixes#540
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A vanilla 26.3 client that died on a Horizon server stayed on its loading
screen after pressing Respawn (#566): ClientPacketListener.handleRespawn
starts a LevelLoadTracker that waits for the level info's "level chunks
load start" game event and the chunk under the player, and Horizon's
respawn sent neither the level info nor the chunk cache centre.
The hub's respawn now follows PlayerList.respawn: the entities paired with
the dead player are removed (one packet each), its chunks are dropped
without ForgetLevelChunk (as PlayerChunkSender does for a dead player) and
sent again, the abilities, then Respawn (with the last death location),
the teleport to the spawn facing its direction, the default spawn,
difficulty, experience, post effects, the level info, the permission
level, the chunk cache centre and the inventory. A dying guest also gets
the death animation event and no health update while dead, as vanilla's
ServerPlayer.die does.
Guests' commands also ran at the host's permission level: an operator on
a dedicated server could not run operator commands (and LAN guests ran
the host's level). They now run at the guest's own level, as the command
tree they are sent says.
The dedicated server harness covers it: after trading, the vanilla-codec
client is made an operator by the console, runs /kill, respawns, and the
packets from the death screen to the respawned inventory are compared
with vanilla's, then the level must load where it respawned. The client
also stops sending a movement packet beside each teleport acceptance
during the respawn: the 26.3 client sends the acceptance alone, and
vanilla's server kicks a second position in the same tick.
Fixes#566
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
online-mode=true now authenticates players as vanilla's
ServerLoginPacketListenerImpl does. The server makes a 1024-bit RSA key
pair at startup ("Generating keypair"), sends it with a random challenge,
checks the challenge and decrypts the shared secret from the client's key
packet, encrypts the connection with AES/CFB8, and asks the session
service's verify endpoint (hasJoined, through the services discovery
document) whether the player joined with the server's hash, from the
"User Authenticator #N" thread. A verified profile keeps its UUID and
properties, so skins show in the player list; an unverified one is
refused with "Failed to verify username!", and an unreachable service
with authservers_down. The offline-mode warnings are only printed in
offline mode.
Refused logins are logged as vanilla logs them: "Disconnecting
<name> (/<address>): <reason>" and "<name> (/<address>) lost
connection: <reason>", with log-ips respected.
horizon-protocol gains RSA key generation (Miller-Rabin primes,
e = 65537), the X.509 encoding of the public key and PKCS#1 v1.5
decryption. test_online_mode_parity.py runs its logins against Horizon's
server too, plus a verified player the whitelist refuses, and compares
the two servers' log lines about the player.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The harness the modpack design calls for, for data-tier mods:
- tools/neoforge_oracle.py installs a NeoForge 21.1.259 server (ATM10's)
under .local/neoforge-oracle, builds the exporter in
mods/horizon/src/neoforge-oracle (our code, never shipped), runs it
headless with the user's jars and writes every block (class chain,
states, per-state hardness, light, tool need, map colour, sounds,
outline and collision; drops for hand, diamond tools, shears and silk
touch; placement; BlockSetType and WoodType), item, recipe and tag of
the mods' namespaces, plus the vanilla blocks for templates. About 30 s.
- examples/mod_port_probe.rs builds the content root from the carried
mods and dumps what Horizon's loaders make of the same things.
- tools/mod_port_harness.py compares them per mod and writes
<work>/mods/<id>/harness/result.json. 1.21.1 sound events map to 26.3's
through vanilla blocks both have, and vanilla items newer than 1.21.1
are not counted against a recipe.
On ATM10's own jars (MIT): Macaw's Trapdoors passes everything; Doors,
Fences, Paths, Glassential, Factory Blocks and Cloud Glass pass every
drop, recipe, tag and placement and fail only on what API 0.2 cannot say
(shapes and sound events of their own, blocks of classes no vanilla block
shares). Jars, facts and results stay in the work folder.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
horizon-bots is a load client on horizon-protocol for any 26.3 server: offline login, configuration,
keep-alives, pings, teleports, chunk-batch acknowledgements, and movement at 20 Hz. The bots play in
creative and fly above their spawn point, so they need no world of their own and no server refuses their
moves; idle, walk, explore and mixed behaviours are deterministic from a seed.
tools/server_bench.py runs the same bots on Horizon's server (horizon-server run) and on the pinned vanilla
jar, each fresh from the same server.properties, and measures MSPT from each server's own /tick query,
RSS and CPU of the process tree, the chunks the bots receive, and the start time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ServerGamePacketListenerImpl.addBlockDataToItem: with Ctrl held in creative,
Pick Block gives the block's item the block entity's data. What each type
turns into item components (removeComponentsFromTag and
collectImplicitComponents: container, custom_name, lock, container_loot,
sign text, waxed, bees, banner patterns, pot decorations, skull profile)
leaves its NBT; the rest becomes minecraft:block_entity_data, tagged with
the type's id. Placing the item does the reverse
(BlockItem.updateCustomBlockEntityTag, op-only types only for a game
master, then applyComponentsFromItemStack), for every block entity type,
which also fills placed chests, barrels, hoppers and the like from their
container component, as vanilla does, where only shulker boxes were.
The client sends includeData on Ctrl in multiplayer, a picked banner keeps
its patterns without Ctrl (AbstractBannerBlock.getCloneItemStack), a picked
beehive carries its honey level, a placed command block with data keeps its
own auto and output tracking, and a placed waxed sign opens no editor.
tools/test_pick_block_data_parity.py compares both directions with vanilla's
own block entities: 148/148 cases.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PlayerDetector reads level.getPlayers(): the guests count for a trial
spawner's detection and a vault's connected players, and a key a guest
inserts rewards the guest's UUID.
Part of #462
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Feedback about the player (target_name) names the guest a command runs
for. A client reading a server's chat now unwraps NbtOps' {"": value}
wrapper of any bare value, not only strings, so translation arguments that
are numbers show ("Replaced 1 slot(s)", the coordinates). horizon-ctl
messages reads a server's chat too.
Part of #435
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SubmitNodeCollection.submitNameTag: a name that is not discrete is drawn
in full over the world and, faded on its background, again with
RenderPipelines.TEXT_SEE_THROUGH (no depth test) after the rest of the
world; a discrete one (a crouching player) only once, faded, on its
background. The background is ARGB.color(0.25, black): alpha 0x3F.
Part of #435
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Player.attack on a player: the host hits the guest on its crosshair, a guest
hits the host or another guest. The hit is worked out as the attacker
(Game::melee_damage, shared with attacking mobs) and lands on the victim as a
player_attack (blocking, armour, knockback to the guest's client), when the
pvp game rule allows it (ServerPlayer.canHarmPlayer).
Part of #435
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The hub's container menus now say where their slots live (lan::menu::Slots):
one block entity, both halves of a double chest (CompoundContainer, the right
half first) or the guest's own ender inventory (PlayerEnderChestContainer,
saved as EnderItems). The host's ender inventory stays the host's while a
guest acts. A Horizon client shows a server's chest-like menu with the rows
and title the server sent, and keeps its slots off a block that holds no such
container.
Part of #435
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The host now runs the rest of the server's body tick for each guest:
LivingEntity.baseTick's drowning and lava, fire blocks, suffocation
(isInWall) and the void (checkBelowWorld, 4 a tick, creative too), and per
move handleMovePlayer's jump (ServerPlayer.jumpFromGround's exhaustion) and
checkMovementStatistics (sprinting, swimming). The first move of a tick now
starts from the ground state before it, so take-offs are seen. Hurt sounds
are heard at the guest; lan status lists each guest's health and food.
Part of #435
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Since #372 a guest's commands need the world's Allow Commands as well as
the LAN's; the test's survival world had none, so every guest command (tp,
gamemode, setblock) was refused and the checks built on them failed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>