Home Fries

Nice catch. I'll update the graphic. This is a known issue with no solution because the AMPCD DirectEntry SnapView holds the DX31+DX32 modifiers (allowing you to press the AMPCD buttons using your MFD if you only have 2 MFDs), and the countermeasure bypass switch uses the on else off switch logic that tends to break when modifiers are introduced. Best workaround is just to click the switch while using the SnapView and then use the Boat Switch when in a regular view. EDIT: I've put in an option to disable the DirectEntry modifiers in the next version (for people with more than 2 MFDs).

Version 2.10 Updates the pilot textures to be compatible with the latest M-2000C objects, but also remains compatible with the 1.5.8 Legacy DCS.

2.42 is released! Change Log: Added MiG-19P Farmer and I-16 Ishak (both WIP). Updated and Improved F-16C, added SnapViews. Fixed profile selection mode not passing over uninstalled non-DCS games. Added MFDisplay overlay to profile selection mode. Replaced fixed 1 second interval with Emergency Jettison Cycle Interval for modules that perform emergency jettison by pulse. Added vocal cues to logical gearstate toggle with S3+T6/LDGH. Setting Number of Thrustmaster MFDs to less than 2 now forces controller exclusion from profile. Fixed seat swap not occuring in L-39 (non-VR) F-14: Reduction in MFDisplay refresh commands while using H1 as RIO. M-2000C: Updated for DCS 2.5.5.39384 (new cockpit) F/A-18C Hornet: Added optional UFC MFD for people with four MFDs (H/T Dr. Jester). Updated UFC assignments on LMFD. IL-2GB: Switched RPM and Mixture axis mapping on Pinky Switch (Warthog). Applied Mixture axis curve when Combat Throttle is selected and Pinky Switch is Forward (Warthog). Added option to map Flaps to Boat Switch when APPATH enabled (Warthog). SA342 Gazelle: Updated X/Y axis shaping based on . Fixed NVG mapping. Remapped NADIR keypad to a layout more representative of the actual NADIR. Elite: Added Cougar functionality (H/T Dream). Added autorepeat functionality to subsystem targeting with S3+H2L/R Long.

Thanks for the amplifying information. I'm head down right now changing the M-2000C and getting 2.42 out the door, but once the dust settles I'll take a closer look at the issue.

Please disregard. Problem was that I used sRGB instead of Linear DXT1. Mods, feel free to delete.

On the topic of ejection shenanigans, if the pilots ejects without the RIO, the RIO still sees the pilot in the front seat. To duplicate (as RIO): Find a willing test partner or unwilling victim to be your pilot. Ensure the Pilot ejection seat is armed and disarm your own seat. Set the command ejection lever aft. Initiate ejection sequence and watch the pilot be in two places at once! Disclaimer: I have never done this to an unsuspecting pilot; I've always warned them ahead of time with a maniacal laugh! Stupid RIO tricks indeed! :D

I'm trying to do custom pilot textures both for black flightgear and for bleaching the green flightgear for use with desert flightsuits. I have updated the HB_F14_EXT_PILOT.dds file to have a black T-shirt and black survival gear, as well as the HB_F14_EXT_PILOT_SUIT.dds file for the black flightsuit. The HB_F14_EXT_PILOT_SUIT MatName works fine, but the HB_F14_EXT_PILOT MatName calls the default HB_F14_EXT_PILOT.dds file regardless of what I do. I have even tried renaming my custom file to HB_F14_EXT_PILOT.dds and just setting the flag in desc.lua to false, and this didn't change anything. Here is the appropriate section of my desc.lua: {"HB_F14_EXT_PILOT", 0, "HB_F14_EXT_PILOT_blk", false}; {"HB_F14_EXT_PILOT_SUIT", 0 ,"HB_F14_EXT_PILOT_SUIT_BVS",false}; And how it looks (you can see the green survival vest and yellow shirt), along with the custom Pilot texture.

Exactly!

Well played! :beer:

@boNes, What you're talking about are two different things. A-Scope vs B-Scope is whether the radar display extends like a baseball diamond or whether the close in is stretched to the edges of the display to make it square. The DDD is a B-Scope, but remember that the TID isn't really a radar. Think of it more as an integrated SA display with you at the bottom in the Aircraft Stab modes. What you're asking about is absolute versus relative vectors. In the Ground Stab mode (i.e. North Up), the TID displays vectors denoting absolute heading and velocity, whereas in the Aircraft Stab mode (i.e. Heading Up), all velocity vectors are displayed relative to your aircraft. Therefore, in the screenshot displayed, what it shows is that your target bears about 20 degrees left, but you're on a direct closure because his velocity vector relative to you is almost straight down. If the velocity vector is to the side, then you can adjust your heading in that direction (slight left in this case) to zero out the X component of the velocity vector to give you a tighter closure.

I'd love to see love for both the Viggen and Tomcat this Christmas, but I also think that if any developer has earned the Blizzard "when it's done" latitude, it's Heatblur. Not only have they delivered or exceeded expectations, but they've also kept us in the loop if an arbitrary deadline is not met. It could also be that a number of these bugs are due to the DCS base code. After all, HB has built features on top of DCS that ED has not yet implemented (ground radar, integrated dual cockpit to the level of the Tomcat, etc.), so many of these bugs or corrections may depend on ED. EDIT: When I saw the title of this post, I was thinking "why isn't this in the Tomcat section?" :D

Thanks, Dream. I replied to your PM.

Just another datapoint on this: I've experienced the same issue where I need to CTL+ALT+DEL and restart DCS. Before killing the process, I notice that DCS is using 6.7Gb of RAM just in the server selection screen (i.e. without even loading a map).

I tried this last night and couldn't duplicate any unintended functionality. Just so you know, the engine crank will stay mapped even with GSU as long as you have the APU switch set to On. This is to allow cross-bleed airstarts. Or was this happening if you left the boat switch off center, turned off APU, then went to GSU? I tried that as well, but couldn't duplicate. BTW, I don't use boat as master mode, but the mapping algorithm should work the same way with MM as with the CM bypass switch. There's always a chance! ;) Seriously, I'll take a look at it in December. Right now I'm up to my eyeballs with the MiG-19 and I-16.

+1. This is the only thing keeping me from doing a full-blown Warthog Throttle gear mapping.

No sweat. Thanks for bumping the thread [emoji16]

Thanks, Stal2k. I'll look into forcing the trim commands off once a station is selected. I've shoehorned as much as I can into the Hat1, so there's no real room for anything else. I'll look at the F-18 as well. EDIT: I'll add the trim issue to the bugtracker to see if any of my VR testers get the same issue.

The bug is not the displays, but the exports. Night mode on the screen is readable (and works for night), but the exports are completely unreadable.

I'm not a lawyer (nor do I play one on TV), but here's my understanding: Using a likeness of the A-4 in DCS is not a legal issue, as this falls under "art." Otherwise, all of the old sims (e.g. MicroProse) would have required licensing from the different manufacturers for using any aircraft's likeness in their games. "But what about IL-2 Pacific Fighters and Northrop-Grumman?" you may ask. The problem wasnt the use of the likeness in the game, but rather the description of the included bomber as the "Grumman TBF Avenger" rather than just "TBF Avenger." This implied cooperation and approval by NG, which was not the case. They could have just avoided the whole issue if Ubi's lawyers just removed "Grumman" from the description. Additionally, far from being "patent trolls" or "money grubbing bad guys," NG had to do this to protect their name. Legal precedent says that intellectual property whose rights are not aggresively enforced is implied to be abandoned. The reason we're seeing the requirements for licensing agreements in DCS modules is that we're going from using the likeness of an aircraft (art) with an abstraction of systems and capabilities (again, art) to the digital replication of intellectual property in the form of systems modeling (e.g. hydraulics, electrical signal flow, system logic). It's this fidelity that goes beyond "art" and why there's the grey area. Bottom line: including an animated 3D object with skin textures should fall squarely into the "art" category, as AI modeling doesn't require the level of systems modeling we expect for a full module. I too would like to see the A-4 added to the CoreMods, because right now the only way to allow the A-4 in multiplayer is to have the server enable the mod and require everybody to have it enabled.

In building a TARGET profile, I have come across a number of functions listed in bindings that do not properly actuate when assigned to DirectX controls (e.g. joystick). I have tried them both as part of a modified DirectX call (e.g. Joy_Btn31 as modifier + Joy_Btn6) and as unmodified assignments on a controller independent of the TARGET script (e.g. MFD 3). The following assignments are INOP when assigned to DirectX: All HUD Control Panel switch positions (e.g. Scales, Flightpath, Data, Altimeter, Reticle, Speed, and HUD Mode). All RWR buttons both high and low (these do not work with keyboard assignments either). EHSI Heading and Course adjustments, mode change ("M"), and brightness toggle. I can update this list as I discover more.

Hi Charlie, Make sure you rebuild your DCS_World.tmc after each update. That should clear the error message.

There you go, quoting NATOPS on us! :D Good stuff, in all seriousness.

The thing with aligning inertials in real life is that you don't want anything that will mess up its calibration during alignment, and you don't want a fluctuation in power while the gyros are spinning up for the same reasons. We would start the APU, then spin up the INS using generator power. We would go to NAV after the 8 minute alignment period, and we wouldn't start engines until then because the physical motion from engine start could cause the INS alignment to dump. Obviously, SINS alignment on the boat is a different story because the platform is moving in three axes. Since we had an APU (and therefore generator power) we didn't need to worry about ground power or fluctuations. The Tomcat doesn't have an APU, so the choices are exclusive ground power, ground power transitioning to engine power during alignment, or waiting for engine start to begin alignment. I don't know if the Tomcat's INS was sensitive to the change of power source during alignment, but it doesn't appear that any issues are modeled in-game. My personal process (I also fly mostly as RIO) is to turn on the WCS and punch in present position once ground power is available, then begin alignment once the right engine is idling. This seems to work well.

We might be talking about two different things. As was indicated earlier in the thread, the LANTIRN system nominally consists of two pods for both navigation and targeting. The F-14 only integrated the targeting portion of the system, and even then the GPS receiver in the AN/AAQ-14 pod is not integrated with the Tomcat's WCS. Where I was going is that since the GPS does not communicate with the INS, what you can do is take GPS coordinates of a visually identifiable position, then perform a visual fix to update the INS.

What you have to do is find a visual point on LANTIRN, punch the coordinates on LANTIRN into a waypoint (what Fix Point, or FP is nominally for), then have the pilot fly over that point and have the RIO mark on top and then Fix Enable.