Questions about the scope of multibox mechanics
I am new to multiboxing so I am a little bit unfamiliar the scope and distinction of mechanics between what would be otherwise considered botting. I had a few questions, if anyone can help clarify it would be much appreciated.
The primary distinction that I've seen and understand up to this point is that while multiboxing is acceptable, botting is not. Using this as the basis for ill pose the following design scenarios.
1A) Action: User presses 1 keystroke that results in the KEY_DOWN signal sent to multiple windows.
- - keystroke repeater: the same signal is always sent to all known outputs
1B) Action: User presses 1 keystroke that *selectively* sends KEY_DOWN signals out to other windows.
- - keystroke router: a keystroke can be sent to all, or only some, of the known windows.
2) Action: User presses a key, results in a signal being sent to known game windows-- but the value of the keystrokes are different.
- - keystroke inverter: if the user presses KEY_LEFT_ARROW then the windows receive the signal for KEY_RIGHT_ARROW.
- - selective inversion: the same as above, only on a configured for selectively inverting signals
3) Action: User presses a key, and 2 keystroke signals are sent to one or more windows.
- - keystroke macros: if the user presses KEY_LEFT_ARROW then the windows receive 2 signals, KEY_LEFT_ARROW and KEY_UP_ARROW.
Design Principles and Observations:
There is a clear 1:1 mapping between keystroke events and their propagation.
-- not the keystroke values, but the timing of those keystrokes. If a key is pressed, then its signal is always relayed immediately-- not on a timer, and only once.
-- A combination of keys may be sent as the result of one key being pressed, but that key combination is sent once and only once each time the user presses a key. This kind of macro interface is very available, especially on the hardware level.
There is no direct memory access, use of CV, or any kind of sensory input processing/systems.
There are no autonomous subroutines.
All signals are only sent in one direction. There is no way to pass data or game events back to the multibox tool, ie through a feedback/callback loop from the game window.
With macros and clever use of how you configure each of your character's skill bars, you can achieve a large portion of the "inversion" functionality.
--Would it be just as acceptable to provide it with as part of a configurable multibox tool?
The end goal is to allow a user to macro together more abstract commands for their group of chars. For example, a command 'Engage!', which tells your tanks to use charge and your mages to start casting frostbolt. As I mentioned before, you can do this by configuring the toolbars around for each char to achieve whichever effect, but that is not an ideal design pattern for many reasons.
Sorry in advance if I was unclear or picked back terminology to use. Thank you to anyone out there who cares or can help.
p.s. I realize that many (if not all) of these features are available with some of the existing multibox tools, but I decided I rather write my own tool. If anyone is interested I'd be happy to open its source up to the community.
