iantron

I would love to see the Hot Mic option follow the configuration of the in-game hot/cold mic switch. Currently enabling it in the VAICOM EX config menu just permanently sets your mic to hot in VA and disregards the in-game switch position.

I can confirm this worked. I had the same problem as the OP. I was able to fix by... 1) Viacom config Menu ->Config Tab ->Slider from 'release' to 'openbeta' 2) same tab -> check 'Use custom DCS path' 3) same tab -> set custom path to DCS install directory. 4) close voiceattack 5) repair DCS without resetting user modifications 6) launch VA 7) launch DCS Afterwards... 1) DCS launches as expected 2) Communication menu no longer randomly turns on and off Also I expect to have to revert this as soon as an update for VAICOM is released.

I'm not super familiar with the "Tune TAC" option yet, but is it essentially a shortcut for tuning more than one system to a particular destination? i.e. RIO radio, data link, and tacan? I believe the tacan's in the mission editor can be configured with unique three letter codes AND "frequencies", they probably need to be, but I don't know. i.e. LAS and LSV I think are Nellis and McCarran at 12X and something else (might have that backwards). If those are the same (default) for more than one tanker in the mission...perhaps you'll see unexpected behavior. Does the TAC menu auto-populate with the assets in the mission?

Not sure if I understand your questions, but the back of the VAICOM manual has a keyword reference with a TACAN section. Use "TACAN tune Texaco" works I think. The "TACAN tune ___" works at least for what they have listed. You have to say the military alphabet though.

@glcollins here's the scanned version...https://www.digitalcombatsimulator.com/en/files/3309867/

+1

Unfortunately that is not the same checklist. I have a laminated copy still. It is the 2GvSAP DCS: P51D Pocket Check List Rev1.0A from 13 July 2012. I'm not having much luck finding it from that, but maybe someone from 2GvSAP (?) is around...? I'll scan if we can't find it.

Uh not sure about the link anymore. Might have a local copy though. I'll check later.

I've noticed that the AI F5s in the bfm campaign will always overtake me in a slow spiral. I feel like the F5 is enough underpowered wrt more modern fighters that conserving energy is a battle against time. You probably can't maintain an energy advantage in BFM. Use superior roll rate to your advantage if you're on the defensive. Sent from my Pixel 4 using Tapatalk

Right...so am I to assume that "DIR GYRO" means directional gyro only, "MAG" means magnetic compass + directional gyro? The labels make it sound like the F-5 just has one or the other rather than the self-correcting combination of the two...

Thanks! I'll have a look. Sent from my Nexus 5 using Tapatalk

I'm looking for some more information on what the alternate settings on the compass switch are for. Does anyone have any information here? This is the switch with options "DIR GYRO", "MAG", and "FAST SLAVE".

SWEET! It has hips. Also how about a T-38 variant and some NASA missions to accompany. That'd be a totally new mission experience for DCS. Not combat, but I don't really care. Sent from my Nexus 5 using Tapatalk

Keep in mind that your battery will be a bit drained from the engine startup procedure. While the generator is charging it up again the current meter will read positive. If there are no other electrical systems using power (turned on) then it may be normal for the generator supply current to approach zero as the battery finishes charging. I'm not sure if there are any electrical systems that are always on, but the engine shouldn't need electrical power after startup.

Bummer. If you aren't used to [de]soldering on PCBs, pick up some junk electronics somewhere to practice on. Or just repair the cable in-line as was suggested earlier. What tools are you planning on using?

Sooooo 170 is Vy. That means you should be able to fly anywhere between Vx (100) and Vy and get a better climb angle than at Vy. Since the mission is based on reaching an altitude within a certain distance (not time) the easiest way to achieve that altitude should be to fly Vx, though it should take you longer to get there. If you're having problems with engine cooling at the lower speed, I would guess that there's some room to cut back the throttle and still achieve the altitude soon enough. If anything, err on the slow side of Vy. Also keep in mind that your VSI measures climb rate not climb angle, and climb angle is what's important for this mission. On the other hand, from all the discussion above, it seems like you're having some other problem with engine management. Make sure you're following a good set of checklists and that you trust what the aircraft was designed to do (turbo should jump up around 20k asl). I like these checklists cause they have good quick reference for aircraft performance info (v-speeds, engine settings): http://simhq.com/forum/ubbthreads.php/topics/3633825/2GvSAP_Flea_s_P_51D_checklists Basic reference: http://en.wikipedia.org/wiki/Rate_of_climb

Thanks JG14, i had definitely misinterpreted 'view angle'. Does this mean that you can define an additional camera view (or more) in the script file (i.e. triplehead2go style with custom view angles). In this case, are the new cameras slaved to the trackir input like the default camera is? Also, is the mouse usable on the custom cameras (for flipping switches and such)?

So I'm trying to find out exactly what "viewDx" and "viewDy" do. Numerous places in this thread label them as the horizontal/vertical view angles. This confuses me for two reasons. First they're both set to zero in most configs. Does anyone know what angle "0" corresponds to, what range of numbers are acceptable, and what angles they correspond to? Second, the config defines aspect ratio and two 'view angles'. This seems unnecessary. If 'viewDx' and 'viewDy' are truely view angles then they essentially define the aspect ratio. Conversly, the aspect ratio and 1 of the view angles would define the other view angle. So why require all three in the config? I'm starting to suspect that I've either interpreted 'view angle' improperly or that "viewDx" and "viewDy" mean something different. Honestly I'm hoping that they turn out to define the magnitude of an offset view frustum (middle column in this image http://www.vis-sim.com/vegaprime/images/vp_chanprojections_01.jpg). Has anyone actually messed around with these values that can provide some feedback? Thanks much.

I would like to see access (read/write) to some of the rendering variables determining camera view. This would allow for custom camera views to be set up on different monitors. This includes variables for positions, angles, and fov (with ability to go to 180 deg or greater). This obviously would require more versitle multi-monitor support.

hmm interesting obiwan i might give that a try

I recently decided to mount my old joystick sideways (collective style) on my desk chair. It works great now except that (because of the lack of a real collective brake i guess???) my arm starts to get tired after flying for a while. does a real collective have a centering force like a joystick does? would it be more realistic if i removed the springs from my joystick?

i'd like to see in game multiplayer voice comms based on radio frequency, or a ts/bs plug-in to only allow comms with people on the same frequency.

Frederf: That's close but not exactly right. The wii-man's program actually changes the field of view as you get closer to the screen (check the football field part). BS does not do this. It is importand to understand the difference between zoom and field of view. Think of the BS rendering process like this: An observer looks through a picture frame into the BS world. That observer is a fixed distance from the frame, and the frame rotates around the observer if he looks left/right/up/down. It's as if you walked around in real life with a picture frame held at arms length. It turns when you turn. That fixed distance between the observer and the frame determines the field of view. In the BS cockpit leaning forward moves the observer and the frame forward, thus maintaining the same field of view. Objects on screen become larger (of course, you're closer to them) but your peripheral vision through the frame stays the same. That's just zoom. The wii-man's program simulates the effect of moving the observer closer to the picture frame. When the observer moves closer, he has greater peripheral vision through the frame (again see the football stadium scene). If you consider your monitor as your picture frame, then moving your head closer to that frame should allow to see more of the BS world on the edges of your screen (the stuff that is actually in your real life peripheral vision because your face is so close to the screen). This does not happen. When you (physically) move towards the screen in BS, the 'in-game' frame stays the same distance from the ingame observer, thus maintaining the fov. For the fov effect to be useful in the game, the in-game picture frame essentially has to have a fixed position relative to the helo. Thus moving your head left/right/up/down/fwd/bkwd (regardless of where it's pointing), alters the view through the in-game frame in the same way that it would if you moved left/right/up/down/fwd/bkwd around a real picture frame. When it comes down to it, moving your head left should angle your view through the window to the right. Moving your head up should angle your view through the window down. Finally moving your head closer should increase the field of view. The last step will keep the frame edges in the same in-game position and essentially compress a larger angular 'slice' of the world into that frame. Of course the practicality of this is limiting...unless you have a separate monitor for each helicopter window and a to-scale physically built helo cockpit, in which case it would be astonishing.

I don't know if anyone is interested but I recently wrote an AutoHotkey script to increase the functionality of my joystick 8-way hat switches. Each now has 12 buttons instead of 8. I'd be happy to provide the script to anyone that's interested, although it may take some tweaking for each user. The buttons are: -up-left -up -up-right -right-up -right -right-down etc... The difference is that up-right and right-up have become different buttons. It only works properly if you actuate the physical hat positions in the listed order (you can't, currently, just go directly to the diagonal positions, my joysticks can't even do that, i could probably change that...). I have also set it up to make some buttons be held down until released and some press only once (whether you hold it down or not). The script allowed me to almost identically match the real life setup of cyclic and collective buttons on two joysticks with a small number of built in buttons.

It seems to me that if BS had the fov (up to nearly 180 deg) programmed as an axis control, you (anyone, not necessarily ED) could pretty easily enable 1 "cockpit window lcd" (as described in my above post). Method: 1: freetrack receives 3 dof (xyz position only not rotations) from camera 2: freetrack computes necessary head direction (the other 3 dof, not position), based on head position and known location/size of window in helo, in order keep the view always pointed at the window. 3: freetrack computes fov based on how close head position is to window/lcd 4: freetrack gives all 6 dof data (3 received & 3 computed) and the fov value to ppjoy 5: ppjoy gives data to BS in joystick form 6: BS will display image according to what its given The shortfall (i think we can't currently do this) is that, for a practical cockpit, we would need the ability to define multiple dynamic views and have joystick axis controls in all 7 dof (6+fov) for each one of them. ED???