Jump to content
Bohemia Interactive Forums

TheHarvesteR

Member
 View Profile  See their activity

  • Content Count

    163

  • Joined

  • Last visited

  • Medals

Posts posted by TheHarvesteR

  2. Posted

    Been playing since te original OFP came out... went to the computer store one day, and saw this game on a shelf there, all unannounced... I couldn't believe the screenshots on the back of the box really did imply you could DRIVE all those vehicles... took it home the same day, and became totally addicted forever.

    I guess that puts me at 10 years game time too :)

    On a side note, I find it amazing that this game can be measured is THOUSANDS of hours of play... can you think of any other title on this same genre that even reaches the hundreds? few enough actually make it into dozens...

    That's why ArmA stands apart from everything else! It's as close to the all-encompassing-multi-game (a hypothetical game in which you can do anything and everything, thereby completely nullifying the need for playing other games) as anything has ever been.

    Cheers

  6. Posted

    Allowing for separate axis would be ideal, next best would be getting full range of settings from the controller.

    Right now, its

    brake----|----thrust
50%      0        50%

    for me at least. Not the best for flying in challenging conditions.

    Exactly. This is what is happening with the Thrust/Brakes (analogue) command, and it's easy to see why it's a problem... it's eating away half your throttle range...

    I've reread this thread, and saw my own replies here from when this update was first introduced... How bitter of me :D

    Anyways, just wanted to inform everyont that I've come up with a solution to this problem... it's not an official (or even pretty) solution, but it works... I have my throttle mapped to the full range of the throttle lever, and the brakes on a separate axis.

    Here's the thread: http://forums.bistudio.com/showthread.php?t=108410&page=5

    Hope this helps

    Cheers

  8. Posted

    yeah, the wheel is a bother sometimes... it behaves funny because there seems to be some kind of interpolation going on there between the position of your wheel, and the vehicle's actual steering... meaning it takes the vehicle a while to turn the wheel to where yours already is...

    This is kind of alright if you're driving with the keyboard.... but a joystick should (needs to) have a 1 to 1 mapping to the car's steering

    Anyways, this video is awesome!! that's why ArmA is a game that lives on a level all of it's own compared to everything else :)

    Cheers

  9. Posted

    I fly with a Saitek X52 Pro, and the Saitek Rudder Pedals, but I'm a flight sim nut, so that's what works for me.

    I do recommend it if you want to make your flying a more realistic experience. It IS harder to control aircraft than with a keyboard (the key commands have an auto-stability AI attached to them), but it's a much more gratifying experience to do a strafing run with the A-10 and spraying left and right by rocking the pedals back and forth :)

    Cheers

  10. Posted

    Just to clarify, the old Increase Thrust and Decrease Thrust actions have some sort of AI attached to them... they attempt to balance out the throttle so there is less input required from the pilot. i.e. you put the throttle to 50% in a heli and it's a perfect hover. That's just not realistic.

    It's even worse with airplanes, these actions act more like an autopilot speed hold than an actual throttle... notice that when using Increase/Decrease thrust, if you apply 75% throttle, the engines will rev up with you pull the nose into a climb, and will even deploy the airbrakes if you nose down... that's because the AI behind that control is trying to maintain the same speed. Increase/Decrease thrust is not throttle, it's a speed hold... 75% throttle with those actions are actually 75% of the airplanes max speed.

    That's why BIS introduced the Thrust/Brakes (analogue) actions for us pilots. They allow 1 to 1 joystick mapping to the aircraft throttle, with no AI trying to keep airspeed. It's much more realistic, but it suffers from a serious flaw, which is what my fix addresses: You cannot map your entire axis range into Thrust(analogue), you have to divide it into half thrust, half brakes, which is still not realistic.

    So what my fix does is not expand the actions to read the whole range, but REDUCE the joystick range into a compressed version of itself, so that ArmA will read it just the same, but your required input will have been maximized.

    Yes, this means that half of the virtual axis will be unused. that's how it's supposed to work. (good thing virtual joysticks are cheap ;) )

    No, this does not mean you're killing off half of your physical joystick's travel. This actually enables you to use ALL of it.

    One point worthy of note, is that maximizing the throttle will logically leave no room for the brakes. This is good, and realistic. Real airplanes have separate controls for brakes, so the best course of action is to remap your brakes onto a button or, if you can spare one, map them to another axis on your joystick.

    I hope this makes it clearer :)

    good to see my topic has sparked up this much interest... maybe BIS will someday address this issue so this kludge won't be necessary.

    Cheers

  11. Posted

    You know, this is not at all unfeasable... one might be able to hook it up, given that there is PC software support for it (hoping for a GlovePIE update ;) )... which is also not ureasonable to expect, since all major console controllers have been hooked up to the PC already.

    If we can connect a wiimote, a sixaxis, (the xbox pad doesn't count because it was made to)... even a playstation Eye... the kinect should follow shortly :)

    Now, about if it outperforms trackIR... no idea... TIR is a dedicated piece of hardware for tracking a VERY specific arrangement of fixed-bandwidth LEDs... move one LED out of that arrangement, and your TIR is worthless.... but this precise setup is also what makes it work so fast... it really knows what it's looking for...

    Kinect on the other hand is tracking patterns... it might be really really good at it, and might have all the tracking done inside it, but it's still trying to find the pixels (or voxels, since it knows depth), that make up yourself... it is a longer and more error prone procedure...

    It would be cool if it worked well though.... the TIR has the major limitation that you have to wear a headset (or hat) while playing... I don't even mention freetrack because it just doesn't work as well... mainly because you have to build your own head clip, and it's using your webcam, which is not made specifically for tracking LEDs...

    Anyways, I would like to see it done yet... :)

    Oh, and the kinect doesn't tell depth because it has 2 cameras. the depth sensing is not done through stereoscopy, it's done through a technique called 'time of flight'... it basically consists up shooting IR light forward and measuring how long it takes for each pixel on the cam sensor to fill up (almost to the nanosecond)... it's something akin to a light sonar...

    Cheers

  12. Posted · Edited by TheHarvesteR

    Hi,

    An idea just occurred to me that could be worth taking the time to script it into a mod, but I wanted to ask here first to gauge the interest on such a system...

    One thing should be made clear: I am not asking for someone to make a mod for me here... I'm trying to find out, by user responses, whether or not the system I have in mind would be a worthwhile addition or not. Also writing down my ideas help in making them more solid.

    Ok, enough rambling, this is what I intend to make:

    The system I have thought is simply a time-saving addition for browsing gear inside ammoboxes.

    Currently, to view an ammobox's content, one must be quite near to it, and use the 'gear' action (or press G) to open up the gear dialog, which lets you view all available items and equip them.

    The problem lies in missions that have dozens of ammoboxes to choose from (as in 'The Longest Day'). These situations force one to be moving from crate to crate searching for the needed gear, and makes gearing up a very long and tedious process.

    What I propose (for now) would be a small dialog, that would popup on the right hand side of the screen, and would automatically list all the items inside an ammobox that is in range. This dialog would be triggered automatically just by being near the crate and looking at it... No need for any action on the player's part other than positioning himself.

    It would not allow you to equip items, but quickly view the content of an ammobox, so you know your gear is there before you open the main gear dialog.

    The dialog would steal the mousewheel while it is up, so you can scroll the list (if it's long enough). Just pointing or moving away from an ammobox would be enough to close the window. It's worth noting that ONLY the mousewheel would be trapped by the window. All other commands and actions would still work as they should.

    The ranges for seeing and unseeing this QuickView screen are not defined as of yet, those would be the subject of careful calibration. Since the trapped mousewheel could, at times, hinder using the action menu.

    If possible, it could be a better idea to not trap the mousewheel at all, since all it does (when no dialogs are open), is flip through the action menu.

    As a second-priority feature (and if at all possible), It could be nice to add an action to open up the gear screen from this preview window and have the selected item already focused out on the main gear screen, so that you don't have to search for it inside a long list after having found it already. This would use a non-standard key or mouse button so as to not create unwanted behaviour by performing other actions, and, of course would depend on the feasability of doing so without having to modify the main gear dialog.

    I frown upon the idea of modifying any content that is already there, because this would break compatibility with other mods. I want this addon to work regardless of ArmA version or Mod... this should be able to work just as well under vanilla ArmA 2 as under ArmA OA:CO with ACE 2, and any point in between.

    I would really like to have this as a client side mod... As far as it's possible to do so. I'm not sure whether querying the ammobox content requires the mod to be active on the server or not, but I feel this addon should be available for any mission, and that means client-side only, since it's unreasonable to expect mass acceptance of any addon.

    This mod could also implement a setting for opting out of it, should need require, because one shouldn't need to deactivate the entire addon should the server reject it. Possibly a server side version that could force it on or off, but that's a little out of scope right now...

    Well, that's my idea... Let me know what you think, so I know if it's a good idea or not :)

    Thanks in advance for any feedback

    Cheers

  13. Posted

    Hi Harvester,

    Thanks! I know you say it's more complete than you anticipated, but feel free to share your ideas about new features (if you have them).

    I recently bought a PS3 Eye and there are some examples in the SDK that use OpenCV. Maybe you have experience with that? I intend to try and make some kind of face-tracker with OpenCV too, if I can find the time...

    Any help would be appreciated :cool:

    I can't say I have a lot of experience with OpenCv, but in my work we do use a good deal of computer-vision based technologies, like AR, fids, face and blob tracking, optical flow and whatnot... Most of those we can do through openCv.

    I did implement a Haar-face tracker not too long ago.. it got cut short and is now parked aside as just one more prototype, but it does pick up your face relatively well, and keeps your face framed in a box (that was for something completely unrelated to head tracking)

    It is a little bouncy right now too.... but I suspect that with some good axis independent smoothing and filtering, it could work quite well.

    When I get to work today I'll try to dig it up again... openCv is really not that hard... (all the dificult bits are already done :) ) maybe we can add the Haar feature-tracking as a... erm.. feature :D

    Cheers

  14. Posted

    I did post a bug report about this matter some time ago, but it didn't get a lot of attention... but I was already quite pleased when they added the Analogue Throttle in 1.5, which is what made all this possible, and that IIRC, was because of a user feature request.

    IMO, BIS does right in worrying more about priority fixes, like random crashes and showstopper bugs, than petty improvements like this one, which can even be worked around by the community... I recall a number of developers who seemed to care more about these 'cosmetic' improvements than actually fixing broken content, because it's more visible than a catastrophic bug that only occurs in 5% of computers.

    Cheers

  15. Posted · Edited by TheHarvesteR

    Hi,

    This is really cool... I've played around with FaceAPI at work and had always thought of creating a TrackIR alternative with it. I never had the time though... (and good thing I didn't because your implementation would have overrun mine, since it's a lot more complete than what I had planned) Good job there!

    The PPJoy/GlovePIE deal is indeed awesome! that's any-game support right there! (even games without trackIR support if you do some GlovePIE scripting)

    The wobbliness is probably due to FaceAPI not picking up your face in the correct orientation... that may be due to bad camera settings, low capture resolution, or poor lighting conditions...

    Try going into your camera settings and disabling any automatic modes.... set the parameters so that you have as good a contrast and image quality as possible (with as little noise (grains) as possible). If possible, crank up the camera resolution to 640x480 (but mind that it will eat away some performance)

    On a side note: Have you thought about implementing face tracking using Haar-cascades feature tracking? they only work in 2D, but detection is a lot faster (although less reliable). Could work as an alternative mode to those with less powerful rigs.

    Again, Great job there!

    Cheers

  16. Posted · Edited by TheHarvesteR

    I agree that the pace should not get any slower... it's slow enough walking around as it is.

    Mind that although realistic, a true walking speed (of about 5km/h) is painfully slow when seen through a computer screen... the screen tunnels down your vision, which makes things seem even more slow than they already are.

    In fact, most games (and sims btw) do exaggerate speeds a little, so you can feel that speed despite the tunnel vision.... it's a compromise between realism and enjoyment.

    ArmA is (still) not reality, and, unless VR domes become mainstream, we must see it through the computer screen.... So I'm perfectly content with these little compromises.

    I would like to see a trot pace implemented though... something in between the normal run and the walk.

    And I also think it would be nice of ACE to add a stamina multiplier setting somewhere to allow servers and SPs to decide how much that should be enforced.

    Cheers

  17. Posted · Edited by TheHarvesteR

    Finally gave this a go today. Its an X52 non pro that I have so I presume its the same as Your pro

    I've got it mapped to ppjoy but when I try to map the new controller in the game I've only got parallel port stick z+ axis, no z- axis when I pull back the throttle so I can't map it to decrease thrust

    Well, that just means you did it right :bounce3:

    If you look again at the main concept behind this fix, you will see that there should be no stick z- axis to map.... that's what the fix does. We disable the bottom half of the virtual range (z- axis) so that we can have the remaining top range spread across the entire travel of the physical throttle lever.

    So it's not wrong that there is no stick z- axis, that's ok, since ArmA will only detect an axis when it's moving away from center (be it into the negative or positive range). That means that you only get a z- axis when you move the axis past it's centerpoint and into the negative range. But the negative range is what we just disabled with the fix.

    You seem to be using the increase/decrease thrust combo... those are for keyboard playing, and they have some sort of AI attached that does the throttling for ya. (that's why I hate it).

    What you shoud do now is map your throttle into the Thrust (Analogue) command. (the single stick z+ mapping will do), and then your slider or some thumbbutton as Brakes (Analogue).

    Check how that affects th handling on planes and choppers... it should already be working.

    About the brakes, I have my rotaty 2 axis set as the airbrakes right now (and running the same fix on it), but I'm not too happy with that assignment... I think I'll remap mine to the clutch button, or just make a redundancy there for dive-braking and other cases. Right now it's a bit too much when doing a dive-bomb or strafing run... to pull out I have to retract the brakes, zoom out using the slider, and throttle up (and fly with my right hand)... a little too much stress on an already stressful situation ;)

    Hope this helps (and makes sense)

    Cheers

  18. Posted · Edited by TheHarvesteR

    Now can someone figure out how to set this up with a toggle so I can turn it on for choppers, off for jets

    You can... It just takes some scripting, and a button or key you're willing to spare for that.

    This is good also for creating a 'collective' mode where pulling is up and pushing is down, as opposed to the default setting for fixed wing

    The Saitek X52 as well as many other joysticks have a mode switch that allows you to create different mappings for each button. (for Saitek that is done through the SST app)

    I don't know what joystick you have, but I'll relate what I did with my X52, and maybe you can understand the principle and apply it to your setup.

    Well first things first... Saitek's SST monopolizes the mode switch, so if you have the profiler up, you can't use the mode switch for anything other than switching SST modes, so what do we do?

    One solution would be to completely uninstall the SST software, but that might not be such a good idea if you already have a bunch of profiles for other games...

    So the other solution is to create a new profile, and in there remove all modes except the default one (which is impossible to remove)... also make sure no button is mapped to anything, so that this profile is as blank as we can have it... Save and apply, good, let's move on.

    Now that there are no more modes, the buttons behind the mode switch become available for GlovePIE... that is, all except the button for mode 1, which is still stuck as a mode in SST because we can't delete it... but that's not a problem, and here's why:

    Since the mode switch is a 3-position switch, if the buttons for mode 2 and 3 are not pressed, then we must be in mode 1. so we can use that to check for our modes.

    For the saitek X52, the buttons for each mode are:

    Mode 1: button 27 (explicitly unreachable)

    Mode 2: button 28

    Mode 3: button 29

    Explicitly unreachable means that we can't directly read it in GlovePIE, but we can implicitly check that it is pressed, simply by checking that the other 2 buttons are not pressed.

    with that, you can write a simple script to map your axes and button depending on what mode is set on the X52...

    unfortunately I'm at work right now, and I can't post an example script, since my own script is at my home rig... later tonight I'll post how you can check for buttons (and modes) in GlovePIE

    Now for those without mode switches, if you wanto to have a button for toggling, all you need is a variable inside glovePIE to be your toggle.

    This variable can be true or false (for 2 modes) or a number that you can cycle around for as many modes as you wish.

    in GlovePIE you can set/read a variable like this:

    // for binary modes
var.toggle = true

// for many many modes
var.mode = 0

    note that the variable name (in this case 'toggle' or 'mode') can be anything you want, just as long as it's preceded by var.

    So, later you can toggle your mode like this:

    
if (Joystick.button1 and not var.b1isPressed) then
   //for toggle vars
   var.toggle = not var.toggle

   //or for numbers
   var.mode = (var.mode + 1) % numberOfModes

   var.b1isPressed = true
else
   var.b1isPressed = false
endif

    The code above says that if button 1 on your joystick is pressed, then it should switch to the next mode, or toggle it if it's true or false...

    note that there is also a b1isPressed variable there... that is to prevent something called state oscillation... let me explain:

    Imagine that the GlovePIE script is running in an endless loop (which it, in fact, is)... that is, once it gets to the end, it stats all over again and keeps doing that until you stop the script. So the problem with that is that this loop is very fast, and will probably loop around a few times in the time it takes to press and release a button... so what happens then? well, if there were no b1isPressed, the script would detect that the button is pressed probably some 5 times before you could release it, and instead of just hopping forth to mode 2, you would fly through all modes and land god knows where... so this b1isPressed is a control var doing something called 'debouncing', which is preventing that the code inside the 'if' block gets executed again after the first time the button was pressed... it only resets beack once the button is let loose again.

    I hope that was clear enough.... now moving on:

    note that strange expression there for var.mode... what this is saying basically is to first increment the value of var.mode by one, then constrain it to the number of modes using the 'mod' operator (which gives out the remainder in a division). this is to ensure that your mode is always a valid mode value

    For instance, if you have 3 modes (as in mode 0, 1 and 2), if you just increment it by one, you'll eventually get to 3, which is not a valid mode anymore... so the 'mod' statement tells is to loop back to zero once it gets to three (provided that numberOfModes is 3)...

    So now later in your script you can write something like this:

    
if (var.mode == 0) then

   // axis mappings for mode one go here

endif
if (var.mode == 1) then

  // axis mapping for mode two go here

endif
//and so on

    You must check if a variable is something or not using a double-equal sign (==), remember that a single equal tells the script that something should be equal to something else, and a double equal tells it to check whether it is equal or not

    with that, you can have different modes in your glovePIE scripts, be it with a mode switch, or just a button...

    I hope this was clear enough :)

    Cheers

  19. Posted · Edited by TheHarvesteR

    Anyone know off hand if I can pass scripts through the command line?

    I would like to able to setup shortcuts for different scripts.

    Ah yeah, is it realy needed to have glovepie all the time running? Isnt there a way to make this permanent? Sucks to have to start it and stop (but its nice to change things on the go :))

    These two question have the same answer:

    Make a shortcut to GlovePie, and after the target name (GlovePIE.exe), add:

    /run <pathToYourScript>.pie /tray /r <pathToArmA>.exe

    so the line will read something like this:

    "C:\Program Files\GlovePIE\GlovePIE.exe" /run "C:\scripts\myScript.PIE" /tray /r "C:\Program Files\ArmA 2\ArmA 2.exe"

    this will open up glovePIE, run the specified script, minimize itself to tray, then launch ArmA. :yay:

    there are more command line arguments for glovePIE, but sadly, the documentation is very sparse... but you can get a list of them by running GlovePIE with the /? parameter (a message window pops up)

    On my setup I have the /r parameter set to my ArmA launcher... so i can set up my mods before I start.

    Optionally you could point it to a .bat file, and from there load up any other apps you may need, like TrackIR, TS or ventrilo... this would make it a one-click deal... and launch 4 or 5 apps all at once :D

    Hope this helps

    Cheers

  20. Posted · Edited by TheHarvesteR

    This is awesome, finaly i can use my G940 Throttle the way it needs to be

    I use this script to read the G940 Throttle (right one):

    PPJoy5.analog2 = (MapRange(-Joystick2.x, -1, 1, 0, 1))

    Ingame its PPJoy Z Axis... Had a mixup with the analog2 code. Should be analog1 for us G940 users. but i was to lazy... :D

    Great work :) Thanks

    Yes, PPjoy's analog2 will remap to PPjoy Z, since it is the third axis on the device (0: X, 1: Y, 2: Z)...

    And it doesn't really matter if the axes on PPjoy don't match the ones on your physical joystick, since it's all the same after it's mapped in ArmA... (unless you have some serious OCD about these things :D )

    Does the G940 report the throttle as a separate device? I see you got joystick2.x there...

    Anyway, glad to hear that it worked!

    Cheers

  21. Posted

    Quick question though...

    Shouldn't this:

    PPJoy#.analog2 = (MapRange(-Joystick.slider, -1, 1, 0, 1))

    Be this:

    PPJoy#.analog2 = (MapRange(Joystick.slider, -1, 1, 0, 1))

    This depends on your joystick.. my X52 Pro needed being reversed... other sticks might not need it...

    And yes, the almighty GlovePIE is perfect for absolute control customization... This full axis fix is just a small adjustment I made for now... later when I have the time (if ever :P), I'm going to script my entire control scheme in GloveScript... and leave the Saitek SST completely empty and arma at it's default settings.

    I did this for the Orbiter space sim... but it was a lengthy procedure that took me almost 4 hours to get it to my liking... but it's so complete it actually speaks! (it tells me what mode I'm on in the voice of Microsoft Anna :D)

    Nothing beats having your joystick call out 'orbital controls engaged' in a digital feminine voice :cool:

    Cheers

  22. Posted · Edited by TheHarvesteR

    Hello,

    Just wanted to share with everyone the solution I came up with for mapping the entire range of the throttle slider to the analogue throttle control in ArmA.

    So this was the problem: ArmA does not read the full range of a joystick axis. It will only read either the bottom half or the top half of any axis (as in Joystick slider + or Joystick slider -). This isn't a problem for the usual stick movements, like pitch up/down and roll left/right, because these are axes that always return to center, and each half of the range is assigned to it's respective direction.

    This is a problem with throttles though, because ArmA is assuming that the bottom half of the throttle range should be the airbrakes, and that's not realistic. The brakes should be activated by another button or a separate axis if one is available, and the Thrust (analogue) action should be controlled by the entire travel of the joystick's throttle axis.

    So, how to get around this limitation? This is what I did:

    Instead of mapping my throttle axis directly into the Thrust (analogue) command in ArmA, I'm using GlovePIE and PPJoy to correct the input before it reaches the ArmA command mapping.

    So, this is how it works:

    GlovePIE is a programmable input emulator. It can read input from devices like keyboard, mice and joysticks, then 'write' input to other devices, as keyboards, mice and virtual joysticks.

    So that's where PPJoy comes in. It is a virtual joystick driver that lets you set up a virtual game controller as if you had it plugged into an USB port... except it's not.. it only exists in windows. (PPjoy is to your joystick what Daemon tools is for you DVD-RW unit)

    So, how does all that help with ArmA? well the concept is as follows:

    Basically since ArmA will only read half an axis, we will give it half an axis to read, but this half axis will be controlled by a full axis from the physical joystick. like this:

    .
.    1 | --------------- | ---------------- |  1
.      |                 |                  |  Thrust (analogue)
.      |                 |                  |
.   0  |        ________ | ---------------- |  0
.      |       /         |                  |
.      |      /          |                  | Dead range
.   -1 | ____/           |                  | -1
.
.  joystick           PPjoy                ArmA
.  throttle            Axis              Throttle

    So how does this happen? that's where GlovePIE does it's magic. We create a (really simple) script in it that tells it to write to the top half of a PPjoy device axis the value it is reading from the full range of your physical joystick throttle axis.

    Don't worry about the axis not being the same... It won't matter if your throttle axis (z) is remapping to PPjoy axis Rx, since it's all the same to ArmA...

    So let's get to that: First we should install and configure PPjoy to create a virtual device. If you have it installed you should see a 'Configure Virtual Joysticks' item in your Start Menu. From there, you can create new devices. (PPjoy won't create new devices automatically on install, you have to do it yourself)

    So create a new device, and give it the next available device number. This depends on how many joysticks you have plugged in (If you got 2 joysticks, you should create a PPjoy device with device number 3, since it's the next number available). All other settings are fine to leave as default. You can play with them later if you're feeling good about all this.

    You can check if PPjoy is installed correctly by going into Control Panel -> Game Controllers and checking if there is a device called PPjoy Virtual Device # there. (the # is the number you gave it). We'll come back here later, so just check that your device is listed there and let's move on.

    Now we go into GlovePIE.

    The first thing you see when you open GlovePIE is a blank screen with a few lines that say 'write your script here'... yes, there is some scripting in GlovePIE (actually PIE stands for programmable-input-emulator, so it pretty much a given that you will be doing some scripting), but don't worry it's quite easy.

    This is the command that does all the magic:

    PPJoy#.analog2 = (MapRange(-Joystick.slider, -1, 1, 0, 1))

    Where # is the device number you gave your PPjoy device when you created it, and Joystick.slider is a reference to the slider axis of your joystick.

    Now, most joysticks define their throttle as 'slider', but that varies from stick to stick... On the X52 Pro the throttle is the 'Z' axis, so you may need to do some searching to find your throttle axis (or whatever axis you're trying to get)

    For that, the simplest way is to write this just before the command you just wrote:

    debug = Joystick.someAxis

    where someAxis is the joystick axis you want to try... on GlovePIE, everytime you press the . [period] key after Joystick, it gives you a list of all possible options... so you can try them until you find your throttle axis... Good candidates are .Z, .Rx, .slider, .roll, .pitch... try those as well as others to find your axis.

    This debug line will enable a small text field next to the 'Run' button on GlovePIE... there you will see a number (which probably will read zero)... run the script and move your axis around to see if this number changes... if it does, you've found your axis.

    So what's going on there exactly? Well, what this script is doing is basically saying that the PPjoy axis called analog2 will be equal to Joystick.slider with some corrections... the four numbers that follow Joystick.slider define that correction. Let's look at that line again... this is what each element means:

    AxisToSet = (MapRange(AxisToRead, minInput, maxInput, minOutput, maxOutput))

    So the first 2 numbers after Joystick.slider represent the range of input, while the last two represent the output after the correction... so what this means is that a value ranging from -1 to 1 will be scaled into a value that ranges from 0 to 1.

    Now, here is why ArmA only reads half axes... normal joystick axes center at zero. Imagine the stick's X axis, the left/right movement is defined as -1 at full left, zero when centered, and 1 when deflected fully to the right...

    So all joystick axes are centered at zero... but this is a problem when handling the throttle axis, since that is an axis without a center... it ranges freely from none to full, but is read as ranging from -1 to 1 anyway... so ArmA only reads either the positive or the negative range of it... Hence our contraption here to counter that.

    So what this script is doing is feeding the full travel of your throttle (-1 to 1) into only the positive range of the PPjoy axis (0 to 1). so when your throttle is pulled all the way back, PPjoy will be at 50% (0), and when you push your throttle to full power, PPjoy will be at 100% (1), which is the full range inside ArmA, so now you can control your throttle using the entire range of your throttle slider/lever/handle.

    So, now let's test if it worked. Open up Game Controllers on control panel again, and choose the PPjoy device, hit Properties, and go into the 'Test' tab. You should see the joystick axes there, along with some buttons...

    Now, ensure GlovePIE is running the script (and that it doesn't show a red line on the script screen, as that means a syntax error), and that the Test screen of your PPjoy device has focus (it won't update if another window is in front of it).

    Now move your throttle a bit... you should see the PPjoy device move one of it's axes. If it doesn't, you'll have to tweak your GlovePIE script to ensure you're actually reading the throttle axis, and double check everything until you see movement there...

    You can also write debug = joystick#.z to check that this device really is receiving what you are giving it. Here '#' is the number of your PPjoy device, and 'z' is the same as ppjoy's 'analog' 2

    Ok. so let's assume everything worked fine and move on. The next step is to map this PPjoy axis into ArmA as your throttle axis. This should be very straighforward... just go into the control settings in the game and for 'Thrust (Analogue)', move your throttle axis... you should see that both your physical joystick's throttle as well as the PPjoy axis were detected... that's both normal and good. Just delete the physical joystick mapping from there and let the thrust mapping be controlled by only the PPjoy device.

    This is all... now you should have a full range of throttle input.

    But that leaves a question... what about braking? that's not an issue on helicopters, but fixed-wing craft need help slowing down... and we just killed the part of the throttle range that was doing that...

    Well, that's in part a good thing, because no aircraft in the world has it's airbrakes on the same lever as the throttle... but we do need to have brakes... so you can either map another another axis to be your brakes (if you have axes to spare) or just map a button for it.

    If you choose to map an axis, you can use GlovePIE to do just what we did there to the throttle axis again for the airbrakes axis... if you're going for a button, ArmA will let you map a key or joy button as 'Brakes'

    Here are links to download both apps:

    PPjoy 0.8.4.6 - http://drop.io/ppjoy0846testrelease (Win XP/Vista/7 x86 and x64)

    Here's an alternative link to PPJoy in case the one above doesn't work.

    GlovePIE 0.43 - http://glovepie.org/poiuytrewq.php (get the one without Emotiv Support)

    Well, I think this pretty much covers it... I hope I made it clear enough... if you have any questions, thoughts or free money, just drop a line here ;)

    Best of luck to all :)

    Cheers

    HarvesteR

    • Like 1

  23. Posted

    I got the Saitek x52 Pro here with the rudder pedals. They're awesome!

    Too bad that after about 2 years, the potentiometers on the twist grip and the rotary axes have become unresponsive... it might be time to switch them out...

    Other than that, I have no complaints... it's a really great stick for it's price...

    Cheers

  24. Posted

    Yours might be caused by some other reason... If it only happens during online play, it might be server-related, or it might have something to do (however obscure) with network issues...

    See if switching servers makes any difference whatsoever (be it for better or worse), and see if running without mods also has an impact...

    I really can't think of anything else to suggest...

    Anyways, best of luck!

    Cheers

  25. Posted

    Well, I updated my drivers, and was surprised to notice how long it had been since I last updated the drivers on my rig...

    I honestly wasn't expecting to see such an improvement! Solid steady performance all around, over an online Domi2 ACE session for about 45 minutes... and apparently the annoying sporadic lag has gone away!!

    Granted there were a few moments of lower FPS, but those were in the regular situations one would expect to have that, like under rain with 14x scopes pulled all the way...

    This is great! that means I don't have to spend money I don't have on a new GPU right now!!!

    Cheers

×