KSP 1.10.1 Debian Buster. Changing kOS nametag in editor must use enter key to complete as clicking buttons clicks object underneath

[mgalyean]

In the editor, when changing a part kos nametag, the clicks are falling through to the object underneath when clicking either the 'cancel' or the 'accept' button on the kOS name tag popup. The workaround is to hit enter instead. There is no workaround for canceling the edit. Click-Through-Blocker generally works fine for me but in the case of the nametag requester it appears to have no power. As a possible help if this ends up being a linux only issue, click events in linux are fairly different from those in windows. I remember that a click event in linux is only registered on mouse-up, not mouse-down, and the element that the pointer is over on mouse-up, if the same as the mouse-down event, will get the click event. Perhaps someone coding the requester, not realizing this, managed to force the requester to work with mouse-down only and this may have caused a fall-through side effect. Or not, just throwing it out there in case it is relevant

How to reproduce: KSP 1.10.1 Debian Buster In VAB or SPH

bring up PAW for a part and click 'change name tag'. Type in new name and click 'accept' or 'cancel'. The part underneath the requestor will be grabbed by the mouse and selected. This is about guaranteed as the requestor always pops up in the center of the screen and the editor defaults to the craft being in the center and the camera pointed at the craft

[charlesstaats]

I have a similar issue using KSP 1.8 on a Mac, although I've always been able to back out somehow (don't remember how at the moment) and then rotate/pan/zoom in the VAB so that some part of the "Accept" button is not over a part.

[nuggreat]

This issue is likely resolved in the development branch of kOS and so the solution is to compile the dev branch your self or wait until the dev becomes the release branch.

If you have clickthrough blocker installed a mod must actively support it for it to work. If clickthrough blocker is not actively supported by the mod then simply having clickthrough blocker installed can cause clickthrough problems. See this issue #2729 for some of dunbaratu's comments/work on the subject.

Also if I remember right You can also click somewhere other than in the text or button area and drag the window else where in the VAB before pressing 'accept'/'cancel' to avoid the click through problem.

[mgalyean]

I haven't found a way to back out, or if I did I forgot it because it was more complicated than editing to what I want an hitting enter. If the popup didn't center on the screen it would help as that is typically over the craft.

I just tried dragging; no go. Can't drag by titlebar or anywhere else. But strangely, clicking to drag does not select the part behind, even without dragging; only clicking the buttons does this. It is a very unique type of click-through problem that I think is more related to the kOS gui buttons not preventing a cascade of the event to objects behind than a general KSP click-through problem as it behaves fairly differently. I'm not familiar with the KSP/unity/mono environment but generally in gui programming, when trapping a click event one has to proactively prevent further cascade of the event. The default is simply to be yet another "subscriber" to the event. The objects in front typically get the event first, but if they don't break the chain it will be passed on to the next object down. Typically

[Dunbaratu]

I'm not familiar with the KSP/unity/mono environment but generally in gui programming, when trapping a click event one has to proactively prevent further cascade of the event.

You are operating under the misapprehension that Unity's GUI windows care about the stacking order and give the window on top first dibs. They don't, especially if the thing underneath isn't a GUI window, but is some other thing (like clicking on a vessel part).

kOS CANNOT stop other code from getting the event if kOS isn't given first dibs on processing it. In general this seems to be the problem. I DO prevent further cascade of the event, but by the time kOS sees it, the vessel part underneath has already seen the click. The vessel part click appears to be handled out of sync with other things.

LinuxGuruGamer's ClickThroughBlocker tries to stop this by grabbing all input events and redistributing them according to its own rules, and the next version of kOS will try using it.

[mgalyean]

I was pretty clear that I was describing how many systems operate and stated that I'm not sure how unity works. So no misapprehension here as I defined the limits of my apprehensions up front and was only trying to offer what insights that might be useful. I'm not having the issue with many other buttons on other mods, so I'm very much trying to describe the problem as well as I can from outside the black box. Your work is very much appreciated

[mgalyean]

From a quick search I'm finding that Unity listeners added programmatically get the event after those instantiated earlier. There are two separate chains that are concatenated in that order. I imagine the listener for craft manipulation is in the latter category and any mod will be in the former. This could explain the problem. It might also explain why so many mod, and many KSP, popups, place the canvases to the side of the craft (even if they ignore the other 3 popups already occupying that space most of the time). A lot of modding problems in this environment seem to come down to alleviating rather than truly solving and changing the placement may alleviate the issue until results of a click-through-blocker approach can be seen