-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOCS: Improved script API docs of InputAction.CallbackContext #2064
base: develop
Are you sure you want to change the base?
Conversation
I noticed this one has malformed xmldoc so need to revisit that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small correction needed in the example code
Packages/com.unity.inputsystem/InputSystem/Actions/InputAction.cs
Outdated
Show resolved
Hide resolved
Packages/com.unity.inputsystem/InputSystem/Actions/InputAction.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, mainly minor comments
/// The callback context provides means to consume events (push-based input) as part of an update when using | ||
/// input action callback notifications, e.g. <see cref="InputAction.started"/>, | ||
/// <see cref="InputAction.performed"/>, <see cref="InputAction.canceled"/> rather than relying on | ||
/// pull-based reading. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a piece of documentation to link to (push/pull based reading) to clarify this statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just referencing the general concept of push vs pull architecture, i.e. callbacks vs polling in this case. Would it be better to switch to those?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just wondering if there is a documentation about the push/pull architecture, differences and advantages in the InputSystem, then this would be a good place to link it, but if there isn't it is fine I think.
/// { | ||
/// // Note: Assumes the underlying value type is Vector2. | ||
/// Vector2 value = context.ReadValue<Vector2>(); | ||
/// Debug.Log($"Value is: {value}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant line in my opinion add something up to a vector (eg the player position)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, I originally had the read value inside the log call but it was more difficult to read. Also I am torn around what to do with the value since the code should compile and ideally do something useful if copied over into a script and entering playmode was my though. Not sure what the suggestion is? To have a public Vector3 direction so its visible in the Inspector?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That, or maybe modifiying the ridgid body of the gameobject directly?
eg ridgidBody.velocity = value*speed; (where ridgidbody is a public or serialized field that needs to be assigned in the editor and speed can be a private float field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would vote for the transform in this case otherwise, if the object has a mesh renderer, otherwise there is nothing to be seen. If rigidBody is used, then we need to add additional detail about that they must reconfigure the system to use FixedUpdate etc or sample value and use additional FixedUpdate to use sampled values. It seems @duckets was fine using Debug.Log at least
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, the only reason why I proposed using the ridgid body was that translating the transform directly is a rather bad practice in general using physics. So I am not sure about how to show case it without messing up with best practices from other areas. Maybe in that case a log would be the safest option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I am slow but why do we need to use physics?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I need to rephrase that: for a game using physics translating a player directly using the transform component is a bad idea, since it will not align with the physics of the game (the gravity, wind and other forces). That's why I am wondering if showing that in an example is a bad idea.
/// { | ||
/// // ReadValueAsButton attempts to interpret the value as a button. | ||
/// bool value = context.ReadValueAsButton(); | ||
/// Debug.Log($"Button state is: {value}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above comment. Is it usual to use prints in the docs examples?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly I am not sure what is recommended, other suggestions to do something useful that indicates that it works if copied into a .cs file without adding much more code to the sample?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be enough even to call an empty function like if(value){Jump();} -> Jump() { //insert player jump logic here OR Debug.Log("Jump"); } for example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, I think it's complaining on a high level and is okay to handle like that, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think about it an update once CI / package tool issues are resolved
Description
Improved script API Doscs of InputAction.CallbackContext:
Testing status & QA
Reviewed generated XML docs in IDE inspector (Rider)
Generated docs via package docs tool.
Overall Product Risks
Comments to reviewers
Check language, compliance and example.
Checklist
Before review:
Changed
,Fixed
,Added
sections.Area_CanDoX
,Area_CanDoX_EvenIfYIsTheCase
,Area_WhenIDoX_AndYHappens_ThisIsTheResult
.During merge:
NEW: ___
.FIX: ___
.DOCS: ___
.CHANGE: ___
.RELEASE: 1.1.0-preview.3
.After merge: