topdog

The bump also occurs as soon as you press (not release) the trim, so it's definitely the disengaging of the authority, it's like letting go of a stretched elastic band that were holding the controls back from exercising their full output. With heading hold on, it also means if you trim whilst turning that the elastic band will instantly reappear again too. When flying a circle with heading hold enabled, half the circle is flown with the heli's nose inside the circle, and half the time it's flying with its nose outside the circle, all the while trying to pull itself back on course. It's a rare time that the nose is actually following the circle and you're flying the course 'straight' without input from the AP. Tacview shows this quite well, but you notice it if you fly the circle without tacview because during the transition from nose-inward to nose-outward and vice versa, there's a noticable drop in pitch for a short while whilst the craft ceases pulling either side. All in all, it seems better/smoother than the old trimmer method which I'm used to using anyway, since for me that's having no discernable delay allowed to getting the stick centered before it starts adding my input when I release trim (even with the tauinverse delay set). That produces so much bump for me that I don't even really notice the one incurred by the AP disengage :) I will have to try the new method some more.

Motherboard RAM Graphics (items in order of suspected faulty location, assuming that no overclocking is in play and mobo settings/bios are at defaults, as that would definitely be the first item to be culled to ensure you've got a real problem to look at) Suspected cause: Static discharge damage or DOA; maybe that capacitor isn't the only dry solder or the only component that has fallen out.. Typically I resolve(d) such problems with process of elimination hardware swapping; either using bits from an old machine, or plugging bits of the suspected hardware into an old machine where they're compatible (e.g. graphics card is a good candidate for that usually), until the fault is isolated. This was an extremely simple and also cheap procedure to do when I had a friendly rapport with a local independent PC shop, as I'd be able to try some swapping of the RAM and graphics etc. from a running PC on display to find it. Sometimes that was my only route to testing the fault with the MB or RAM if my current personal collection of 'spare parts' doesn't yield a compatible combo to try out. Last thought.. you 'snapped' the capacitor back into place? No re-soldering? So it may not have a permanent or good/strong bond with the circuit, I wonder what vibrations inside the case would do to cause fluctuations in the bond it has, even if using SSDs cuts down on some of that.

It's not actually the same motherboard, but even so, there are positive accounts of it being as good or better than the premium (non -E model) anyway. http://www.overclock.net/intel-motherboards/726295-p6x58d-e-vs-p6x58d-premium.html Look around some more for prices of the -E version though; since it seems to be the 'normal' price difference between the two anyway, you can keep on checking for better deals of it.

It explains the changes in the thread. I have only skimmed a little of it, but one of the first things that stood out is that the team you are flying for in the mission is what dictates the environment (and sounds) you're given to fly in. I.e. It depends on who you're flying FOR, as to who you will be hearing. Whilst you wait for a reply more worthy than mine, you could at least consider looking at the thread and/or giving the mod a try to see if it helps you out. Good luck.

If you mean you're getting Russian audio, that's normal for 1.0.2 I believe, and if you search around these forums a bit more you'll find a mod that has been done to provide English audio options instead. If you're getting Russian symbology inside the helicopter cockpit, you can switch that within the game's Options menu before you start a mission. Edit: Your new post, just before mine, indicates you've been looking for the answers and couldn't find them. I don't use any of the English audio mods myself, but start here which looks to 'fix' Betty for you: http://forums.eagle.ru/showthread.php?t=54051

Why must you toy with me! Seriously, I was just about settled on taking the plunge when suddenly I saw some naysayers mentioning about how the information you get to see is now only half as bright, that it doesn't work well enough, or that the alternating eye flicker sent some users insane. Then there's a post like this, and I'm involuntarily reaching for my debit card again... :D :joystick:

I found a way to force a minimum NVG brightness value that wasn't zero, so that instead of it being completely black (screen 1 problem/concern), you at least get something. The current brightness level of the cockpit dial is held in c2.y (as far as the pixelshader routine is concerned), so when this is 0 and it multiplies the current colour values of the pixel by the brightness amount, and they're all wiped out leaving you with the black masked area. So this is something we can tweak ( / hack) for aesthetic purposes, but how it compares to real ka-50 NVGs when switched on but set to minimum brightness level, I would not know.. maybe someone else who knows could comment on that. In any case if you just decide that you don't like the black oval enough and want to try ensuring a minimum level of brightness that you can still see through a little bit, you can try this in your ka-50\bazar\effects\postmotioneffect\nightvisiongoogle\nv_p.dat file (additions highlighted in bold purple below, there are 4 lines were additions are placed, a new comment line, 2 new code lines, and 1 edited code line below that): ps.3.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 dcl_texcoord0 v0 ;tex coord 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, v0, s0 mov r5, r0 texld r1, v0, s2 texld r2, v0, s3 ;generate tc & sample noise mask mul r3, v0, c0.w texld r4, r3, s1 [b][color=purple]; cap the NVG brightness value from c2.y to minimum value[/color][/b] [b][color=purple]mov r6, c1.z ;borrowing an existing 0.01 value already defined above[/color][/b] [b][color=purple]max r6, r6, c2.y[/color][/b] dp3 r0, r0, c1 mul r0, r0, [b][color=purple]r6 ;[/color][/b]c2.y mul r2, r0, r4 add r0, r2, r0 mul r0, r0, c3 lrp r0, r1, r0, r5 mov oC0, r0 I'd also say that this means conclusively it's just coded to be this way in the 1.0.2 patch, and not a fault of any driver.

The approach most "commonly" (I use the term loosely :D) used seems to be having a specially shaped glass ('fresnel') lens between you and the bank of monitors. It's not just for the bezel area, I'm not sure how well that could be made to work. Just if you go ahead with this type of idea, might want to make sure it's not in direct sunlight.. :D

The problems you're experiencing are of a different nature; the OP and SUBS17's problems that they are unable to get any NVG effects at all, it's like it simply isn't installed by the ground crew (but they have no head mounted sights either) or powered up (but it is). I think in your case, it's looking as normal as can be expected for this version, unless the drivers I'm using are screwy too. Taking your screens 1 by 1; Screen 1: I get the same thing with 258.96 drivers on an 8800GTX. I don't think the blackness was intended to appear like that, but I don't have knowledge of how the real NVGs would look in that situation either. At least the workaround is easy enough since I don't think there's much of a necessary use-case for needing them set only to minimal brightness level. Screen 2: There's 2 things going on here, not sure which one you mean specifically but I guess the latter. First is the grainy (noise) feel over the NVG area; that part is intentional and looks the same as it does in the Night Patrol mission briefing image. The other is the loss of edge anti-aliasing. I don't think that can be resolved by us, and is just a known (to the community) defect/limitation. Screen 3: Again what you see looks the same as what I see, it might have been changed in the patch from 1.0.1 to 1.0.2 but it's not something I would have noticed. It IS a big-ass floodlight mounted on the truck that's spreading light across the runway, seems to be intentional as the white cone shape is modelled into the geometry. There seem to be other lighting differences and issues posted, so I expect it is separate from the NVG issue(s) too. The changes I made to any NVG shader code wouldn't have a positive effect to correct anything in the screenshots you posted I'm afraid, its only purpose is to get these other pilots up to the point of being able to to see the same things you can, because currently their cards are just refusing to play ball at all and just silently 'erroring out' into the log files (but still letting them fly around and do everything else - blindfolded). The files that create that black (and once the brightness is turned up, transparent) shape where the NVGs are drawn, are plain graphic files in the same directory as the shader code files, and they didn't exist before 1.0.2 so they are part of new changes to the code for this feature, but you can't really modify them in any way to help improve with this situation - the results would only come out worse where you would lose the ability to see NVG effects at all in some areas.

The browsing back and forth through the forums is capped by default but you can override this, either permanently (can be set here, and as per example image below: http://forums.eagle.ru/profile.php?do=editoptions ) or temporarily (options within each forum, just to the bottom-left of any page of threads). That should help expand the reach of your rummaging :) When using the Search feature to get results, it will probably be pulling back threads of any age.

Ok, so once again it's a DirectX 9.0 compatible card (no DX9.0c, just DX9.0) like the others who've had the problem, meaning, you cannot run anything above PixelShader version 2.0. The default NVG's are coded using PixelShader version 3.0 (the highest level supported by DX9.0c). This is the issue, before the patch it was using a lower version that your card was compatible with. I provided files in the .zip attachment to this post (linked) that will give you back PixelShader 2.0 coded NVGs to run on your hardware: http://forums.eagle.ru/showpost.php?p=959451&postcount=27 Give them a try at least; you can always replace them again afterward with the original files if they don't work. Chances are if this is ever fixed 'officially' it will take the same approach as I've done anyway. The files are text files not pre-compiled binaries, you can inspect them yourself and compare to your existing ones if that is a concern. I only lacked the hardware to test it myself 100% conclusively, as I don't have a card that is without 9.0c support (but I have tested it). I do expect it to restore the NVG visual completely as it should do. P.s. The files also only change the NVG shader files, any other pixelshader / vertexshader files for other in-game effects have their own files and won't be modified nor need fixing. These (NVG ones) are the ONLY shaders that got bumped up to v3.0 putting them out of reach of some users.

#1 I'm not a dev of course, figured I should state it even though I'm responding to you :) #2 What graphics card (vendor and model number or chipset) do you have? #3 Did you try replacing the shader files with the ones I provided as a test (and if so, and you still have problems, are you a Vista/Win7 user)?

Well, I don't have hands-on with the A10C but if the way the game is launched has changed so it doesn't do the launcher -> simulator -> launcher -> simulator process shimmy* anymore, or it's no longer dependent on the 'working directory' being explicitly set in the shortcut/profiler, that will be why it (and other applications) behave differently. * If you check in a task manager, you'll see that as you bounce between the menu system and the flying the game, these processes die and spawn fresh copies of eachother with a new task/process ID, and that may be screwing with any application launcher that monitors the lifetime of that ID.

Anyone else get this scene come to mind? You lucky, lucky, b£$^d! Might need to adjust those axis curves to come in for a gentler landing though, or just edit that part out of the next Producer's Notes ! :P

If you patched BS then you don't need to touch affinity, it's already all-cores by default and no other tools or settings are required.

Rather unfortunate, but thanks for the heads up Matt. I'd like to ask if that's all you can/will say on the matter, or would you be willing to say if it is something that will be continued to be worked on post-release for inclusion as a patch on the game N months after release (for example)? Just wondering if it's shelved for the next DCS module or still planned for the A10 post-release. Thanks. Edit: I see it got answered, thanks again :)

Yes, those are the ones commonly on all together from take off until landing (not necessarily though). And the Alt Hold one, which comes on by itself when you engage auto-hover within the right parameters, but doesn't go out when you turn auto-hover off again, you have to switch it off manually or else be fighting against the system maybe unsure why.

Yeah that mission was a good start but it put me off joining multiplayer for a while.. I'd sometimes blink and lose sight of the guy or come near to crashing him and from that felt for quite some time I'd just be a liability :D It's good to have missions that, like that one, try to set your pace rather than give you full control over it. Normally you can do what you like until you're out of gas, but missions like that, some escorts/chases, or timely intercepts make for some fun challenges AND easier narratives. When time is a factor, you're acting with more purpose. Just don't overdo it and make it too hard/frustrating and it's a golden mission.. I presume it won't stop us from making missions like that :)

You'll find with your transition to sim mode that the cyclic and collective behave quite differently now; when in flight (and in a hover) your cyclic won't be in the center anymore and instead be some way forward (and usually to the left, to counter some of the natural tendency it has for pulling to the right). From the perspective of the in-game controls and the control box display I mean. Looks like as the flight progressed you were starting to adjust and transition to the changes, but after my brief experience with your game mode track before I can see where your initial control inputs were coming from :) I'm not what I'd consider a good flyer, in that I don't have good technique or experience developed, but three things I would suggest getting the hang of are (other than making sure your AP dampers are engaged and regular trimming for your changes in flight, already having been covered): 1. letting the craft catch up with your control input, it will adjust and overadjust behind your own actions so gentler movements after the craft has finished reacting to your last inputs helps, more so than with the game mode. 2. watching your speed, making sure you don't exceed the little bar/notch on the hud (that's when the higher pitch warning tones were going off, as your indicated airspeed went above that bar.. since the position of that bar can change during flight, keep an eye on it). Adjust your speed primarily by adjusting your cyclic. 3. Keep an eye on your ascent/descent rate, the gauge is the fastest visual cue for me as you can easily see the subtle deviations from 0 showing if you're going up or down. Adjust the position of that needle by altering collective. As you alter speed or rate of ascent/descent, it will have an affect on the other, so change what you need to change, but keep those changes small(ish) and balance them out with adjustments to the other control. Once you get a hang of those things I reckon you'd have a good chance of surpassing my modest efforts in short time. Since I've never formally introduced myself on this thread either, I guess I can drop in a track file too, but heck did I feel rusty and make some mistakes :) So long as you manage that speed vs. descent/climb balance, a lot of other things end up just being extensions of that to get you moving in your preferred directions, even with the rust, stiction issues on the joystick, and using the unforgiving 'old' trim mode without any time allowed to center (that accounts for the lurching I get whenever it's trimmed, even if I do center the stick fairly swiftly -- excuses, excuses... :D ). takeoff-wobble-land.trk

The only downside I've encountered has been I can't play this over mobile (due to soundtrack copyright). Most of your other videos are fine, including the A10C teaser. http://m.youtube.com/profile?gl=GB&client=mv-google&hl=en-GB&user=GlowingAmraam "Not Available on Mobile" Caused by this (see response from Audrey D): http://www.google.com/support/forum/p/youtube/thread?tid=1909e4c9f75ec4d3&hl=en Just thought you should know, perhaps you already do :) I may be able to play it once we get our phone upgrade to Android 2.2 'froyo' and can install Flash; I'll be able to use the non-mobile youtube content then as well, but I'm not sure that will perform too well.

Alter the dropdowns - you currently have 'free camera' and 'axis commands' selected, which is for when you're in a 'spectator mode' over the airfield not as a pilot sitting inside the cockpit of the machine. Does that help give you access to what you need?

Forgive my slightly erratic head movements, but I noticed when playing your track and taking control, the handling of the shark seemed odd, I could abuse the collective, the position of the cyclic was off, and yet the heli seemed rather stable. I couldn't get the turn-to-target to work initially, so I thought I'd make a copy of the mission (from the \temp directory where it put itself during track playback) and fly it under my preferences. Small shock when I unpaused to start as the bird fell out the sky and I had to stabilise things. I then just popped on Moving Ground and Auto Turn, pointed to the left with my HMS and uncaged the Shkval and it immediately started to pan as expected (doesn't need weapons armed or targets locked or anything, it'll work with any ground position you get a fix on). So I think the differences we get might be down to some options you have enabled, could it be either the Game Mode or Game Avionics perhaps? cannon2.trk

They may not be available anymore, not sure. I found the lead from http://cougar.flyfoxy.com/mods.php which suggested the maker's (Kosmo's) own website which seems to be down or maybe had its DNS hijacked after expiry by a hosting company (the kind that splash ads all over old domains). They also suggest http://www.simw.com/ as a reseller but a quick glance/search didn't find any product there of this type. Hope it helps with your search.

Rename the file from .zip to .miz then just browse to it from within Blackshark's folder/file browser for loading the mission. Nothing needs installing per se. The (physical) file format of a .miz and .zip file are the same, and web servers left on default configurations may mixup (or their administrators may mixup) the extension of the file.

If launcher.exe didn't keep closing and relaunching every mission, it would have been easy :) We could have just started vacsystem (letting the batch file continue) and then started blackshark with /wait so that when it closed, it then could execute the cleanup commands. Whilst it's not perfect, if you really want the batch file to handle both the startup and the cleanup, it's probably best to do something like this: start "DCS:BS with VAC" /d "C:\Program Files\Eagle Dynamics\Ka-50" bin\stable\launcher.exe --console [b]start [/b]"C:\Program Files\VAC System\VACSystem.exe" MyShark.xml,True [b]pause[/b] taskkill /im VACSystem.exe exit That should (hopefully) get vacsystem running and then wait at the pause line until you 'press any key to continue'. Since blackshark will be dominating the screen and input, until you close blackshark (or alt-tab to the command prompt) the screen should remain open. Once it is closed, you would just need to press some key to get it to finish cleaning up. I think anything else would require a small app to monitor the state of blackshark because the reloading and switching between launcher.exe / simulator.exe processes means they don't persist reliably enough and will keep being assigned new process IDs. A batch file could be forced into looping around detecting this, but it wouldn't be CPU friendly.