topdog

Didn't know you had plans on targetting for DX11. Nice, I wonder what benefits you'll end up being able to take from that in time (specifically in the areas of say, long distance tesselation, to get high-detail long-distance terrain in real time at the GPU's expense, or similar -- not just lighting tricks or something :)). If that's too adventurous for your current release schedule plans, I suppose things like that can always be a future possibility. Been waiting for the next note in ernest too but I'll take these screenies! Cheers :beer: Edit: Btw, not to mean that what we've seen is lacking, just mostly I see DX11 features touted for tesselation of close-up surfaces, only once did I see/read about a long-distance improvement for the image quality, here incidentally, check out the terrain demonstration: http://www.guru3d.com/article/geforce-gtx-460-review/10

I did wonder how well such a setup could work whilst also using TrackIR, I thought they'd more than likely be mutually exclusive devices. Especially the advances in 3D that are going glass-less anyway, since they are depending on being able to project different screens to different eyeballs so angles and distance between eyes is important. We'll have to see, ultimately if I'm still alive in the future to be able to choose between full 3d holographic cockpit or a jack in the head, I'll probably volunteer for the jack. That's what I'm holding on for :)

Adjusts your throttle automatically to maintain your current speed setting (when you enabled it), even when speed increases or bleeds off due to changes from manouvering.

Stop the press! I am, if nothing else, horribly tenacious. If you're willing to try one last thing, you can give v2 retro hack a spin, which for me at least is showing green nvg's in both simulation and game modes, and if the file I've created is to be believed, using only pixelshader version 2.0 which your card claims to support. This uses the 1.0.2 blackshark vertexshader file supplied by ED too instead of a hacked one, so with this version of my retro-hack only one of the two files is changing, but I've provided them both in the zip to make it easy to just copy them in and replace what you're using now. I hope this one works for you, my card will handle above PS2.0 so I can't be entirely sure myself but I expect it to behave. Here's the actual changes highlighted for anyone curious: ps.[color=red]2[/color].0 def c0, 0.1, 10.0, 0.0, 10.0 def c1, 0.3, 0.59, 0.01, 1.0 def c3, 6.0, 11.0, 6.0, 1.0 [color=red]dcl t0.xyzw ;_texcoord0 t0 ;tex coord[/color] dcl_2d s0 ;diffuse map dcl_2d s1 ;noise mask dcl_2d s2 ;main mask dcl_2d s3 ;mask (HZ nahua nuzhna) ;sample maps texld r0, [color=red]t0[/color], s0 mov r5, r0 texld r1, [color=red]t0[/color], s2 texld r2, [color=red]t0[/color], s3 ;generate tc & sample noise mask mul r3, [color=red]t0[/color], c0.w texld r4, r3, s1 dp3 r0, r0, c1 mul r0, r0, c2.y mul r2, r0, r4 add r0, r2, r0 mul r0, r0, c3 lrp r0, r1, r0, r5 mov oC0, r0 I'll keep my fingers crossed for you, but remember, if this doesn't work you really are going to be back to the 2 options I outlined in the last post of mine. The pic just shows the nvg off (left) and on (right) with this change in place, in game-mode. I checked it in simulation-mode too, was ok there too. nvg_retro-hack_v2.zip

I took a look and I see the problem in game mode, that doesn't seem to want to play ball at all. The black area you see is coming from the graphic file focus_2.bmp, which acts as a 'mask' (it identifies the area the NVG green display routine is meant to be applied to). Since it's not running it, it's just displayed as-is which is mostly black. I've tested inverting it, but changing that file won't bring the code into working. I'm not a shader developer myself, but it looks like further tweaking would require the shader code to be rewritten (the text from the files I posted in code blocks above are assembly language codes for shaders, these are almost machine level instructions before they become unreadable to humans). So to get to a summary and a solution that works with game mode as well for you, I think you're down to 2 final options I'm afraid: 1) Use 1.0.1c for single player, and 1.0.2 just for multiplayer / non-game mode.. you would lose some of the new features as a result of this, but some of those aren't working for you anyway, it's a trade-off. 2) Upgrade the graphics card (though judging by your other thread, it may need to be more than just the card). You need one that is at fully DirectX 9.0c compatible as in the chart I linked to, to be sure of running all the graphics correctly. Again, I'm unsure, but would expect at least the same requirements would be forthcoming in DCS:A-10C too. Since the game's minimum specs require DX9.0 compatible graphics, it's unlikely to be accepted by ED as a bug in the new patch. It doesn't mean it can't be fixed (it used to work before anyway I presume, and if someone knows shader coding enough it could be modified), just that the game isn't now requiring different hardware than was already listed so isn't a fault per se.

They've crammed more onto that with their short/long presses than I dare cram onto my X52 usually.. going to be a challenge getting my head around all that in the middle of flight for sure :)

I recently moved my 1.0.2 install to a different folder name then just re-installed the game to the location I used originally, and no issues with activations/deactivations occurred (as EtherealN advised me it wouldn't). Incidentally the reason I did that had nothing to do with AI and I patched back up to 1.0.2 again, it was just to test a fault I was/am having with the game crashing to desktop. I'm only really playing multiplayer or self-training stuff at the moment.

bigdog4215's capturing of the error message before clearing out the temp folder was key. I don't know a good deal about about D3D programming but I took a guess that the error message meant it had bumped into something advanced it didn't know about. No problem, would be good if you can confirm if it works for you or not, as I'm sure you won't be the only one that finds themselves affected by it. To its credit, BlackShark doesn't just flip out and crash to desktop when this problem occurs but gracefully carries on, and on the other hand, a change in API version requirements would now mean that graphics cards that previously just had the sufficient raw power to play the game may now lack on the features front (this would probably become even more apparent by DCS:A-10C too, as I'm sure the lighting improvements I saw in the videos are going to mean the use of more modern shader tech). Not everyone affected by this in blackshark may even know it yet though, as night missions are generally few and far between.

You probably have them already anyway, they're in the ka-50\backup folder under the same bazar\effects\postmotioneffect\nightvisiongoogle path as the new ones are. Replace the new ones with the backups. I'll attach them here too, that's no problem. nvg_retro-hack.zip

I've been cheating and basically marking up all my targets/points of interest using the datalink, then I set each one in turn to my ingress datalink point, which the shkval zooms to when you uncage it. Obviously this hampers the use of the ingress point for its actual intended purpose, but when I need a quick solution it has sufficed.

By the way, I did some digging around of your posts, and I think this settles it: On the chart I mentioned before, that only covers up to PixelShader version 2.0. So until you do upgrade your graphics, try my retro-hack in the previous post; I'm sorry I have no idea how to turn the greyscale back into a greenscale though, or fixing other anomalies it may display.

You can also go back to 1.0.1's versions of these files which used PixelShader version 1.1 instead. I just tried it out to make sure it wouldn't just completely freak out, and it works, albeit not as it should / used to. I'll update with screenshots added in a bit once I've re-processed their sizes to demonstrate, but the files would be changed to have their contents completely replaced with this: nv_p.dat: ps.1.1 tex t0 ;main tex t1 ;noise tex t2 ;main mask tex t3 ;display mask dp3_x2 r0, t0, c3 dp3 r0, r0, c0 mul r1, t1, r0 add r0, r1, r0 add r0, r0, c4 mul r0, r0, t2 mul r1, t0, t3 add r0, r0, r1 ;mov r0, t0 nv_v.dat: vs.1.1 dcl_position v0 dcl_texcoord v7 def c7, 1.0, 4.0, 8.0, 12.0 mov r1, v7 mul r1, r1, c7.w mov oT0, v7 add oT1.x, r1.x, c5.x mov oT1.y, r1.y mov oT2, v7 mov oT3, v7 mov oPos, v0 This is essentially a change to the 'code' and as such, carries some risk. It may not work, it may crash and die horribly, and it certainly hasn't undergone anything of a real test and wouldn't be supported by ED. However if you do have a graphics card limitation as a result of the patch, maybe it will help tide you over until you can upgrade. Good luck. P.s. The right-side of each image is using the unsupported retro-hack. Obviously not preferred to use unless absolutely necessary, and at the least should be able to help prove where your issues are.

If re-installing the latest graphics drivers didn't help, you could try re-installing DirectX 9.0c (specifically the 'c' version). This is the only version from when PixelShader version 3.0 came into effect. If it still doesn't work, it may be that your card doesn't support this combination fully. Refer to the Hardware chart against the PS 3.0 / D3D 9.0c row, compared to the row that your graphics card vendor/model exists in: http://en.wikipedia.org/wiki/Pixel_shader

In 5 years we could easily be sporting 50TB+ disks. /tangent on It's the way storage has trended ever since hard disks started racing off.. whether it's MB or GB or TB it starts out in small numbers but follows the same sort of patterns.. 0.5 or 1 to 2 to get going with... then it starts doubling a little and you get your 4s and 8s, then everyone (vendor) goes nuts and you get your 10's 20's 32's and 50's, before you know it it's in the 100+ range and getting ready to switch to the new denomination to start all over again. Personally I'm looking forward to it, but not as much as I'm looking forward to magnetic racetrack technology being commercialised which offers a quantum leap in personal storage shifts: http://www.almaden.ibm.com/spinaps/research/sd/?racetrack (As can be typical with IBM, they research brilliant designs, sit on them for 1-2 decades, then someone else comes along and produces marketable versions of it for them that then become popular..). /tangent off Personally I wouldn't be too troubled about storage escalation. The device capacity also goes up by an order of magnitude or more frequently enough to keep up. What does become difficult is effectively backing it all up!

You posted a track before didn't you? And someone else commented in playing (and taking control of that track) that the NVGs were already installed and available immediately (defacto night mission configuration)? That being the case, I'm suspecting the night vision goggles are actually 'there' and you have some graphic condition preventing their display, since other than the light diffusing overlay on the screen you'd otherwise not know they were active (no other visual indicators bar the switch itself). I've used NVG in 1.0.2 fine when playing online, haven't tried single player, in a mission that just took so darn long that it went from day to night so on my refuel/rearm run I also switched helmets, and that was working fine. However in your situation, I'd look for errors in the black shark \temp folder log files, looking for other graphics driver versions to use if you can get your hands on them, and your graphics settings to see if you can reset to defaults if you've been playing at all with the its 3d display settings.

Ponder that for long enough, and by the time you have an answer you'll no longer be able to tell the difference anyway :)

There are a few things I would think to check if this was happening with (games) software on my machine. #1 The directory you installed blackshark to, has a temp directory (e.g. C:\Program Files\Eagle Dynamics\Ka-50\Temp). Where did you install the game to exactly, and does your game's temp directory contain any files at all? If so, would you mind listing them or attaching any of the text log files it has created there? #2 Have you ever specifically installed DirectX9 runtimes, or just gone with the DirectX (10) installed on your Vista system? You should at least one time install DirectX 9.0c runtimes for Vista, you can do so directly from a quick search at microsoft.com. You'll still have 10 as well, it's in addition to what you have, and not a downgrade at all. #3 Have you tried right-clicking the shortcut for the game and choosing "Run As Administrator" if it is available in the pop-up menu? #4 And the last thing I would think to check for now, if this was my system, is whether you're running from the shortcuts that the game created for you, or if you went and created your own to use? The ones provided have additional parameters on the command line. Slight but significant. The Testers here may have more specific knowledge of the problems that would occur with the above, so they may have already been able to logically rule some out, but for peace of mind I would check these if you find you need to.

I have enough respect for the virtual aerobatic display teams to understand flying a fighter-type jet in a non-combat situation/application, but it's a niche and won't appeal to everyone. I'm surprised this wasn't mentioned though (or my speed reading overlooked it).

Would this explain why when I'm trying to fly straight and level, my cyclic is always banked a few degrees to the left (and I tend to fly in a slight slip) whilst rudders are centered? I did mean to figure out the reason for it as I couldn't be entirely sure it wasn't just me flying with a wonky controller. So I'm not sure I understood the normal tendency of the craft, whether you have to correct it by banking right (as I read it), or if it banks right by itself and you (optionally) correct it with counter-banking left.

I may have missed something in 1.0.2 FC compatibility patch (I haven't really read the fine print of it), but in 1.0.1c whilst the affinity is set for you to automatically use ANY core, it doesn't necessarily make use of both. There were some DX improvements for Vista / Win7 that meant some of the burden could be placed onto a different core than the one the game is running on; this is the reason for those users getting a sudden performance boost (as it is leaving more CPU cycles free on _the core_ that BS is using) and it occurs just by switching OS. So in summary: in XP you may benefit from telling BS to run the least-loaded core specifically, but it will still be sharing some of the cycles on that core with DX code that could have been offloaded to another one if using win7/vista. I'd turn off those immortal/fuel/ammo things. If nothing else, the loaded weight of the heli affects its performance. If you turn them off, take off and fly around a little, then jettison all your weapons, and fly some more, you'll feel it is a lot more bouyant than before. You can often land and refuel at a nearby farp/airport if absolutely needed mid-mission, and some of the campaign missions are fun in that it can be a challenge to get back home whilst 'running on fumes' not being sure if you're going to make it or not. The only 'immortal' setting I turned on, was for my pilot's logbook, because it was a pain to have to keep recreating it and starting over for reasons not of my fault :)

I reinstalled from DVD last weekend to perform some tests; I use on realistic/sim mode settings, but once in the game and configuring it I had to specifically set them again as some game mode options were still enabled (I didn't really pay much attention as to what it was exactly that was enabled and just reconfigured as per my old install). I also made/make sure to set the 'use this in all missions' option on the same screen, otherwise some standalone missions can override it on you unexpectedly too (including the missions you make in the editor yourself).

Just to clarify; systems will often have a couple of debug directx dll's alongside all the retail ones. The "(problems)" are related to the warning it gives on the relevant page of the dxdiag app, which you have described adequately above, but probably isn't actually in use. To be using it, you would have to do have done the following: 1. Have installed the DirectX SDK 2. Used the DirectX Control Panel app (which isn't actually IN the Windows control panel, that's just what it is called and would be found off your DXSDK start menu, aka dxcpl.exe) 3. In here, specifically selected to "Use Debug Version of Direct3D 9" on the D3D9 tab and applied it. You would also be able to see this option if enabled under HKLM\SOFTWARE\Microsoft\Direct3D\LoadDebugRuntime with a value of '1'. If it has a value of '0' then you're using the retail .dll's anyway. So just the sight of this .dll being reported in the dxdiag is fine, it will do that just from detecting that it exists, and isn't an indication that it is currently being used unless you verify by these other means. You shouldn't play with it or remove it if the above registry key doesn't exist or has a value of 0 since those files will be completely harmless to your performance.

So far, no crashing in single player mode (was just doing the Quick Mission and flying around for an hour+). I did crash it once in local server multiplayer mode, on the same map that I crash on on 104th as a few copies got left behind in my temp folder after the crashes, and ended up with a similar but not quite identical .crash dump file. The odd thing about these tests is that my memory usage with this mission on 104th is ~1250MB to 1450MB. When playing the same map in multiplayer locally it is consuming ~1350 to 1550MB. When playing the Quick Mission it's ~1500 to 1600MB used. So it's not even memory accumulation or a 'leak' of memory not being deallocated causing it. Still testing I guess, as it takes time to build up the results, but wishing there was something better for debugging built in I could enable, to capture what's needed to identify the cause, as it's a royal pain. My online experience is akin to spending 30 mins flying farp to airfield, get shot down, flying farp to airfield, crash to desktop, then flying farp to airfield again... one hour 30 mins later, I get to fire my first shots, the team on the other side have already claimed their airport and are cleaning up the WP groups, and I'm about to start throwing heavy objects around the room :)

It's not really designed for grass landings (it can't pickup or ferry anybody, other than an emergency where you're going to be walking or waiting thereafter there's no need to even try), and the game certainly isn't. It can be done but the geometry in that part of the landscape doesn't seem so pristine.. then again I doubt for real it would be so perfectly flat as it appears anyway. If you get any of those back-flipping moments when landing on the farp or airports that would almost certainly be due to forgetting to turn off auto-hover and/or alt hold AP. Do you put the controls overlay box on your screen? The one in the bottom left corner with a press of right-ctrl + enter? If you're floating out of autohover it would seem probable that whilst you might momentarily be manually hovering, if the controls are set to allow you to drift then you can still drift even with autohover on. I can also suggest that if you load up and view someone else's posted tracks to see how they do things, pulling up this box (if they don't do it for you as part of their own flying) will help you to 'see' what they're doing with the controls that are often out of sight. One thing that I'm reminded of - if you have extra controllers plugged in during your flight (even if not in use, like steering wheel or another stick, etc.), they might be interfering too and you could try disconnecting them. A lot of us are taking off, landing, and using autohover several times of every day in black shark - it can be done, but figuring out what you could be doing wrong is going to take some head scratching, the sim isn't designed in its 'real mode' to be forgiving in any way. And another thing that comes to mind; check and make sure there's no usage or overlap in the control configuration with the Trim Reset function and those events where you're nosing up and backflipping unexpectedly. Trim Reset is generally best reserved for when you're on the ground, you wouldn't make common use of it (if at all) whilst up in the air. Last but not least; instead of just describing the things you're having difficulty with, take or make the track file that was created to demonstrate the fault and post that with it. I know you've posted track files in another thread already, but if you can, do it for each bizarre control gripe you come across as there's likely to be an easy explanation when it can be actually replayed to be seen.

Real mode quick start (assuming you meant left-win + home) does enable those 3 AP channels; but your inputs during this time can interfere with the startup sequence since it basically simulates a series of keypresses itself in a macro. Remember not to engage auto-hover too low (or leave it on when descending too low) as that will start turning off and freaking out the AP channel buttons too. Hopefully none of your problems have been caused by editing of .lua files. There's nothing wrong with editing them, just a mistake can cause for some ugly and difficult to trace issues.