Re-applying the same two-axis part picks adds a no-op undo step instead of 'already holds the part that way'
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 70/100
Research direction
Start in crates/app/src/commands/setup_align.rs, especially AlignPartToSetup::align_from_axes and change_of, then read the axis alignment tests in crates/app/tests/align_axes.rs and, if relevant, mcp_align_axes.rs. Reproduce applying the same +Y and +X picks twice, then test the chosen fix against both identity alignment and a real alignment change. Done means the repeated picks are rejected with the named “already holds the part that way” message without suppressing a real change.
Written by the indexing model from the issue text.
Description
Found while fixing #1329 (PR #1346).
What happens: AlignPartToSetup::align_from_axes with both +Y and +X picked builds the new alignment through the held one. Applied a second time to the same picks, the turn should be the identity, but the composed alignment comes out a float hair away from what the setup holds (e.g. origin y -7.499999999999999 against -7.5). change_of (crates/app/src/commands/setup_align.rs) compares next == prev exactly, so it accepts the change. The result is a no-op undo step where the user should get "setup '...' already holds the part that way". The in-plane path avoids this because in_plane_turn_deg snaps to exact quarter turns. This happens in both the GUI (Setups page "Part axes" Apply) and MCP set_part_axes.
Expected: re-applying picks that already land refuses with "already holds the part that way", or align_from_axes returns the held alignment unchanged when the turn is the identity within tolerance.
Done means: re-applying the same two-axis picks refuses by name (pinned in crates/app/tests/align_axes.rs and/or mcp_align_axes.rs), and no tolerance change lets a real alignment change through as "already held".
- Dominant language
- Rust
- Stars
- 8
- Forks
- 11
- Avg merge
- 6h 39m
- Merged PRs (30d)
- 603
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
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 NeoTech/Camcraft
-
area:mcp effort:low P5 source:agent
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area:mcp effort:low P5 source:agent
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
area:build bug effort:low P7 source:agent
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
area:3d effort:high enhancement P7 source:agent
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
area:mcp area:sim effort:high enhancement P7 source:agent
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
All issues in NeoTech/Camcraft
Similar issues
-
area:schema documentation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ElectronicWave/Elemental#252 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
dekobon/big-code-analysis#1887 ·
Maintainers usually reply within 1 day
-
Shell中文符号输入异常Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day