TheHarvesteR

Hadn't seen that there was a new version of SpiritedMachine's Launcher... I use this launcher too, and was using the FRAPS auto-launch to launch TrackIR instead... this new 'external apps' panel is far better Oh, and I found another scenario where this fix is very helpful... If you have rudder pedals, you probably have, like me, set them to be also your brakes/gas pedal, no? Well, the Saitek Rudder pedals have 3 axes... one for the main rudder action (heel back/forth) and two other axes for the toebrakes... these toebrakes can also double as gas/brakes... but the same half axis issue arises here because (on the Saitek pedals at least) each toebrake axis is it's own full axis... so ArmA will ignore half of it's travel.... mine's ignoring the bottom half, so when I start flooring it, I have a 50% deadzone before any gas starts to flow. Seems minor at first glance, but remember these are axes you use with your feet, and lack of travel there makes for a VERY hard time trying to find the right amount of pressure your foot should apply... Anyhow, the fix is still the cure here... only wanted to share another use case with everyone :) Also, on another note, this fix made it to the A2 Bug Tracker as a workaround for the original bug. Does this mean this is now an 'official' workaround? ;) :D Anyways, the issue is assigned there, and it has a target version... :bounce3: Cheers

That sums it up perfectly! I've always wanted to get some of the so-called l33t players from battlefield, CoD and others into an ArmA session, just to teach them a little humility :D Someone definitely should set this up Cheers

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

Hi, Just wanted to say sorry for the delay on my part... work is eating away my life right now, so I haven't had much time to focus on other things... I'll try to get that Haar-tracking code as soon as I can :) Cheers

It's awesome because that's a real military squad there... playing essentiallly the same game (or simulator) as we do (albeit theirs does have some cool extra features... but they paid 1000 times more than we did :p ) Cheers

Just saw the link you posted. Now that's a really helpful bunch of apps there :bounce3: I hope you don't mind me reposting the link here, just for safekeeping ;) http://www.wingmanteam.com/latest_software/gadgets.htm#DX%20Tweak%202 Thanks!! Cheers

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

Hehe, I was about to reply to your question about this on my thread, but I see you've got it down already :) I wondered how you planned to use the mousewheel for zoom without disturbing the default setting... Nice job with the modes there! Isn't GlovePIE awesome? :bounce3: Cheers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hello, I'm facing a weird situation here, and I'm probably gonna need a new video card... but if this rings a bell to anyone and it does prove fixable, well, it can't hurt to ask... So, I'm having sporadic moments of very low FPS while playing... it doesn't seem to be related to anything content-wise (like heavy missions or something) since I get this lag even on an empty Utes in the editor... This is probably related to the fact that my video card has already been in the oven... since it didn't really have this problem before that whole episode... I'm resigned to the idea of getting a new video card... but money is an issue right now, and any new GPU is still some way away... So I'm asking here just to see if anyone's ever had this issue and who knows, maybe there is a miracle fix for it :bounce3: So, any thoughts? Thanks in advance Cheers

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