1. 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.

  2. It counts as botting when a ingame action is executed w/o direct input from the player.
    For expl, you press a key once and it triggers a script that automaticly spams a certain key for X seconds.

    It doesn't count as botting when a key is remapped.
    For expl, you hit the one key on your keyboard and ingame it sends 1,2,3 on press and 3,4,5 on release.

  3. Awesome, I agree with that assessment completely.

    No timers, no autonomy, definitely no indirect input(non-player initiated) signals being sent.

  4. May 21, 2019  
    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.
    This is basically what Hotkey statements in Hotkeynet do. You can send different keys to different windows based on an input keypress, while preserving solo-friendly toolbar setups on each character.

    Did you ever work on your tool, or try the existing ones? Let us know if you have more questions... I did a bunch of my own scripting with AHK years ago before discovering Hotkeynet - it was fun, but ultimately there was no need to reinvent the wheel...

  5. May 22, 2019  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •