topdog

Check the options again and see if you have the one enabled that says to use your (realistic mode) preferences in all missions.

Yeah that should work, it's the same approach I posted then pulled heh, I just wasn't 100% sure since it would replace 3 of the 4 aspect= entries if that was desired or not, but that should work for XP -> Vista -> win7, whether 32-bit or 64-bit, except that XP wouldn't understand the /affinity parameter for the start command.

Edit: You guys are only changing 1 line in that file, out of 4 that have aspect = N values? If so, I'm taking back my suggestion until I think of an alternative and/or you clarify, just to be safe.

I believe you, if you say you could not reproduce this (if it is a bug that is a possibility), but here are the steps I can follow to reproduce this consistently. It's not 'omgosh' bad of course, quite the minor 'buglet', but just in case there is something I have done wrong I would welcome enlightenment. What do you think? I can crash, recover, repeat, without touching any other controls and get this. I can quit and go back in instant action, always the same for me (1.0.1 patch, no mods except acmi file exports for tacview).

I have a 27" (2707WFP - note the 07 indicates the fiscal year of this model's release) and 24" (2407WFP) model Dell panels, both are fantastic, but.. .. I might have been lucky, the criticism levelled at Dell's monitors seems to be that they use good parts/builds with a release whilst they're trying to get favourable tech reviews, then in later revisions (e.g. from A00 to A01, A02, etc.) they start to cut some corners with the quality whilst keeping it sold as the original product. How true this actually is I can't say, and I tended to buy near the next model's release timeframe (e.g. 2408's and 2709's were arriving on the horizon when I got mine) but still got 'early' revision panels for my models, so maybe I was smart, maybe I was lucky, maybe some other people are just unlucky.. really hard to say except I personally think mine are great. I think actually my 2407 might have been an 'A04' revision, which for its line was the favoured one, for some reason or other (firmware / fixes), but other than that the generalism I mention was a common theme I'd read about. Some people even feared having to send theirs back for warranty repair in case it got replaced with a 'newer' (inferior) revision, that's how widespread the information got. Since you might be looking at a 2410 there (with the 10 being this fiscal year's model) you should be ok, but scour around for any recent reports of this type of complaint being levelled at it.

Having taken apart my X52 Pro (and not being all that smart at engineering my own solutions I have to admit) it doesn't look too hard to take any trigger casing and turn it into a dual-action one. It's just 2 microswitches side by side, and the trigger contains a spring-loaded rod that would make contact with one of the microswitches early, before a full depress allowed the main trigger body to initiate contact with the second trigger. The microswitches were covered by a thin strip of metal to allow the trigger rod/casings to slide against the face of the microswitch without having to have precision contact directly over the 'switch' part. The wiring of the microswitches was done that they shared the same ground power lead, such that switch1 had to be down before switch2 could engage (mechanically it took care of this anyway really, but electronically it was wired that way too).

If you try going into the game anyway (to an actual mission), and then quit, could you see if you get these files generated and perhaps they will provide some useful content to consider: C:\Program Files\Eagle Dynamics\Ka-50\Temp>dir *input* Volume in drive C is bringit Volume Serial Number is C8EE-2179 Directory of C:\Program Files\Eagle Dynamics\Ka-50\Temp 14/03/2010 08:02 AM 52,034 inputscript.log 14/03/2010 08:02 AM 99 NewInputDevices.txt 14/03/2010 08:02 AM 0 newinputlog.txt 14/03/2010 08:02 AM 3,212 NewInputStart.txt 4 File(s) 55,345 bytes 0 Dir(s) 46,209,687,552 bytes free C:\Program Files\Eagle Dynamics\Ka-50\Temp> All sorts of device recognition seems to attempt to take place and be reported in those files, whether it's keyboards, mice, soft devices, head track units, or joysticks. Don't know what to expect given your problem, but a scan might give some clue.

How uptodate are your Saitek drivers and software (two separate downloads from the saitek.com website)? I'd start there, and make sure both are running successfully with the profiler icon in the system tray. I believe I'd be right that the X52 (pro and non-pro) are quite a bit older than the game, and probably had some software updates even before DCS:BS was released.

I don't think you need to get the plus sign to show actually; just press it at the appropriate time in the sequence depending on whether you need a positive (unlit) value with the +/0 key or negative (lit) value with the -/1 key and continue with the rest of the sequence. I also noted that I didn't seem to need a leading 0 for the sequence in the upper PVI display but I did for the lower PVI display (for the second half of the sequence). What also was odd is that I couldn't get some values to 'stick' as I entered. It started out showing 43'58'(.)7 to match Abris value 43'58'44 and I changed it to 43'58'(.)6 in the PVI and it was fine. I then went to change it back to 43'58'(.)7 and it refused, kept setting to 43'58'(.)6 again. I tried with 43'58'(.)8 and that was fine so seems some odd rounding takes place that just prevented me from regaining 43'58'(.)7 and it kept getting rounded down. Normal or seems to be a minor bug? P.s. I should note, that number sequence was for the upper display. I forget what the lower display was, but basically, these two values are the defaults for waypoint1 when going into Instant Action. It was 41'03'(.)6 or something if I recall.

Did you keep the track file? Would be awesome to be able to replay it, fast-forward to the auto-rotation landing, then see what's up and play around with it :) I didn't think of it myself at the time but will do from now on. Can't be worse than me attempting to 'walk home' to base one time heh. I didn't realise until later that my ejected pilot and forest wanderings were all captured in TacView at the same time though... :doh: I got a laugh out of seeing one of my apparently shattered pieces of shark stay in the track replay, and then start to scurry around on the ground like a small bug/insect hoping not to get noticed.

Thanks Frederf. As fortune would have it, a timely bump of the Leading Edge Training thread today revealed a video I'd not watched before, and covered the engine cranking need/process. Looks like 2+2=4 here for what I probably experienced before based on your description, (but I didn't know how to deal with it). Good to see I could give it a try to clear the fault if it happens again, and this video is a good next step for me to cover. Cheers!

With a single-threaded / single-processing app, even then an extra core could help a little bit. Let's say your system has to dedicate 15% processing time to 'other stuff' (though this number is a bit high for normal idle use), and then if you only had 1 core available total, it would only get 85% left for it to use for a game. So adding 1 extra core can mean you'd get a little extra performance out of any app that was previously maxed (provided it wasn't forced onto the wrong core), because instead of peaking at 85% it can now peak at 100% (with total system load now 115%). It seems 'by accident' (not by design or development) that DCS is able to use some extra available processing from a second core - due to things like Distiler suggests - but not enough to max out 200%+ of CPU load to make more cores worthwhile at this time. I do not have a quad core myself at the moment I could try DCS:BS on, so that isn't proven by me, but it is what I believe to be true. I therefore also believe that if you had a 6 core CPU, that playing DCS would mean 4 of those cores would be doing nothing for you. The fudzilla post you linked explains why, and even suggests that if there is a time to take advantage of more than 4 cores, then wait for the non-extreme edition - you'd have to be using some serious and uncommon engineering/modelling type software to use more for some time. The advice they give there is quite good; gamers should stay away from it for now.

Just having multiple threads doesn't necessarily mean multi-processing of those threads (i.e. different threads across different CPUs) - sorry for not being clearer. My DCS:BS is reporting 14 threads at the moment as it happens, so it isn't strictly 'single threaded', but it may be limited still to only executing one thread at a time even if it can bounce back and forth between them. I take the comment from the producers to mean it would not use multi-processing, at least not by design. Lua (which DCS integrates and uses, and can be extended by users with further scripting,) has the ability to spawn multiple threads itself too, but even that as you'll see mentioned here doesn't necessarily instantly enable it to be effective across multi-processing platforms either:- http://lua-users.org/wiki/ThreadsTutorial I'll concede your comment about the performance benefit of having a 2nd core though :) an unexpected and unplanned benefit it would seem.

Assuming I didn't touch any of the weapon systems, cyclic was 'neutral', power never went higher than automatic, collective was always on the floor, gear is intact and lever never touched... .. is it then known if damage is modelled to the point that if I sufficiently screw up startup/shutdown procedures, that the systems will be affected to the point they can no longer be used? Like complete inability to restart engine 1 no matter how hard I try, yet engine 2 will still start/stop quite happily? (since this seemed to happen to me twice in succession, but only after I'd already landed so not sure if I did engine damage that way, I'm concerned by the coincidence). Or is it just a matter of troubleshooting the cause each time and fixing that? Whilst I was playing around trying to figure it out, I did notice that oil pressure for left engine had dropped below the lower needle point and wondered if that was the cause and/or fixable. If I know it can ultimately be fixed without needing a base replacement / ground crew repair, then I'll happily screw around with it a lot more :D Kind of like a rubiks cube.. I may not know what I'm doing, but I don't fear permanent damage whilst learning how to solve the puzzle. On the other hand, if I can cause permanent damage, I am going to need to get an idea of what to watch for, otherwise I'll waste a lot of time getting nowhere with it. Does that make sense? Insights appreciated, apologies in advance for not fully RTFM yet :P

http://forums.eagle.ru/showpost.php?p=568711&postcount=7 I'm a developer, but I'm not a developer for ED/TFC, but the concept is clear - single threaded apps cannot use more than 1 core worth of power. Apps need to be designed for a multi-threaded environment (with careful marshaling/synchronisation of data so as to not create adverse performance effects through thread deadlocks - this means multiple threads accessing the same data have to be careful about attempting to make changes to that data whilst another thread/core wants to use it) in order to exceed 1 core worth of power. Having 2 cores helps because you can dedicate 100% of a core to DCS whilst the other core handles other tasks (services, drivers, OS, etc.), more than 2 cores does not help, nor would DCS use more than 1 core itself.

Yes, here's a comment :) Have your buddy read up more on CPU Affinity because that's all DCSMax enables*. Summary: affinity helps the OS select WHICH cores an app runs on, not how many cores it can SATURATE. *Edit: To be fair, DCSMax does other things too, but with regards to CPU cores, this is what it did.

This is more like learning to drive a car, you need to be at least a bit hands-on doing it for real to experience it early on (and how things interact around you, like wingmen who have kamikaze tendencies..). Can't just learn to play by chords and scales. Watch all the producer note videos, if you have the DVD, locate the folder there with them on since they're all present in a good quality and you can pause/rewind/etc. easily. They're a great insight. The training missions are OK too, but I didn't labour on them too much and even skipped a couple first pass through (we need to have fun as well as the theory right). Give this a go too, it's a handy walkthrough with some target practice and more thrown in: http://simhq.com/forum/ubbthreads.php/topics/2626185/1.html For myself, I then started a campaign for a few missions to get more of a feel for things in the wild, and got by just with the LWIN + HOME / LWIN + END cheatsheet methods for startup and shutdown. Now I'm going back to some of those original training missions again to refine certain things, learning how to start the beast up properly/manually, things like that. It's not exactly been a textbook approach to learning, but it's been fun and I feel like I'm developing along the way sufficiently which is rewarding by itself. I mostly use the manuals as a reference though some swear by going through it page by page (Strongharm seems to be a good example of that, whilst he hasn't been playing any longer than I, his grasp of the mechanics and methods was higher/faster than mine). I just needed to have a balance to keep me sane, and if I was to start over again, I'd not regret repeating it the same way. I don't think there's any one really right way, it is something you can enjoy at your own pace. Last tip; I'd suggest grabbing the program/mod/addon called Tacview and installing it. Early on there'll be a number of "wtf happened there" moments, and aside from having a track file you can replay, it can sometimes be a clearer set of events seen on a tacview recording -- particularly if you stumbled into the wrong place at the wrong time, I learnt a lot about AA threat capabilities from that (first with lockon, not so much with blackshark, but it works well for both).

They activated mine today too, I only bugged them once about it, so they just don't check/process that mailbox very often. I already had just about everything I needed answered by then though heh.

Default settings with a pro clip (the only things I turned off / changed were the keybindings for pause and precision). I do a quick calibration in the trackir software before each play session too, and make sure I can more or less reach my 6 o'clock without going out of the camera's view in the up/down/left/right positions, so the view in-game doesn't freak out when you reach some of the extents (left and right calibration seem to have a little amount of 'roll' on them near the -180 degree positions but that's ok, probably a defect with my head :D). So my software as it is now is set on Speed 1 and Smooth 10. Those 2nd and 3rd missions are a bit 'wtf happened / am I supposed to do?'. They do seem like extended / advanced versions of 'familiarisation' within battle theatre conditions, so just being along for the ride does seem part of it. I played Lockon for a while without head tracking, but my trackir and blackshark arrived together -- I couldn't imagine playing it without that. Haven't played properly lately though, been goofing around getting the eyecandy on my X52 Pro to function in-game. :joystick:

I'm only a Vista user without 'old' profiles to try and convert or force into the new software; but using new drivers plus new software, does the profile editor seem to 'work'? I mean, are you then able to at least edit/update the profile and save it to .pr0 format without it going (or looking) crazy? Because this is what I expected it to look like: If so it may just be best to redo the profile or ask questions @ www.saitekforum.com (though I must admit it has been challenging just trying to get an account registered and activated there with no reply yet to forum admin emails).

But with 0 time-to-center (as the old trim method has normally)? So no matter where your controls are, the moment you release trim, they are immediately additive to the set position? If so, that would explain a lot for the behaviour I've been getting. I never played BS before 1.0.1(a?c? I forget the current patch level), and have never modified the values in config files, but I have been getting no noticable time to center.

Your reply doesn't appear to be any continuation of the problem that occurred with the DB server that weekend (unless it's recurring, but that isn't clear from your message). I would suggest you use the Payment and Activation forum and create a new thread detailing your issue or contact the appropriate addresses in the sticky.

A bit of reading through these should help, in short, yes you can edit some files to do this, there are some caveats (such as, overlapping radio received from 2 broadcasts at once won't be in sync and will also cross-fade a bit as coverage goes from one to the other). First link is probably the most useful to you: http://forums.eagle.ru/showthread.php?t=47292 http://forums.eagle.ru/showthread.php?t=38558 http://forums.eagle.ru/showthread.php?t=44221

That's very cool. I had wondered if modifications had been made to DCS:BS at all, like in adding the signal flares for example (they seemed in an odd location and capabilities), but there you go.. they're right there in the pictures too.

Only time hover landing has caused any actual damage for me is if I've recently used auto-hover and forgot to turn it off again. I'll end up fighting controls a bit (unknowingly) on the descent, then when I think I'm down and release the controls, the thing flops like a fish and (invariably) inverts itself onto the rotors >< Neglecting to cancel the Alt Hold AP has always seemed to be the bane for me on that - I've since mostly been cured of it through developing better diligence of the systems state before I end up that way, but occasionally I'll still facepalm after a glorious mission ended ingloriously back at the airbase.