samtheeagle

Excellent news :) Having exchanged some messages with V4Friend (of FreeTrackNoIr fame) it seems that my FreeTrack wrapper application is a bit superfluous, as FreeTrack already creates a shared memory area and a controlling mutex. That's what my wrapper does, via the FreeTrackClient.dll, but that's not really needed. Of course my way seems to be working for people, but I've reinvented the wheel somewhat :D I could defo simplify things now knowing what I do now.

So if I understand you correctly, you're saying that the FreeTrack application already writes it's data to a shared memory area? Is that how come you avoid using the FreeTrackClient.dll? If that's the case then I suppose my wrapper is a bit surplus to requirements :) Edit - It seems it does!!! I wish I had found that out earlier :D The sample c file in the FreeTrack SDK doesn't make any mention of it, but looking at the Delphi SDK code I can clearly see the shared memory key and mutex that are used. Oh well, it was a fun learning experience :)

@V4Friend: Great work on this :) Thanks on behalf of the community. I really like the look of the FTNIR project, I'm just waiting for it to mature a bit :) Hence my work on a FreeTrack interface... You say that your HeadTrackers will work with FreeTrack too, but I can't quite figure out how the 32bit/64bit issue is overcome? I can't see how your HeadTracker can work with FreeTrack "as is". Do you perhaps mean that the 32bit HeadTracker.dll will work directly with FreeTrack via their SDK, but perhaps the 64bit one wont? (And indeed cannot) Your readme file exaplains your use of shared memory for the IPC mechanism with the 32bit FTNIR application, and this is exactly the approach I took with my FreeTrack wrapper. I think perhaps that we've solved slightly different things here, that are complimentary to each other :) Again, great work on FTNIR, I look forward to watching it develop.

Cool, I guessed that the default prefs values would be ok, a standard webcam at a "regular" sitting distance from the camera would yield the same kind of FOV. Still, I though it was important that people could tweak things to suit their setup.

Excellent! :D Yes, I am planning on making the source available, I just wanted to throw the binaries out last night to see if they worked for anyone else. I'll try and get the sources packed up at some point today.

Awesome, well that's +1 Arrowhead, glad it works for you, and thanks for letting me know :) It's so funny that 20 minutes after I put my implementation up the FTNIR team deliver one too! The community is spoilt for choice now :)

lol, you wait for one to come along for ages, and then two come at once! :D

I'll just leave this here: http://www.forum.lockon.ru/showthread.php?t=75917

By jove I think I've cracked it! http://www.forum.lockon.ru/showthread.php?t=75917 Well it works on my machine. I need some testers :)

I tentatively present a first cut implementation http://www.forum.lockon.ru/showthread.php?t=75917 Well it works on my machine. I need some testers :)

Ok, so I finally cracked how to implement a custom HeadTracker.dll for the A-10C game :D It works on my machine, and that's about as much as can promise at the moment, I've literally just got it to work! But if anyone else wants to give it a try I'd be very interested to hear if it works for you. If this works for you it will allow you to use the 32bit FreeTrack application with the 64bit version of DCS A-10C. Instructions are included in the zip file... There's a fairly simple one off setup, and then it should just work behind the scenes for you. Please feel free to post questions here. <DEPRECATED> HeadTracker Binaries.zip </DEPRECATED> SEE BELOW FOR AN UPDATED VERSION

Just FYI I'm fairly happy that my approach is sound, I have the 32bit FreeTrack wrapper writing to shared memory, and a 64bit test harness reading that data. The test harness also handles to conversion of the FreeTrack data values to the -1..+1 range required by the HeadTracking API. So the mechanics of the IPC seem to be there, where I'm getting stuck is putting the code from the test harness into the HeadTracker.dll plugin system. I just don't get anything back to diagnose what's wrong. Nothing crashes, I can find no reference the anything HeadTracker.dll or such like in any log files... I don't even think the HeadTracker.dll is being loaded, as I chucked in some custom logging into the API entry points, but the log file never gets created, let alone written to. So have I just got the dll file in the wrong location? I've tried many many different places in the hope of getting some kinda of a response. Or am I being a bit keen here? Is the API not implemented yet? Do I need to wait for the next patch or something? Cheers in advance :) ----- Additional ----- I've been fiddling about with the Input.lua file, to see if I can get some more info out in the log files, and it's been partially successful: 00012.035 INFO NEWINPUT: TrackIR: Error initializing NPClient interface! 00012.036 INFO NEWINPUT: Cannot load headtracker.dll! I assume I can ignore the NPClient stuff, as I don't use TrackIR. Unless ofc this interface is required for any head tracking system? The only thing that I can think of is that I'm building these HeadTracker.dll files using Visual Studio 2010, and a lot of comments I've seen in various files seems to refer to Version 9.0, so my next thing to try is recompiling usuing that version. Just need to install the old Visual studio now :S

Hi, I'm working on a little project to get the 32bit FreeTrack application to work with the 64bit A-10C game. I've put a wrapper around FreeTrack to write it's data to a shared memory block. I'm now trying to implement a HeadTracker.dll as defined by the API posted on the forums here by waggs, but as yet I'm not getting it to function. I've tried to build the reference implementation included in the API distribution supplied by waggs, just to test the file locations and what not, but even that isn't working. So I can rule out my code for now, I'm just trying to work through getting the reference up and running. I am of course assuming that the example supplied by waggs should work. The code certainly compiles, and it should rotate the view around the yaw axis once every 5 seconds. I think I'm placing the file in the right location bin/headtracker/headtracker.dll, that's where Input.lua says it should be. Anyhoo, any support for the API would be greatly appreciated :)

So can any of the ED people offer me some help with the Head Tracker API. As far as I can tell I've implemented it to the spec defined by the header file, and I've put the appropriately named dll in the folder specified in the readme file... But so far nothing. No head movement is detected, and I see nothing in any logs files that might help guide me. Is the loading of a head tracker something that gets logged? Thanks.

That would be nice. A bit of an issue tho - FreeTrack is written in Delphi, and at present Delphi doesn't support compiling to 64bit. It appears to be under development, but as far as I can make out it's not released yet, maybe later this year. At that time then yes, a recompile to 64bit would be the best approach. Until such time some form of IPC needs to be used to overcome the 32/64bit issue.

Well today I've knocked up a wrapper around the FreeTrack.exe which does a few very simple things... (1) It fires up the FreeTrack application, and monitors it waiting for it to be closed, at which point the wrapper terminates too. (2) While the FreeTrack process is running the wrapper queries FreeTrack via the FreeTrackClient.dll. The sampling rate is defined via a command line parameter passed in to the wrapper E.g. 30 times per second. (3) The wrapper creates a uniquely named shared memory map and semaphore to be used for interprocess communication. This wrapper allows 64bit processes to access the data generated by the 32bit FreeTrack application, but of course the 64bit apps would need to support the interface I've defined. So the next job is to try and create a HeadTracker.dll implementation that will read data from the shared memory map with the help of the semaphore so that DCS A-10C will work with FreeTrack, without the need for PPJoy :D Here's hoping!

See my post above :) But the key things are poor tracking i.e. jittery and high cpu usage i.e. 50% plus :( I'm talking about FTNIR here, FreeTrack with PPJoy works better, not ideal, but smoother and far less CPU intensive.

I'll not get too carried away then :) I hope whatever solution comes can support FreeTrack. Although FTNIR is a very appealing concept, my initial tests of it have been less than pleasing. It's jittery, slow to detect my face (maybe I'm that odd looking? ;) ), and drops tracking easily too. And when that happens it chews up the CPU like a monster i.e. 50%+ usage, which ofc destroys the gameplay as it turns into a slideshow :( Fingers crossed later iterations will improve on these issues, as like I said, the concept is a fantastic one, it just needs a bit more polish.

As far as I can make out this is all a bit messy. I was gutted to find that A-10, and BlackShark post 1.0.2 patch wouldn't support freetrack. Since then I've been trying freetrack via PPJoy, which kinda works, but it's a bit clunky compared to the proper support. As far as I understand it there are a couple of issues with freetrack and 64bit support. The freetrack project has shown no signs of life for a loooong time now, so I'm not sure if it'll ever get updated again :( Freetrack is written in Delphi, which atm doesn't appear to support compiling to 64bit binaries. So that's terminal, even if the freetrack developers were still around. I'm currently doing some investigations about how the 32bit freetrack client dll could be used from the 64bit A-10C process. Some form of IPC will be required, as 32/64 bit stuff WILL NOT mix together at all, it's just not possible. So right now I'm looking at defining a 32bit RPC server to wrap around the freetrackclient.dll, and then creating a 64bit RPC client that implements the recently released HeadTracking API realeased by waggs. I am a developer, but not a C++ one, so all of this is a bit greek to me, but I'm going to give it a shot. Of course if someone more technically adept than me could know this up that'd be great too ;) I'm pretty confident that the approach will overcome the 32bit / 64bit problem, just so long as the RPC stuff isn't too slow for this application? It's defo going to be slow next to proper InProc calls, but as I already mentioned that is not an option here.

Thanks ZaltysZ! I see, so it's a two stage process, you define things that can act as modifiers first, and then you can use those when allocating actions to buttons. Not immediately clear from the UI that's how it works, but I guess this is a good lesson in RTFM :music_whistling: Thanks again :smilewink:

Hi, I'm trying to set up my X45 to handle as many of the gazillion controls as possible... What I'd really like is to be able to use a joystick button as a modifier. This would allow me to at least triple the number of actions on the stick. It strikes me as VERY limiting that only CTRL, SHIFT and ALT etc can be used as modifiers. The last thing I want to do when taking fire is take my hands off the controls to use the damn keyboard! Does anyone know of a way to do this? Am I just being special and it is in fact possible? Or perhaps it could be included as a very useful feature in a future update? Cheers, Sam.