topdog

DX9.0c will also be used by a ton of other games as well, so it will find itself in good company and quite a normal thing for almost every games player to be doing :)

A quick google seems to find a common theme there with other Steam 'powered' games (this 'StackHash_b4ee' thing). Further reading: Seems two other trends with this error and module are: 1. It doesn't happen if you launch the game manually, outside of Steam (but you've tried that) 2. It can be cured if you disable the Steam 'ingame overlay' (I guess this is the buddies/chat plugin it provides, I remember it popping up for GTA and such). I don't know where you will find the setting for that though, with respect to BS. Perhaps that 2nd option is something you can still look for and explore.

No luck with windowed mode. Practically identical experience as before, only difference being a loss of framerate whilst playing (which was to be expected). C:\Program Files\Eagle Dynamics\Ka-50\Temp>type DCS-20100808-171501.crash # -------------- 20100808-171501 -------------- C:\Windows\system32\kernel32.dll # E06D7363 at 7763FBAE 01:0003EBAE # # EAX = 0012F688 # EBX = 3F26FA28 # ECX = 00000003 # EDX = 00000000 # ESI = 7C380EDC # EDI = 0012F718 # CS:EIP = 001B:7763FBAE # SS:ESP = 0023:0012F688 EBP = 0012F6D8 # DS = 0023 ES = 0023 FS = 003B GS = 0000 # Flags = 00000216 C:\Program Files\Eagle Dynamics\Ka-50\Temp> Further tests I intend to do (try and build a fuller picture and/or narrow scope of problems), but otherwise at a loss for the moment: - go back to some single-player playing and see what it's like - do some multiplayer fc2 on same server and see what it's like

I can give that a go easily enough, but I'm experiencing no overheating or graphic artifacts during play (or crash). Thanks Hower. I just had another crash (and another last night, 2 different maps, and not many players on right now, about 12-14), and had plenty of memory headroom at the start and at the point of crash, didn't appear to leak. Here's a summary so far. - OS is patched up - over 15GB free space - last defragged on wednesday (scheduled weekly) - no mods - no antivirus / crash guard type software currently, uninstalled avg9 about a week ago (was crashing before and after this and wasn't the reason I uninstalled it) - no virtualstore/uac file permission issues - fc2 seemingly runs fine without crashing (though I don't do multiplayer in fc2) - bs 1.0.1c ran fine without crashing (exception: 2 missions known to crash, especially w/nvidia cards, such as night-ops mission with nvg and AA enabled, though again this wasn't multiplayer) - crashes with AA forced on or off - sufficient available memory headroom - not close to hitting 2GB max per process - not due to MP map being played for too long - dxdiag provided - doesn't crash during other games or intensive applications (e.g. dbms, app compiling, 2009 release games) - doesn't matter if DEP is enabled or disabled (either system-wide, or just on simulator.exe) - system heat stable, not overclocked anywhere (not on ram, cpu, graphics) - 195.62 and 258.96 nvidia drivers both tried - bluetooth stack uninstalled upon request - game reinstalled from request (english dvd + md5 checked 1.0.2 patch english patch file) - had to remove HKLM\SOFTWARE\Eagle Dynamics\BlackShark\PatchVersion before it would install because it said I had 1.0.2 already Most recent: The second you see the CPU usage nosedive is the point in time of the crash occurring. C:\Program Files\Eagle Dynamics\Ka-50\Temp>type DCS-20100808-144642.crash # -------------- 20100808-144642 -------------- C:\Windows\system32\kernel32.dll # E06D7363 at 7763FBAE 01:0003EBAE # # EAX = 0012F620 # EBX = 75952AA0 # ECX = 00000003 # EDX = 00000000 # ESI = 7C380EDC # EDI = 0012F6B0 # CS:EIP = 001B:7763FBAE # SS:ESP = 0023:0012F620 EBP = 0012F670 # DS = 0023 ES = 0023 FS = 003B GS = 0000 # Flags = 00000212 E06D7363, I am lead to understand, is an exception message from the MSVC runtime when a 'throw' occurs to give the app/developers a chance to deal with it. The latter 3 bytes '6D7363' are 'msc' in ascii, which is a code they use to signal this. Next and final test available, not using fullscreen mode.

In single player game, with nvidia cards, the best way to avoid/reduce this from happening is to disable anti-aliasing for simulator.exe (make sure it's not just doing it for launcher.exe). It won't stop all of the instances, but it will help with the most common ones. Chance of this occurring increases significantly in the night missions.

I created a Master Arm macro in SST (which is just the alt+w keypress) and if you look where I assigned it in this image, the behaviour is that when I go into Mode1 it will press it, and when I leave it, it will press it. Be sure that Mode2 and Mode3 are set to Unprogrammed in the same slot, you don't want it set to Fallback. That works OK as a toggle but it means you should always go to Mode2 or Mode3 before you start a mission or fly a craft in multiplayer. Though if you do, it's no big deal, just toggle master arm manually once, and then the mode wheel will take care of it again from there. It's a little more awkward if you use more than 3 modes (with the extra shift-states, like pinky trigger), but if you just use and define only the 3 and get rid of the rest, it works a treat. I had the same philosophy in naming and using my modes based on the hostility of their LED colours too :)

PSUs in general will become less efficient (typically also outputting more heat in the process) as time goes on. The components will eventually burn and the fans associated with them will also become impaired through use/time. Higher rating AND better quality PSUs (needs both really to qualify) can be worth purchasing to put this off for as long as possible. This can lead to system performance problems, but you wouldn't normally expect this to be a concern or need upgrading of the machine is relatively new (if less than 18 months old I wouldn't even normally start to suspect PSU as a culprit unless you get freak crashes and the like). P.s. Had a 600W Seasonic in mine when I bought it 3 years ago and it has been fantastic. Might not be enough for a juicy, overclocked, machine with multiple heavy graphics cards but for a single card system it's awesome and I'd get another.

4GB physical, but as you'll see in the dxdiag it equates to 2.8GB available for OS and apps (32-bit OS, subtract 512 for OS hardware address range mapping, and subtract 768 for graphics RAM address range mapping). Sucks to lose that much I know, but at the time Vista 64 was untested and drivers were especially bad, so it was common sense to stick with 32-bit even with that much RAM. The other tests (reinstalling, for which I'll need to make some room first, and monitoring memory usage for leaks) will take some time so might be a weekend job before I get back to the thread on those. I will remind you though that tacview only puts 1 line into export.lua and then references it's own .lua for everything else, and in my own hand-written modding I followed the same style, so uninstalling mods was fairly simple and complete to do. I haven't screwed around with additional models, skins, or changing of game file parameters, with one other exception and that was adding my own 'radio maykop' beacon up the top of a mountain. I'll check to make sure that's gone too but I believe it was overwritten in the patch anyway, and it'll be extra moot when I do the reinstall tests this weekend. By the way; if I move my current install and try to reinstall in-place to my main location, do you happen to know how that might behave with respect to activations, and should I do anything else first like deactivate or not need to bother with that? It's not a big concern anyway, just curious to know what I should expect. Thanks. DxDiag.txt

Appearances can be deceiving though, so be certain:

Ok, interesting development after uninstalling the bluetooth stack. What I was getting before (consistently) were 2 concurrent crashes (and windows dialogs to match them) when my game ended. One was always the btmmhook.dll, and the other was just 'some random DCS module' (edcore, mitkagraphics, etc.). Now I just get the random module one when it crashes alone now. So, a worthy test to do, but looks like a it was just a victim rather than the cause this time around. I also confirmed the complete removal of the bluetooth stack drivers from my system, btmmhook.dll which was in my %windir%\system32 was gone after the uninstall and reboot that it requested. I didn't pay attention to memory at this time, I was just content to fly after the uninstall without paying too close attention to things, to see if I would encounter the problem. It was again after about 2-3 hours of flying, which fits into my normal yet somewhat random timeframes to get it. After the crash I popped into my temp directory and did "dir /od" to locate the newest files, the reason for the time lag between the .crash file and the others is simply because I was still talking to 2 other pilots in my flight group to let them know what's up :( C'est la vie. ... 04/08/2010 08:20 PM <DIR> .. 04/08/2010 08:20 PM <DIR> . 04/08/2010 08:20 PM 398 DCS-20100804-192038.crash 04/08/2010 08:23 PM 162,967 Error.log 04/08/2010 08:23 PM 767,823 debrief.log 04/08/2010 08:23 PM 146,001 obj_arrays.log 04/08/2010 08:23 PM 76,390,400 ~tr48AB.tmp 04/08/2010 08:23 PM 219,500,544 ~tr48AA.tmp 274 File(s) 1,394,074,091 bytes 3 Dir(s) 5,916,504,064 bytes free C:\Program Files\Eagle Dynamics\Ka-50\Temp>type DCS-20100804-192038.crash # -------------- 20100804-192038 -------------- C:\Program Files\Eagle Dynamics\Ka-50\bin\x86\stable\edCore.dll # C0000005 ACCESS_VIOLATION at 0027169F 01:0001069F # # EAX = 00000000 # EBX = 03C9AE24 # ECX = 00000000 # EDX = 101E0B08 # ESI = 0027D380 # EDI = 3D62241C # CS:EIP = 001B:0027169F # SS:ESP = 0023:3E75F26C EBP = FFFFFFF2 # DS = 0023 ES = 0023 FS = 003B GS = 0000 # Flags = 00010246 C:\Program Files\Eagle Dynamics\Ka-50\Temp> From the Problem Reports applet (more or less the same thing): I was just moseying down towards a waypoint at a reasonable sub-140k's cruise, nothing engaged me or shot me down (one of my flight group was slightly behind me and had visual). Edit: P.s. Program Files / Virtualstore isn't the problem..... :)

I've been flying online in formation with other choppers at the time I crashed, so I wasn't shot down or under attack, it would have been seen and they would have been next. I haven't been able to identify yet anything common about the occurrences; they're all inside the chopper (since external views are disabled), they're during daytime conditions (no ghost of NVG/AA pasts), and the only graphics anomaly that seems new to me but I think has been dsicussed elsewhere on the forums is the issues with the water and coastline - it looks like the land is floating above the water surface and there's no coast effects, but I have crashed when no water is visible (even though we all know the water runs right through and under the earth). So no luck on a commonality there, but I haven't yet done the memory monitoring or disabling of BT stack (I'm still at work currently) so I'll still be able to give those a shot. Sound in my system is pretty good (compatibility wise, technically it's just a soundblaster x-fi gamer, basic, but is robust and does the job), and the only sound issues I ran into somewhat recently were resolved with c0ff's help for FC2, which was more a case of either having sound or none at all, but no crashes. That and the mysterious engine 2 vs. engine 1 startup issue, which isn't really significant and everyone gets that anyway.

I think I know why; on startup BS iterates over a number of potentially available input devices (even if you don't have one, it looks specifically for trackir, for x52pro, etc.). So it's loaded simply because it's looking for (bluetooth or other) mice/keyboard inputs I guess. The stack does monitor keyboard inputs even from non-bluetooth devices (provides on-screen overlays for when capslock, etc., is pressed), but that shouldn't be directly accessible from BS as it's out-of-process. But just to indicate how it can be relevant to input device drivers that a game would use. I don't really use the bluetooth stack anymore on that machine so I'll uninstall it too, see if that helps or just deflects the failing module to another. Cheers.

Flaps / brakes / gear (as toggles) are all things I put on the toggle switches on the base of the stick. Usually it's like down for wheel brake, up for air brake, down for gear change, up for flaps change, etc. For the same reason mentioned, that you can often use these things in non-critical hands-off situations (or at least, infrequently enough to be off the direct fingertips, but not too far out of reach as to be still left on the keyboard itself). I also use the Modes for switching between 'weapons hot' (red) mode and 'nav' (blue) mode. Purple mode is my hybrid awareness settings in the middle that mix the two, so off hand and away from the stick I can't quite remember but I think I only have some of them active for these functions in Nav mode (no need to fiddle with gears when in a firefight).

32-bit processes can't consume much more than this amount anyway (the 2GB per process is a theoretical maximum, reality is that the amount is usually less) but even if it is a memory issue, it shouldn't (be designed to) just dump out on you like that as an unhandled exception. That's just not how memory management is to be done in the event of a *alloc() being unable to satisfy the request, so would be a bug. I expect they are somewhat related, and I have seen those other threads including yours. In case there are different causes or a solution for one doesn't work for another, each instance needs reporting as a separate thread though really. It was odd in my case that it so frequently would bomb on that module in particular compared to others. I'll look for memory leak type behaviours next time I play though, I appreciate the tip, and it may be something that can be tuned better in my configuration to reduce the load to make more room for the MP fluff in memory so I'll give it a try, thanks.

Virtual store not in use; the game is installed to a location with full current user permissions. No overclocking of cpu/ram/graphics in use. Typically I would measure my system uptime as 'weeks' and would be 'months' except for necessary reboots due to OS patches requiring it. Game is played full screen in a single monitor (though I do have 2 attached to the machine, fullscreen option is still enabled for just primary monitor when playing the game). I've seen others with the protect.dll errors being reported but as far as I recall, not one time has it been that module for me.

I get this after every couple of hours on average (but not every couple of hours mind you, it's still fairly erratic and out of the blue without warning). I searched forums for the initial .dll reporting the problems (btmmhook.dll) and found no references (oddly I thought). So here goes.. Patched to 1.0.2, removed all mods (so as to be integrity check compatible, though the only mods I ever had before were my own export.lua's for x52 pro shenanigans, and tacview). Vista 32-bit, but don't let that freak you out ;) One common theme is that it's always 2 crashes in series, though I guess that matters not in the grand scheme. Copy/pasting the gubbins inside each of the windows that pop up, it has this to say. The first item is always the same, the second item is sometimes this .dll, sometimes kernel32.dll: I never played MP before so can't say for sure if this is patch related or not, previously in SP I would typically only crash due to anti-alias (which is off) and/or NVG hangs. As was recently asked, I used to run only firewall / windows defender for protection (seeing as I never got infected anyway, I run a tight network) but did install AVG9 about a month ago for kicks, de-installed it 24 hours ago due to performance impacts and incompatibilities with IE8. The BS MP crashes occurred both before and after I de-installed AVG9. Latest .crash file contained this, but I have about 6-7 others if interested (haven't started to look in them yet even, just let them build up :)). Ok.. I guess that will get us started, will add more if I remember/find it :)

The speed of the bullet would be relative to the speed and angle of the gun it is fired from (clarification: to anybody except the shooter), so firing ahead would increase the speed of the bullet (it would already be going as fast as the jet, now it's propelled and will travel faster), firing behind would decrease it and the bullet would appear to be travelling slower than normal. Though - turbulence/friction/other matters aside - if fired from the front and the back simultaneously, both bullets would pretty much be moving away from the jet at equal rates from the point of view of the jet/shooter. Firing from some angle at the sides would be the equivalent to firing it whilst stationary.

When I was referring to SEAD, it's a task assigned to some other flights (like the Tornados) in your mission to help you -- so don't get in front of them, but if they get shot down, then sometimes I'd "cheat" by pretending to finish their task since the AI can be manipulated a bit. Been a while since I flew the A10 (campaign) now, but from what I remember.. Flying low, 2000-4000, is good generally for winging through the waypoints to get to your target areas, it'll help avoid some large SAM sites to your sides due to terrain mask effects (as will staying on the waypoint path and not drifting off it as sometimes they're tight with danger on both sides). When actually at the fight area I would survey at 8000-12000 so that if shot at unexpectedly, I could turn-dive-turn-climb to evade. You need height on your side to do that and since the A10 isn't all that fast, if you have to do it a couple of times quickly, you don't want to be too near to the ground else it starts to take your evasive options away. Around 9000-8000 or so down to 4000 on a run was good for releasing ordnance. Whether evading or going in for a run, it was common to climb back out to a decent altitude (8000+) again shortly after. All varies a bit depending on the exact targets you face and what ordnance you have remaining to deal with them, but it was usually around these kind of starting values.

Warthog HOTAS looks capable enough to use elsewhere; some of the system lights won't work or seem right, but that's no different to the X52 Pro's MFD/LED setups (generally) not working out of the box either. However.. it's not here yet, and you could probably get all those other things you mentioned and have cash to spare for replacements for the next few years, for the same cost, so I agree with your sentiments/direction. I just wouldn't write it off as a one-trick pony :) They say the stick and throttle are basically borrowed from other craft anyway, so they can't be too A10 specific.

Apart from taxi to park, wheel brakes on, engines shutdown, canopy open, there's not much else to really do (turn lighting off..) in Lockon. The detailed startup/shutdown procedures applying to Blackshark is what will be added to other 'DCS module' craft like the A10C. Wags' most recent producer notes show how different this can be when that module is released compared to what you are used to now: Until then things are a lot simpler for the fixed wings.

Demonstration of playing back an ACMI recording in Tacview. I picked an old mission of mine at random here. Pay no attention to the fact I'm in the middle of it all and inside the SAM's firing ranges far earlier than I should be :D Here I should have let SEAD do its job before I flew in. This itself can be a problem, if you fly at max speed through your waypoints too fast without paying attention to what other units in your mission need to accomplish. But you can also see the risks they take (look at where the tornados are flying to launch their missiles from, could they pick a more life-threatening launch position?) and why they sometimes needlessly fail in their job. Now without the radar helping them, the SA-13's on its own as a significantly decreased threat - even if in this flight I'm still ridiculously deep into his firing range because he's too busy at the moment swatting the tornados to pay attention to me :D Hindsight is 20/20.. :D

15000 - if you imagine the SAM engagement range to be a sphere (actually a hemi-sphere since they can't shoot through/under ground) you'll see they have less coverage and range to get you the higher from them you are. At this height pretty much all ground defenses are reduced to very limited threat capabililities. Thus allowing you to get closer to their engagement range, create some tease opportunities for them to give away their positions firing at you even, whilst you still have some wiggle room to fly out from with more comfort, and so on. At least this was the way in FC1, if you went high enough, you could even 'loft bomb' right over the top of them whilst being out of range of their missiles, but this isn't much challenge (I only used to do this if SEAD abysmally failed and I was too lazy to fly back, land, and restart mission, to finish their job for them before getting on with mine). Take a look for a program called Tacview (search the forums here) that can help show you after your flight a better picture of the overall threats (perceived and real), though if you want to do multiplayer/online flying you'll need to know how to enable/disable it as it makes some changes to configuration files that are disallowed in many online servers. You'll also find sometimes that the perceived threat of someone firing on you can more easily be taken out or dumbed down a lot, if you can identify the radars that are feeding them with intel on you that may not have any firing capabilities of their own. So the real threat to you (and to be taken out, probably at your longer range of attack) is the non-firing radar. Then you can get in closer and more personal with some of the others.

I still find it a little hard adjusting to the green/orange laserbeams in the middle of the day that firefights create (in addition to the fireworks display of the ground ricochets). I saw the joint fire tactics video of TBS on youtube and it didn't seem to have this effect in it; the avenger cannon fired without any stream of tracer type rounds in it. Not sure if that's part of a change/improvement we'll see in DCS:A10C of the graphics in general (there are some clear lighting improvements in the producer note videos) or if that was requested of them by contract or similar. It seemed more natural of live engagements that have been recorded of A10 flights though so I'm hoping it'll come.

Regarding neck pains, I experience this also and it's a kind of straining of the neck brought about by you positioning your head/neck in a way that becomes uncomfortable after a long period of time there. Essentially it's not just a matter of training your body to get used to it, but also training your routine to reset your posture every 20-30 minutes or so. Forget the centering/positioning in-game (which is what leads you to crook your head/neck and hold it unnaturally and eventual pain) and use the Reset button of the TrackIR to re-baseline the camera with your normal and natural posture. You'll be surprised I think at what adjustments your head/neck/spine makes to maintain a particular view in-game in what it thinks/believes is normal. After a quick reset it's noticably more comfortable. Thus the Center hotkey of the trackir is the only function of the device that I enable (plus it helps if you accidentally knock or displace the position anytime in-game without having to go back out to fix). If you leave or ignore it, the pains can set in quite severely and add lasting headaches to the mix as well. I can get this with any game playing to be fair, but nowhere near as quickly as when using head tracking. Though admittedly I do routinely abuse all other forms of RSI and posture advice when it comes to using computers and taking breaks. This one I can't neglect though as it's genuinely painful. P.s. I recall when I first starting to ride motorcycles that the weight of the helmet does take some time for your head/neck to adjust to before it doesn't feel like a burden - not just the time for the inner foam to shape/mold around your skull - so wearing headphones and/or head tracking clips (light as they are) for long periods could have a similar effect that you do need to get used to, but that's not the cause of the severe pains that people can get.

I suppose there's always the hat clip-on for a wireless solution that never needs charging or replacement batteries ;)