v0.4.0

Added

• Every part of the panel has a colour of its own. The colors group has one entry per part - name,
  facing, identifier, translationKey, x, y, z, distance, label, value and health -
  and each is a vanilla formatting code without the §: "c" means §c, and an empty value
  (or none / off / default) leaves that part in the plain text colour, client.textColor. Both
  panels and the extras lines read from the same group - a labelled line such as a chest's
  Items 12/27 uses colors.label for its label and colors.value for its value - so one scheme
  covers the whole display. The defaults only spell out the colours the coordinates are usually drawn
  in (x red, y green, z aqua) plus red hit points; every other part keeps the grey/white the
  panel has always used, so a colour scheme stays opt-in.
• The accepted codes are the Bedrock set, which is larger than Java's sixteen: g minecoin gold,
  h quartz, i iron, j netherite, m redstone, n copper, p gold, q emerald, s diamond,
  t lapis, u amethyst, v resin and w party blue, next to the sixteen 0-9 / a-f. The
  formatting codes (k, l, o, r) are rejected - one of those on a line would change how the
  rest of the panel is drawn.
• The configuration screen has a Colours group with one dropdown per part, each option shown as
  the colour's name (Red, Dark aqua, Minecoin gold, ...) rather than its code.
  /insight set <colors.*> <code> takes the bare code or the §c / &c / #c spellings, and
  none clears the colour again.
• The entity panel draws the hit points and the armor row itself, and entity.healthStyle picks how:
  bar, bar+number, hearts, hearts+number or number (it covers both rows). The bar is painted
  by the game's own UI renderer - a rounded dark track with the fill laid over it - and takes its colour
  from the scheme (colors.health for the hit points, colors.value for the armor). The hearts are the
  vanilla sprites (heart_new, falling back to heart), with the background sprite and the half sprite
  over it for a half heart, and every row is exactly one line of text tall. A row is drawn for the
  subject's whole scale, not for what is left of it, so hearts that have been lost stay visible as their
  background sprites.
• entity.heartsThreshold, entity.heartsPerRow, entity.healthDecimals and entity.armor: how many
  points still fit as icons (a subject whose maximum health is above the threshold keeps the numbers,
  so a boss does not turn into a wall of hearts while a player or a zombie does get them), how many
  hearts fit on a row before the next one starts above it and overlaps the row below by half a heart
  (in the bar styles it is the bar's width instead), whether the hit points carry one decimal, and
  whether the armor row appears at all.
• On a server install the bar is spelled out in text, because that is all a vanilla channel
  carries: █ per whole step, ▌ for half a step and the empty rest as the same █ in the muted
  label colour - the same fixed-width track the client paints, red for the hit points by default. The
  icon rows are deliberately not spelled out there: the font's glyph hearts read badly in a vanilla
  channel, so a server shows the numbers for those styles.
• /insight gui opens a configuration menu on the server as well, since a server has no screen of
  its own: it pushes a group picker followed by one form per group to the player who asked. The values
  go through the same path as /insight set, so the range checks, the validation and the immediate
  save behave exactly like the command - a value that is out of range says why in chat and the menu
  reopens. The groups are General (the master switch, distance, interval, the channel, ...),
  Block lines, Entity lines, Colours, Extras: every block, Extras: block entities
  and Extras: redstone, which covers every option that means something on a server.
• The entity panel grew its own group of extra lines, entityExtras (extras.enabled gates them like
  the block ones), each showing what the subject actually has and staying silent otherwise:
  the owner of a tamed animal, the active status effects with their remaining time on one line
  (effectsLimit caps how many fit), a breeding timer (the love timer or the cooldown after
  breeding), a zombie villager's conversion time, the pet armour in the body slot
  (all / damaged / off - the humanoid armour slots were already reported), a mount's coat and
  markings, movement speed, jump strength and saddle, an armour stand's pose index, a
  villager's profession and trade level, and whether a copper golem is waxed.
• A horse's coat and markings are named in the order the game's own horse render controller lists its
  textures in (Array.base / Array.markings, indexed by query.variant / query.mark_variant), so
  the same seven colours and five markings the vanilla horse models use; a horse with no markings shows
  the coat alone.
• Where those values come from: the status effects, breeding and conversion state are the engine's own
  components, the timers are ticks; a villager's profession and trade level are synced actor data - the
  game's own villager render controller reads the same two values as query.variant and
  query.trade_tier - and the profession names are the game's entity.villager.* translation keys, so
  they follow the player's language. Two of them are server-side state that the game never syncs to a
  client: the copper golem's waxed flag (an entity property the game declares as not client-synced) and
  a zombie villager's conversion countdown (only the "it is converting" flag is synced), so those lines
  appear on a server install and stay empty on a client.
• Two of the requested entity adapters are not implemented, because the engine does not expose what
  they need: a baby's growth time (its component carries a raw age counter with no total and no
  documented unit or sign, and it is not synced) and a villager's profession as a name on the old
  villager type (only the V2 villager's variant is the profession; the old one has no such field).
  The next entity drop is deliberately left out as well: asking the loot table would consume the
  world's random number generator, which is not something a display mod may do.

Changed

• Higher Config schema version (6) for the colors group; an existing file is merged
  automatically and keeps every value it already has.
• Higher Config schema version (7) as well, for the entity display options above; an existing file
  is merged automatically.
• Higher Config schema version (8) for the entityExtras group above; an existing file is merged
  automatically.
• In the +number styles the client writes the row's own "label number" text behind the sprites,
  never the line itself: that line may carry a bar spelled out in block characters for a server
  channel, which must not appear next to the sprites.
• The gui subcommand is registered on both sides now (it used to exist on the client only) and is
  always opened for the player who asked: the client shows its own screen, the server pushes the menu.
  A console origin is told that the command can only be run by a player. The client-only options are
  absent from the server's menu - showOverlay, the anchor, the offsets, the font and appearance
  settings, the language and the key bindings do nothing there.

Removed

• The server.channel: "popup" value is gone. A popup sent as a text packet made the client
  reject it and drop the connection (the "Block" error on join, "There was an issue with the
  Minecraft data being sent or received"), so the channel is removed rather than kept as a trap.
  A configuration file that still says "popup" falls back to actionbar, exactly like any
  other value the channel list does not know. actionbar and tip remain.

Fixed

• A block container's contents no longer turn into the player's own inventory once its screen
  has been opened. The screen's models map holds the player's inventory models next to the block's,
  and the player's main inventory has exactly as many slots as a chest (27), so matching by slot
  count picked the wrong model - and the snapshot it wrote then kept the panel on it, because a
  snapshot is only dropped once it agrees with the world copy again. Models whose category is the
  player inventory are never candidates now, and a model that wraps the block's own container (which
  is how a brewing stand's three models are found) is preferred outright.
• A message-only text packet - what the tip channel sends - now carries a fully filled payload:
  the localize flag, the filtered message and the sender's xuid and platform id, instead of
  nothing but the message body, which the client can reject as a malformed packet.
• The two client hotkeys only fire where they belong. They used to act on any key press, so the
  key that opens the screen also fired while typing in chat, in an anvil or on a sign, and in the
  main menu, where it had no business being. A hotkey now needs the game to be playing - the
  screen that owns the input has to be the HUD one, which also covers every other menu, since the
  screens behind an open one report no focus - and no text box may be selected for typing, which
  the client reports for chat, signs, the anvil and the creative search field alike. While the
  configuration screen itself is up its own keys are left alone too: a rebind capture or an edited
  text field no longer gets its key eaten by the hotkey.
• The status effect line shows every effect again, with the right level. The engine's effect list
  carries slots it has no name for, and counting those made the line stop after the first effect and
  report the rest as +n; only the entries that produced a name are counted now. The name and the
  level come from the game's own effect table (potion.*, so the same wording the game itself uses)
  rather than from the engine's display name, which carries the level on one side and none on the
  other - which is what turned a level II speed into Speed II II.
• The status effect line is a server-side one now. A client is never told more than the latest
  effect of another creature - measured: the server's list holds every effect in its id slot, a
  client's holds that single latest one - so on a client the line could only show one effect and then
  disappear with it. Rather than extrapolate the rest, the line is left to the side that owns the data.
• A horse's numbers are the ones a player can judge: speed in blocks per second (the attribute
  times 42.16) and the jump height in blocks (the jump strength through the cubic the game's horse
  jump uses), instead of the raw per-tick engine values - Speed 7.34 blocks/s · Jump height 3.25 blocks.
• A villager's trade level is one higher than the raw value: the game counts the tiers from zero, so
  the number now matches the Novice / Apprentice / ... the trade screen shows.
• A zombie villager's conversion time is read from the transformation countdown the game itself runs
  (TransformationComponent::mDelayTicks): the per-class field is zero on this build and the
  "converting" flag is not set on every converting villager, so the line never appeared. A client, which
  is never told the countdown, shows the state on its own when it is told at all.
• The copper golem's waxed line reads yes / no instead of the on/off of a switch, and it is a
  server-side line: the game declares that property as not client-synced, so a client would only ever
  read the default and say "no" about a golem that is in fact waxed.
• The breeding line appears for a client as well: the counters are server-side state, so the line falls
  back to the "in love" flag the client is told (Breeding In love) instead of staying empty because
  the component is missing there.