Skip to content

DOCS: Replacing architecture diagrams - #2448

Open
suearkinunity wants to merge 12 commits into
developfrom
docs-arch-diagrams
Open

DOCS: Replacing architecture diagrams#2448
suearkinunity wants to merge 12 commits into
developfrom
docs-arch-diagrams

Conversation

@suearkinunity

Copy link
Copy Markdown
Collaborator

Description

manual/Architecture.html has two old diagrams. They're very hard to read, and we've had user complaints about that.

This is an attempt to replace them with Mermaid diagrams.

Testing status & QA

Docs only

Overall Product Risks

None: docs only

Comments to reviewers

Very different way to construct the diagrams, so requires careful review.

Checklist

Before review:

  • Changelog entry added.
    • Explains the change in Changed, Fixed, Added sections.
    • For API change contains an example snippet and/or migration example.
    • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
    • Jira port for the next release set as "Resolved".
  • Tests added/changed, if applicable.
    • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
    • Performance tests.
    • Integration tests.
  • Docs for new/changed API's.
    • Xmldoc cross references are set correctly.
    • Added explanation how the API works.
    • Usage code examples added.
    • The manual is updated, if needed.

During merge:

  • Commit message for squash-merge is prefixed with one of the list:
    • NEW: ___.
    • FIX: ___.
    • DOCS: ___.
    • CHANGE: ___.
    • RELEASE: 1.1.0-preview.3.

@cla-assistant-unity

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@suearkinunity suearkinunity changed the title Documentation: Replacing architecture diagrams DOCS: Replacing architecture diagrams Jul 15, 2026
@codecov-github-com

codecov-github-com Bot commented Jul 15, 2026

Copy link
Copy Markdown

Codecov Report

All modified and coverable lines are covered by tests ✅

@@             Coverage Diff              @@
##           develop    #2448       +/-   ##
============================================
- Coverage    78.95%   58.37%   -20.59%     
============================================
  Files          767      738       -29     
  Lines       140780   136459     -4321     
============================================
- Hits        111153    79656    -31497     
- Misses       29627    56803    +27176     
Flag Coverage Δ
inputsystem_MacOS_6000.7 ?
inputsystem_MacOS_6000.7_project ?
inputsystem_Ubuntu_6000.7 ?
inputsystem_Ubuntu_6000.7_project ?
inputsystem_Windows_6000.0 5.31% <ø> (-0.01%) ⬇️
inputsystem_Windows_6000.3 5.31% <ø> (-0.01%) ⬇️
inputsystem_Windows_6000.6 5.30% <ø> (-0.01%) ⬇️
inputsystem_Windows_6000.7 ?
inputsystem_Windows_6000.7_project ?

Flags with carried forward coverage won't be shown. Click here to find out more.

see 285 files with indirect coverage changes

ℹ️ Need help interpreting these results?

@suearkinunity
suearkinunity marked this pull request as ready for review August 12, 2026 09:04

@u-pr u-pr Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Harness Review

LGTM

The new Mermaid diagrams make the architecture more explicit, but the runtime-flow description now misrepresents how action callbacks and action-state data are connected to the implementation.

Reviewed commit 8efe30b

🤖 Helpful? 👍/👎

space -->|"state change monitor"| ctrl

%% ---------- Callback out to the scene ----------
trig -->|triggers| IU["InputUser"]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2

InputUser is not the intermediary that invokes PlayerInput.OnActionTriggered(). PlayerInput installs its OnActionTriggered delegate directly on each InputActionMap.actionTriggered event; InputUser manages user/device/action association. As drawn, a reader tracing a normal PlayerInput action will look for a callback route that does not exist. Replace this edge with the action/map callback flowing directly to PlayerInput (and present InputUser separately as the device-pairing layer).

🤖 Helpful? 👍/👎

%% ---------- Action state ----------
AState(["InputActionState
NotifyControlStateChanged()"])
trig["triggerStates[]"]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2

This diagram and the preceding text name a triggerStates[] array, but InputActionState actually exposes actionStates (whose element type is TriggerState), alongside bindingStates and controls. Also, state-change monitors call into ProcessControlStateChange; they do not update the binding/control arrays shown by the incoming arrows. This makes the new architecture diagram impossible to reconcile with the source and incorrectly suggests binding resolution happens for every state event. Rename the action-state array and draw the monitor as invoking action-state processing while the resolved binding/control arrays are read from it.

🤖 Helpful? 👍/👎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant