[kovarex] [2.0.17] Spidertron Toolbar Remotes Losing Selections/Adding 'Fake' Selections When Grabbed On 'Wrong' Surface
Posted: Wed Nov 13, 2024 2:34 pm
What did you do?
After setting up my first spidertron on Nauvis primarily using a remote placed in the toolbar, and with no obvious issues controlling it, I shipped myself and spidertron #2 to Gleba to set it up there. Using the toolbar remote, I tried adding this new spidertron and was unable to do so. Perhaps up to this point that's an intended albeit clunky interaction, if remotes are supposed to save control groups only from their first creation, but things got more confusing the more I tested it.
Ofc if toolbar remotes are supposed to be editable that's also a lil bug, but this report is mostly for the other weirdness I discovered along the way.
What happened?
TLDR:
Toolbar remotes bug when grabbed while viewing surfaces other than the one they are intended to have selected a spider from(Or just related to the surface they were saved from, which seems to be a factor in some of the advanced cases) - Probably the main bug.
Toolbar remotes can't be created(placed into the toolbar for the first time) while viewing unrelated surfaces from their selection(0 displayed as selected, even if spiders are legitimately selected elsewhere) - Weird edge case I assume related to not wanting empty remotes on the toolbar combined with only checking the current surface.
Toolbar remotes can be created while viewing unrelated surfaces when the bugged remote says (1 selected) even if that selection is on another surface. - Side effect of the main bug breaking that apparent restriction.
The Remote button also creates a copy of the most recently used toolbar remote(Or perhaps is just overwritten by the toolbar's preset when it they are selected) - Probably intended, but contributes to stacking the above effects.
Primarily, this all leads to seemingly random moments of having more spiders selected than should be possible on that surface. And then depending on whether you're intended to have remotes controlling spiders across surfaces, either:
This makes creating remotes across multiple surfaces/remotes that control spiders from multiple surfaces much more painful than it should be, and working results can later fail depending on the viewed surface while you select them.
or
This makes creating remotes that control spiders from multiple surfaces possible when it shouldn't be, and they break appropriately to that fact after a while.
For the reproductions, here's the rant of specifics:
Just using only the button, things work as smoothly as I would expect. If I tab through the planets and select both spidertrons with the button-remote, both will remain selected every time I continue pulling out the button-remote without using any toolbar remotes, and while swapping between planet views. Deselecting them also saves properly. Overall this seems perfect, a remote that is saving a different preset for each surface being looked at all at once. The 'number of selected' properly changes to 0 on every surface not currently with a selected spider.
Example: Using the button(Making sure you haven't polluted it's default empty state by making/using toolbar remotes), select Gleba-Tron, tab over to Nauvis and select Nauvis-Tron, swapping between surfaces should only show 1 on those two, nowhere else. Both remain selected until unselected, are controllable as intended, etc
Problems start occur when toolbar remotes get involved.
As setup for I simply created a blank remote from the button, select Nauvis-tron and give that a slot(1) in toolbar while viewing Nauvis, Then with the button again, deselecting Nauvis-tron to be safe, before selecting Gleba-Tron and gave it another slot(3) in toolbar while viewing Gleba.
Remotes pulled out on the wrong surface can end up with fake selections and sometimes not select what they are supposed to select.
Example: Looking at Nauvis and pulling out Gleba's remote, it indicates 1 spider selected despite this being false(For Nauvis). When moving to look back at Gleb with this still held out, it will then indicate Gleba has 0 spiders and Gleba's spider is not selected. This will consistently happen if you keep pulling the remote out looking at Nauvis.
But once you pull the remote out once while looking at Gleba, it will correctly select the Gleba-spider and then remember that going forward, even if later pulled out from Nauvis! Including remembering if this state is saved and later loaded.
Regardless, this gleba remote will still also display a 1 when being held on Nauvis. And because the remote button seems to create a copy of your recently used remote settings, then the button is also temporarily poisoned to have an extra fake spider selected under the same conditions after holding Gleba's remote.
Overall also it seems that saving remotes to the toolbar doesn't work at all, if no spidertrons selected are on the currently viewed surface. No idea if that part is intended, but when related to the bug: The 'fake' of the other surface's spider counts, and will(while viewing Gleb) let you add a remote that is set to control Nauvis'
Examples:
Starting with a fresh save & remote from the button, swap to Gleba, select Gleba, view Nauvis, and cannot add to toolbar despite theoretically holding a real and un-bugged remote.
Pull out Gleba's set up remote(3) and put away, grab the button's remote which has now copied it, and you are allowed to add this to the toolbar even though it's representing a spidertron from another surface.
Remotes that control multiple spidertrons across surfaces but fail when pulled out from the wrong surface
Examples:
Starting with a fresh save & remote from the button - View/Select Nauvis - View/Select Gleba - Add to toolbar while viewing Gleba - Pull out immediately: Controls both successfully while still holding or pulling out from Gleba, breaks if ever pulled out viewing Nauvis(Leaving only Gleba selected)
Starting with a fresh save & remote from the button - View/Select Nauvis - View/Select Gleba - Add to toolbar after swapping back to viewing Nauvis - Pull out immediately: Controls both successfully while still holding or pulling out from Nauvis, breaks if ever pulled out viewing Gleba(Leaving only Nauvis selected)
What did you expect to happen instead? It might be obvious to you, but do it anyway!
Overall I was hoping to grab my existing nauvis-spider remote, add the gleba-spider, and have it immediately save with both selected. That way the same toolbar remote can be used for controlling Nauvis spiders while viewing Nauvis, Gleba on Gleba, etc.
In practice, I was originally expecting the button on the toolbar to basically just be a pure shortcut to the existing button's functionality, but failing that(I assume it saving separate groups is intended and desired behavior) hopefully it can be fixed/upgraded to let those selection groups cover multiple surfaces. And also to let you edit their selection after creation without destroying and remaking the remote, ideally.
Does it happen always, once, or sometimes?
The behavior mostly seemed to be weird depending on differences in surface viewed while saving the remote vs. surface viewed when grabbing the remote. Every test I wrote out seems to be consistent in replicating the effect though.
This seems to be related although not exactly the same as viewtopic.php?p=636057#p636057
After setting up my first spidertron on Nauvis primarily using a remote placed in the toolbar, and with no obvious issues controlling it, I shipped myself and spidertron #2 to Gleba to set it up there. Using the toolbar remote, I tried adding this new spidertron and was unable to do so. Perhaps up to this point that's an intended albeit clunky interaction, if remotes are supposed to save control groups only from their first creation, but things got more confusing the more I tested it.
Ofc if toolbar remotes are supposed to be editable that's also a lil bug, but this report is mostly for the other weirdness I discovered along the way.
What happened?
TLDR:
Toolbar remotes bug when grabbed while viewing surfaces other than the one they are intended to have selected a spider from(Or just related to the surface they were saved from, which seems to be a factor in some of the advanced cases) - Probably the main bug.
Toolbar remotes can't be created(placed into the toolbar for the first time) while viewing unrelated surfaces from their selection(0 displayed as selected, even if spiders are legitimately selected elsewhere) - Weird edge case I assume related to not wanting empty remotes on the toolbar combined with only checking the current surface.
Toolbar remotes can be created while viewing unrelated surfaces when the bugged remote says (1 selected) even if that selection is on another surface. - Side effect of the main bug breaking that apparent restriction.
The Remote button also creates a copy of the most recently used toolbar remote(Or perhaps is just overwritten by the toolbar's preset when it they are selected) - Probably intended, but contributes to stacking the above effects.
Primarily, this all leads to seemingly random moments of having more spiders selected than should be possible on that surface. And then depending on whether you're intended to have remotes controlling spiders across surfaces, either:
This makes creating remotes across multiple surfaces/remotes that control spiders from multiple surfaces much more painful than it should be, and working results can later fail depending on the viewed surface while you select them.
or
This makes creating remotes that control spiders from multiple surfaces possible when it shouldn't be, and they break appropriately to that fact after a while.
For the reproductions, here's the rant of specifics:
Just using only the button, things work as smoothly as I would expect. If I tab through the planets and select both spidertrons with the button-remote, both will remain selected every time I continue pulling out the button-remote without using any toolbar remotes, and while swapping between planet views. Deselecting them also saves properly. Overall this seems perfect, a remote that is saving a different preset for each surface being looked at all at once. The 'number of selected' properly changes to 0 on every surface not currently with a selected spider.
Example: Using the button(Making sure you haven't polluted it's default empty state by making/using toolbar remotes), select Gleba-Tron, tab over to Nauvis and select Nauvis-Tron, swapping between surfaces should only show 1 on those two, nowhere else. Both remain selected until unselected, are controllable as intended, etc
Problems start occur when toolbar remotes get involved.
As setup for I simply created a blank remote from the button, select Nauvis-tron and give that a slot(1) in toolbar while viewing Nauvis, Then with the button again, deselecting Nauvis-tron to be safe, before selecting Gleba-Tron and gave it another slot(3) in toolbar while viewing Gleba.
Remotes pulled out on the wrong surface can end up with fake selections and sometimes not select what they are supposed to select.
Example: Looking at Nauvis and pulling out Gleba's remote, it indicates 1 spider selected despite this being false(For Nauvis). When moving to look back at Gleb with this still held out, it will then indicate Gleba has 0 spiders and Gleba's spider is not selected. This will consistently happen if you keep pulling the remote out looking at Nauvis.
But once you pull the remote out once while looking at Gleba, it will correctly select the Gleba-spider and then remember that going forward, even if later pulled out from Nauvis! Including remembering if this state is saved and later loaded.
Regardless, this gleba remote will still also display a 1 when being held on Nauvis. And because the remote button seems to create a copy of your recently used remote settings, then the button is also temporarily poisoned to have an extra fake spider selected under the same conditions after holding Gleba's remote.
Overall also it seems that saving remotes to the toolbar doesn't work at all, if no spidertrons selected are on the currently viewed surface. No idea if that part is intended, but when related to the bug: The 'fake' of the other surface's spider counts, and will(while viewing Gleb) let you add a remote that is set to control Nauvis'
Examples:
Starting with a fresh save & remote from the button, swap to Gleba, select Gleba, view Nauvis, and cannot add to toolbar despite theoretically holding a real and un-bugged remote.
Pull out Gleba's set up remote(3) and put away, grab the button's remote which has now copied it, and you are allowed to add this to the toolbar even though it's representing a spidertron from another surface.
Remotes that control multiple spidertrons across surfaces but fail when pulled out from the wrong surface
Examples:
Starting with a fresh save & remote from the button - View/Select Nauvis - View/Select Gleba - Add to toolbar while viewing Gleba - Pull out immediately: Controls both successfully while still holding or pulling out from Gleba, breaks if ever pulled out viewing Nauvis(Leaving only Gleba selected)
Starting with a fresh save & remote from the button - View/Select Nauvis - View/Select Gleba - Add to toolbar after swapping back to viewing Nauvis - Pull out immediately: Controls both successfully while still holding or pulling out from Nauvis, breaks if ever pulled out viewing Gleba(Leaving only Nauvis selected)
What did you expect to happen instead? It might be obvious to you, but do it anyway!
Overall I was hoping to grab my existing nauvis-spider remote, add the gleba-spider, and have it immediately save with both selected. That way the same toolbar remote can be used for controlling Nauvis spiders while viewing Nauvis, Gleba on Gleba, etc.
In practice, I was originally expecting the button on the toolbar to basically just be a pure shortcut to the existing button's functionality, but failing that(I assume it saving separate groups is intended and desired behavior) hopefully it can be fixed/upgraded to let those selection groups cover multiple surfaces. And also to let you edit their selection after creation without destroying and remaking the remote, ideally.
Does it happen always, once, or sometimes?
The behavior mostly seemed to be weird depending on differences in surface viewed while saving the remote vs. surface viewed when grabbing the remote. Every test I wrote out seems to be consistent in replicating the effect though.
This seems to be related although not exactly the same as viewtopic.php?p=636057#p636057