vstolmech513

After updating to the latest software (1.8.18), my UFC/HUD controls are not recognized in SimApp Pro and the exports from the game are not working on the physical MIP UFC controller. The game recognizes the controller is there and functions correctly with all of the buttons/knobs, etc., so it is being detected by Windows and DCS, just not in the SAP software. I tried doing the repair lua function and that did not solve the problem. I tried unplugging the USB-C cable to the controller and plugging it back in, but that did not work either. I have the ST throttle, SL joystick, CR and TO panels, and the 3 MFDs connected, and they are all recognized and working correctly in SAP. Anyone else seeing this or know of a way to roll back to the previous version of the SAP software to troubleshoot?

You can always just hit ESC and click on message history, it allows you to see all the messages you have received based on the selections at the top.

I use a modifier on my flight stick to allow me to effectively double the number of buttons. I use the paddle switch and DMS FWD to bring up the kneeboard and then paddle switch and DMS left and right to cycle the kneeboard pages forward and backwards. I also use the paddle switch and TMS FWD and AFT for my zoom in and out slow.

@Wawarare you still having trouble seeing the Compass George menu and it not even showing up on your screenshot? I was having the same issue as you, I could see the menu as the pilot but when I was the CP/G, I couldn't see the compass and it never showed up on my screenshots to even begin to troubleshoot where it was. Then I realized that I had only mapped the George/AI button for the pilot and never mapped it for the CP/G. Doh! Not saying that's your issue, but it was why I could never see it on my screenshots...

@ExoticTroutwhen you say you had no joy of tanking from the S3, did you get cleared to connect, then just not get the "you're taking fuel" bit after plugging? A quick track is always a bonus, but is this a tanker in a mission that you created? Did you ensure that you added an S3B Tanker, not just an S3B? These were things I messed up when I started trying to be super cool and trying to make my own practice missions, not sure how advanced you might be in mission making, not trying to offend.

Chapter 10 should be what you are looking for in the 80T-111, although it doesn't give in-depth procedures, it does show diagrams.

Everything on this airplane has to do with weight. Electrically driven adds weight that has to be sacrificed somewhere else. So you either get less fuel, less ordnance, less avionics, etc. IRL these are a POS and hardly ever get fired. When they do get fired they jam or hardly, if ever, come back empty and I have seen these actually frag themselves (usually due to pilot error, firing too low/too steep or once, and it was a full bird Colonel, swore that two rounds impacted in mid-air and fragged his jet because there is no way he did something wrong...)

It's also worth noting that the DDI that the TPOD is on has to have TDC priority (diamond in top right corner) for it to 'fire' the laser for the Mav to pick it up. Not sure if it is a bug or correct for the TPOD to continue blinking LTD/R when the TDC priority is not on the DDI that the TPOD is on, but it will either not lock at all or it will blink between the X and the square but not actually lock on without TDC priority on the TPOD (or that's the issues I found I was having when I could not get a solid lock on the Mav).

It just depicts the stations from left to right (as you're looking straight ahead out of the cockpit) as top to bottom. It's like the jet is in a right-hand bank.

Multi-Monitor works in CA I was having the same issues as well as being unable to use the bino view with my muti-monitor setup. I am running three 27" monitors with a 24" below them for MFD exports. I added the below to the bottom of my monitor setup lua and it has been working perfectly for me. UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center I used to define my GUI and just had my UIMainView as my GUI. I deleted all of that and added the above at the end of my export definitions and it worked.

Multi-Monitor works in CA Talk about a necro... but, I have been messing around not willing to accept that you need such workarounds when the stock 3cameras lua works with CA and allows a centered bino view and gunner's view. I always defined my GUI in my monitor lua and after copying and pasting what the stock 3Cameras lua had, I finally got it to work with 4 screens, 3 wide and one below it where I export my MFDs. My overall resolution is 7680/1080 This was how I defined my GUI and MainView before: GUI = { x = 1920; y = 0; width = 1920; height = 1080; } UIMainView = GUI Here is what the stock 3Cameras lua has, which is what I copied and pasted into my custom lua after deleting the GUI definition: UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center I don't know if this is something that has changed recently but I haven't tried messing with this in years, only to find out I never tried the stock 3Cameras lua to see if it would work. Works well in both SP and MP (tested in current OB) as you can see in the below screenshots (only complaint is that in bino view the rest of the view is not blacked out):

I think I threw up after watching your first video... actually, I think I blew chunks twice...

Are you using a single monitor or multiple monitors?

This happens at night too with NVGs mounted. The visor edges are green but still visible even with NVGs down. Track and screenshots attached. AV-8B NVG Visor Bug.trk

Sorry, just now seeing your reply. A cannon plug is just a connector from a wire bundle to a component. All they did was cut the wire, wrap it with a sleeve and tie it back on itself. Your comment about horizontal flight preventing a rapid reduction of RPM is not correct. A jet engine will only spin as fast as the combustion section is burning a set amount of fuel that gets determined by the Fuel Metering Unit (FMU) which is set by throttle position, which in turn spins a turbine at the back of the jet. These are what actually spin the compressors (which is what sucks the air into the intake but only at the speed the turbine is spinning it at). In the above image you can see the firewall in the middle of the picture (it's grey with a cutoff pipe coming out of it) with the High Pressure Compressor (HPC) just in front of it. The ring you see would be where the cold nozzle sits on the jet. Air cannot force itself into the compressor and make it spin faster nor can it keep it from slowing down. The turbines in the back are painted red to show where the hot exhaust gas is, and those are what spin the compressors in the front, not the other way around. If you add more gas (throttle up), the engine spins the turbines faster. Take gas away (go to idle), then it spins them slower. Any air that is flowing into the intake that the engine does not need gets either pushed out of the intake or gets vented through what are called boundary layer doors on the inside of the intake (the flaps are spring loaded and circled in red below). These also prevent supersonic air from entering the engine, and vents the air upwards behind the canopy (if you look at the F2 view with the canopy open you can see the large white squares that are covered by the canopy when it's closed). Now whether or not you can hear that sound on the ground or not in DCS externally or in the cockpit only should get looked at but has nothing to do with the thread that you linked. You can view my reply to that thread here and see that there doesn't seem to be anything wrong or modeled incorrect about the responsiveness or the spool time. The only real issue I can see is how long it takes to go from full throttle to idle. I clocked it at around 7-7 1/2 seconds where in the real jet it takes about 5-5 1/2. Almost every function of the engine and its acceleration and performance can be seen in this video of a high power: These are just my findings and what I see on my end. Not meant to make anyone mad or take away from what you might be seeing on your end. Strictly for information only.

SINS Cable Connects Not sure what your issue is, worked last night just fine in OB:

That's some strange happenings there Swift. It doesn't blink on me when I replayed the track and taking control it doesn't blink either. I know it's probably a stupid question but did you try a repair? I had an issue where I couldn't dim the indexer at night and it was washing out my NVGs. I ran a repair and for whatever reason it fixed it. I wonder if there is some sort of log file that says what file was changed or fixed during a repair? Anyways, just my .02

I searched as much as I could and did not find any other bug reports regarding the issue that I, and others in my group, are seeing. When you slew the TDC cursor over the azimuth scan setting in RWS, the scan numbers disappear and remain missing until you slew the TDC cursor over the number again. You can sometimes get the TDC depress to change the setting while it is gone, but not every time. If you switch to TWS everything works as advertised, and even in RWS the radar range options work perfectly using the TDC cursor. I tried a repair and removed all mods to ensure it wasn't something interfering with the files. Track attached. I was using the Instant Action Free Flight mission on the Nevada Map. F-18C Azimuth TDC Bug.trk

Engine Performance In regards to the acceleration times, I have been testing them and they are pretty spot on, at least in the lower end RPM ranges. The limits are 35%-60% in 2.4 - 3.1 seconds. I have tested this several times in different maps and they are usually anywhere from 2.7-2.9 seconds. It's not a one value place holder as I suspected, where it is always the same value, so that's a good simulation. I have checked manually and the values I get on a manual timer are about as close to what we see in the jet, so it's fairly accurate. The higher end RPM acceleration check (60%-105%) is not modeled as accurately, in that you can get a value even if you don't get up to 105%. There should never be a value if the RPM never reaches the upper number. You should be able to do a lower end acceleration check from 35-60%, pause and bring the throttle below 60% and then do an upper end acceleration check from 60-105%, but as soon as you go over 60%, whenever you bring it back below 60% it fills out the acceleration time it was above 60%. All times from 60%-105% that I have gotten when I went full power and back to idle after going above 105% are within limits, fastest is 2.2 secs and slowest I've seen is 2.4 secs. It's been a hot minute since I did a high power but I believe the limits are 2.1-2.8, but that is a guess. The times from idle to 35% and anything above 105% is not timed and does not matter. Currently I'm seeing anywhere from 7.9 to 8.2 secs from idle to full 113.5%. I did not test the full wet datum, idle to 120% because it is still not modeled correctly due to misunderstanding non-dimensional RPM limits below 10,000 feet and limiting it to 116.8%. There are several warnings in the NATOPS that warn full power could take up to 8 seconds to reach, depending on atmospheric conditions and initial throttle position. The way it is now, seems more accurate to me TBH and comparable to what it is IRL. The sound is horrible when coming back down and the engine noise is a lot more muted in the cockpit IRL, but the performance and timing seem to be modeled fairly well. All acceleration checks are done with water off and nozzles at 0* to ensure that there is no bleed air coming off the engine. Nozzle deflection should cause slower times since when they are below 0* they are bleeding 8th stage air from the HP compressor, which in turn would cause a longer acceleration time. You can put the nozzles to any angle and will get the exact same acceleration times.

Technically there is SMDC (Shielded Mild Detonating Cord) all the way around the base of the canopy, so there shouldn't be any plexiglass left on the canopy at all. It would be even cooler if the emergency canopy fracturing handle would work on the ground to do that for when the pilot is stuck in the canopy and can't eject (mostly ground emergencies such as crash landing and can't open the canopy due to the canopy step being jammed/stuck.) It's a metal cable that's connected to the black and yellow D-handle and is about 10-15 inches long. It gives just enough slack to crouch down and then a good tug blows the canopy, assuming the safety pin is pulled out just behind the seat checklist on the port side canopy rail.

The fast deceleration solenoid was removed and the cannon plug tied off almost 15 years ago. The spool down sound I believe you are referring to can be heard anytime that you retract the throttle from high RPM location to idle quickly. I will agree that the sounds are now horrible in the cockpit as they used to be pretty darn spot on. The only time you should hear the spool down sound is as the RPM comes down rapidly, like from max to idle in <2 secs. but it seems like any rapid retraction causes that spool down sound to play and mixed with the normal sound of the motor it sounds like a dying cat.

Swift, do say that thinking they followed the density gross weight reading along the curved line rather than dropping vertically? I don't see how else they could have gotten the roll distance that far off.

This has seemed like it was backwards to me since I first started doing the training missions almost 7 years ago. Does anyone else feel that the emergency flap retraction is supposed to bring the flaps back up and not deploy them? The emergency speed brake retraction closes the speed brakes when they are open, however the emergency flap retraction extends them to the full down position.

No, pressing designate makes the selected waypoint the target. It should change from a circle to a diamond and the TGP slews and should lock in place. I have this happen all the time and the only way to get it to stay is to TDC depress. Seems like the TGP is not recognizing the designate as a type of TDC depress maybe?

Just curious, how come you have an aspect ratio on your exports? Seems like that makes them a viewport in and of themselves and not just a display that is exported to an alternate location? I'm genuinely curious as I have not seen that anywhere else. I've attached my monitor config (3 27" 1080 monitors with a 4th 24" 1080 monitor for MPCD/MFD/DDI/AMPCD exports). Ricks 3cameras_MFCDs_Right.lua