Rangoon

Thanks, Hollywood - appreciate your efforts to help me solve this. This part keeps coming back to me as some kind of clue as to what's going on, but I can't figure it out. Maybe someone else can see something in here: Once I've loaded a mission in DCS, if I then quit and relaunch VA, as soon as VAICOM is initialized DCS triggers the comm menu (upper right corner). This is even before I've gone back to DCS as the "Active Window". So it seems something in VA/VAICOM is sending a command directly to DCS, but I can't determine what or how. This is without any buttons/keys being pressed. edit: to be clear, this doesn't happen when a mission is first loaded and entering the world. This bit happens when VAICOM is initialized. A command is sent at that moment.

I could have sworn I remembered this working in the past...even if it was years ago.

When I give the command "Hold Position" to my wingman, he climbs and starts orbiting (Ka-50). He's extremely exposed this way, which is the opposite of what I'm after. What I expect him to do is to stay put, either maintain altitude from where he was, or possibly get lower to hunker down behind cover/concealment. How do I get the behavior I'm after?

Sometimes have to press PTT a second time This doesn't happen all of the time, but usually during a session (early on) I reach a point where PTT no longer sends the command to DCS until I press/release PTT one more time (without saying anything). If I do this that second time and say something, it will both send the previous command and listen/register the one I'm saying (but not send until PTT is then pressed again). Is anyone else seeing this behavior? Is there something I can do to fix it? I have menus and pilot voice disabled, but this happened regardless of those settings. I am mostly using Ka-50 and Huey. VAICOM PRO 2.5.1 (also happened in 2.5.0)

That worked, thanks!

I accidentally overwrote a vanilla DCS mission while using the editor to make a variation on something. Without uninstalling/reinstalling DCS, is there a way to verify or redownload just one stock mission? Kind of like how Steam has the function to verify local files, can DCS do something like this?

Nope. Thrustmaster support only suggested replacement. They offered a new base for $20 less than I could purchase a whole new stick from Amazon, so I just got the new stick. I'll use the grip from my original on the VPC T-50 I have on order and I guess enjoy the convenience of not having to swap grips if I'm using the Warthog grip on the VPC and still end up having use for the Warthog stick (like for...A-10C! :) )

Is there any way in DCS to devote individual video cards to specific tasks or viewports? For example, is it possible to have a 1080Ti running the camera while a 2nd card (980Ti) runs MFCDs? And if so, is it then possible to run the camera in Fullscreen mode while the MFDs are still output to the other card/display? Further, is a 2nd non-SLI video card of much benefit in DCS for general performance (Windows 10)? Or does it create other problems (compatibility issues, driver/OS/DCS conflicts) that result in a performance loss or headaches? Is that not really where the bottleneck is with multi-monitor setups in DCS? Or would it definitely help in this case - regardless of whether or not DCS has the ability to assign dedicated viewports to specific cards?

I'm still a little unsure how DCS handles the overall inclusive dimensions of the display area. If there are areas within the resolution defined in the lua, but which don't actually relate to a physical display, then DCS doesn't need to draw those pixels. So if it doesn't need to draw the pixels, then it shouldn't take up any processing/graphics power. However, I have read that it *does* matter how you configure the displays. As in, you can set them up efficiently or inefficiently and that matters. So does DCS process these dead areas? Does it reserve memory or something for them even though they are not actually part of the drawn areas? FWIW, my current configuration does use two side displays in portrait (1440x2560), one in the center ultrawide 3440x1440, and now a 1920x1080 for just MFCDs. So I do have mixed resolutions to content with. I'm also still wondering if there is a way to back the FOV out even further because it's much too close/zoomed in when I run DCS in this configuration. And as another consideration, does anyone know if there is a way to run triple-screen (all matching 2560x1440 landscape displays - same model - NVIDIA Surround) and get the benefit of using fullscreen mode (framerate) but also use a 4th screen (the MFD screen for example)? Would this be possible with one video card? Possible only with two? not possible at all (as in DCS will still need to be run in window mode and with the same basic approach as what I'm doing now)? Thanks!

I emailed VirPil a week or so ago and was told currently the estimate is about 2-3 weeks.

I received word that at least a few people have mounted their MT-50 bases to Obutto pits. Any such folks watching this thread? I'd be very interested in learning how this was done. I'd like to be able to keep the center mount basically as it is with the TMWH. I'm thinking the front U-bracket could mount to an adapter extending from the front of the circular plate and the base of the T-50 could just sit (or not) on that plate as well. The mounting would be done with the normal T-50 bracket and an adapter, but the position of the circular plate is pretty optimal at least how I have it now. If anything, I wouldn't mind even having an adapter sit on the plate, thereby bringing the T-50 aft even a bit further.

I've read PeterP's guide and gone through many of the threads here about multi-monitor setups. I'm currently trying different things with my own, tweaking LUAs, and trying to determine what other possibilities there are which might require the purchase of other hardware or delving into other 3rd party sortware. 1) When setting up multiple displays, does the "dead space" matter that's not being output by DCS as pixels? Since DCS calculates an encompassing rectangle for its output, if you have mixed resolutions and/or gaps in your displays, DCS sees the overall outside dimensions as the total resolution. But since it's not actually rendering pixels outside the defined viewports, does it matter if you have dead space within the overall dimensions? Is there an optimization to these arrangements? For example, I currently have an odd layout: ------------------| 1920x1080(L) |----------------- 1440x2560(P) | 3440x1440(L) | 1440x2560(P) My 1920 is physically below my 3440, but I have it above in NVIDIA Control Panel because it creates less dead space. My two portrait 1440x2560 are aligned bottom-bottom-bottom with the 3440 creating the center viewport. So for example would it matter whether I have the 1920 above where it is absorbed into a smaller overall rectangle vs. below where it adds so much more dead space below the other three displays - a larger rectangle? 2) Another question I have is wrt NVIDIA Surround. Right now, since I have various displays, I cannot use Surround. I just use windowed mode and have the tops of each side portrait empty in DCS, with MFDs output to the 1920 for use with the Cougar MFDs. If I were to replace the 3440 with a matching 2560x1440, run those three in landscape, set up Surround and then run Full Screen, would I be able to also use the 1920 for the MFDs? Or would that invariably mean windowed mode, no Surround, and I'm basically back in the same situation I'm in now? What I'm interested in with the Full Screen/Surround is the option to gap out the bezels and a possible boost in framerates, as well as other potential improvements such as streamlining issues with the GUI, Control Indicator position, FOV etc. (leading to #3) 3) Right now, my FOV is too narrow. I have the seat pushed all the way back and view zoomed all the way out but it's still too close. My virtual flight stick is literally larger than my physical flight stick/HOTAS. I need to be able to zoom out further. Not sure if that would be fixed, but it's on my list of things to sort out.

Ah, okay. I can't find the exact post I'm thinking of, but I recall the pictures showed it bottom-mounted. It was earlier in this thread, though, so I guess that was "old info" and the current solution is only to use the u-bracket. Do we know if the base case be easily rotated so that the bracket is either on the front of the base or the rear? Is it a matter of reversing axes in the software or sim? Or is it a physical limitation in the connector at the attachment of the grip to the base (since the grip has an obvious front/back)? I'm just trying to figure out how to mount this... IIRC, the VKB bases basically mount like the TMWH (not sure, but possibly even have matching mounting dimensions?).

I read in this thread that the T-50 can be mounted via the bottom of the base. However, in an email I received from VirPil support it was stated: "2. The MT-50 does not mount via the underside bolts like the TM Warthog. We include a U-Bracket for attaching to the VPC Desk Mount. The U-Bracket attaches to 4 bolt holes which you can mount directly to instead with your own adapter." So I'm a little confused. I use an Obutto Revolution and the VirPil desk mount is not an option for me. I'm trying to determine whether or not I can mount this to my TMWH mount or what sort of adapter I would require.

Thanks for the suggestions, LT. I had done both of those things and still can't get it working correctly. I reset all cal data for a clean slate, ran calibration again, same problem. I then tried DXTweak and achieved a sort of workaround, or so I thought at first. I was able to mimic the behavior of the aft/left on the fore/right to make it more or less symmetrical. But I can't fix what's happening on the aft/left. I even tried negative numbers. It's that physically the stick is not reporting anything past about 75% left or aft of center. So any tweaks have to work within that limitation. Thinking I at least achieved that symmetry where all directions maxed out at 75% (therefore matching rates of change throughout all axes), I then tried to run a script and see how it affected the stick as a combined virtual controller. No luck. The changes of DXTWeak don't register in the combined controller. So I tried to adjust the combined controller in DXTweak but it just crashes every time. I'm using the 64-bit DXTweak2 executable. One final thing I thought I'd try: I removed the gimbal again and adjusted the position of the magnet. I moved it aft and left on the post ever so slightly. It "looks" centered to me in the outer piece, but after getting it all back together and recalibrating, the behavior is exactly the same. What a shame. I've dug up a few other threads that suggest I'm not the only one experiencing this. This is a new stick, too, with probably only a couple dozen hours of use on it.

My problem is that, after calibration, moving the stick aft or left hits the virtual limit (in this case a value of zero) when the stick is physically about 75% of full travel. Moving the stick right or forward requires me to really push the stick physically into it's limit to have any hope of seeing a virtual limit (65,000 or so). I have tried both the Windows calibration utility and the 1.13 Thrustmaster calibration utility. Both will correctly update the center position and get basic travel on each axis. However, neither will solve the problem. So calibration is happening, as my center updates correctly. The center starts out as forward and right, incidentally, in case this is helpful information since it matches one side of this equation. I see this exact behavior whether I'm looking at the Windows controller utility or the TARGET device analyzer. I also see this whether I have a script loaded or not (I see it in both the individual controller as well as the combined virtual controller). I'm used to having all limits and center tuned during calibration, such that you see symmetrical and consistent movement across all axes. Is what I'm seeing a common issue with Thrustmaster? Is my controller defective? Or is the calibration not functioning correctly?

Thanks for taking a look. I think my consistent way to get this problem to occur is to launch DCS, load a ramp-start mission, not touch my throttles, batteries on, EKRAN on, master caution x2 - no self-test. Once I've played a mission for example and load another mission, then it seems to synchronize the throttle position HOTAS and cockpit on start. But that first time for sure, I can see that the sim has throttle position at auto while my controller position is at idle - that's a guarantee for the problem to occur. Once I move the throttle that first time, it's fine. (sim throttle position matches CTL-ENTER indicator and 3D cockpit throttle position, but doesn't match controller/HOTAS position).

I have been going back through my forum search results another time, hoping to find some nugget of insight here, but I still come up empty. As far as I can tell, other user-made missions have successfully set up a default ABRIS flight plan that properly displays custom waypoint callsigns without having to load anything or fiddle with re-confirming each waypoint callsign. Am I doing something wrong here? I've tried so many things, such as using the full combat nav switch vs. the ground nav-only nav switch, leaving the ABRIS powered up when I hit quit, lighting candles, crossing my fingers, everything. Nothing seems to work. It's definitely getting saved. I just can't get the behavior I'm seeing in other missions. I'm pretty sure what I've seen elsewhere is where the mission maker used single-digit integers to denote PVI-800 matching waypoints and leading zeroes to denote ABRIS-only waypoints. How could this have been done if not in the same manner I am describing here? Is there another method? Can I manually edit the .miz file somehow in a text editor to achieve this?

I am having trouble getting what I think should be the correct behavior when saving an ABRIS flight plan in the Mission Editor. I have waypoints for my flight which show up in the PVI-800 correctly. However, when I try to save changes to the ABRIS flight plan, they don't load correctly in the mission. The route exists and can be loaded, but the waypoint callsigns do not appear on the main ABRIS NAV page in the fields at the bottom. They do show correctly when viewing the flight plan in the grid page. I see the ABRIS double-digit names along the left (01, 02, 03, etc.) for the actual sequence, followed by waypoint callsigns as I had them last saved (RU FA, 1, 2, 3 etc.). But they don't show in the NAV page. I have to edit the flight plan, then simply go to each waypoint and re-edit/confirm the callsigns one by one. It's tedius, but it works and then the callsigns appear as expected in the data fields at the bottom of the NAV page. To clarify, I don't need to actually edit the names. The correct name is already there. I simply need to go into that field and hit enter again. Then they appear in the NAV page. What I have done: 1 ) Set route/waypoints in the ME 2 ) go to Prepare Mission, turn on batteries, the NAV switch and the ABRIS. 3 ) edit the waypoint callsigns (so that they match the PVI-800 waypoint numbers, etc.) 4 ) activate the flight plan 5 ) save the flight plan to ABRIS memory 6 ) save the flight plan to HDD (CTL menu, database, save nav and route) 7 ) shut everything off and exit Prepare Mission 8 ) save the mission and click "Fly" 9 ) get everything booted up, unload the flight plan, load the flight plan, activate the flight plan So what I'm wondering is: - how do I get the edited callsigns to appear correctly without re-editing them? - is there a way to get the flight plan to appear by default when the mission loads without even having to load it from HDD? - is this ABRIS data stored in the mission file such that it will be in tact when shared?

Good thinking. It's actually kind of the opposite. I have the throttles (discrete L/R analog axes) left in the lower/idle position from the previous shut-down sequence. The sim starts the Black Shark's throttles in the AUTO position, so yes there is a mismatch. I have it selected in the options to sync up the HOTAS with the aircraft's controls, but this doesn't seem to work. I also tried moving the other analog controls from the HOTAS and they have no impact on the issue. It's only the throttles. When I tried leaving the throttles in the AUTO position, then launched the mission, I had the same problem. It seems the only way around this for me at the moment (version 1.5.7) is to physically move my throttle controls in some way (which I should do before startup regardless) before turning on the EKRAN. This sequence/workaround is consistent for me now. So if I run through a basic controls check before flipping switches, this issue is moot. Further, the throttles are a separate device in windows from my main HOTAS (Thrustmaster Warthog running a TARGET script) and my pedals (Crosswinds). This device is a CH throttle quadrant. No, I haven't. I'll google how to run a repair on DCS and give it a shot. EDIT: Okay, simple enough...not much different from forcing an update. I ran a repair and there is no change to this behavior.

Oh, this is bizarre! I hope this is a workaround and it may help someone else. It appeared mine was stuck to the point I tried restarting Windows but it still wasn't working. I believe the pattern is this: You have to move a control on your HOTAS before turning on the EKRAN. I tested it again after restarting DCS. If I run the sequence of batteries>EKRAN>master caution per usual, but without moving any controls (specifically in this case it was analog throttles that I tested), EKRAN will not self-test. But if I move a HOTAS control before turning on the EKRAN (doesn't matter if before or after the batteries are turned on), then EKRAN functions normally.

I have that disabled. Also, it appears sometimes even restarting the mission doesn't work. Sometimes restarting DCS entirely doesn't work. Does this sound like a problem with my install of that module?

I can't find a pattern here yet; it seems random. Sometimes when I load a mission with a ramp start, I turn on batteries, turn on EKRAN, see "EKRAN Failure", press Master Caution twice, but the EKRAN won't run the self test. Further, when this happens, when I run the fire suppression system test, I hear Betty's verbal warnings. Normally you don't hear the warnings, only see the lights. Something is not right here, but I don't know to what extent. Are these the only symptoms of this situation, so...oh well, carry on? Or does this indicate the EKRAN system just isn't working? And has anyone else noticed this? Anyone else noticed a pattern or way to avoid this from occurring? I have tried cycling the EKRAN itself, tried cycling electrical power, with and without intercom switch...not sure what else to try. The only thing that fixes it is to reload the mission.

Is this intended behavior of the playback feature? I had just started a campaign, completed the 1st mission (100% success), then chose "watch track". After a few minutes, I hit "quit" again. It showed 50% success on the playback (?). But now the campaign progress shows I've flown two missions with 75% success when in fact I've only flown one mission, one time.

EDIT: please delete - sorry, realized this is not the correct forum for this topic. I'll repost elsewhere.