[1.12.x] Click Through Blocker - NEW DEPENDENCY

[leatherneck6017]

4 hours ago, SynX said:

This mod have caused unity errors...

You're going to need to provide log files to get support.

[Brigadier]

7 hours ago, SynX said:

This mod have caused unity errors...

Read the post at the link below in my sig block for more information on what to post.  At least post the versions of KSP and this mod you're using, a link to your player.log fine (if KSP 1.8+) uploaded to a file sharing service.

Edited February 16, 2020 by Brigadier
Repetition

[linuxgurugamer]

7 hours ago, SynX said:

This mod have caused unity errors...

If you had bothered to read the post RIGHT ABOVE YOURS, you would have seen the problem. To repeat:

 

[EasyAce]

Is this compatible with 1.9.0?

[linuxgurugamer]

Yes

[Dunbaratu]

I am considering removing the input lock code of kOS and replacing it with just using this mod, because the current kOS code doesn't always prevent other mods from seeing keypress events first before kOS gets them.  It does for most mods but there's always one or two edge cases that bleed through.  But one phrase in the description gives me pause, and it's this:

Quote

position of the mouse is checked to see if it was on top of the window Rect

This describes how it handles mouse clicks, but how does it handle a mod trying to capture an EventType.KeyDown in its OnGui()?  Does it use the mouse pointer's current position at the moment the key is pressed (like X-Windows' focus-follows-mouse mode)?  Or does it use where the mouse pointer *used to be* the last time there was a mouseclick, even if the pointer's not there anymore now (Like click-to-focus mode)?

kOS's terminal window currently behaves in a click-to-focus mode.

Edited March 4, 2020 by Steven Mading

[linuxgurugamer]

If I am following your question, it keeps track of the mouse position

its very easy to install, takes about 2 minutes to do, the best thing may be to install it and see if it does what you want it to do.

If this isn’t goid, contact me via PM to discuss 

Edited March 5, 2020 by linuxgurugamer

[abbiii]

On 5/10/2019 at 9:42 PM, GDorn said:

I'm noticing that some clicks still fall through in PreciseNode.  Specifically, while in the map screen editing a node, if I click with the left mouse button too quickly, it thinks I am double-clicking behind the window and deactivates my target.

Getting this too with the latest version

[leatherneck6017]

6 hours ago, abbiii said:

Getting this too with the latest version

Only for Precise Node?

[abbiii]

1 minute ago, leatherneck6017 said:

Only for Precise Node?

Nope, got it also with Antenna Helper which also uses CTB, which leads me to believe it's a flaw of CTB

[leatherneck6017]

3 minutes ago, abbiii said:

Nope, got it also with Antenna Helper which also uses CTB, which leads me to believe it's a flaw of CTB

More likely a flaw with CTB implementation for those mods. Try reaching out with proper logs on those threads.

[Krzeszny]

CKAN shows that this mod, as well as MiniAVC and Toolbar Controller are incompatible with 1.9.1 (which makes around 100 mods show as incompatible). Could you please update the metadata?

[Dunbaratu]

kOS developer here.  A few months ago I tried to explain a thing I saw in ClickThroughBlocker code that felt kind of off to me, and I did a poor job trying to describe it.  I now have a much better example to illustrate what I was talking about with the word "focus-follows-mouse".  For this example, I use "KSP Notes", which is the simplest ClickThroughBlocker-using mod I could find (it just lets you type text notes in a window.)

(For the screenshots below, I had to maually draw where the mouse pointer was, since KSP's screenshots don't show the pointer.)

The same effect happens for all the other keypresses the game uses, like "M" to toggle map view, "T" to toggle SAS, and so on.
A ClickThroughBlocker window's input locks engage as soon as the mouse pointer crosses the threshold into that window's rect, even if the user never intends to click that window.

Was this the intended behavior of ClickThroughBlocker, (or if not, has it been this way long enough that users expect it now and it's too late to change it?).

Currently, kOS's terminal (which does not use ClickThroughBlocker) does not take focus away from the main game until you click on it.  When I tried changing it to use ClickThroughBlocker, it started doing this behavior, which is what makes me nervous about publishing that change.  It's not something that kOS users would be expecting or desiring.

[Corax]

It's not something that kOS users would be expecting or desiring.

Actually I think I would, desire that is.
Maybe it's just the way I'm used to how window focusing works with my window manager (Focus follows mouse, but not required to click, I think I've also seen it called "lazy focus" in other places).
IMO it speeds up the workflow considerably, which is especially helpful in situations like KSP, where you might need to quickly give input focus to your main controls, and the additional click may take just that fraction of a second too long.

[linuxgurugamer]

On 5/22/2020 at 7:46 PM, Steven Mading said:

Was this the intended behavior of ClickThroughBlocker, (or if not, has it been this way long enough that users expect it now and it's too late to change it?).

Currently, kOS's terminal (which does not use ClickThroughBlocker) does not take focus away from the main game until you click on it.  When I tried changing it to use ClickThroughBlocker, it started doing this behavior, which is what makes me nervous about publishing that change.  It's not something that kOS users would be expecting or desiring.

Working as intended.

I suppose that I could have a setting to ignore a window, but then clicks will fall through underneath.

So lets assume there is such a setting.  Enabling it is easy, click a button to activate.  But how would you them disable it?  If the window is unresponsive, the only way I could see doing that would be with a separate window, at which time you might as well just have two lines in your OnGUI, one of which calls the Clickthroughblocker method, and one which doesn’t 

Edited May 24, 2020 by linuxgurugamer

[Dunbaratu]

Rather than "option to ignore one of the windows", I wonder if there could be "option to configure ClickThroughBlocker itself into either click-to-focus or focus-follows-mouse mode".  (So it applies universally to all the mods that use it, according to user's preference).

The ClickThroughBlocker github code looks simple enough I may try playing around with this myself and see if I can submit a PR.  The harder part is seeing if all the other mods using ClickThroughBlocker may have been written in a way that presumes focus-follows-mouse and would break in some way if using click-to-focus.  If so then this might not be a viable option even it was technically doable.

Edited May 24, 2020 by Steven Mading

[linuxgurugamer]

Hi all, 

I've implemented a new feature based on some requests.

The current mod has the focus follow the mouse (FocusFollowsMouse), meaning that the window under the mouse has the focus.  I've implemented a new mode called FocusFollowsClick, mean that you have to click on a window to move the focus there, and to remove focus you need to click outside the window;  either left or right click will work.

I have this available in a beta, which needs testing.  I'd appreciate as many people as possible try it out and let me know how it goes.

Latest Beta available here:  https://github.com/linuxgurugamer/ClickThroughBlocker/releases

Changes

• Added Settings page 
  • Added new setting to specify Focus follows Click
• Added code to have the focus follow the click instead of the mouse, for both editor and flight modes

To activate it, in any scene (other than th editor):

1. Hit the escape key to bring up the Game Paused menu
2. Click Settings
3. Click Difficulty Options (at the top)
4. Click the tab (along the left) labeled Click-Through-Blocker

There will be two options displayed; the first one is Focus follows mouse click

Enable it to use this new mode

The second toggle is Focus change is global. This currently has no effect, I just haven't implemented that yet.  For information only for now, this option will normally be enabled, and changing the focus option in one save will change it in all saves which have the option enabled. 

 

@Steven Mading this is for you (and others)

Edited May 26, 2020 by linuxgurugamer

[Dunbaratu]

@linuxgurugamerThank you for implementing this - I will be trying it out late tonight.

[linuxgurugamer]

New beta, 0.1.10.1

• Modified the CBTMonitor to not run in any scene other than the editor
• Fixed window data not getting cleared properly
   

https://github.com/linuxgurugamer/ClickThroughBlocker/releases

[IonMage]

I just installed this to satisfy a dependency for NavHud, and when I get to the KSC, I cannot interact with anything via mouse, save for the toolbar in the lower right.  I cannot click on any facility, and even the 'menu' button in the upper right is grayed out.  Removing this mod solves the issue, but obviously breaks NavHud, expectedly.  I am still able to right-click and move the camera around.

[linuxgurugamer]

7 hours ago, IonMage said:

I just installed this to satisfy a dependency for NavHud, and when I get to the KSC, I cannot interact with anything via mouse, save for the toolbar in the lower right.  I cannot click on any facility, and even the 'menu' button in the upper right is grayed out.  Removing this mod solves the issue, but obviously breaks NavHud, expectedly.  I am still able to right-click and move the camera around.

Well, something was installed wrong, or the wrong version installed, etc.

I can't do anything without a log file

[IonMage]

Im using Clickthroughblocker labeled as 1.8.0-0.1.10.1, most recent version listed.

Toolbarcontrol is 1.8.0-01.10.1, most recent version listed.

Navhud is extracted from the 'master' file on github, since the spacedock link said it was obsolete. 

Incidentally, I noticed that each of these is labeled as 1.8.0, but the threads for each of them have titles indicated 1.9.x compatability.  I figured this meant that the 1.8.0 versions didnt break and are therefore compatable.  If not, having them linked from a thread labeled as 1.9.x compatable is highly misleading.

I just tried removing NavHud and reinstalled Clickthroughblocker. and this no longer happened, so maybe the glitch is to be found in there. 

On that note I subsequently tried reinstalling NavHud to replicate the original behavior and get an appropriate logfile, and it was not replicated.  But Then Navhud wasn't working.

Then I investigated it more closely and I see that the GameData folder found on the github master has only 4 tiny files of what is likely metadata, meaning it definitely is the wrong package.  I will try the 'obsolete' spacedock version next and see how that goes.

Update:  All is working well now.  Huh.  If I run into any more issues should I continue the discussion in here or bring it to the Navhud thread?  I dont want to split the discussion but at the same time want to stay in the proper, relevant thread.

[linuxgurugamer]

On 5/29/2020 at 3:51 AM, IonMage said:

Im using Clickthroughblocker labeled as 1.8.0-0.1.10.1, most recent version listed.

Toolbarcontrol is 1.8.0-01.10.1, most recent version listed.

Navhud is extracted from the 'master' file on github, since the spacedock link said it was obsolete. 

Incidentally, I noticed that each of these is labeled as 1.8.0, but the threads for each of them have titles indicated 1.9.x compatability.  I figured this meant that the 1.8.0 versions didnt break and are therefore compatable.  If not, having them linked from a thread labeled as 1.9.x compatable is highly misleading.

I just tried removing NavHud and reinstalled Clickthroughblocker. and this no longer happened, so maybe the glitch is to be found in there. 

On that note I subsequently tried reinstalling NavHud to replicate the original behavior and get an appropriate logfile, and it was not replicated.  But Then Navhud wasn't working.

Then I investigated it more closely and I see that the GameData folder found on the github master has only 4 tiny files of what is likely metadata, meaning it definitely is the wrong package.  I will try the 'obsolete' spacedock version next and see how that goes.

Update:  All is working well now.  Huh.  If I run into any more issues should I continue the discussion in here or bring it to the Navhud thread?  I dont want to split the discussion but at the same time want to stay in the proper, relevant thread.

The GameData on Github is NOT a release.  If you want a release of any of my mods, go to the Releases tab

 

=============================

 

New Beta, 0.1.10.3

• Added MiniMod to clear input locks via toolbar button:  
• Added one-time popup window 
• Added ToolbarController as a dependency
• Removed need to save window rect
• Added Focus Follows Click mode
• Reorganized code a bit
• Removed some unnecessary assignments
• Added stock settings page to support the FocusFollowsClick mode

Available only from here:  https://github.com/linuxgurugamer/ClickThroughBlocker/releases/tag/0.1.10.3

 

Edited June 5, 2020 by linuxgurugamer

[simtom]

Hello,

I'm not sure if my problem is related to Click Through Blocker or this one, but at startup I always get an input lock (as seen in the console). This means that I can't access anything on the screen (can't click on anything basically).

This problem only occurs after I installed both Toolbar Controller and Click Through Blocker. Is there something I did wrong, or haven't set up correctly?

I can fix it by removing the input locks but that's only a temporary solution.

[0211beno]

3 hours ago, simtom said:

Hello,

I'm not sure if my problem is related to Click Through Blocker or this one, but at startup I always get an input lock (as seen in the console). This means that I can't access anything on the screen (can't click on anything basically).

This problem only occurs after I installed both Toolbar Controller and Click Through Blocker. Is there something I did wrong, or haven't set up correctly?

I can fix it by removing the input locks but that's only a temporary solution.

I also have this problem, running KSP 1.8.1