Build 19: Active window tracking

[Freddie]

http://mojoware.org/art/active-window-tracking.gif

[Fursphere]

I'm guessing that this is almost entirely for "same box" multiboxers? Not one-client per PC setups.

[Freddie]

I'm guessing that this is almost entirely for "same box" multiboxers? Not one-client per PC setups.
Maybe somebody who asked for it can explain. I don't know why people like it.

[Akoko]

Does it only track WoW windows or does it track all other windows as well?

[Freddie]

Does it only track WoW windows or does it track all other windows as well?
All windows.

This is a feature of Windows not Mojo. Mojo is just turning it on and off.

[Moorea]

if you have only 1 window per pc and they are all maximized then you don't care about this feature, otherwise you'll love that you don't need to click for the window to get the (unbroadcasted) keys

[Moorea]

there is a bug: when you click either of the 2 radio button set; it unsets the other one

gimme build 20 :-)

[Fursphere]

Works fine for me.

Windows 7 Pro. I only enabled "window tracking" - its pretty cool even for basic Windows stuff.

[Freddie]

there is a bug: when you click either of the 2 radio button set; it unsets the other one

gimme build 20 :-)
That's strange. I played around with it for about 10 minutes before I posted it and this bug wasn't there.

Maybe the bug is happening because of optimization in the release build. I was testing with a debug build. Well I'll look at a new debug build and see.

Thanks.

[Fursphere]

OK, I got a different bug.

Setting it back to "system defaults" doesn't turn it off - you have to click "off" then apply it. Then it'll "stick".

It messes with the Taskbar though - makes it hard to use it.

[Freddie]

It's fixed but I'm going to change the window a little bit before i post it. about 20 min.

[Freddie]

OK, I got a different bug.

Setting it back to "system defaults" doesn't turn it off - you have to click "off" then apply it. Then it'll "stick".

It messes with the Taskbar though - makes it hard to use it.

That's not a bug. "Use system setting" really means "Mojo doesn't do anything." You won't get your system defaults back till you reboot.

Maybe there's a better name than "Use system defaults" for those buttons.

Edit: The problem is, Mojo has no way to know what your system defaults are They are probably in the registry but Microsoft doesn't document them (at least I don't think it does) and I don't lke using undocumented features.

Edit: Maybe just this once I'll use undocumented settings. :)

[Freddie]

Build 20 is up.

Fur, you're right, that "Use system setting" stuff doesn't cut it.

I'll have to figure out tomorrow what to do about it.

[Freddie]

It's amazing how tiny things like this turn into problems. :)

This whole feature should have taken 45 minutes. :)

Here's my proposed solution for "Use system settings."

When Mojo starts up, it will record the settings that were in use before it started.

If you select "Use system settings," Mojo will restore those settings.

Maybe the caption should say "Use prior settings" or something like that.

Maybe the caption should say "Restore something or other."

"Restore original settings."

"Use existing settings."

"Use current settings."

[TheFallenOne]

It's amazing how tiny things like this turn into problems. :)

This whole feature should have taken 45 minutes. :)

Here's my proposed solution for "Use system settings."

When Mojo starts up, it will record the settings that were in use before it started.

If you select "Use system settings," Mojo will restore those settings.

Maybe the caption should say "Use prior settings" or something like that.

Maybe the caption should say "Restore something or other."

"Restore original settings."

"Use existing settings."

"Use current settings."

Would it be better to store the settings that were in use whenever the user changes the setting off of "Use system default", rather than when the program starts?

That would prevent conflicts if the user changed the Windows setting between starting Mojo and changing the setting in Mojo.

[Freddie]

Maybe I'll do it that way.

[Moorea]

I don't mind having to reboot to get back to system default if it's hard to remember and it wouldn't be the same (ie it would change something from default) - don't sweat that part too much

now the radio buttons do all work ! thx a lot !

small suggestion: add an "apply" button so the user can experiment with the settings without having to click "ok" and reopen the dialog between each try


thanks a lot for that feature and quick turn around !

another minor nit picking (but I wouldn't sweat it either) the raise window part doesn't work if the first on is on off (so I guess in theory it should be grayed out in that case)

[I know it's not a mojo feature but you're doing the UI for microsoft :-) ]

minor unrelated bug report: I tried to assign NumLock to toggle broacasting on/off so I get some visual feedback on my keyboard (pending the overlay or semi transparent status window :p) but if I do it eats the event and my keyboard light doesn't toggle anymore
(tried to put both nothing and "when numlock is on" which didn't work; and pressed "numlock" which worked (toggles it in mojo) but then doesn't toggle the light on my keyboard anymore

another interesting side effect/bug of this new feature:

when I mouse to the other PC's screen, mojo comes to the foreground on my main PC, even if the mouse doesn't at all go over mojo's window while moving out of the 1st pc' screen (seems like when you hide the local cursor; you put it maybe on mojo's and that raise that window - can you leave it at the last window it was in on the original computer screen?)

sorry for all the issue reports :-) don't be discouraged :-)

[Freddie]

small suggestion: add an "apply" button so the user can experiment with the settings without having to click "ok" and reopen the dialog between each try
To save time, I've been omitting Apply buttons from all settings boxes. I'll add them in at some future time.

Maybe I'll add them today since you reminded me.


I don't mind having to reboot to get back to system default if it's hard to remember and it wouldn't be the same (ie it would change something from default) - don't sweat that part too much
I agree. The problem is that if the "do nothing" buttons work that way, it's hard to give them names that make their function clear. But when I woke up this morning, a possible answer popped into my head:

-- Do not change
-- Turn off
-- Turn on

[Freddie]

another interesting side effect/bug of this new feature:

when I mouse to the other PC's screen, mojo comes to the foreground on my main PC, even if the mouse doesn't at all go over mojo's window while moving out of the 1st pc' screen (seems like when you hide the local cursor; you put it maybe on mojo's and that raise that window - can you leave it at the last window it was in on the original computer screen?)
During mouseover the local cursor has to be handled in a pretty complicated way. It's not just parked. It's moving, it's on top of a special invisible window, it's constantly moving away from the center of the screen and getting recentered, etc.

Edit: I just looked at the source code and this doesn't seem to be true. I think I was remembering a different version I wrote earlier. I'm not sure why this problem is happening.

I'll try to figure out a way to fix this.


sorry for all the issue reports :-) don't be discouraged :-)
I'm not discouraged. I'm glad you're noticing all this stuff.

You probably feel like you're dumping work on me but my reaction is the exact opposite.

My reaction is, "Oh good, I don't have to spend time testing, because Moorea will tell me about errors."

[Freddie]

another minor nit picking (but I wouldn't sweat it either) the raise window part doesn't work if the first on is on off (so I guess in theory it should be grayed out in that case)

[I know it's not a mojo feature but you're doing the UI for microsoft :-) ]
I think that's important. I"m glad you pointed it out.

If I don't change that, people will report it as a bug, because they'll say "raise window" isn't working. I'll change it.

[Freddie]

minor unrelated bug report: I tried to assign NumLock to toggle broacasting on/off so I get some visual feedback on my keyboard (pending the overlay or semi transparent status window :p) but if I do it eats the event and my keyboard light doesn't toggle anymore
(tried to put both nothing and "when numlock is on" which didn't work; and pressed "numlock" which worked (toggles it in mojo) but then doesn't toggle the light on my keyboard anymore

I know why this happens but I don't know how to design the program to deal with it.

When a keystroke triggers a hotkey, Mojo takes some action. Then it has to decide whether to pass the keystroke to the operating system so the OS and other applications can take whatever actions they would normally take if the keystroke had not been redefined as a hotkey trigger.

(I said the other day that I don't like the word "pass" but in this case, Mojo really is allowing something to pass.)

By default, Mojo doesn't pass hotkey triggers to the operating system. Triggers have been redefined by the user to be commands to Mojo, and Mojo processes those commands, and that's the end of it.

When this happens, users often say that the hotkey program "swallowed" their keystrokes. This isn't right because they redefined the keystrokes themselves, and the keystrokes got processed.

But it's convenient to say the keystrokes get swallowed (you said eaten) so I'll say "swallowed" too.

Now, the thing is, sometimes the user wants the trigger to get swallowed and sometimes he doesn't. The way I handled this in HotkeyNet was with a keyword, <PassThrough>.

You're familiar with HotkeyNet so I 'll illustrate this with two examples from HotkeyNet's script language. We're talking about the difference between the two following hotkeys:



<Hotkey NumLock>
<SetWindowBroadcast toggle>

<Hotkey NumLock>
<PassThrough>
<SetWindowBroadcast toggle>
The first one would have the side effects you've reported here. The second one would not.

That's fine for HotkeyNet because everything's defined by the user in a script. But Mojo's supposed to be easier to use.

So the question here is, how to handle the issue of passthrough or not passthrough.

I would like to hide this decision from the user but I can't think of any way to do that, that would really work.

The only thing that occurs to me is to add it as a checkbox on the Set Trigger dialog. In this case, with this hotkey, when you make the trigger, you'd check "PassThrough."

[Fursphere]

Numlock Light Toggle as a visual indicator:
- A visual onscreen overlay will solve this. So I feel the numlock issue should be pushed aside as something else is already planned. I don't think creating two workarounds for one "root" issue is a good way to spend time.

[Moorea]

(about numlock example)

cool so maybe add checkbox to the dialog "with pass thru" option ?

that or automagically treat the checked "when numlock is on" and nothing in the top (keyed in) section as meaning that you should just look at the key status but not consume it ?
(as I assume that if I say for instance "A" and numlock on; you won't touch / do anything with numlock on/off transitions)

(about mojo getting raised when mouse is on another screen)
any chance to make that invisible window independant from mojo's other windows so only the invisible one gets raised by the OS (if it's not possible to make it not do that at all)

I'll add apply in the feature requests in case you forget but for bugs do you need something to track them?

[Moorea]

ps: Fur: I agree a visual overlay would fix my numlock issue but I suspect eating up the key in all cases may have other consequences and so the option to look/peek instead of consume the event is probably valuable for other advanced use - minor though I'd agree - I'd rather get some basic DNP and click broadcasting than this (in term of order)

[Fursphere]

ps: Fur: I agree a visual overlay would fix my numlock issue but I suspect eating up the key in all cases may have other consequences and so the option to look/peek instead of consume the event is probably valuable for other advanced use - minor though I'd agree - I'd rather get some basic DNP and click broadcasting than this (in term of order)

True. Can you clearly define the issue / request and add it to the FAQ Request post? :)

[Freddie]

Numlock Light Toggle as a visual indicator:
- A visual onscreen overlay will solve this. So I feel the numlock issue should be pushed aside as something else is already planned. I don't think creating two workarounds for one "root" issue is a good way to spend time.
It's really a question about passthrough not numlock. It just happened to get noticed for the first time with Moorea's numlock hotkey.

It has to be decided sooner or later because it's going to affect a big percentage of user-defined hotkeys.

It's not a work around. It's a choice of two ways that hotkeys can work and the choice has to be provided.

[Moorea]

I think I added them in
http://www.dual-boxing.com/showpost.php?p=250812&postcount=2
and a new
http://www.dual-boxing.com/showpost.php?p=250812&postcount=3

[Freddie]

(about numlock example)

cool so maybe add checkbox to the dialog "with pass thru" option ?
Unless somebody thinks of something better.


that or automagically treat the checked "when numlock is on" and nothing in the top (keyed in) section as meaning that you should just look at the key status but not consume it ?
"When numlock is on" is a state, not an event. Only an event can trigger a hotkey. You have to do something (press a key) to make something happen. Which key do you press? That's what the top section is for.


(as I assume that if I say for instance "A" and numlock on; you won't touch / do anything with numlock on/off transitions)
I'm not sure I understand. Are you saying you define the trigger NumLockOn A?

That means, "If I press A while NumLock is on, Mojo should do the action."

There's no way to infer anything about passing from that trigger. Two people might define hotkeys with that same trigger. The first person might want A to pass, and the second might want the opposite.


(about mojo getting raised when mouse is on another screen)
any chance to make that invisible window independant from mojo's other windows so only the invisible one gets raised by the OS (if it's not possible to make it not do that at all)
I'm looking at the source code and it looks like the invisible window isn't even a factor. I'm not sure why this is happening.


I'll add apply in the feature requests in case you forget but for bugs do you need something to track them?
I think probably it would be better if I track bugs myself because users have no way to know whether something is a bug or unfinished work.

If you include unfinished work in the bug list you would immediately have dozens or maybe hundreds of items and it would only make the program look bad.

[Akoko]

Would it be possible for it to only track WoW windows (and maybe Mojo window(s))? I find it super annoying that it's continually mousing over to my internet browser when I don't want it to!

[Freddie]

Would it be possible for it to only track WoW windows (and maybe Mojo window(s))? I find it super annoying that it's continually mousing over to my internet browser when I don't want it to!
Active Window Tracking doesn't distinguish one program from another but you might be able to get the effect you want some other way.

For example, you could set all your WoW windows "topmost" (always on top). That way your browser wouldn't cover up a WoW. That's not quite what you want , though.

[Fursphere]

I find it super annoying that it's continually mousing over to my internet browser when I don't want it to!

Technically speaking, YOU are mousing over internet explorer. If you don't want to mouse over IE - don't put the mouse cursor there. :)

[Freddie]

Technically speaking, YOU are mousing over internet explorer. If you don't want to mouse over IE - don't put the mouse cursor there. :)

Bah technicalities. This calls for one of those jumping mice. :)

[Freddie]

Build 21 is up with bug fixes and minor changes requested in this thread.

-- I fixed (fingers crossed) Mojo rising to foreground during mouseover.

-- Added progressive disclosure to Active Win Track settings.

-- Changed names of fields on Active Win Track settings.

-- I couldn't fix the crash reported by Moorea but I wrapped the crash location in an exception handler. From now on, when that bug happens, the program should display a message box and keep going. If people can figure out what makes the message box appear, that would be great.

[TheFallenOne]

Active Window Tracking doesn't distinguish one program from another but you might be able to get the effect you want some other way.

For example, you could set all your WoW windows "topmost" (always on top). That way your browser wouldn't cover up a WoW. That's not quite what you want , though.

I'm not entirely sure how it's handled, but Keyclone has a "Focus Follows Mouse" option that makes the mouseover'd WoW the focused window without clicking, and it doesn't use the global Windows setting, AKA it doesn't set the focus to non-WoW windows when they are moused over.

I'm not sure if you'd be able to use the same system as Keyclone to handle the active window tracking in Mojo or not (or even figure out how they handled it), but figured I'd mention it anyways. :)

[Freddie]

I'm not entirely sure how it's handled, but Keyclone has a "Focus Follows Mouse" option that makes the mouseover'd WoW the focused window without clicking, and it doesn't use the global Windows setting, AKA it doesn't set the focus to non-WoW windows when they are moused over.

I'm not sure if you'd be able to use the same system as Keyclone to handle the active window tracking in Mojo or not (or even figure out how they handled it), but figured I'd mention it anyways. :)
I guess one way would be, when the OS calls the mouse hook:

1. Call a Win32 function called WindowFromPoint that tells us which window the cursor is in.

2. Check whether that window is on our list of WoWs. (If a program doesn't maintain a list of WoWs, it could call a function that gets the window class name and compare that to WoW's.)

3. If the answer is yes, call SetForegroundWindow.

I could add that to to program as an option. It's just a few lines of code and I don't think it would affect performance noticeably.

[Moorea]

I found a small bug/issue with the latest (21) build:

I changed my network settings for 2 laptop to use ICS (internet connection sharing) [ethernet link between the 2 and 1 of them only on wireless - this is to see if latency is even smaller that way when KMing] and the slave computer was showing as a black screen on the master one (and the master not at all on the slave) until I went into advanced settings and set the master (the one on the computer with the internet connection) to use the private IP from ICS instead of system default - I think Mojo should be smart enough to guess that it should check both sides if I have multiple network interfaces - some explanation of the colors would help too (what does black and yellow mean exactly ? just seems that blue = good and the others are not so good but what exactly?)

[Moorea]

another related issue: if I start a mojo on the other side of the interface that one shows yellow for the middle pc on the outside one (when the ics one works) or if I get back to default setting, the master and 3rd outside work but the one behind the ics is black...

Anyway to have all the PCs showing up as well as (maybe) proxying automatically so the one outside sees the one inside too - through the one it would see ?

I think for the first problem you just need to listen to all interfaces - the proxy part can wait

[Freddie]

Mojo's connection stuff isn't finished yet. With the current build, you if you make a change like that you need to shut down both Mojos and then start them both.

Did you do that?

Edit: For all problems of this type, please let me know if you shut down all Mojos and restarted all of them before you saw the problem. It makes a big difference to me.

The color codes aren't finished. The current scheme is temporary. Blue means two socket connections between the computers; purple means one socket connection (they are connected in one direction but not the other); black means no connection.

[Moorea]

yes I shutdown all mojos in between each try/change as I noticed that exiting 1 doesn't change the status on the other (doesn't detect the deconnection)

[Freddie]

I think for the first problem you just need to listen to all interfaces - the proxy part can wait
Mojo does listen on all interfaces. Please let me know if you shut down all Mojos and restarted them.

Edit: Sorry this crossed your last post.

[Moorea]

another small issue : a multi monitor mojo doesn't show as multi monitor on the other computers mouseover settings screen

[Freddie]

I think Mojo should be smart enough to guess that it should check both sides if I have multiple network interfaces
I'm not sure what you mean by check both sides. Mojo doesn't check anything having to do with IP addresses. Here's how Mojo actually works.

Each Mojo sends out UDP packets to the whole network saying, "I'm a Mojo, call me if you're interested." Meanwhile other Mojos are listening for these packets on all their adapters. There is no special IP address used.

Where the specified IP address comes in (the one you had to change) is that when a Mojo sends out the message, "Call me if you're interested," it has to provide an IP address at which it will be called. In other words, it actually says, "If your'e interested, call me at the following IP address: XX.XX.XX.XX." By default, Mojo lets the OS choose this IP address. That didn't work, so you intevened and chose an address manually. That didn't work either.

What's happening here is (apparently) some peculiarity in the way ICS works. It's possible that it doesn't propagate UDP broadcasts. I don't know anything about ICS. I'll look into it.

[Freddie]

another small issue : a multi monitor mojo doesn't show as multi monitor on the other computers mouseover settings screen
Do they have a blue connection? (Blue in both directions?) They won't show up properly if they aren't connected properly.

[Moorea]

another bug: I set my "bring cursor home" key to Ctrl-Home

when I press that key; it leaves Ctrl stuck on the slave the cursor was in (when going back and using the native keyboard/mouse there everything is like if ctrl is pressed; for instance mouse wheel on firefox zooms in/out instead of scrolling)

[Freddie]

Edit: On second thought, that's probably the same sort of thing as the old Alt-tab problem. Mouseover gets terminated at the instant you press the Home key. Then, a few milliseconds later, you release the Ctrl key, but by then mouseover is no longer happening and therefore the "release Ctrl" signal doesn't get sent to the remote.

I'll have to change something. Thanks for letting me know.

[Moorea]

I'm not sure what you mean by check both sides. Mojo doesn't check anything having to do with IP addresses. Here's how Mojo actually works.

Each Mojo sends out UDP packets to the whole network saying, "I'm a Mojo, call me if you're interested." Meanwhile other Mojos are listening for these packets on all their adapters. There is no special IP address used.

Where the specified IP address comes in (the one you had to change) is that when a Mojo sends out the message, "Call me if you're interested," it has to provide an IP address at which it will be called. In other words, it actually says, "If your'e interested, call me at the following IP address: XX.XX.XX.XX." By default, Mojo lets the OS choose this IP address. That didn't work, so you intevened and chose an address manually. That didn't work either.

it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is having both the "inside" and "outside" mojos

so to solve the first case; can you send in that msg all the IPs instead of just one ?




What's happening here is (apparently) some peculiarity in the way ICS works. It's possible that it doesn't propagate UDP broadcasts. I don't know anything about ICS. I'll look into it.it's windows' built in 0 config NAT and it's kind of handy; I expect several people to use it - but maybe not in the weird setup that I have where I try to save 1 wireless latency yet still use extra computers on both side of that nat

[Moorea]

Nothing is going to work right if they don't have blue connections in both directions.
the bug I reported about screens is unrelated - I go back to a "working" setup - it's related to my request of wrapping in the faq thread but I didn't want to put a bug report there as it's probably very short lived (you'll fix it soon ;-) )

[Moorea]

The color codes aren't finished. The current scheme is temporary. Blue means two socket connections between the computers; purple means one socket connection (they are connected in one direction but not the other); black means no connection.

I think you are color blind (it's ok, no shame, my dad is too) as it's yellow (or maybe mustard rather as it's a dark yellow) and not purple :-)

This being said, more seriously/interestingly, why do you need 2 sockets - a socket is bi directional; so you should only need either of the machine to connect to the other; not both

[Fursphere]

I only get yellowish when my firewall is blocking one or more mojos. But its yellow for sure.

Black for disconnected.

Blue for connected and ready to go.

[Freddie]

so to solve the first case; can you send in that msg all the IPs instead of just one ?
I need to understand why it's not working before I can fix it. I'll have to set up ICS here, watch the programs in a debugger, log their communications, etc.

Edit:


it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is having both the "inside" and "outside" mojos
I don't understand the two cases. I don't know what "inside" and "outside" mean.

Every IP address that a computer knows about itself is on its drop down list. If at least one of those IP addresses works, you can select it.

If none of them work, then a human being needs to enter it. Send them all automatically won't help if none of them work.

[Freddie]

This being said, more seriously/interestingly, why do you need 2 sockets - a socket is bi directional; so you should only need either of the machine to connect to the other; not both
Because I discovered through testing that Windows sockets are capable of making more transmissions per second in one direction than the other. Winsock connections aren't symmetrical in terms of performance.

[Moorea]

Because I discovered through testing that Windows sockets are capable of making more transmissions per second in one direction than the other. Winsock connections aren't symmetrical in terms of performance.
IC, Are you sure it's direction issue ? I think what you may have found is you get more throughput using 2 sockets than using 1 (for the same latency, and depending on stack tuning) but the direction itself shouldn't(*) matter - is the difference really noticeable ? Maybe you can fallback to using 1 socket if somehow you can't get the second one ? (though that may make your code more complicated) - I guess sending all IPs would probably work)


*: I know TCP/IP pretty well; admittedly I have no clue about windows specifics though so I don't know how the folks in redmond may have botched it up so I guess anything is possible...

[Moorea]

I need to understand why it's not working before I can fix it. I'll have to set up ICS here, watch the programs in a debugger, log their communications, etc.


Given what you said about how it works I know why the connection fails: if you send the default (external) IP to the computer using ICS it can't connect to that IP from it's side of the network, which is why it fails - sending all the IPs and trying them all would work

ps: maybe we should use the IRC chat or something so we don't create hundreds of post for a simple dialog :-)

[Freddie]

IC, Are you sure it's direction issue ?
Yes.


I think what you may have found is you get more throughput using 2 sockets than using 1
No, because only one connection is used at a time.


is the difference really noticeable ?
Yes, it's quite noticeable during mouseover. That's the only time that Mojo (or HotkeyNet 2 where I first noticed this) tries to make many transmissions per second on the same connection. Cursor motion on the remote is noticeably snappier (a higher FPS rate, so to speak) when the socket connection is used in the preferred direction.


Maybe you can fallback to using 1 socket if somehow you can't get the second one ? (
When the program is mature and fully debugged, at that future time, I'll do that. But if I do it now, it will only conceal problems.

I want the problems to be seen and reported to me so I can fix them.


I guess sending all IPs would probably work)
I thought you said that picking different IP addresses from the drop down list didn't fix the problem (or it half solved the problem but not completely). All the IP addresses are on that list. If picking them from the list didn't fix the problem, then sending them automatically won't fix it either.

In any case, this idea would have some bad effects because normally, on most computers, all the IPs would connect and Mojo would end up with many (possibly many dozens) of socket connections between every pair of computers. If you have two PCs and each one has four interfaces, you'd end up with 4 x 4 x 2 = 32 socket connections. During mouseover, every time you moved the mouse, the local PC would send 16 different TCP packets instead of just one. The receiving Mojo would receive every communication multiple times on every one of its adapters. I would have to add serial numbers to the messages so the receiving Mojo could throw away the duplicates.

To avoid this, I would have to add complicated code to Mojo to audit the number of connections and prune them.


*: I know TCP/IP pretty well; admittedly I have no clue about windows specifics though so I don't know how the folks in redmond may have botched it up so I guess anything is possible...
I don't think this asymmetry is particularly surprising, and I don't think it means that Microsoft botched anything.

There are always limits to peformance because performance can't ever be infinite. Even the speed of light is finite.

All this proves is that the code for the client end and server end of sockets isn't exactly the same. Since it's not exactly the same it has different maximum performance limits.

By the way, I only tested this on XP and Vista. It may be different in Win 7. For all I know, the situation is reversed in Win 7.

[Freddie]

Given what you said about how it works I know why the connection fails: if you send the default (external) IP to the computer using ICS it can't connect to that IP from it's side of the network, which is why it fails -
There are two issues, UDP and TCP.

We don't know if the UDP packets are getting received in both directions.

Regarding TCP, if the problem is what you say, you would have been able to fix the problem by selecting a different IP address from the drop down list.

But you said that didn't fix the problem (or it solved the problem partly but not completely).

You say that sending all IP addresses would fix the problem.

But all IP addresses are on that list. You can select them manually. If sending one at a time (after choosing manually) doesn't fix the problem, then sending them all together automatically won't work either.

[Moorea]

I found a small bug/issue with the latest (21) build:

I changed my network settings for 2 laptop to use ICS (internet connection sharing) [...] the slave computer was showing as a black screen on the master one (and the master not at all on the slave) until I went into advanced settings and set the master [...] to use the private IP from ICS instead of system default [...]

and after the first time you put in a post that I'd say it didn't work after setting IP manually:


it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is [...]followed by another 2 or 3 post on why sending both ip would work... I don't know how else to say it... but it does highlight that using some sort of instant messaging would be much better medium for those than posts (would clear misunderstandings faster)

Also to clarify something else; when I say try the other IPs; it means try something else only if the previous one fails; not brute force open many-many connections - in most case it would work as today, and sometime would just make another attempt and succeed if the first connection fails, instead of getting stuck...

[Freddie]

and after the first time you put in a post that I'd say it didn't work after setting IP manually:

followed by another 2 or 3 post on why sending both ip would work..
Part of the reason I don't understand is that you wrote the following:


it did work (after changing the IP in the drop down) for the simple case of 1 mojo using ics connected to the mojo providing ics; what didn't work after that (2 different tests; 2 different posts) is having both the "inside" and "outside" mojos
I don't know what "inside" and "outside" mean. I thought you were saying that manual selection didn't solve the whole problem. Or didn't solve both of two problems.

If there are two problems, I don't know what the second problem is.

Before I can do anything -- before I can even think about a solution -- I have to understand the observed behavior.

When you tell me about a problem, what I need is a clear description of the program's visible behavior. That's the priority. I can't do anything without that.

[Moorea]

Problem 1
--------------
Step 1: 2 computers A and B; B sharing the A's internet connection (Windows built in ICS feature, need 2 interfaces)
Step 2: start mojo on both
Step 3: on A (the computer which has 2 ips) you'll get a black screen for the B mojo
Step 4: on A go to advanced connection settings; pick 192.168.0.1 instead of "let the operating system choose"
Step 5: 2 mojos are now blue on both A and B and everything now works (which shows it's "fixable")

The bug is step 3 and the need for step 4

My personal opinion again on the fix is that sending both IPs in the UDP packet and having the slave try the second one if the first one doesn't succeed would fix it easily and simply with no downside I can see


Problem 2
--------------
Step 6: Add a 3rd computer C on the "internet" side of A (ie not on same network as B)
Step 7: Start Mojo on C: C is yellow picture (in computers section) and purple text (in geeky stuff section) on A - 3rd column of text shows "C" (B is still blue with "AC"); A is yellow on C; B's screen shows A,B blue unchanged (doesn't see C which is normal)
Step 8: pick the other IP; C becomes blue too

So here again, trying both automatically will fix the problem - More work (and not necessary imo; would introduce complexity), i.e write a proxy, would be needed for C to see B and B to see A (proxied through A)


Diagram

B --------------------> A (ICS share) -------------> C
"private ICS side" ................... "internet side"
(aka 'inside') .............................(aka 'outside')

internet side isn't really the internet; just another network that's not the ICS private one and happens to also have the router to the actual internet


If problem 2 is confusing - just look at problem 1 as fixing it will fix both

Note btw this problem is not specific to ICS - any computer with 2 interfaces where you can't route/access 1 of the IP from the other side will have the exact same problem (ie will advertise the same IP on both side which won't work on one of the network, with again an ez fix (a cleaner fix would actually be to get the IP of each interface and broadcast separately but that's more work and unnecessary)


Thanks

ps: It's 3am here so hopefully this is clear enough - and if not - well I'll try again some other day as I need sleep now

[Aragent]

This is a know problem with Windows ICS.

ICS is Windows Native Nat Router software. {Last I checked ICS does not use a standard NAT trasnlation]

What Moorea is experiancing is that his one machine that he is using to Route out to the internet must have 2 IP adresses. one recived by his IP provider to go out to the internet, and a internal private address which his network uses.

On that one machine that is acting as his router Mojo is finding and using the IP provided by his IP provider, and not his internel private address. thus Mojo on that maching is not conecting properly to the other till he goes in and tells that mojo to use the private network.

I suppose to fix that you could put in an algorithm to priortise a private network befor a standard network ip.

However ICS is not considered very efficent Nat Router software so not sure how many serious Multi boxers will use ICS [Internet Conncetion Sharing]

And this can allready be solved on that one pc by going under MOJO connection settings under more optiens and add the private network this then should make it use that network as default.

[Fursphere]

I think they're talking about on the "left side" and "right side" of a firewall. Why would you put mojo on the outside of your internal firewall?

[Aragent]

I think they're talking about on the "left side" and "right side" of a firewall. Why would you put mojo on the outside of your internal firewall?

ICS=Internet Connection Sharing is the built-in NAT feature in Microsoft Windows and allows a Windows PC to “share” its Internet connection to other networked devices. In this configuration, the PC with ICS is directly connected to the Internet in some way (modem, ISDN, etc.) and networked with other computers. The ICS-enabled PC can then share its connection with other Windows computers, acting as an NAT device. In addition, the ICS-enabled PC can automatically assign IP addresses through DHCP.

The problem in Mooraes case is that when Mojo is running on the machine running ICS its detecting the IP address provided by the Cable/ISDN Router and choosing this as defualt and not his Private Internal address.

Most of that if I remember correct is how ICS Handles Nat translation and generates its internal DHCP.

[Moorea]

internet side isn't really the internet; just another network that's not the ICS private one and happens to also have the router to the actual internet

[...]

Note btw this problem is not specific to ICS - any computer with 2 interfaces where you can't route/access 1 of the IP from the other side will have the exact same problem (ie will advertise the same IP on both side which won't work on one of the network, with again an ez fix (a cleaner fix would actually be to get the IP of each interface and broadcast separately but that's more work and unnecessary)


Aragent, Fur ^^^

[Freddie]

Problem 1
--------------
Step 1: 2 computers A and B; B sharing the A's internet connection (Windows built in ICS feature, need 2 interfaces)
Step 2: start mojo on both
Step 3: on A (the computer which has 2 ips) you'll get a black screen for the B mojo
Step 4: on A go to advanced connection settings; pick 192.168.0.1 instead of "let the operating system choose"
Step 5: 2 mojos are now blue on both A and B and everything now works (which shows it's "fixable")

The bug is step 3 and the need for step 4

My personal opinion again on the fix is that sending both IPs in the UDP packet and having the slave try the second one if the first one doesn't succeed would fix it easily and simply with no downside I can see


Problem 2
--------------
Step 6: Add a 3rd computer C on the "internet" side of A (ie not on same network as B)
Step 7: Start Mojo on C: C is yellow picture (in computers section) and purple text (in geeky stuff section) on A - 3rd column of text shows "C" (B is still blue with "AC"); A is yellow on C; B's screen shows A,B blue unchanged (doesn't see C which is normal)
Step 8: pick the other IP; C becomes blue too

So here again, trying both automatically will fix the problem - More work (and not necessary imo; would introduce complexity), i.e write a proxy, would be needed for C to see B and B to see A (proxied through A)


Diagram

B --------------------> A (ICS share) -------------> C
"private ICS side" ................... "internet side"
(aka 'inside') .............................(aka 'outside')

internet side isn't really the internet; just another network that's not the ICS private one and happens to also have the router to the actual internet


If problem 2 is confusing - just look at problem 1 as fixing it will fix both

Note btw this problem is not specific to ICS - any computer with 2 interfaces where you can't route/access 1 of the IP from the other side will have the exact same problem (ie will advertise the same IP on both side which won't work on one of the network, with again an ez fix (a cleaner fix would actually be to get the IP of each interface and broadcast separately but that's more work and unnecessary)


Thanks

ps: It's 3am here so hopefully this is clear enough - and if not - well I'll try again some other day as I need sleep now
Thank you very much for taking time to explain this clearly. This is what I needed in the first place. All the time we spent going back and forth about this last night -- what a waste.

Here's my summary of what happened. Please correct me if I misunderstand.

You had to adjust a setting manually (using the drop down list) to make the computers connect.

After you adjusted the setting by clicking on a drop down list, the program worked perfectly.

You're calling that a bug.

That's my summary. Is that correct?

Please let me know if the program worked perfectly after you clicked on the drop down list. I need to know. Thank you.

[Aragent]

Note btw this problem is not specific to ICS - any computer with 2 interfaces where you can't route/access 1 of the IP from the other side will have the exact same problem (ie will advertise the same IP on both side which won't work on one of the network, with again an ez fix (a cleaner fix would actually be to get the IP of each interface and broadcast separately but that's more work and unnecessary)

True But thats pretty standard in Subnetwork protocol. and normmaly when you want it to pass you setup addvanced network Rounting and port forwarding. but now your getting into more advanced networking, and Those who use subnetworking should be a bit more advanced than the average user and shouldn't have problems with changing the ip address under mojo.

[Freddie]

You guys are assuming that the OS always picks the "wrong" IP address in this situation.

Do you have some basis for believing that the OS's algorithm works this way?

[Aragent]

You guys are assuming that the OS always picks the "wrong" IP address in this situation.

Do you have some basis for believing that the OS's algorithm works this way?

I havent looked at what your using for a discovery protocol, I am making a couple assumptins here. and I will try to look latter and see what MOJO is acually using.

I am assuming your using DHCP discovery when detecting network addresses and UDP ARP for detecting other running Mojo clients.

Last I looked it was standard when discovering 2 Network IP's especially on one network card, to give Priorty to a Public IP address over a Private one.

I Might have a couple suggestions however I think I should try and see if I can find the accual Code first befor I do.

[Moorea]

When a computer has 2 interfaces, using 1 of the IPs on a random interface has 50% chance to be wrong; using that same IP on both interfaces has 100% chance to be wrong; which is exactly what is happening here (causing the user to have to click 10 times to workaround this while it's just a matter of trying both IPs (or asking the correct one from the OS for the correct interface, but that's (again) more work and actually unnecessary when the trying until it works would work just fine))

But I'll rest my case on the topic; spent too much time on this already

[Freddie]

I havent looked at what your using for a discovery protocol, I am making a couple assumptins here. and I will try to look latter and see what MOJO is acually using.

I am assuming your using DHCP discovery when detecting network addresses and UDP ARP for detecting other running Mojo clients.

Last I looked it was standard when discovering 2 Network IP's especially on one network card, to give Priorty to a Public IP address over a Private one.

I Might have a couple suggestions however I think I should try and see if I can find the accual Code first befor I do.
I explained what it does earlier in the thread. It broadcasts a UDP datagram. It doesn't use DHCP. It doesn't detect network addresses. It doesn't look at the network in any way.

The only thing it does with addresses is ask the operating system for a list of IP addresses that belong to the PC it's running on.

If you want to look at the code, it's in class cFinder in the mojo_engine project.

If you want to understand the whole connection mechanism, you'll also have to look at class cPool, which handles TCP communications.

[Fursphere]

I'm going to go out on a limb here - but running 2 nics in one PC is a non-standard config.

Want proof? Go look at any desktop PC made by Dell, and find me one that comes with two onboard NICs standard.

I use multiple nics in one PC for two things:
1) FIrewall servers (Microsoft ISA, Soothwall, etc)
2) Redundant connections on server hardware.

[Moorea]

All laptops come with 2+ nics : wireless and ethernet - if you want the best network performance and have 2 such laptops you will setup the ethernet to try to pay the wireless latency "price" only once - which is again my real (not hyphotetical either) case - if you have 1 wired computer, 2 laptops and want to box you may want to setup the way I had: the 2 laptops linked to each other with ethernet; and the rest in a home network; ie 2 interfaces used with 1 of the laptops in the middle

Anyway, we spend more time arguing whether this is an issue or not than actually fixing it would take - I'm not saying it's the highest priority issue just that it shouldn't be summarily dismissed - typically you weigh the cost vs benefit of any fix to see if it's worth it - here I see big benefit for an admittedly small fraction of users but at a small cost - so personally I'd rank that "medium", not "low" as a result

I look forward to a ticketing system where interested party can follow the issues they care about and the people who do not care don't necessarily have to feel obliged to comment (can "vote" it down if they want I guess) - even if the resolution is "wontfix" at least it'd be documented why etc...

[Freddie]

Anyway, we spend more time arguing whether this is an issue or not than actually fixing it would take -
Wheee. Our first drama on the Mojo project. :) Not fun.

Moorea, nobody is arguing about that except you (in the PM you just sent me).

All I've been doing is trying to find out what the problem is. From your posts last night, I couldn't tell if

(1) Mojo didn't work on your network at all, or

(2) Mojo worked but you had to resort to a manual setting.

Those are very different things.

If I had understood that you were saying (2), I would have told you:

--- The connection code is unfinished.

-- Of course I intend to enhance it.

-- Of course I am going to try to make it connect automatically under as many conditions as possible.

-- I can't talk about solutions for a problem until I understand what the problem is and I'm certain of what caused it.

And I would have made a special build that logs connection events and asked you to run that build on ICS, so I can see exactly what's happening.

[Freddie]

Regarding the question of two NICs, I don't want to get too far off track here. But since it came up:

When I wrote the early version of Mojo's connection code that we are using, I ordered a USB wireless adapter from Newegg and plugged it into my development machine.

The whole time I wrote and tested the code, there were two NICs in the machine. I did this to make sure the drop down list works with multiple NICs.

The drop down list is an important part of the program. It's there as a fail safe in case the automatic connection code fails.

At this early stage, the automatic connection code is unfinished. It's buggy. It's unreliable. For that reason, the drop down list is especially important in these early alpha builds.

My priority at this early stage is making sure that testers can use the program enough to test new code as I add it build by build.

[Fursphere]

All laptops come with 2+ nics : wireless and ethernet - if you want the best network performance and have 2 such laptops you will setup the ethernet to try to pay the wireless latency "price" only once - which is again my real (not hyphotetical either) case - if you have 1 wired computer, 2 laptops and want to box you may want to setup the way I had: the 2 laptops linked to each other with ethernet; and the rest in a home network; ie 2 interfaces used with 1 of the laptops in the middle



Ok, you've got a point.

But the intent is for the end user to use one or the other, not both at the same time (even though its possible)

And for the record, I said desktop PCs - not laptops.

[Freddie]

I'd like to put this thread in perspective.

This is an alpha test. That means you're watching the program's basic features get built. . Nothing is finished. Auto Connect isn't finished.

If a feature seems incomplete, or if you wished it did more than it does, that doesn't mean there's a bug. It probably just means the feature hasn't been finished yet.

Eventually, at some future time, I'll get back to Auto Connect and improve it. But for now, at this stage of the alpha test, as long as everybody can connect with manual settings, that's good enough.

Unless somebody finds a serious problem in Auto Connect that prevents people from using the program I'm not going to work on Auto Connect in the near future because just four days ago we decided on the development schedule for the next few builds. Here's what we decided.



I'd like to do DNP next but for technical reasons there are three pre-requisites that have to be done first. Here's the schedule for the next couple of weeks:

1. Rewrite the underlying data structures for config info.

2. Finish "launch WoW" because DNP and choosing particular output key combinations for particular WoWs is the same code, and I can't write it unless the program can identify particular WoWs, and its method for doing that will be launch.

3. Make a spreadsheet kind of control that will be used for the DNP/key-assignment screen.

4. Write the DNP/key-assignment screen.

[Moorea]

my view of a simple straightforward dnp is that it's not tied statically to a given wow but only tied to the focused window: the window under the cursor (or last clicked if the user didn't setup follow cursor) gets everything always and all the other ones get everything except the keys mentioned in dnp - in that sense "launch wow" (step 2 above) shouldn't matter - now again I can see that there is value in having a more complex setup too but I do hope this simple use case stay simple (and dynamic as I said; the "wow" that gets or doesn't get the key change depending on where the mouse is)

but I'll take any new build with any feature in any order either way


ps: this thread should probably die off and move on to another one

[Freddie]

I look forward to a ticketing system where interested party can follow the issues they care about and the people who do not care don't necessarily have to feel obliged to comment (can "vote" it down if they want I guess) - even if the resolution is "wontfix" at least it'd be documented why etc...
The issue that came up here -- the Auto Connect stuff --- is a design recommendation. You noticed that the program required you to use a manual setting and you're recommending that the automatic feature be enhanced so the manual setting isn't needed in that particular situation.

You want to call this a "bug." That's fine. Call it anything you like. But let's be very clear on what this bug is. You're recommending that I add additional functionality to unfinished code. That's the nature of your "bug."

Recommendations of this kind are very good. I welcome them. I rely on users to design the program. I want people to recommend new features and new functionality.

But I think it would be a bad idea to track design recommendations with a bug tracking system for several reasons.

For one thing, any given design recommendation is a spectrum of possibilities. It's not a single "item." You can't "track" a spectrum of possibilities. You can only discuss it.

For another thing, it would force us to design things prematurely. I want the program's design to evolve iteratively through a process where I publish builds, people react to them and make suggestions, I publish more builds, they react again, etc.

That kind of design is open ended. We make design decisions as we go along. We don't lock ourselves in by writing down what they will be more than a litle bit in advance.

Edit:

I just realized that it would be completely absurd to track design recommendations in a bug-tracking system, because potentially, the number of design recommendations is infinite.

There's no limit to the number of recommendations that people could make.

The purpose of a bug tracking system is to drive the number of entries to zero.

But if you put design recommendations in the system, it never gets to zero. It just gets larger and larger.

[Freddie]

my view of a simple straightforward dnp is that it's not tied statically to a given wow but only tied to the focused window: the window under the cursor (or last clicked if the user didn't setup follow cursor) gets everything always and all the other ones get everything except the keys mentioned in dnp - in that sense "launch wow" (step 2 above) shouldn't matter - now again I can see that there is value in having a more complex setup too but I do hope this simple use case stay simple (and dynamic as I said; the "wow" that gets or doesn't get the key change depending on where the mouse is)
Let's keep this discussion in the thread where we're discussing it, okay?

http://www.dual-boxing.com/showthread.php?p=260677#post260677:

[Fursphere]

Freddie - the only thing missing here is a clear project scope.

"A multiboxing program" is just way to vague. To design and publish a proper scope would take hours / days / weeks / months. This is what there are project development "teams" out there in the wild.

In this fashion you can track scope creep - when new feature requests are outside the original design intent.

But since this project is ad-hoc, the users should treat it as such. Freddie drives, we can all make recommendations on where to stop next, but ultimately Freddie gets to choose how and where we all go.

I'm just happy to be along for the ride. :D

[Freddie]

I like the way things worked with HotkeyNet. It was based on the idea "This program is like AutoHotKey, but easier and designed for networks."

That was the whole formal specification. :)

Then I published builds and people made suggestions. More builds, more suggestions, round and round. We just kept doing that for two years.

It worked great, it was fun. Eventually it bogged down because the original code was written in a half assed way and it got hard to add things.

[Freddie]

I'm just happy to be along for the ride. :D

P.S. I'm glad you're along for the ride too. :)

[Moorea]

It seems this is going to come up in this thread until I say something like "yes, sorry, I'm so grateful that anything at all is produced in freddie's free time that mere suggestion that taking 10 clicks to do something simple and how to solve it is very offensive and should never be made and would never need to be tracked anywhere and visibility on what is planed or left to do is not helpful at all - sorry for even suggesting it"

can we close this thread now ?

ps: and obviously make me look like a total asshat... tyvm... yes I'm a bad person and you need to hammer it down

[Freddie]

It seems this is going to come up in this thread until I say something like "yes, sorry, I'm so grateful that anything at all is produced in freddie's free time that mere suggestion that taking 10 clicks to do something simple and how to solve it is very offensive and should never be made and would never need to be tracked anywhere and visibility on what is planed or left to do is not helpful at all - sorry for even suggesting it"
This is ludicrous because just a few days ago, I asked you to add a section to the FAQ where you maintain a running list of requests. I even invited you to editorialize and put them in whatever order you think is best.


can we close this thread now ?
No, but let's close out your involvement in Mojo. I'm serious. I don't want you involved in this project anymore. I'm trying to write a program, and you're making it more difficult instead of helping.

[Fursphere]

On that note, lets close this thread and move forward.

new thread for the current build.

http://www.dual-boxing.com/showthread.php?p=261453#post261453