Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement] multi-toon support #27

Closed
Twisted-Code opened this issue Aug 30, 2017 · 5 comments
Closed

[enhancement] multi-toon support #27

Twisted-Code opened this issue Aug 30, 2017 · 5 comments

Comments

@Twisted-Code
Copy link

Twisted-Code commented Aug 30, 2017

currently, there is no user-friendly way to control which window is targeted. This is fine if you're only running one instance of the game, but since I usually run 4, it gets to be... frustrating... to have to close one window before it will switch to a different window.

@kpreisser
Copy link
Owner

Hi,

I agree, if you have multiple windows open, you currently cannot specify which window to use.

An easy fix would be to check the available TT Rewritten windows and then let the user chose which window to use. I will look at this when I have some time.

A more advanced fix would be to allow the simulator to send mouse and keyboard events directly to the window's message queue, instead of simulating these inputs globally, which would allow to run multiple instances of the simulator at the same time (and allow you to do other work while the simulator is running).
However, I would need to check how exactly this can be done. A disadvantage is that this would make it easier for TT Rewritten to detect that these inputs are only simulated, e.g. because the window receives the messages althouth it is not active, etc.

Thanks!

@Twisted-Code
Copy link
Author

I think you should stick with simple global sending option, at least by default. It would probably be a lot less bug prone, and while I usually keep the window active anyway, I'd rather avoid giving the game any way to detect the simulated nature of the inputs. Besides, the fact it's receiving controls while inactive is probably not the only way they could detect it.

@kpreisser
Copy link
Owner

Hi,

right, I tried to simulate inputs by sending messages to the window directly, but it turns out that after sending a WM_MOUSEMOVE to an inactive window, the OS immediately sends WM_MOUSELEAVE message after it, causing the TT Rewritten window to act as if the mouse button was released, so fishing would not work this way.

I think I will implement the basic fix: Before starting, determine if there is currently more than one TT Rewritten window open, and in this case, let the user choose which window to use.

kpreisser added a commit that referenced this issue Aug 12, 2018
…inform the user that he should activate one of the windows.

Issue: #27
@kpreisser
Copy link
Owner

Hi,
sorry for the long delay.

I have implemented a change so that if the Simulator detects multiple Toontown windows, it allows you to select which window to use (by activating it).

Thanks!

@kpreisser
Copy link
Owner

With the recent commit d8e431e, the simulator now supports a background mode, which sends mouse and keyboard inputs directly to the (selected) Toontown window.
This allows e.g. to play in one window while the simulator is using another window.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants