topdog

Some details about your pilot log are global, and some are campaign specific. Your progress in a campaign 'game' is recorded in its own section, each mission you do along with the next mission to try (if you've just progressed to a new one but not yet flown it) are held in their own block of data related to each campaign associated with your pilot. It will record multiple entries for the same mission if you have to redo them (so I have over 20 missions recorded against Deployment campaign because I ended up doing mission08 some 8 times, and a few other missions I failed first time and had to redo as well). Flying missions out of the campaign 'system', such as when taking control of a watched track, aren't registered there. You could likely review the content held in your Ka-50\BlackShark\data\scripts\Logbook\Players.lua file (that's where all the above is derived from), though don't change anything if you're unsure, could corrupt your pilot file and need to wipe and restart it. Some longer missions that include a fair bit of flying to the target area before you get into any action, so long as you're flying a course that's unlikely to see you impacting the ground or a mountain, I'll fast-forward along a way point to save up some time. Just try to turn it off again before you reach any FACs, bases/FARPs, convoys, etc., as you may fast-forward through some useful mission dialog too. You can turn a 2 hour flight into a 30-40 minute one that way, and still not miss any of the action.

It's not really any different (for this purpose) as any other head tracking tool, however it's going to be less efficient at tracking a full head/face in real time from a web cam, than it is going to be tracking 3 IR dots. From forum search on faceapi for further (prior) info and discussion: http://forums.eagle.ru/showthread.php?t=50492 http://forums.eagle.ru/showthread.php?t=33754

The FC install method built into tacview up to 0.94 is for FC 1.x. Because FC2 borrows heavily from DCS:BS for a number of upgrades, until such time as Tacview is updated to have a 'native' FC2 support, you treat FC2 as though it was blackshark. If you used Tacview's integrated installer to enable/install directly to your FC2 environment, I would go ahead and uninstall it. Then you have to follow the manual installation instructions for Tacview which means having the TacviewExportBlackshark.lua in your FC2 folder (the FlamingCliffs one is for 1.x..) and the dofile needs to reference that file also, not the FlamingCliffs one. C:\Program Files\Eagle Dynamics\LockOn Flaming Cliffs 2\Config\Export>tail -5 Export.lua -- "mfd2" - not used -- "mfd3" - not used -- "mirrors" - mirrors [b]dofile("./Config/Export/TacviewExportBlackShark.lua")[/b] C:\Program Files\Eagle Dynamics\LockOn Flaming Cliffs 2\Config\Export>dir TacviewExportBlackShark.lua Volume in drive C is bringit Volume Serial Number is C8EE-2179 Directory of C:\Program Files\Eagle Dynamics\LockOn Flaming Cliffs 2\Config\Export 06/02/2010 03:35 AM 26,072 [b]TacviewExportBlackShark.lua[/b] 1 File(s) 26,072 bytes 0 Dir(s) 11,413,712,896 bytes free C:\Program Files\Eagle Dynamics\LockOn Flaming Cliffs 2\Config\Export>type Config.lua -- !!!!!FOR NETWORK MISSION MAKERS !!!!! -- put this file to your mission package Config/Export/Config.lua --( miz file , it basicly ZIP archive,so just open it with your favorite archive manager) -- to avoid using LoGetWorldObjects() and LoGetObjectById(id) functions -- this setting does not affected to server and single player game [b]EnableExportScript = true[/b] -- set true to enable Export.lua script, please C:\Program Files\Eagle Dynamics\LockOn Flaming Cliffs 2\Config\Export> Three items in bold are the important ones, the dofile (with the correct filename), the enable export, and the actual (correct) tacview lua script itself, and note their location (relative to your FC2 install). To Lulac: You do not need to install DCS:BlackShark itself, the game is unnecessary.

These are inherited from black shark and to the best of my knowledge, unused in either game. They're samples of integration with Saitek's DirectOutput API, which is basically a fancy way of toggling the colour of the stick's LEDs and contents in the MFD display. It has nothing to do with the flight model or input manipulation. Your woes with the F15 I cannot answer.

Not quite what I was after but interesting to know. More like given 100% setting, what are my actual chances of a normal take off or landing being impacted before I exceed the 200m ceiling, 1% of takeoffs, one in a thousand, etc. Not too worried using it as a below-radar / ballistics miscalculation deterrent, but rather how much annoyance vs. realism factor I would have in dealing with this. I actually like going through a campaign etc. with 'the same' pilot rather than one who dies in service and then comes back to life for another attempt, I do what I can to stay alive even when otherwise it's moot because the game doesn't care too much whether you fully crash and burn or make it to the ground alive in your chute.

Would be nice to have a clue what the % represents.. is it modelled on actual bird migrationary patterns in the region (hilarious to think it might be, or that research was done to this effect)? Does this fluctuate so you have less at night time, but peaks at sunrise / sundown as activity changes or do I have as equal chance at midday as I do at midnight of playing chicken with actual chickens?

If you're trying to create one big virtual screen from a multi-monitor setup, you probably need to use some software designed for the task. eyefinity for some ati cards or softth for others as a start. Although Windows will extend the 'desktop' across multi monitors giving the appearance of 'one window', it's a high level operation not one really for a low level / high performance graphics api. Are you using any of those other solutions?

Also I note your use of the term reset trim, which is different to doing a re-trim. Resetting trim is most often a recipe for a quick manouvre into the shark's "playing dead" position (laying on its back) :D Unless things are getting REALLY out of hand already anyway, the only time I tend to reset trim is upon touchdown of a landing, speed and motion permitting.

Depending on your situation, after you set your controls and Trim, if rudder is way off but you weren't intending to trim in a sustained turn or yaw, a quick tap of Z or X (if left on defaults) will quickly re-center your rudder and you can hit Trim again. Often that will help neutralize a lot of the rudder input build-up, but you'll have to recognise when to use it, and when to just re-trim the controls to a more central and stable position (else when you do try to move off, chances are you'll be flying off on a diagonal aspect rather than ahead direction anyway, with rotor pitch and rudder operating opposite eachother).

Don't think that it won't get noticed either - when I saw this in Tacview, I felt like I'd been busted by a CCTV camera..

This will be due to permissions on the protected Program Files folder most likely, as MS don't like app developers writing user data there and developed data virtualization techniques to redirect the writes to another folder on your hard disk when using Vista/Win7/Win2K8 with all security enabled (including UAC). They're doing this temporarily with 32-bit apps to give them a chance to still work on the new OS, but data virtualization won't be a long-term feature for MS to keep. Given where Lockon is installed now, do Start -> Run -> %localappdata% (including the % characters) and then press Enter. The folder that opens up should have another in it called VirtualStore. Go in there, and then navigate through the directories as if you were trying to find where Lockon is installed to (Program Files\Eagle Dynamics\etc. etc.) until you find your missing screenshots. This isn't a bug per se, unless Lockon was trying to get the MS Windows Vista/7 logo certification.

Most of the LCD is unchangable, it's not like a graphic plate you can fully replace. The 3 rows of text characters inside the centered black rectangle is what you can change. How you change it and how frequently is up to you. If the text is too long to fit, it will auto-scroll. You could use it to display a kind of 'ASCII gauge' but it would be crude, it's better for short strips of information given as acronyms and numbers, like coordinates, whatever you call your ascend/descend rate, data from the ekran (though ekran is 4 lines and x52 pro is 3, rarely is there actually 4 lines of useful output in the ekran anyway so it can be considered). You can also decide through this same API what to do when the MFD wheels are pressed or rolled, which would allow you to build in scrollable text or menus, things of that kind. The left wheel is half predefined for you, the right is free for customization, for any given page. You can also have multiple pages with different functionality on each to scroll through. I've written a small test harness app to play around with these settings, I'm just thinking about how best to put the pieces together for something useful. The LEDs I've already got a good idea what I want to do with them (autohover/heading hold indicators, gear up red/gear down green, weapon control system led's off when master arm off, etc.), the MFD data I'm still unsure what options to settle for aside from ekran and its history / timestamp data. Of course, the numeric output of pretty much all the instrumentation (including those off to the sides like APU etc.) could be output, I'm not actually sure about the data regarding the trim and rctrl+enter controls helper display though offhand, probably with some work, but probably not in a (good) graphical format. E.g. [---<--|------] [------X------] [------|----->] You could do rudder and bank trim for example using 2 horizontal rows of the LCD in ascii form if the raw data is accessible, that'd work. Any other ideas?

Nice setup, I was able to check it out now :) Unfortunately seems like the other site I was referring to has had to shut down but an offline copy of it is still available and may have some good references/plans for helping others. None of it is my work of course, no credit for me to take unlike your own efforts. Good to see different approaches/solutions to the same kind of problems though, and this kind of design may help solve some of those headroom issues for some. I do like the almost 'bath tub' style of it though it'd be a little less glamorous to get in/out than the platform based solution heh. http://www.youtube.com/user/tronicgr#p/u/38/1SX_oBSGoKk

Also make sure you've not:- 1. Copy/pasted any key profiles for one plane over the top of another. They're not that compatible since the planes have some different controls (in many cases). 2. Haven't turned any joystick buttons into custom "Modifiers" if they're type of buttons that are "always on" (if you use or know an X52 controller, the Mode wheel/switch is one such example, it's always on in one of the 3 positions, you can never turn it fully off). Both of these would hamper the ability for you to press the key and have it recognised for that action.

I can't access anything youtube related from here to see, but a search for youtube user 'tronicgr' will dig out some good demonstrations of motion platforms rigged up to lockon - starting out with just a cage on pulleys for X/Y rolling, but he's since been working on one of the more expensive platforms with more motion freedom (dimensions). Very inspirational, and if you look around you'll even find something of a how-to for assemling one (he had a design originally with one pulley on the left side of the cage, that wasn't so good since the cables needed to be re-tensioned frequently and he's since relocated it), so dig through and find the good ones and the updates :) Once I move house I'm planning on dedicating some space for making one.

Their Apache Longbow and the Tornado ones I had - think I may have even played the Tornado one first on my Amiga before I (reluctantly, dragged kicking and screaming,) migrated to a PC. I dug out both copies recently on a frenzied search for my old TFX CD :D

Those ones are locked into the X52's MFD (rather, LCD,) control mechanism. They CAN be programmed (I mean actual write code to do stuff, not edit a profile) to do various things using Saitek's "DirectOutput" API (not to be confused with anything DirectX related from MS). [Edit: line removed, unsure if it's accurate] So out of curiousity, if you could use the LCD and scroll wheels, what would you want them to do exactly? I had a couple of ideas I'm toying with myself, but I'm limited to some extent on the shape of the LCD (3 rows, 4 would have been nice for KA-50's ekran,) and some display outputs we can't easily get (PVI-800 LED displays) for example. I haven't thought about Lockon yet as I was waiting to see what changes might come through in FC2 before I checked that. In my project I'm feeding back various states through to the X52 Pro's various button LEDs as well, and other things, so it's taking a while to find time to piece it all together - if anyone else could use what I end up with, it would make the efforts more worthwhile.

Played with them some more. In summary, I'd say the in-game control settings for modifiers add some new twists, but don't behave the same as they do in SST. The switch for example is a press-to-enable and press-to-disable modifier. Put another way, let's say you setup 3 switches mode1 to mode3. You launch the game with mode1 selected on hotas. Turning the wheel to mode2 turns that switch ON, buttons which are now expecting mode2 as a switch modifier will now work. Turning the wheel to mode1 again turns that switch ON (note it hasn't turned mode2 off), and any buttons which are expecting mode1 as a switch modifier will now work. Turning the wheel to mode2 now turns it OFF, and any mode2 switch modified buttons cease to work. The 'always-on' nature of the selected mode wheel setting makes it unsuitable for adding as a regular modifier (like shift/ctrl/etc.), as it invalidates most regular key settings (unless you're prepared to setup every single one to operate when modeX is enabled, including base functions like game pause and game quit). On the other hand, these capabilities can be useful in giving certain buttons/hats multiple operations under different toggled states. So I think this should be treated as an additional tool, not really a replacement, if you're after very specific behaviours from button/switch press combinations. As a side note, I'm using X52 Pro (it registers the modes as JOY_BUTTON28 to JOY_BUTTON30, by the way, but otherwise should be no different).

Have you ever had this cause conflicts with the keyboard? For instance, I go into a mission and I can't press Pause/Break to start it. I try RCtrl+Pause/Break and it shows the FPS counter fine. I fiddle with the mode switch wheel whilst pressing Pause/Break, and now it works. I test the bindings I set with the joystick, and I'm content it's doing what I programmed it to do. I then hit Esc to end mission.. hmm.. not responding. I fiddle with mode wheel some more, and then Esc works. - Saitek profile is successfully blanked to a single line with no bindings and all set as No Button (not blue), saved and activated profile. - All 3 modes are added in FC2 as both a switch and a modifier with different names. - If I only define switches for mode wheel, then the modes don't work (i.e. don't limit another button to only function within that mode when pressed). - If I define only modifiers for mode wheel, I get this conflicting behaviour with Pause/Break and others again. It's a strange interference. Clearing those newly added modifiers returns keyboard back to proper responsiveness again.

Click Start -> Run then type in this: %localappdata% [enter] Should open up an Explorer window in what is normally a hidden folder tree from you (i.e. not normally seen when just browsing around in Explorer). Now from here go into VirtualStore -> Program Files (x86) -> Eagle Dynamics -> LockOn Flaming Cliffs 2 -> Temp folders. You should find the requested files here.

The most important question is which folder on Wags' desktop is the one you want to see most: http://forums.eagle.ru/showpost.php?p=867075&postcount=551 My vote's for DCS:pr0n - should make for some interesting producer's notes videos at least !

That's awesome news :) But what the heck was it?!

SysRq is the secondary label/function of the Prt Sc (or Print Scr) key. Stands for System Request but that feature of the key is more or less unused for Windows systems under the purpose it was designed for. http://en.wikipedia.org/wiki/System_Request

I thought the jet nosing down at lower speeds without setting trim was normal / 'a feature' :D It doesn't sound to me like the same thing where people are getting the full deflection nose dive.

Re: lower FPS, it really does two things specifically. 1) Prevents your FPS from going higher than your monitor refresh (which is OK, anything higher is not seen anyway). 2) Prevents half-frames from being drawn, so you never have lower 'completed frames' ps, you just lose the torn ones. Not as bad as it sounds, and should probably be turned on forever except under two specific conditions - troubleshooting a fault, and benchmarking for system bottlenecks. Those people who found their refreshes (on an e.g. 60Hz screen) wouldn't output anything between 60fps and 30fps or lower, are those I'd categorize as 'troubleshooting a fault' because that isn't normal.