Menu / Index Switching changing exposed node parameters in 5.1.0 #63

Open
opened 2026-04-12 18:13:32 +00:00 by Triager-bot · 7 comments
Owner

Original bug report: https://projects.blender.org/blender/blender/issues/157253

System Information
Operating system: Windows 11
Graphics card: Nvidia Geforce RTX 4090 Laptop GPU

Blender Version
Broken: 5.1.0
Worked: 5.0.1

Short description of error
I make a lot of nodes that have 2 or more 'branches' in their makeup, all with different parameters exposed at surface to keep stuff tidy. Upon making the move to 5.1.0, I noticed almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching (1 branch of the node) is chosen (which in theory should annul any 'usage' of nodes in the other branches).
Yet i have changed nothing within the nodes, they stay perfectly identical between versions (minus a few UI changes to group and node context menus). I have gone through 5.1.0 release notes multiple times to see if menu/index switch node behaviors have changed but no success.

Exact steps for others to reproduce the error
Attached is a blend with one of my 'time nodes'. It has two main branches, one that repeats 1 or 2 easing functions between chosen values with options for loop length/offset etc, and another i dubbed keyframe emulator, where up to 8 steps/values in time can be set, with choice of easing functions between them etc.
Open the blend in 5.1.0 and go through the different menu options (noticeable behavior between 'easy looper' and 'keyframe emulator', or 'one function' and 'two functions'). And then open it in 5.0.1 and do the same, you will see what I mean :)

Many lany thanks in advance.

Original bug report: https://projects.blender.org/blender/blender/issues/157253 **System Information** Operating system: Windows 11 Graphics card: Nvidia Geforce RTX 4090 Laptop GPU **Blender Version** Broken: 5.1.0 Worked: 5.0.1 **Short description of error** I make a lot of nodes that have 2 or more 'branches' in their makeup, all with different parameters exposed at surface to keep stuff tidy. Upon making the move to 5.1.0, I noticed almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching (1 branch of the node) is chosen (which in theory should annul any 'usage' of nodes in the other branches). Yet i have changed nothing within the nodes, they stay perfectly identical between versions (minus a few UI changes to group and node context menus). I have gone through 5.1.0 release notes multiple times to see if menu/index switch node behaviors have changed but no success. **Exact steps for others to reproduce the error** Attached is a blend with one of my 'time nodes'. It has two main branches, one that repeats 1 or 2 easing functions between chosen values with options for loop length/offset etc, and another i dubbed keyframe emulator, where up to 8 steps/values in time can be set, with choice of easing functions between them etc. Open the blend in 5.1.0 and go through the different menu options (noticeable behavior between 'easy looper' and 'keyframe emulator', or 'one function' and 'two functions'). And then open it in 5.0.1 and do the same, you will see what I mean :) Many lany thanks in advance.
Triager-bot added the
Status
Needs review
label 2026-04-12 18:13:32 +00:00
Author
Owner

Report is clear

LLM Reasoning

Got it, let's analyze this bug report. The user is asking if the bug report clearly describes the issue. First, check the clarity of the text and steps to reproduce.

The title mentions "Menu / Index Switching changing exposed node parameters in 5.1.0". The body has a short description: nodes with branches have all parameters exposed instead of only the active branch after upgrading to 5.1.0. Then exact steps: open the blend file, check menu options in 5.1 vs 5.0.1.

The steps are present and clear enough—tells others to use the attached blend, compare versions. The description explains what's wrong (parameters not being hidden when switching menus). Even though there's system info, we ignore that per instructions. The text is understandable, so the clarity is good. So the answer should be Yes.

JSON Data

{
"llm_judgement": true,
"processing_time": 10.93286
}

<!-- ID: CLARITY_CHECK --> ### Report is clear <details> <summary>LLM Reasoning</summary> Got it, let's analyze this bug report. The user is asking if the bug report clearly describes the issue. First, check the clarity of the text and steps to reproduce. The title mentions "Menu / Index Switching changing exposed node parameters in 5.1.0". The body has a short description: nodes with branches have all parameters exposed instead of only the active branch after upgrading to 5.1.0. Then exact steps: open the blend file, check menu options in 5.1 vs 5.0.1. The steps are present and clear enough—tells others to use the attached blend, compare versions. The description explains what's wrong (parameters not being hidden when switching menus). Even though there's system info, we ignore that per instructions. The text is understandable, so the clarity is good. So the answer should be Yes. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 10.93286 } </details>
Author
Owner

Report is specific

LLM Reasoning

Got it, let's tackle this. The question is whether the bug report is specific or generic. First, let's recall the definitions: specific is about a particular issue (like crashing with a specific feature), generic is vague.

Looking at the bug report: the title mentions "Menu / Index Switching changing exposed node parameters in 5.1.0". The body talks about nodes with branches and how switching menus affects exposed parameters, which is a specific behavior change between versions. The steps to reproduce are detailed (using a blend file, checking menu options). So it's not vague; it's about a specific issue where index switching changes node parameters in 5.1.0 compared to 5.0.1. So the answer should be 'Specific'.

JSON Data

{
"llm_judgement": true,
"processing_time": 10.155948
}

<!-- ID: SPECIFIC_REPORT --> ### Report is specific <details> <summary>LLM Reasoning</summary> Got it, let's tackle this. The question is whether the bug report is specific or generic. First, let's recall the definitions: specific is about a particular issue (like crashing with a specific feature), generic is vague. Looking at the bug report: the title mentions "Menu / Index Switching changing exposed node parameters in 5.1.0". The body talks about nodes with branches and how switching menus affects exposed parameters, which is a specific behavior change between versions. The steps to reproduce are detailed (using a blend file, checking menu options). So it's not vague; it's about a specific issue where index switching changes node parameters in 5.1.0 compared to 5.0.1. So the answer should be 'Specific'. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 10.155948 } </details>
Author
Owner

Report flagged as NOT a duplicate by LLM

Viewer nodes affecting exposed parameters in a menu/index switch system.

https://projects.blender.org/blender/blender/issues/157229

System Information
Operating system: WINDOWS 11
Graphics card: NVIDIA Geforce RTX 4090 Laptop GPU

Blender Version
Broken: 5.1.0
Worked: 5.0.1

Problem
I am noticing that Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen.

Exact steps for others to reproduce the error
Attached is a blend with one of my nodes. Bottom left is the node. Bottom right in a red frame the viewer node that is affecting the exposed paramaters regardless of whether it is active or not. Delete it in 5.0.1 and then in 5.1.0 and you will see what i mean.

Feature or bug?

Many many thanks in advanced.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the key sections: Description and Steps to Reproduce.

Bug Report 1 talks about menu/index switching changing exposed node parameters in 5.1.0. The steps involve opening a blend with a time node that has branches (like easy looper vs keyframe emulator) and seeing parameters not being annulled when switching menus. So the issue is about index switching affecting exposed params.

Bug Report 2 mentions Viewer nodes affecting exposed parameters regardless of menu/index switch. Steps: delete a viewer node in both versions to see the effect. The problem here is viewer nodes impacting params even when inactive, related to index switches.

Wait, but are they the same? Let's check the core issue. Both are about exposed parameters being affected by something (index switching or viewer nodes) in 5.1.0 vs 5.0.1. But Report 1 is about menu/index switching causing params to show all instead of annulled, Report 2 is about viewer nodes affecting params regardless of index switch. Are these the same underlying issue? Or different?

Wait, maybe not. Let's see: Report 1's steps involve switching between branches (menu options) and seeing params not being hidden. Report 2's steps involve a viewer node affecting params even when inactive, during index switches. The descriptions are different—one is about menu switching causing params to be exposed, the other is about viewer nodes affecting params regardless of switch. So maybe they're different issues. But wait, could the viewer node issue be part of the same problem as the menu switching? Or not?

Wait, the question is if they are the same issue. Let's check the core: both are in 5.1.0, both involve exposed parameters and index/menu switches. But Report 1 is about params being exposed when they shouldn't (due to switch), Report 2 is about viewer nodes affecting params regardless of switch. Are these two separate issues or the same?

Hmm. Let's think: maybe the first report is about menu switching causing params to be visible, the second is about viewer nodes interfering with that. But are they duplicates? The descriptions are different—one is about menu switching behavior, the other is about viewer node impact. So probably not the same issue. Therefore, answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 27.220667000000002,
"duplicate_report_number": "157229"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Viewer nodes affecting exposed parameters in a menu/index switch system.</summary> https://projects.blender.org/blender/blender/issues/157229 **System Information** Operating system: WINDOWS 11 Graphics card: NVIDIA Geforce RTX 4090 Laptop GPU **Blender Version** Broken: 5.1.0 Worked: 5.0.1 **Problem** I am noticing that Viewer nodes, either active or inactive, are affecting exposed parameters regardless of what menu option driving index switches towards the end of my nodes is chosen. **Exact steps for others to reproduce the error** Attached is a blend with one of my nodes. Bottom left is the node. Bottom right in a red frame the viewer node that is affecting the exposed paramaters regardless of whether it is active or not. Delete it in 5.0.1 and then in 5.1.0 and you will see what i mean. Feature or bug? Many many thanks in advanced. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the key sections: Description and Steps to Reproduce. Bug Report 1 talks about menu/index switching changing exposed node parameters in 5.1.0. The steps involve opening a blend with a time node that has branches (like easy looper vs keyframe emulator) and seeing parameters not being annulled when switching menus. So the issue is about index switching affecting exposed params. Bug Report 2 mentions Viewer nodes affecting exposed parameters regardless of menu/index switch. Steps: delete a viewer node in both versions to see the effect. The problem here is viewer nodes impacting params even when inactive, related to index switches. Wait, but are they the same? Let's check the core issue. Both are about exposed parameters being affected by something (index switching or viewer nodes) in 5.1.0 vs 5.0.1. But Report 1 is about menu/index switching causing params to show all instead of annulled, Report 2 is about viewer nodes affecting params regardless of index switch. Are these the same underlying issue? Or different? Wait, maybe not. Let's see: Report 1's steps involve switching between branches (menu options) and seeing params not being hidden. Report 2's steps involve a viewer node affecting params even when inactive, during index switches. The descriptions are different—one is about menu switching causing params to be exposed, the other is about viewer nodes affecting params regardless of switch. So maybe they're different issues. But wait, could the viewer node issue be part of the same problem as the menu switching? Or not? Wait, the question is if they are the same issue. Let's check the core: both are in 5.1.0, both involve exposed parameters and index/menu switches. But Report 1 is about params being exposed when they shouldn't (due to switch), Report 2 is about viewer nodes affecting params regardless of switch. Are these two separate issues or the same? Hmm. Let's think: maybe the first report is about menu switching causing params to be visible, the second is about viewer nodes interfering with that. But are they duplicates? The descriptions are different—one is about menu switching behavior, the other is about viewer node impact. So probably not the same issue. Therefore, answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 27.220667000000002, "duplicate_report_number": "157229" } </details>
Author
Owner

Report flagged as NOT a duplicate by LLM

Nodes: Make Shift+D and Alt+D behave as expected

https://projects.blender.org/blender/blender/issues/146752

We already have separate operators to Duplicate and Duplicate Link in all the node editors.

However when this was introduced, we didn't want to be disruptive and I first introduced bpy.context.preferences.edit.use_duplicate_node_tree to make the new behaviour opt-in.

Now that 5.0 is around the corner I think it is time to:

  • Set the default behaviour to be True.
  • Get rid of this option once and for all.

Note that we did a similar change for the VSE scene strips also for 5.0.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about menu/index switching in nodes changing exposed parameters when moving from Blender 5.0.1 to 5.1.0. The issue is that node branches with different exposed parameters are showing all parameters instead of just the active branch's. The steps involve opening a blend file and checking menu options between versions.

Bug report 2 is about making Shift+D and Alt+D behave as expected in node editors, related to duplicate operators and a preference setting. The focus here is on duplication behavior, not parameter exposure or menu switching.

The core issues are completely different: one is about exposed parameters in node branches during menu/index switching, the other is about duplication shortcuts. So they aren't the same issue. Therefore, the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 12.749317,
"duplicate_report_number": "146752"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Nodes: Make Shift+D and Alt+D behave as expected</summary> https://projects.blender.org/blender/blender/issues/146752 We already have separate operators to Duplicate and Duplicate Link in all the node editors. However when this was introduced, we didn't want to be disruptive and I first introduced `bpy.context.preferences.edit.use_duplicate_node_tree` to make the new behaviour opt-in. Now that 5.0 is around the corner I think it is time to: * Set the default behaviour to be True. * Get rid of this option once and for all. Note that we did a similar change for the VSE scene strips also for 5.0. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about menu/index switching in nodes changing exposed parameters when moving from Blender 5.0.1 to 5.1.0. The issue is that node branches with different exposed parameters are showing all parameters instead of just the active branch's. The steps involve opening a blend file and checking menu options between versions. Bug report 2 is about making Shift+D and Alt+D behave as expected in node editors, related to duplicate operators and a preference setting. The focus here is on duplication behavior, not parameter exposure or menu switching. The core issues are completely different: one is about exposed parameters in node branches during menu/index switching, the other is about duplication shortcuts. So they aren't the same issue. Therefore, the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 12.749317, "duplicate_report_number": "146752" } </details>
Author
Owner

Report flagged as NOT a duplicate by LLM

Can't use 2 group inputs for 2 different menu switches that are the same

https://projects.blender.org/blender/blender/issues/118698

System Information
Operating system: Windows-10-10.0.26063-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.61

Blender Version
Broken: version: 4.1.0 Beta, branch: blender-v4.1-release, commit date: 2024-02-22 20:09, hash: ced066e0c8db
Worked: Never

Short description of error
I have 2 menu switch nodes that have exactly the same settings, X / Y / Z but it won't work to have the same group input for the menus, it might be by design or a limitation but from user view it's a bug (atleast it seems to me).

Exact steps for others to reproduce the error
Create this node setup and see that it won't work

image

LLM Reasoning

Got it, let's analyze the two bug reports. First, look at the description and steps for each.

Bug report 1 is about menu/index switching in Blender 5.1.0 changing exposed node parameters—when switching between branches (like different menu options), all parameters are shown instead of just the active branch. The steps involve opening a blend file with two branches and comparing 5.1.0 vs 5.0.1.

Bug report 2 is about using two group inputs for two menu switches that have the same settings, which doesn't work. The steps are creating a node setup with two identical menu switches and seeing it fail.

The core issues are different: one is about parameters being exposed incorrectly when switching menus (bug 1), the other is about using duplicate menu switches with the same group input (bug 2). So they're not the same issue. Therefore, the answer is No.

JSON Data

{
"llm_judgement": false,
"processing_time": 13.794555,
"duplicate_report_number": "118698"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Can't use 2 group inputs for 2 different menu switches that are the same</summary> https://projects.blender.org/blender/blender/issues/118698 **System Information** Operating system: Windows-10-10.0.26063-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 551.61 **Blender Version** Broken: version: 4.1.0 Beta, branch: blender-v4.1-release, commit date: 2024-02-22 20:09, hash: `ced066e0c8db` Worked: Never **Short description of error** I have 2 menu switch nodes that have exactly the same settings, X / Y / Z but it won't work to have the same group input for the menus, it might be by design or a limitation but from user view it's a bug (atleast it seems to me). **Exact steps for others to reproduce the error** Create this node setup and see that it won't work ![image](/attachments/66e9e522-5b2f-4141-ad8c-d3c62e5c06d1) </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze the two bug reports. First, look at the description and steps for each. Bug report 1 is about menu/index switching in Blender 5.1.0 changing exposed node parameters—when switching between branches (like different menu options), all parameters are shown instead of just the active branch. The steps involve opening a blend file with two branches and comparing 5.1.0 vs 5.0.1. Bug report 2 is about using two group inputs for two menu switches that have the same settings, which doesn't work. The steps are creating a node setup with two identical menu switches and seeing it fail. The core issues are different: one is about parameters being exposed incorrectly when switching menus (bug 1), the other is about using duplicate menu switches with the same group input (bug 2). So they're not the same issue. Therefore, the answer is No. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 13.794555, "duplicate_report_number": "118698" } </details>
Author
Owner

Report flagged as NOT a duplicate by LLM

Nodes: Menu Switch node default value is not set to the first item upon resetting

https://projects.blender.org/blender/blender/issues/155034

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3070 NVIDIA Corporation NVIDIA 580.97 Vulkan Backend

Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-01 00:06, hash: 6eefd13b2619

Short description of error
As you can see in the videos, the default value for the menu switch node is not set to the first item in the list when resetting. Also, when you add a new item and if the list was empty, the added item is not set as the default immediately.
First I thought it was because of the name "A" and "B" but as you can see in the second video, it's very in consistent.


Exact steps for others to reproduce the error
In geometry_nodes editor or the shaders editor,

  1. Add menu switch node
  2. Remove all the items
  3. Add new ones. See that the first item is not set a default immediately.
  4. Also, resetting the default value will leave it blank.

You can also try renmaing the items A and B to see if it's because of that specific names. It sometimes works, sometime doesn't.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about menu/index switching changing exposed node parameters in Blender 5.1.0. The issue is that when using a node with multiple branches (like different menu options), all parameters are exposed regardless of which branch is selected, whereas in 5.0.1 it worked correctly. The steps involve opening a blend file and checking the behavior between versions.

Bug report 2 is about the Menu Switch node's default value not being set to the first item when resetting or adding new items. The steps are adding the node, removing items, adding new ones, and checking if the first is default, plus resetting leaves it blank.

These are different issues: one is about exposed parameters in multi-branch nodes (menu switching affecting parameter visibility), the other is about the Menu Switch node's default value handling. So they're not duplicates.

JSON Data

{
"llm_judgement": false,
"processing_time": 14.490769,
"duplicate_report_number": "155034"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Nodes: Menu Switch node default value is not set to the first item upon resetting</summary> https://projects.blender.org/blender/blender/issues/155034 **System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3070 NVIDIA Corporation NVIDIA 580.97 Vulkan Backend **Blender Version** Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-01 00:06, hash: `6eefd13b2619` **Short description of error** As you can see in the videos, the default value for the menu switch node is not set to the first item in the list when resetting. Also, when you add a new item and if the list was empty, the added item is not set as the default immediately. First I thought it was because of the name "A" and "B" but as you can see in the second video, it's very in consistent. <video src="attachments/b511f137-532b-4b63-ba83-34ab37ad1084" title="geo_node.mp4" controls></video> <video src="attachments/b899c1ab-9603-46f4-9642-ad7bbb6b1b26" title="shader_node.mp4" controls></video> **Exact steps for others to reproduce the error** In geometry_nodes editor or the shaders editor, 1. Add menu switch node 2. Remove all the items 3. Add new ones. See that the first item is not set a default immediately. 4. Also, resetting the default value will leave it blank. You can also try renmaing the items A and B to see if it's because of that specific names. It sometimes works, sometime doesn't. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about menu/index switching changing exposed node parameters in Blender 5.1.0. The issue is that when using a node with multiple branches (like different menu options), all parameters are exposed regardless of which branch is selected, whereas in 5.0.1 it worked correctly. The steps involve opening a blend file and checking the behavior between versions. Bug report 2 is about the Menu Switch node's default value not being set to the first item when resetting or adding new items. The steps are adding the node, removing items, adding new ones, and checking if the first is default, plus resetting leaves it blank. These are different issues: one is about exposed parameters in multi-branch nodes (menu switching affecting parameter visibility), the other is about the Menu Switch node's default value handling. So they're not duplicates. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 14.490769, "duplicate_report_number": "155034" } </details>
Author
Owner

Report flagged as duplicate by LLM

Unused node will cause menu switch don't hide parameters

https://projects.blender.org/blender/blender/issues/156285

System Information
Operating system: Windows-11-10.0.26100-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 572.16 Opengl Backend

Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-11 22:42, hash: 81e41f5f73fa
Worked: (newest version of Blender that worked as expected)

Short description of error
The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node.

Exact steps for others to reproduce the error

  • Open the attached menuswitch.blend
  • connect the bottom menu switch node to the set position node ( or any node, for that matter).
  • observe the hiding of the unused socket in the group (on the left side) suddenly starts working.
LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug Report 1: The issue is about menu/index switching changing exposed node parameters in 5.1.0. The user has nodes with branches, and when switching menus, parameters that should be hidden (from unused branches) are showing up. Steps involve opening a blend file in 5.1.0 vs 5.0.1 to see the difference.

Bug Report 2: The issue is about unused node causing menu switch not hiding parameters. The steps involve connecting a menu switch node to make the hiding work, implying that an unconnected identical menu switch node was confusing the parameter hiding.

Now, check if they're the same. Both are about menu switching and parameter hiding (exposed nodes) not working as expected. But let's see the details:

Report 1: Focuses on parameters being exposed regardless of index switching in 5.1.0, comparing to 5.0.1.

Report 2: Focuses on an unconnected identical menu switch node causing confusion in hiding unused sockets.

Are these the same underlying issue? Let's see. Both involve menu switches and parameter visibility (hiding unused parameters). But Report 1 is about a version change (5.1.0) where previously hidden params are now shown, while Report 2 is about an unconnected node causing the hiding to fail. Maybe related, but let's check the steps.

Report 1's steps: Open blend in 5.1 vs 5.0.1, switch menus. Report 2's steps: Connect a menu switch node to fix hiding. The core issue might be similar (menu switching not hiding params), but the causes or specific scenarios differ. However, the question is if they are duplicates. Let's see if the descriptions align.

Report 1 says "almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching...". Report 2 says "The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node."

Are these the same? Maybe not exactly, but let's think. The key is whether the issue is about menu switching causing parameters to be exposed when they shouldn't. Both have that. But Report 2 has a specific cause (unconnected identical node), while Report 1 is a version change. However, maybe the underlying bug is the same: menu switch not properly hiding unused parameters. But let's check if the steps are similar.

Report 1's steps involve switching menus and seeing params exposed. Report 2's steps involve connecting a node to fix it. The core problem might be the same, but the specific triggers differ. However, the question is whether they are duplicates. Let's see: if both are about menu switch not hiding parameters, then maybe yes? Wait, no—Report 1 is about a version change (5.1.0) where previously working nodes now show params, while Report 2 is about an unconnected node causing confusion. Are these the same issue?

Wait, let's re-read. Report 1: "Upon making the move to 5.1.0, I noticed almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching...". So in 5.1.0, when you switch menus (index), params from other branches are shown. Report 2: "The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node." So when there's an unconnected identical menu switch node, the hiding fails.

Are these two different manifestations of the same bug? Or different bugs?

Let's think about the core issue: menu switching not properly hiding unused parameters. Report 1 is a version regression (5.1.0), Report 2 is a specific case with an unconnected node. But are they duplicates? The question says to focus on Description and Steps.

Report 1's description: parameters exposed regardless of index switching in 5.1.0. Steps: open blend in 5.1 vs 5.0.1, switch menus.

Report 2's description: hiding fails due to unconnected identical menu switch node. Steps: connect the menu switch node to fix it.

Are these the same issue? Maybe not. Because Report 1 is about a version change where previously working nodes now show params, while Report 2 is about an unconnected node causing confusion. The underlying cause might be different. So the answer would be No? Wait, but maybe they are related. Let's see.

Alternatively, maybe both are about menu switch not hiding parameters, so duplicates. But let's check the steps again. Report 1's steps involve comparing versions, Report 2's steps involve connecting a node. The core problem is similar, but the specific scenarios differ. However, the question is whether they are the same issue (duplicates). If the descriptions and steps point to the same underlying bug, then Yes. Otherwise No.

Wait, let's see: Report 1 says "parameters exposed regardless of what menu option driving index switching". Report 2 says "hiding of unused sockets influenced by a menuswitch can get confused...". So both are about menu switch not hiding parameters. But Report 2 has a specific cause (unconnected node), while Report 1 is a version regression. Are these two different bugs or the same?

Maybe they are duplicates because the core issue is menu switch not hiding parameters. Let's think: if in Report 1, the problem is that when you switch menus, params from other branches are shown (i.e., not hidden), and Report 2 is about an unconnected node causing the same problem (params not hidden), then maybe they are duplicates. But I'm not sure. Alternatively, maybe Report 2 is a specific case of Report 1's bug.

But the question says to answer Yes or No. Let's see: if both are about menu switch not hiding parameters, then maybe Yes. But let's check the steps again. Report 1's steps: open blend in 5.1 vs 5.0.1, switch menus. Report 2's steps: connect a node to fix it. The core problem is similar, but the triggers are different. However, the question is whether they are duplicates. If the descriptions and steps indicate the same issue, then Yes. Otherwise No.

Alternatively, maybe Report 2 is a different bug because it involves an unconnected node, while Report 1 is about version change. So perhaps No. But I'm not sure. Let's think again.

Report 1: The user has nodes with branches, and in 5.1.0, when switching menus (index), parameters from other branches are exposed (not hidden). So the menu switch isn't hiding unused params.

Report 2: The user has a menu switch node that is unconnected, and this causes the hiding of unused sockets to fail. When they connect it, it works. So the presence of an unconnected identical menu switch node confuses the hiding.

Are these two different bugs or the same? Let's see: both are about menu switch not hiding parameters. Report 1 is a version regression (5.1.0), Report 2 is a specific case with an unconnected node. Maybe they are duplicates because the underlying bug is the same (menu switch not properly hiding unused params). So the answer would be Yes? Or No?

Wait, let's check the titles. Report 1: "Menu / Index Switching changing exposed node parameters in 5.1.0". Report 2: "Unused node will cause menu switch don't hide parameters". Both mention menu switch and parameter hiding. So maybe they are duplicates.

But I'm not entirely sure. Let's think of the steps. Report 1's steps involve switching menus and seeing params exposed. Report 2's steps involve connecting a node to fix it. The core problem is similar, so maybe Yes. But maybe not. Alternatively, maybe Report 2 is a specific case of Report 1's bug.

Given that both are about menu switch not hiding parameters, I think they could be duplicates. So the answer is Yes? Wait, but let's see: Report 1 is about a version change (5.1.0) where previously working nodes now show params, while Report 2 is about an unconnected node causing confusion. Are these two different bugs?

Alternatively, maybe Report 2 is a specific instance of the bug described in Report 1. So they are duplicates. Therefore, the answer is Yes? Or No?

Wait, let's check the descriptions again. Report 1: "almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching...". Report 2: "The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node."

So both are about menu switch not hiding parameters. So maybe they are duplicates. Therefore, the answer is Yes? Or No?

Hmm. I think the key is whether the core issue is the same. Both involve menu switching and parameter visibility (hiding unused params). So yes, they are duplicates. So the answer is Yes. Wait, but maybe not. Let's see: Report 1 is about a version regression, Report 2 is about an unconnected node. Maybe different causes, so different bugs. Therefore, No.

I'm a bit torn. Let's think of the steps. Report 1's steps: open blend in 5.1 vs 5.0.1, switch menus. Report 2's steps: connect a menu switch node to fix it. The core problem is similar, but the triggers are different. However, the question is whether they are duplicates. If the descriptions and steps point to the same underlying bug, then Yes. Otherwise No.

Given that both are about menu switch not hiding parameters, I think they are duplicates. So the answer is Yes. Wait, but maybe Report 2 is a specific case of Report 1's bug. So yes, duplicates. Therefore, the answer is Yes.

JSON Data

{
"llm_judgement": true,
"processing_time": 111.510727,
"duplicate_report_number": "156285"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as duplicate by LLM <details> <summary>Unused node will cause menu switch don't hide parameters</summary> https://projects.blender.org/blender/blender/issues/156285 **System Information** Operating system: Windows-11-10.0.26100-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 4050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 572.16 Opengl Backend **Blender Version** Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-11 22:42, hash: `81e41f5f73fa` Worked: (newest version of Blender that worked as expected) **Short description of error** The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node. **Exact steps for others to reproduce the error** - Open the attached [menuswitch.blend](/attachments/49a7d427-ebb2-48e2-86f0-e7bdd6ecabe6) - connect the bottom `menu switch` node to the `set position` node ( or any node, for that matter). - observe the hiding of the unused socket in the group (on the left side) suddenly starts working. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug Report 1: The issue is about menu/index switching changing exposed node parameters in 5.1.0. The user has nodes with branches, and when switching menus, parameters that should be hidden (from unused branches) are showing up. Steps involve opening a blend file in 5.1.0 vs 5.0.1 to see the difference. Bug Report 2: The issue is about unused node causing menu switch not hiding parameters. The steps involve connecting a menu switch node to make the hiding work, implying that an unconnected identical menu switch node was confusing the parameter hiding. Now, check if they're the same. Both are about menu switching and parameter hiding (exposed nodes) not working as expected. But let's see the details: Report 1: Focuses on parameters being exposed regardless of index switching in 5.1.0, comparing to 5.0.1. Report 2: Focuses on an unconnected identical menu switch node causing confusion in hiding unused sockets. Are these the same underlying issue? Let's see. Both involve menu switches and parameter visibility (hiding unused parameters). But Report 1 is about a version change (5.1.0) where previously hidden params are now shown, while Report 2 is about an unconnected node causing the hiding to fail. Maybe related, but let's check the steps. Report 1's steps: Open blend in 5.1 vs 5.0.1, switch menus. Report 2's steps: Connect a menu switch node to fix hiding. The core issue might be similar (menu switching not hiding params), but the causes or specific scenarios differ. However, the question is if they are duplicates. Let's see if the descriptions align. Report 1 says "almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching...". Report 2 says "The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node." Are these the same? Maybe not exactly, but let's think. The key is whether the issue is about menu switching causing parameters to be exposed when they shouldn't. Both have that. But Report 2 has a specific cause (unconnected identical node), while Report 1 is a version change. However, maybe the underlying bug is the same: menu switch not properly hiding unused parameters. But let's check if the steps are similar. Report 1's steps involve switching menus and seeing params exposed. Report 2's steps involve connecting a node to fix it. The core problem might be the same, but the specific triggers differ. However, the question is whether they are duplicates. Let's see: if both are about menu switch not hiding parameters, then maybe yes? Wait, no—Report 1 is about a version change (5.1.0) where previously working nodes now show params, while Report 2 is about an unconnected node causing confusion. Are these the same issue? Wait, let's re-read. Report 1: "Upon making the move to 5.1.0, I noticed almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching...". So in 5.1.0, when you switch menus (index), params from other branches are shown. Report 2: "The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node." So when there's an unconnected identical menu switch node, the hiding fails. Are these two different manifestations of the same bug? Or different bugs? Let's think about the core issue: menu switching not properly hiding unused parameters. Report 1 is a version regression (5.1.0), Report 2 is a specific case with an unconnected node. But are they duplicates? The question says to focus on Description and Steps. Report 1's description: parameters exposed regardless of index switching in 5.1.0. Steps: open blend in 5.1 vs 5.0.1, switch menus. Report 2's description: hiding fails due to unconnected identical menu switch node. Steps: connect the menu switch node to fix it. Are these the same issue? Maybe not. Because Report 1 is about a version change where previously working nodes now show params, while Report 2 is about an unconnected node causing confusion. The underlying cause might be different. So the answer would be No? Wait, but maybe they are related. Let's see. Alternatively, maybe both are about menu switch not hiding parameters, so duplicates. But let's check the steps again. Report 1's steps involve comparing versions, Report 2's steps involve connecting a node. The core problem is similar, but the specific scenarios differ. However, the question is whether they are the same issue (duplicates). If the descriptions and steps point to the same underlying bug, then Yes. Otherwise No. Wait, let's see: Report 1 says "parameters exposed regardless of what menu option driving index switching". Report 2 says "hiding of unused sockets influenced by a menuswitch can get confused...". So both are about menu switch not hiding parameters. But Report 2 has a specific cause (unconnected node), while Report 1 is a version regression. Are these two different bugs or the same? Maybe they are duplicates because the core issue is menu switch not hiding parameters. Let's think: if in Report 1, the problem is that when you switch menus, params from other branches are shown (i.e., not hidden), and Report 2 is about an unconnected node causing the same problem (params not hidden), then maybe they are duplicates. But I'm not sure. Alternatively, maybe Report 2 is a specific case of Report 1's bug. But the question says to answer Yes or No. Let's see: if both are about menu switch not hiding parameters, then maybe Yes. But let's check the steps again. Report 1's steps: open blend in 5.1 vs 5.0.1, switch menus. Report 2's steps: connect a node to fix it. The core problem is similar, but the triggers are different. However, the question is whether they are duplicates. If the descriptions and steps indicate the same issue, then Yes. Otherwise No. Alternatively, maybe Report 2 is a different bug because it involves an unconnected node, while Report 1 is about version change. So perhaps No. But I'm not sure. Let's think again. Report 1: The user has nodes with branches, and in 5.1.0, when switching menus (index), parameters from other branches are exposed (not hidden). So the menu switch isn't hiding unused params. Report 2: The user has a menu switch node that is unconnected, and this causes the hiding of unused sockets to fail. When they connect it, it works. So the presence of an unconnected identical menu switch node confuses the hiding. Are these two different bugs or the same? Let's see: both are about menu switch not hiding parameters. Report 1 is a version regression (5.1.0), Report 2 is a specific case with an unconnected node. Maybe they are duplicates because the underlying bug is the same (menu switch not properly hiding unused params). So the answer would be Yes? Or No? Wait, let's check the titles. Report 1: "Menu / Index Switching changing exposed node parameters in 5.1.0". Report 2: "Unused node will cause menu switch don't hide parameters". Both mention menu switch and parameter hiding. So maybe they are duplicates. But I'm not entirely sure. Let's think of the steps. Report 1's steps involve switching menus and seeing params exposed. Report 2's steps involve connecting a node to fix it. The core problem is similar, so maybe Yes. But maybe not. Alternatively, maybe Report 2 is a specific case of Report 1's bug. Given that both are about menu switch not hiding parameters, I think they could be duplicates. So the answer is Yes? Wait, but let's see: Report 1 is about a version change (5.1.0) where previously working nodes now show params, while Report 2 is about an unconnected node causing confusion. Are these two different bugs? Alternatively, maybe Report 2 is a specific instance of the bug described in Report 1. So they are duplicates. Therefore, the answer is Yes? Or No? Wait, let's check the descriptions again. Report 1: "almost all of my nodes that have this structure have most/all parameters exposed regardless of what menu option driving index switching...". Report 2: "The hiding of unused sockets influenced by a menuswitch can get confused by the presense of an identical unconnected menu switch node." So both are about menu switch not hiding parameters. So maybe they are duplicates. Therefore, the answer is Yes? Or No? Hmm. I think the key is whether the core issue is the same. Both involve menu switching and parameter visibility (hiding unused params). So yes, they are duplicates. So the answer is Yes. Wait, but maybe not. Let's see: Report 1 is about a version regression, Report 2 is about an unconnected node. Maybe different causes, so different bugs. Therefore, No. I'm a bit torn. Let's think of the steps. Report 1's steps: open blend in 5.1 vs 5.0.1, switch menus. Report 2's steps: connect a menu switch node to fix it. The core problem is similar, but the triggers are different. However, the question is whether they are duplicates. If the descriptions and steps point to the same underlying bug, then Yes. Otherwise No. Given that both are about menu switch not hiding parameters, I think they are duplicates. So the answer is Yes. Wait, but maybe Report 2 is a specific case of Report 1's bug. So yes, duplicates. Therefore, the answer is Yes. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 111.510727, "duplicate_report_number": "156285" } </details>
Triager-bot added the Trager-Bot Will Send Comment label 2026-04-12 18:16:57 +00:00
Triager-bot added
Status
Good judgement
and removed
Status
Needs review
labels 2026-04-13 14:28:09 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Triager-bot/blender-bug-reports#63