v0.3.82 — Guarded clicks reach transparent button hit areas like a real pointer

v0.3.82 — Guarded clicks reach transparent button hit areas like a real pointer

Why this matters

unity_ui_click refused a common uGUI button: a Button whose own Image is
fully transparent (alpha 0, raycastTarget on) and serves only as the hit area,
with a visible child icon that does not take raycasts. Unity's GraphicRaycaster
still hits that transparent Image, so a finger or mouse click works in the
game. The MCP tool read the button as visible=false and refused it as
ui_target_not_visible, and selecting the icon instead was refused as
ui_target_does_not_block_raycasts. The only way through was a temporary
project hook that called the production code directly.

What changed

• unity_ui_click now decides whether a click is reachable the way Unity's
  uGUI raycast does, not by whether the target is drawn. It looks for a
  Graphic that a pointer at the target's centre would land on: the target's
  own, or any Graphic under the click handler whose click reaches that
  handler. It checks the same things Unity checks: the Graphic is active and
  enabled, raycastTarget is on, its Canvas has an enabled
  GraphicRaycaster, CanvasRenderer.cull is off, the point is inside
  raycastPadding, CanvasGroup.blocksRaycasts (with ignoreParentGroups and
  override-sorting canvases), the Image alpha hit test, and other
  ICanvasRaycastFilter components such as RectMask2D. The event camera
  matches GraphicRaycaster.eventCamera. The existing live EventSystem
  raycast still decides depth and occlusion.
• A delivered click reports pointer_targetable, pointer_target_path, and,
  when the Graphic that takes the click draws nothing, transparent_hit_area
  with transparent_hit_area_evidence: visible_descendant_renders (the
  icon-button pattern, with the icon's path) or no_visible_descendant, which
  adds the ui_click_transparent_hit_area_without_visible_content warning. A
  Graphic counts as drawn only when its colour, its CanvasRenderer alpha and
  colour (CrossFadeAlpha/CrossFadeColor), culling, and its CanvasGroup
  chain all leave it visible.
• A refused click names the reason in pointer_target_status and the blocking
  component in pointer_target_blocked_by, for example
  alpha_hit_test_rejected, raycast_filter_rejected,
  canvas_group_blocks_raycasts, outside_raycast_area, or no_raycaster.
  A hidden target keeps ui_target_not_visible unless it is interactable, has a
  click handler, and a pointer reaches that handler, so hidden panels refuse
  exactly as in v0.3.81. A visible target that nothing reaches is
  ui_target_does_not_block_raycasts (a CanvasGroup blocks it) or the new
  ui_target_not_pointer_targetable.
• UI tree nodes with a uGUI Graphic report pointer_targetable and
  pointer_target_status for their own Graphic when they are active and have
  bounds. The existing visible field keeps its meaning (is it drawn), so
  requireVisible selectors and snapshot signatures behave as before. The
  scenario ui_click step carries the same pointer evidence.
• An Image with an alpha hit test on an unreadable or Crunch-compressed sprite
  texture is accepted without sampling, as Unity accepts it after logging an
  error, so reading the UI tree no longer writes that error to the console.

What this gives developers

• Buttons built as an invisible hit area with an icon on top can be clicked
  through MCP without project hooks, and the payload says the click went
  through a transparent hit area.
• When a click is refused, the payload names the uGUI filter and the component
  that blocked it, so the next step is fixing that component rather than
  guessing why a visible button "cannot be clicked".
• An invisible hit area with nothing drawn over it is still clicked, as Unity
  would click it, but it is flagged so an accidental invisible click-blocker is
  easy to spot.

Validation

• Host Python suite on macOS: 1157 tests passed, 14 expected platform skips.
  Release checks for version consistency, docs freshness and public safety
  passed; public site checks passed 42/42.
• Package EditMode self-tests in freshly scaffolded consumer projects: Unity
  6000.0.58f2 with uGUI 178/178, Unity 2022.3.67f2 with uGUI 178/178, Unity
  6000.0.58f2 without uGUI 128/128.
• Package PlayMode on Unity 6000.0.58f2: the uGUI PlayMode assembly passed 17
  with 2 environment skips. The new live-raycast test passed on its own (1/1):
  a real EventSystem raycast reaches an alpha-0 Image with
  cullTransparentMesh on, stacked over an opaque button, and resolves to its
  handler (event_system_raycast_resolves_to_handler).
• Before the final review fixes, putting each old behaviour back failed exactly
  the tests written to catch it: the old render-alpha gate failed the two
  transparent-hit-area tests, the old CanvasGroup gate failed the icon-child and
  hidden-target tests, and skipping the alpha hit test failed only its own test.

Known limitations

• Hosted Unity Package CI is still waived because the runner has no Unity
  license, so the Unity results above are local runs, not CI evidence.
• PlayMode was not run on Unity 2022.3.
• The fix was not re-checked live in the consumer project that reported the
  refusal: that project had already worked around it with a hit-area alpha of
  1/255, and its gameplay was not reachable in the editor at release time. The
  alpha-0 case is covered by the scaffolded-project tests above.
• The static check does not model Graphic.depth (a Graphic the canvas has
  not drawn yet) or cross-canvas sort order; the live raycast still covers
  those, and without an EventSystem the click keeps the existing synthesized
  raycast and its ui_click_pointer_raycast_synthesized warning.
• transparent_hit_area_evidence treats any active, unculled descendant
  Graphic with positive alpha as drawn content; an empty Text, or a sibling
  drawn over the hit area, is not distinguished.

Git UPM install URL:

https://github.com/FoxsterDev/xuunity-mcp.git?path=/packages/com.xuunity.light-mcp#v0.3.82