XIMCommander - Initial ideas and call for comments

[Aiken_Drum]

Edit: If you wish to be a tester for XIM4 Commander, you need to read ALL of the text below, and in fact the rest of this thread, as it will set you up with background info and the ability to contribute better.

That said, I should mention that there is now an early version for testing available here:
http://xim4.com/community/index.php?topic=38509.0 (20141219 - CURRENT)
http://xim4.com/community/index.php?topic=38510.0 (20141218 - obsolete)
http://xim4.com/community/index.php?topic=38511.0 (20141216 - obsolete)
http://xim4.com/community/index.php?topic=38512.0 (20141209 - obsolete)

IMPORTANT: Official support is NOT PROVIDED for this software yet.  Please do not report issues or seek help in the official Support section of this forum.  Any issues should be reported here, on this thread, but only AFTER thoroughly reviewing all documentation in the package you downloaded to be sure you didn't overlook the solution, not to mention checking this thread to see if anyone else has had and solved the same issue.

If you know yourself to be technologically-challenged, I would gently and politely suggest that you hold off until at least the Beta stage of testing, when documentation is improved, nagging bugs are mostly resolved, and there is much more information in the heads of other testers who can help you.  Otherwise, it may be very frustrating for you in these early Alpha stages, not to mention that my own bandwidth is rather limited and I cannot afford to do very much non-bug-related troubleshooting.


TL;DR version:

XIMCommander resurrection in the works.  Requesting suggestions/needs.

L,BRA version:

So, as most of you know, I'm tech support here with XIM, and as some of you know, I'm also a long-time senior engineer from the games industry.  I've been gently prodding OBsIV several times a day for months now to see if there's any way I can use my skills to contribute to the XIM project.  He's been surprisingly patient with my nagging, and as it turns out, it looks like there is a way I can help: I'm going to be resurrecting XIMCommander.

The first thing he and I need to do is figure out the initial scope.  I actually have not had the opportunity to use the original XIMCommander, as XIM4 is my first XIM and it doesn't yet support that, obviously.  As I understand it, XC allowed you to capture PC inputs (mouse, keyboard, other) and pass them across a USB transfer cable to the XIM, as if the PC were one of its peripherals.  Restoring that functionality is our bare minimum target.

The question is: Are there other things that are important and which have traditionally been missing from XIMCommander?  Is there anything that might not be obvious to me because I am not in a group that needs the features, but which might be vital to, e.g., someone with a disability and a customized input device?

I do need to make clear the following:

- Internal support for macroing is not on the table.  It's a PC, there are probably other ways you can do this if you really want to, just like you can use a macroing controller with a console, but we wish to honor the terms of service on consoles and, as such, do not condone or support this.

- Internal support for automatic behaviors such as rapid-fire are not on the table.  See above.

- A mod-friendly library/SDK is not planned to be released with XC.  Consider the previous two statements and the reason for this will probably be evident.  This is OBsIV's call, so I won't be able to change it, no matter how many of my fingernails you tear off.  Anyway, I agree with him.  As such, all functionality will need to reside inside of XIM Commander and/or XIM Manager.  Keep this in mind if you want to have features from previous user-created projects that were based on the old library.

Okay, over to you guys.  Try to be as realistic as you can, since I am only one dev and I am brand new to this code, not to mention that I will still be doing tech support.  Let's assume my bandwidth will be near-full right out of the gate and start with the most important things.  Especially, let's avoid arguing about the "not on the table" points above, okay?    If you guys really insist on arguing any of those points, please start up a separate thread and take your arguments direct to OBsIV, since I defer to him.  Edit: here's a thread with some arguments I moved out of this one: http://xim4.com/community/index.php?topic=35817.0

Thank you! 


Items suggested and accepted so far (working, not working, not done):

• Do not break external accessibility programs that can massage input for disabled gamers.  This also includes drivers/software for peripherals, like LGS or Synapse.
  
  
• KVM-like hotkeys for activating and deactivating XC.
  
  
• Support DInput.
  
  
• Support XInput.
  
  
• Support driving wheels.
  
  
• Don't freeze on disconnect. 
  
  
• Windows voice control.
  
  
• Map axes and buttons without requiring external apps.  This might be a follow-up feature.
  
  
• Give certain keys permission to bypass XC.
  

Items suggested but not yet accepted or declined:

• A way to record live data from XIM4.
  
  
• Integrated dead-zoner functionality, a la Kodek's stuff.  Possible issues with using existing code.  Must investigate.
  
  
• Chat audio injection or possibly extraction, to/from PC.
  
  
• Touchpad and sixaxis support - depends on DS4 support in firmware.
  
  
• LGS + Extreme 3D Pro joystick
  
  
• OCZ's / BCInet's Neural Impulse Actuator - SDK available?
  
  
• SmartNav head tracking mouse in
  
  
• Tobii EyeX controller and/or the Mirametrix S2 controller - use eye tracking for mouse movement
  
  
• Convert PC keyboard to on-screen keyboard sequences.
  

Items needing clarification:

• n/a
  

Items declined:

• SDK, for now anyway.
  
  
• .NET version of the SDK.  Not unless there IS an SDK.  At that point, it's probably fine.
  
  
• Toggle to use keyboard as text input - requires the same feature on XIM4 first.
  

[tails72]

Does the data work both ways? Like having a program to capture what the xim is doing. To help with getting mouse movement info for sensitivity settings..  And ballistics. 

[Od1n]

dunno what you mean with macros are off the table, im not asking for Xim Commander allowing you to setup macros through the software itself, but if autohotkey or similar programms arent picked up by the Xim Commander it loses a big part of its userbase

Xim Commander actually just needs to fill three roles as done in the past

1) accept inputs from programms like Xpadder
xpadder and similar programms accept pretty much any input device you attach to the pc and let you change it into a keyboard input or so, that way it becomes accessible for the Xim Commander too
eg foot pedals for disabled gamers

2) accept autohotkey macros
thats another thing that disabled gamers requested a lot lately, so they can create shortcuts for sequences they cannot perform physically or so
the amount of non-disabled gamers going for abusive macros like rapid fire with Xim Commander have been extremly minor, i mean you need a PC next to you, easy transfer cable, all that stuff just to shoot faster
most people just buy a macro mouse for that, so i dont expect a lot of abuse

3) have an easy to launch and close interface
a lot of people use Xim Commander instead of a KVM Switch just to switch fast from PC to Console, however this only will be the case again if the transition is fast and easy to do (eg keyboard shortcut to close)
i think it was CNTRL + ESC to close the programm with the old software and you instantly were back on the PC
if doable i would love to see the same as a launch sequence, something complex like STRG + SHIFT + F-Key automatically launches the Xim Commander from the PC
(a input combination that isnt used by any other programm, if not doable then an ahk script can do that too)



personally i could see myself using Xim Commander the following

- manage my record/stop after each game from my capture card without having to switch my monitor to the desktop
i can already do that with the KVM Switch but it tends to lock up once in a while with the XIM, Xim Commander doesnt lock up
- manage my music libabry, load a different music album via ahk or just skip a track via music player hotkey
- maybe playing around a bit with ahk in general, eg to create some shortcuts for the console, for instance after launching the console it starts the game, signs into my account and loads the multiplayer lobby or so while im still downstairs or so

[tuffrabit]

Integrated dead-zoner functionality.  Telling people to run the dead-zoner is just trouble, they have to find it and ask what it is.  Be easier if it's in the core software.

[Aiken_Drum]

Hey Od1n,

dunno what you mean with macros are off the table, im not asking for Xim Commander allowing you to setup macros through the software itself, but if autohotkey or similar programms arent picked up by the Xim Commander it loses a big part of its userbase

No, I just mean there won't be any built-in support for macroing.  We totally understand that some users require AHK for their input methods.  If they do any macroing with AHK, that's between them and the console manufacturer.  We simply aren't going to provide the feature ourselves.

1) accept inputs from programms like Xpadder
2) accept autohotkey macros

See above.  External accessibility programs are intended to work, though we can't condone usage that violates the console terms of service.  Macros are against ToS, so the user will need to take that risk on their own shoulders if they use an app on their PC that provides macros.  Misuse of such an app can result in console bans, of course.

Some people will use such a feature for very good reasons, but some will use it to cheat, so we have to make it clear that, as a company, we do not condone macroing or provide a built-in way to do so.

3) have an easy to launch and close interface

This is good to point out.  I want to include a config setting for a OS-level hotkey that toggles input capture, much like a KVM.

STRG + SHIFT + F-Key

STRG?

- manage my record/stop after each game from my capture card without having to switch my monitor to the desktop
i can already do that with the KVM Switch but it tends to lock up once in a while with the XIM, Xim Commander doesnt lock up
- manage my music libabry, load a different music album via ahk or just skip a track via music player hotkey
- maybe playing around a bit with ahk in general, eg to create some shortcuts for the console, for instance after launching the console it starts the game, signs into my account and loads the multiplayer lobby or so while im still downstairs or so

I think this is all covered by "don't break external input helpers like AHK."  Am I right?

Thanks for taking the time to write all that up. 

[Aiken_Drum]

Does the data work both ways? Like having a program to capture what the xim is doing. To help with getting mouse movement info for sensitivity settings..  And ballistics.

I think I would want to get OBsIV's opinion on this one.  There might be issues with this, such as being seen to record macros (see my post to Od1n to learn why this is a problem), or potentially providing competitors with too much internal knowledge of XIM tech.

I'm not saying it's not an option, but I would want OBsIV to consider and approve any such plan.

[Aiken_Drum]

Integrated dead-zoner functionality.  Telling people to run the dead-zoner is just trouble, they have to find it and ask what it is.  Be easier if it's in the core software.

This isn't something I'm familiar with.  Can you give me more details?

[tuffrabit]

The deadzoner is used to help figure out a game's deadzone.  This is useful for games that don't yet, or won't ever, have official ST support.

You plot dots on a virtual joystick to make it move the game camera.

[Aiken_Drum]

The deadzoner is used to help figure out a game's deadzone.  This is useful for games that don't yet, or won't ever, have official ST support.

You plot dots on a virtual joystick to make it move the game camera.

Ah, I see.  Hm, yes, I can see where that would be useful.  It sounds do-able, at least on the surface.  I'll have to get back to you with an offical nod or shake, but it sounds like a good feature.

Thanks!

[Aiken_Drum]

I'm keeping a list of bullet points, covering the suggestions so far, in the original post.  If I lost any info in summarizing someone's suggestion(s), please let me know.

[mist4fun]

An integrated Deadzoner would be terrific.

In addition to Tuffs break down, deadzoner allows the user to move the screen and verify movement in three different ways. Pulling an onscreen dot, manually entering stick values, and using the wizard. Pulling the dot on the graph also allows you to save that position and then create a new dot. Think of this as setting visual anchors for where the deadzone begins, allow you to get it's shape and size at multiple points. It also allows you to zoom and on zoom the graph.

Here are some images and features of Kodeks Deadzoner that was nearly perfect. One thing that I liked about it is it allows you to use a deadzone wizard that quickly finds the deadzone after a series of on screen Y/N prompts. Then it allows you to check this with manual entry. This is important because some games will give a false positive sometimes and manually checking this a couple times is a good idea.

[Od1n]

wouldnt a fully automatic deadzone finder be a bit of a interest for the competition to enhance their product?

strg = cntrl, sorry i used the german word for it, didnt pay attention

[mist4fun]

Yes they should have done it years ago. It's nothing spectacular though.

[Aiken_Drum]

wouldnt a fully automatic deadzone finder be a bit of a interest for the competition to enhance their product?

Possibly.  This is another thing for OBs to comment on.

Since the functionality is already exposed if they have a XIM3, though, and since honestly they could easily write something like it themselves, I'm not sure it matters.

[Aiken_Drum]

An integrated Deadzoner would be terrific.

In addition to Tuffs break down, deadzoner allows the user to move the screen and verify movement in three different ways. Pulling an onscreen dot, manually entering stick values, and using the wizard. Pulling the dot on the graph also allows you to save that position and then create a new dot. Think of this as setting visual anchors for where the deadzone begins, allow you to get it's shape and size at multiple points. It also allows you to zoom and on zoom the graph.

(much info)

Thanks for that, mist.  Question is, does that stuff remain useful for XIM4?  As I recall, XIM3 still had standard translators where you needed to know that.  Is it still useful to figure out the shape of the dead zone when you don't have direct control over the setting in the translator?

(Well, *you* do, but you are definitely not the typical XIM user. )