HOTAS Warthog and Future DCS Titles

[ivanwfr]

When in mention emacs and gvim, i guess I can't be wrong, kind of like comparing a Mercedes or a BMW to some custom car. I'm sure CH never claimed to provide any editor for programmers otherwise, I would have heard about it years ago.

 

But please let's just put an end to this digression, my point was about TARGET, not CH and certainly not how we put characters into a script file.

 

-- Back to the topic --

 

When TM, and CH, take the time to build advanced scripting tools, some users have to show they appreciate the effort and this is what I'm talking about in all my posts, even this one that I did not want to be just another reply.

 

Effectively using TARGET does not come easily to people who are not familiar with any programming language. And, even though I know nothing about it, I'm sure that with CH tools, difficulties are the same. This is real-time multi-threaded programming, and even for experienced professionals, it will always be a challenge. This is why I know it can't be made easy through any kind of friendly editor.

 

Once again, trial and error, learning ant talking about scripting is the way to go! Quite like any other subject discussed in this community. People ask for help, those who understand the question and have some experience to share try to answer them.

 

I'm no pilot and I appreciate what those who are have to say about avionics. The ease that comes with years of real life experience cannot be missed when your read their explanations.

 

My domain is about software and I am not interested at discussing about what or who is best for the sake of argument. I'm willing to be helpful on subjects I know, that's all.

 

So, if there is a real point in comparing TM to CH, I will step back as long as I miss one half of the experience and let you help those who are facing that choice.

[WynnTTr]

I never understood the software programming argument - so long as the software allows me to map the correct keys to the button then it's doing its job. Press a button and it should do something accordingly: pretty simple. I don't need a button to drop my flaps 1/3 while calculating next year's tax.

 

Just give me a mapping feature and a shift multiplier and that's all I need and in today's age any/all joystick software allows you to do that.

 

I think in end it really comes down to which HOTAS do you like flying better.

I seriously doubt that most people are going to go out any buy an expensive HOTAS just on how the programmable the software is.

 

To answer the OP: you're fine with the WH purchase. Like I said, any modern day HOTAS will allow you to program what you need for future titles.

[ivanwfr]

Yea, and the most part of your time is spent jumping on your keyboard and mouse as if you had not enough buttons on the HOTAS and TM or CH scripting features were not there.

 

But I agree, I also believe that Logitech is right. they give you the minimum they can with each of their product and spend their energy on the next one that will get them more profit... They are smarter than Thrustmaster indeed, when it comes to business, they seem to know that scripting is mostly unused.

[metalnwood]

Button boxes FTW! :) I don't like using the keyboards but then again I have never really needed to use scripting for my games.

 

If I ever felt really lacking I would make up a button box so I had all the other functions I needed.

 

I think we are lucky today that the latest of new sims don't have restrictions on the number of controllers and they are making more options available through their native config. E.g., scripting was used a lot to make something that only had key presses behave like an axis. Now a lot of things provide native axis for the stuff we had to emulate.

 

From what I have seen, most hardware providers (saitek, logitech, TM and CH) have at least the minimum required to supplement that, I.e. mapping buttons to keyboard commands and adding macros.

 

The games will only get better to support the kind of features that we used to script for.

 

Unfortunately scripting is also used to gain advantages where the game developer didn't intend you to have them, ala smart macros etc but thats not really a problem for simmers.

 

To answer one of your original questions, A10 supports adding a modifier directly so target is not required to program that as it would be required for other games.

 

So the future looks bright for DCS and the TM warthog.

[WarriorX]

ivanwfr, here is my humble suggestion to really improve TARGET.....remove the restriction in TARGET to 1 Virtual Controller being created in a profile. The main reason is the DirectX 8 axis limit.

 

The reason I ask for this change is because since I run my Simped Rudder Pedals with Toe Brakes through my TM Cougar base, and as it stands now I have to make some serious compromises to include them with my Warthog in a TARGET Profile.

 

Let's take a look at the axis limits as they now stand with the Warthog. You know that the Warthog has 2 axis on the stick, and 5 axis on the throttle. That totals 7 axis combined for the Warthog. This leaves 1 axis left, before we hit the single controller limit of 8 that is bound by DirectX.

 

This is fine, unless you want TARGET to be able to program assignments to let's say your Rudder's Toe Brakes.

 

So what do we do when we have a nice set of rudder pedals that have a set of individual toe brakes? (Like the Simped's that are running through my TM Cougar base right now) This set up has 3 axis, one for the rudder, and 2 for the toe brakes.

 

If we want to use TARGET to control our Warthog and our Rudder Pedals with toe brakes, then we have exceeded the single controller axis limit by 2. Which means, we have to pick which 2 axis we will not add to the creation of our single Virtual Controller in TARGET.

 

This is a shame, 2 perfectly good axis that that you paid good money for, are going to waste if you use TARGET to program them.

 

My suggested solution would be to change TARGET to be able to create multiple individual Virtual Controllers(VC's) in a profile. (1 VC for the Warthog Stick, and 1 VC for the Warthog Throttle, 1 VC for the attached Rudder Pedals). The user created TARGET Profile will then show Windows 3 independent Virtual Controllers instead of just 1. Each VC will still be under the DirectX 8 axis limit easily!

 

Now, if you have a set of Rudder Pedals that are not running through the serial port of your TM Cougar Base, then TARGET is not going to see them anyways. TARGET only will accept TM hardware into it's Virtual Controller creation.

 

(Just a theory, but TARGET's single Virtual Controller restriction, may be the reason TM did not include a set of nice Hall Sensor Rudder Pedals with Toe Brakes with the Warthog).

[Revvin]

But please let's just put an end to this digression, my point was about TARGET, not CH and certainly not how we put characters into a script file.

 

So, if there is a real point in comparing TM to CH, I will step back as long as I miss one half of the experience and let you help those who are facing that choice.

 

Its not about comparing either, the Cougar was also capable of compelx programming but when you make blanket statements about CH's capabilities without having tried the software available then as a programmer I'm sure you'll understand there is not logic to your view. If ED make an F16 sim next then the Warthog and Pro Throttle are out of luck if users want to have a close copy of the real throttle which was why in my first reply I wondered if Thrustmaster would release a standalone Cougar throttle unit. Both the Warthog throttle and Pro Throttle have been criticized a little for not having rotaries to hand like the Cougar throttle and Saitek gear, perhaps a separate USB Cougar throttle could be a nice little earner for TM. I think it was a good move for Thrustmaster to move to a proper GUI for general programming instead of the DOS legacy stuff before.

[ZaltysZ]

My suggested solution would be to change TARGET to be able to create multiple individual Virtual Controllers(VC's) in a profile. (1 VC for the Warthog Stick, and 1 VC for the Warthog Throttle, 1 VC for the attached Rudder Pedals). The user created TARGET Profile will then show Windows 3 independent Virtual Controllers instead of just 1. Each VC will still be under the DirectX 8 axis limit easily!

 

This will solve not only an axis limit problem, but will rise count of available DX buttons.

 

I personally don't like mapping HOTAS buttons to virtual keyboard, because its is problematic. I either have to create my own keyboard profile for game and assign single keys for HOTAS, or I have to program my stick in a blocking way (so that one multikey keystroke could not interfere with another one) - what really kills effectiveness of HOTAS. It is way better to work with DX buttons only, as they are easily assignable in game and they do not conflict with each other. The only problem - there is 32 button limit per controller.

 

In case of Warthog, there are more than 32 buttons in HOTAS, and almost all of them (except 4) have their own functionality in DCS: A10. This means that if you want to stick to DX buttons, retain functionality of all buttons and program Warthog, you either have to exclude throttle or stick from virtual controller. I.e. I programmed my stick so that I get narrow FOV on depressing the lever and wide FOV on releasing it. I want to have left mouse button mapped to MIC button on throttle, but I can't (unless I choose to use virtual keyboard for part of my HOTAS buttons). Having more than one virtual controller would solve that.

[ivanwfr]

@Revvin:

My point was limited to the CH Editor part, not about scripting capabilities I don't know.

 

And I would not take CH's editor capabilities you mentioned as beeing an asset we could consider at the same level as scripting languages features. The editor is just a tool and I even don't talk about TM's counterpart as I never used it either.

 

About CH's vs. TM's hardware choices, I'm no experienced sim user and I will digest what others like

you have to say about before I pretend having any valuable point to share.

[ivanwfr]

@WarriorX:

TARGET could be better, and BTW all of us could as well ;)

 

I agree with your critics about the Combined limitation. This must be the result of a tough compromise between ED and TM when Plug and Play functionality was at stake. But my interest, for the moment, is mostly about what's good with TARGET. If I were to look for bad, I'm pretty sure I could write pages about what I've struggled with so far. It does not mean that I am the "positive thinking" kind of guy, I'd rather say that I'm looking to see what we get from TM scripting when pushed to the limit. When I'm done with that phase, I will join those asking TM to move on!

 

What i'm going to say is off topic but as audience is here, I'm going to take advantage. :smilewink:

 

first I need to repeat that I don't work for TM, I just like doing things the right way, as if my life depended on it... immersion!

 

Here is my collection of facts (no opinion there, all this is about working features):

 

NUMBER OF KEYBOARD BINDINGS:

There is exactly(!) 256 keyboard shortcuts bindings in DCS A-10C.

- (DCS/Config/Input/Aircrafts/A-10C/keyboard/default.lua)

Unless a good part of them are superfluous, we are going to use our keyboard at some point. And I don't think we can rely on modifiers to handle all those commands from the HOTAS.

 

MODIFIERS:

Using a switch as a modifier means loosing its default function. A script can help at keeping this default function when it detects a short click of that switch and use it as a modifier (/reformer/shift) when held down to alter other buttons handling.

 

WHAT SCRIPTING IS GOOD FOR:

It's all about tuning and customization!

• Associate switch release events to a custom function
  
• Short - Long press switch differentiation (there could even be more than 2 with some more coding)
  
• Experimenting with adjustable custom delays (put our experience at good use)
  
• Custom sensitivity (instead of single default values)
  
• On the fly dynamic sensitivy adjustment (depending on what we are doing at the moment)
  
• Smart handling (i.e. VOI: get us back to our current selected snap view after taking a look to another)
  
• Layer structured by topic as an ergonomics goal:
  A modifier (/reformer) opens the door of each topic-related layer of functions:
  (After some time, I expect mode selection will become muscle memory)
  
  • Up In : Desktop(Alt-Tab)
    ...misc accessory controls
    
  • Up Out : TrackIR, [DCS Pause,Accel,Slow], Script log
    ...gameplay controls
    
  • Middle In : COCKPIT SNAP VIEWS smart handling (select,look,save)
    ...smart view handling
    
  • Middle Out : STANDARD DCS Plug and Play---] -- (Middle Out layer)
    ...this is the default layer -- what we have without TARGET.
    - DCS does all the work for us, because we are lucky owners of a great sim!
    - And this is where some experience at using TARGET (or the lack of) will help
    to cope with other games bindings (or not).
    - (*)
     
    
  • Down In : Function keys F1-F12 +LR_MOD-] -- ( Down In layer)
    ...display layout controls
    
  • Down Out : Function keys F1-F12---------] -- ( Down Out layer)
    ...camera controls
    

  [*] ...you name it (...in fact this is exactly what I'm looking for!)

WHY ADVANCED SCRIPTING :

About structure polishing beyond obvious simplicity promoted by the manual:

• extensive use of include capability:
  ...file architecture by function (the black box paradigm)
  ...consistency of calling files (a small amount of lines covering all script features)
  ...focused included files contents (all contents code focused on the subject at hand)
   
  
• custom int function() calls instead of CHAIN and EXEC macros:
  ...those generate hidden multi-threading issues.
  ...they are interpreter inputs, meaning CPU resourses wasted at doing the same thing over and over.
  ...more to say here but it would be realy, realy! :geek: out of topic!
  

 

Exactly each of those topics deserves further consideration and discussion in order to satsify more than a single user needs or preferences. This is another good motivation for scripting. All those who are satsified enough with the default behaviour will have no means to compensate for the obvious immersion drag coming fro having to rely on a keyboard. And I am happy to be able to try something when I feel the urge of keeping my hands where they are at times where my eyes and my TrackIR are busy.

 

Keyboards are the worse ergonomics device of all times aside of the TouchStream Fingerworks exception that led to Apple Multitouch technology. Touch screens with gestures could be worth exploring too.

 

* BTW, TARGET does not make us loose anything from the P&P functions.

 

To make that happen (TM SHOULD HAVE DOCUMENTED THAT), Joystick default layer has to be mapped to the related keyboard shortcut and Throttle has to get all DX-Input bindings available and that's it!

 

This is written nowhere and I still do not understand why!

- Joystick has only transcient switches, just like a keyboard, unless we keep our finger on, it won't send keystrokes.

- Throttle on the other hand can drown us with any keystroke bingings we put there... just don't.

 

Even better: Direct input is ready to handle idle state transitions which aren't even part of the 256 defaults and DCS detects them quite well.

[Revvin]

@Revvin:

My point was limited to the CH Editor part, not about scripting capabilities I don't know.

 

You missed the point, if you've not tried it you can't make such bold comments, if you'd said that "I've tried CH's editor and don't feel the editor that deals with scripting is as strong as program x" then thats a difference of opinion, but not having tried it you can't possibly make that statement. This discussion is going away from where it started so I'll leave it on that simple fact, your follow up post is a whole new discussion :)

[ivanwfr]

You must be right.