Low priority: validate debugger speed_changed time-scale input
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start with SceneDebugger::_msg_speed_changed() in scene/debugger/scene_debugger.cpp and the time-scale behavior in core/config/engine.cpp and core/config/engine.h; inspect the linked pull request discussion for context. First establish the accepted protocol type and range, then check whether debugger-message tests support focused coverage. Done means invalid inputs return ERR_INVALID_DATA while valid Game view changes and reset behavior remain intact.
Written by the indexing model from the issue text.
Description
Priority
Low priority.
Summary
Validate speed_changed debugger messages before SceneDebugger::_msg_speed_changed() applies the value through Engine::set_user_time_scale().
The current handler in scene/debugger/scene_debugger.cpp rejects an empty argument array. It accepts the first value from any non-empty array. A custom debugger-message sender can provide a non-numeric, non-finite, or otherwise unsupported time-scale value.
The embedded Game view GUI currently uses a fixed finite range. Normal GUI use does not reproduce this condition.
Rationale
The debugger message handler is a protocol boundary. It should reject malformed values before they enter engine timing calculations.
The project must first define the accepted time-scale input range and behavior. The accepted range can be different from the current Game view preset range.
Affected areas
scene/debugger/scene_debugger.cpp:SceneDebugger::_msg_speed_changed(const Array &p_args)scene/debugger/scene_debugger.h: handler declaration, if the validation design needs API documentationcore/config/engine.cppandcore/config/engine.h:Engine::set_user_time_scale()and effective time-scale calculationseditor/run/game_view_plugin.cpp: Game view sender behavior, if protocol constraints change
Reproduction
This condition is not reachable through the existing embedded Game view speed menu.
To reproduce it, use a debug build with an active editor debugger session, then use a modified editor build, debugger extension, or other custom debugger-message sender that dispatches the scene capture message named speed_changed with malformed arguments.
- Start a project from the editor with the debugger active.
- Send a
speed_changedmessage to the running process with one malformed argument, such as a NaN or positive infinity floating-point value. - Alternatively, send a non-numeric value or send zero or more than one arguments.
- Observe the result after
SceneDebugger::_msg_speed_changed()convertsp_args[0]and callsEngine::set_user_time_scale().
The existing Game view GUI only sends its finite preset values and sends 1.0 for reset. It does not provide a user-accessible path to send NaN or infinity.
Acceptance criteria
- Define the accepted debugger-protocol input type and numeric range for
speed_changed. - Reject invalid argument counts, non-numeric values, non-finite values, and values outside the accepted range with
ERR_INVALID_DATA. - Preserve successful behavior for valid Game view speed changes and reset behavior.
- Add focused coverage if the debugger-message handling test infrastructure supports it.
- Document any intentional difference between the protocol range and the Game view preset range.
Backlinks
- Pull request: https://github.com/Redot-Engine/redot-engine/pull/1346
- Review comment: https://github.com/Redot-Engine/redot-engine/pull/1346#discussion_r3763689026
- Requested by: @Arctis-Fireblight
- Dominant language
- C++
- Stars
- 6.1k
- Forks
- 337
- Avg merge
- 4d 5h
- Merged PRs (30d)
- 52
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Redot-Engine/redot-engine
-
bug confirmed topic:3d topic:rendering
Difficulty 5/5 Over a week Newbie friendliness 35/100
Redot-Engine/redot-engine#1568 ·
Maintainers usually reply within 1 day
-
bug enhancement
Difficulty 3/5 1-2 days Newbie friendliness 57/100
Redot-Engine/redot-engine#1559 ·
Maintainers usually reply within 1 day
-
bug topic:3d topic:editor usability
Difficulty 3/5 1-2 days Newbie friendliness 48/100
Redot-Engine/redot-engine#1554 ·
Maintainers usually reply within 1 day
-
bug topic:animation
Difficulty 3/5 1-2 days Newbie friendliness 54/100
Redot-Engine/redot-engine#1552 · 3 comments ·
Maintainers usually reply within 1 day
-
AnimationTree does not respect AnimationPlayer's speed_scale or the AnimationClip's update modeOpenbug topic:animation
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Redot-Engine/redot-engine#1551 ·
Maintainers usually reply within 1 day
All issues in Redot-Engine/redot-engine
Similar issues
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
EchoTools/nevr-runtime#2042 ·
Maintainers usually reply within 1 day
-
Download size and speed show scientific notation between 1000 and 1023 unitsPossibly taken @RaphaelFakhri claimed this today. Open
Difficulty 2/5 Under an hour Newbie friendliness 88/100
kiwix/kiwix-desktop#1570 ·
Maintainers usually reply within 1 day
-
Device Request
Difficulty 2/5 Half a day Newbie friendliness 62/100
dresden-elektronik/deconz-rest-plugin#8686 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
aminya/project_options#303 ·