Michael,

I'm actually a bit surprised that you are deferring the fix of a V2 bug until V3, especially since the browser seems like one of the big features of V2 and having it work in a way that is extremely confusing and frustrating to the user doesn't seem like the approach you normally take.

I just ran across this bug today, and spent a lot of time head scratching, trying to figure out if I correctly understood how the browser was supposed to work or not. Eventually I did a search of the forums and found this thread. I've now bound you're one liner "fix" to a hot-key, but it is still a bit annoying having to select something, press the hot-key, then click the eyeball icon in the browser to hide the selected object.

I hope you at least document the problem clearly in the documentation, and provide the information on how to set up the hot-key fix...

Hi Dave, some kinds of bug fixes can just be too risky to attempt right near the end of a beta cycle, especially if the bug fix will involve altering some sensitive or heavily used area.

In this case it would involve altering behavior that happens on every selection, that's such a frequently occuring and important area that I'm just not comfortable with making any changes to what happens after every selection at the end of the beta cycle.

It seems that the "Selected/Unselected" sub categories in Types just were not used by anyone at all until recently, otherwise this bug would have surfaced earlier. That also makes it hard to justify a potentially disruptive fix when it is in such a little used area.

There is a lot of potential with any change to actually introduce new problems and bugs even while fixing some other one. That's why it can sometimes be better to actually not attempt to fix a bug, especially if it is in a "high potential danger" area, and for a "low usage" type area.

Anyway, I hope that will explain the reasons why it can be better to defer some bug fixes.

Basically, making any changes at all to heavily used areas right before shipping a final product without any beta testing of them is not a good recipe for stability.

- Michael

Hi Dave, after thinking about it a bit, I think the best choice for this is to remove those "selected" and "unselected" type sub-categories from the Scene Browser by default.

You'll be able to re-enable them by a setting in the moi.ini file and also if that is set I will update the scene browser when selection changes so that you should be able to avoid the workaround.

That way there will be some protection from any potential bad side effect from having the Scene Browser updated with every selection change.

The setting in the moi.ini file will be under:

[Scene Browser]
EnableSelectionSubTypes=n

- Michael

Michael,

Sounds like a good idea to me! This actually will eliminate the bug, since it should work as expected when it is enabled in the .ini file.

I've also thought about what I was trying to do a bit more and realized that I can get a much faster workflow by binding 'hide selected' and 'unhide all' to keys. But I'm also a big fan of having things work correctly, so your fix should definitely help out. Might even give you one less thing to do in V3. I'm glad my complaint had such a positive effect :-)