

Mikaa
Members-
Posts
105 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by Mikaa
-
The only way I can reliably hit with high drags with any cross wind is to offset the target about 1/4 to 1/3 the way to the side towards the ASL, and then as the ASL slides in, hold pickle, adjust to hit the ASL right with the release cue and hope the timing is right. It's a bit aggravating. Or just don't use high drags at all... which is a shame.
-
It only seems to do it somewhat accurately with slicks (most likely because the low TOF means less correction needed). With high drags, you seem to end up chasing the ASL at the last moment. Something isn't right, but with low-ish winds you can compensate or chase the ASL enough to accommodate it. Not sure what's exactly going on.
-
I've also noticed that it's offcenter in 2D when messing around without TrackIR enabled.
-
Thanks for your feedback. The plot thickens… I also fly the other sim, and have had no issues with my TM gear in terms of roll response. Hopefully someone well versed in the FLCS can shed some light on what might be causing this. just spitballing, but could it be that some of the FBW gain filters are being accidentally applied more than once? Either way, I’m out of my depth for this aircraft, however it anecdotally seems a bit sluggish when roll is initially commanded.
-
I wonder if it would be easier for ED to implement a modified curve for non-FSSB users (which is the majority of us), similar to the central trimmer mode options for Helos (or F-5). That way those who have a replica Viper Force Sense stick can use realistic the breakout forces and gains, but the rest of us with physically moving sticks can still have a similarly snappy Viper out of the box. Just a thought.
-
I don't disagree that at this stage it's relatively a low priority task (as most of the flight envelope is already quite accurate), however the NFM-000 is pretty specific on high alpha handling qualities, and the stated attainable (instantaneous and sustained) alpha IRL is just not possible with the current flight model, especially when attempting a pirouette. I don't see this as subjective at all, but I do realize that it's not a priority and can take a lot of work to fine tune. Maybe now that the Viper FM has been updated, and seems to be much more representative of it's RL capabilities, there will be some devs available to have another look at the Hornet. Edit: Perfect, thanks for the update!
-
Does this mean that there will not be any further changes to the pirouette logic and high alpha pitch authority capabilities, as referenced in the bug report marked "investigating"? Or has this already been rectified, and implementation is pending the next patch?
-
fixed Autopilot Steering Select Seems Incorrect
Mikaa replied to 777coletrain's topic in Bugs and Problems
This. If the STRG SEL was in fact just a simple homing autopilot, it would never be used IRL due to significant wind drift, and pilots would just use the HDG function to track to the desired steerpoint by referencing the tadpole and vv cues and collocating them manually. Just because the F-16 autopilot is incapable of intercepting a specific HSI selected course to a steerpoint does not mean it doesn’t have the capability to compensate for wind drift and track (read steer) directly to the selected steerpoint. I really hope this is looked at again. -
Let's hope so. I haven't heard anything regarding us having the XFER from GPS database function and found my way to this post, but it would be a welcome addition to the Mission planning and diversions. Fingers crossed.
-
investigating Spin recovery active despite pirouette commands
Mikaa replied to Hulkbust44's topic in Bugs and Problems
Agreed. In the appropriate NFM, the subsections pertaining to Aircraft Stability and Dynamic Response, and High AOA Flying Qualities outline some deficiencies in our DCS Flight model; specifically including AOA Capability (Transient and Sustained), Yaw Rate Warnings, and Pirouette Logic. Some Highlights Include (paraphrased): - Full Aft Stick input results in 50-55 degrees maximum sustained AOA (resulting in potential -18000fpm descent rates); and yaw rates during maneuvering above 50 degrees aoa can be significantly higher than desired. - Combined Pedal and Lateral Stick inputs between 35 degrees and 55 Degrees AOA provide enhanced roll performance when compared to individual inputs in this AOA regime. These inputs can lead to excursions into the "60s" of degrees AOA, which can blanket the ADC (reading 48 KCAS in HUD). - When AOA is above 35 Degrees, Yaw Rate warning is replaced with the Departure Warning tone (not implemented in our current model; we should hear beeps increasing in frequency depending on the Yaw Rate, starting at 40 deg/sec Yaw) - If Yaw Rate develops at 50-55 AOA easing control stick off the aft stop should immediately reduce AOA below 50 and terminate the yaw - Sustained Yaw Rate at 50-55 Degrees AOA can lead to display of Spin Recovery command arrows. - Pirouette Logic is engaged at <210KCAS and >25 AOA and spin display logic is modified during this maneuver to prevent "nuisance spin indications" (though at 50-55 AOA and sustained Yaw Rate the spin recovery command will engage, as written above) The Attached track is my attempt to enable the pirouette logic, mirroring Wags' Pirouette video from 2018 (also attached). Although the current FM allows the maneuver, maximum sustained AOA is ~36, with transient to ~40.9 with slight stick modulation to increase yaw-roll coupling on entry (as well as to attempt to increase transient AOA above 35). AOA never even approaches 50 degrees, thus AFAIK the Spin Command should never display. Additionally, my interpretation of the above sections indicates that 50-55 degrees AOA should be commandable and sustainable with full-aft stick input, and if full aft stick and pro-spin pedal and lateral stick were commanded, a transient to "60s" of AOA should be possible, setting off both the departure warning tones and spin recovery display commands. My humble interpretation of this is that the pirouette should be sustainable with full lateral stick and pedal, and aft stick modulated to maintain appropriate AOA (Above 25 degrees, but optimally 45-50 degrees). This just isn't possible with our current DCS model. Aside from the dampened AOA capability and the lack of departure warning tone implementation, the current FM seems pretty close until you reach the edge of the envelope. F-18C Pirouette Test.trk -
need track replay TWS undes locking tgt outside reasonable RDR FOV.
Mikaa replied to DUSTY's topic in Bugs and Problems
I didn’t realize you could have guided intercept with entirely off board contribution, but that makes sense. My question was really about if the onboard radar has an easy way of taking the off board track designation and easily acquiring it with your onboard radar without much (read any) pilot input (ie the radar snaps to the L&S track without having to manually slew and train elevation). Of course you can manually cursor slew over it and designate yourself once it shows that your radar is also contributing. Being able to launch off a donor only track makes my question a bit moot anyways. Thanks! -
need track replay TWS undes locking tgt outside reasonable RDR FOV.
Mikaa replied to DUSTY's topic in Bugs and Problems
Quick tangent question. If an offboard only target is designated (let's say L16 from an AWACS), how is the transition handled from that L&S track to an onboard firing solution for an AIM-120? Is this handled in a pseudo AACQ once within radar scan volume or does it have to be manually designated again in RWS/TWS, but until then the L&S cues will give intercept symbology for the offboard linked track? -
can not reproduce Waypoint Designate isn’t working in multi and single
Mikaa replied to Punisher74's topic in Bugs and Problems
I’ve potentially encountered issues with UN-designating from a TGT point, but wasn’t sure exactly on the logic so I haven’t made any reports. Something does feel a bit buggy, but seems hard to pin down whether user error, or something broken. -
Yep, just had this bug come back after not flying the mig for quite a while.
-
Any updates on this?
- 3 replies
-
- pixelated sea
- sea looks terrible
-
(and 1 more)
Tagged with:
-
Small QOL update would be the ability to rename the "Takeoff From Ground" slots. Can be difficult when spawning into a MP mission with multiple user made FARPS and having to guess which aircraft is parked where (or naming the aircraft partially by it's location, which is less elegant). Ultimately, it'd also be nice if some of this was auto-detected, where if a helo is placed at a named FARP, the "Ground" just becomes that name when the spawn is within a certain proximity in ME, and similarly if placed within a few nm of an airbase, or even just on the airfield somewhere, it'd just inhabit that name, despite not being on a listed parking T.
-
I’ve noticed this as well. Makes judging wingspans a bit more difficult, but not impossible. Hopefully it’d be an easy fix to just rotate the reticle by 30ish degrees.
-
Tested this shortly after the patch in a lightly loaded hornet. Did some push-pull and got a spike to 11.2G, wings stayed on. I'm satisfied with the paddle implementation now. If you're doing crazy stuff like that with spikes well above 10G and a wing occasionally comes off, I don't see a problem; had to work to get it that high. Yes, in RL you'd turn the jet into an ugly dihedral abomination before you'd get the one (or two) wing clap, but as long as wings stay on for an "oh crap" CFIT avoidance pull, I'm alright with the slightly simpler implementation. Maybe they'll revisit this once the advanced damage model moves from WWII to the modern jets.
-
It's absolutely related to this Posted this a few days ago; thought it was strictly an AUTO solution issue with the ASL - tested today to see if any fixes were implemented and just left out of the patch notes. Once I realized there weren't, I decided to mess around with CCIP, and noticed there were wild inaccuracies sometimes, and others a pretty close miss. Used active pause to launch a few, and saw the CCIP line and cross jump exactly the same way I described the ASL for AUTO... Something is really messed - worst part is it's inconsistent so you can't rely on any HUD or AG designation cues.
-
Not sure if this has been reported, but it may be related to the attached bug report that is being investigated. I have been trying to figure out why my unguided bomb deliveries in AUTO seem so inconsistent in the Hornet, and whether it came down to a case of "git gud," or a bug. I'm now convinced there's something funky going on with the AG designations that's affecting AUTO deliveries, and could also be why there are constantly complaints of unguided munitions not landing on target. Additionally, I have consistent issues with this both before and after a slow repair with a check for extra files, and deleting fxo and metashaders folders. Attached are 4 tracks that show a preplanned waypoint that is then designated as a TGT using the HSI WPDSG function. This point does not always correlate, when looking through the HUD or JHMCS, with where the point actually is. It is also observable that this designation "jumps" at different times, and if conducting an AUTO delivery when this occurs, the ASL itself jumps, making deliveries very difficult. This was tested with both slick Mk82's and 82Y's with and without wind. While using the slick bombs, the effect is minimal as TOF is shorter, as well as required offset of the ASL (usually can still hit within CEP) but it is still present; however when any high drag munition is used, this "jump" in the ASL is magnified because of larger ASL offset to compensate for wind and longer TOF. Additionally, I cannot always be sure that the designated TGT point is in the correct place, which leads me to suspect that forum complaints of very large misses are often due to following the ASL to an incorrectly designated point. The following 4 tracks (mk82 no wind, mk82 with wind, 82Y no wind, 82Y with wind) show a TGT designation at waypoint 1 (set in center mass of the truck at ground level, with FLIR used to visually identify) with a fly over the point, then return pass for simulated AUTO drop. - During the initial flyover, one can see that the JHMCS diamond is significantly off from the designated point, and then inexplicably "jumps" back to the correct spot (within margin of error - I don't expect the HMD to be exact all the time). This is visible before active pause is engaged, but the pause function demonstrates the magnitude of error better. - I then head NE, set up the stores page, and return for a pass, focusing on the ASL and diamond in the HUD. On every pass, the diamond (and by consequence the ASL) seems to be incorrectly placed in the HUD, and then randomly "jumps" to a different position as I get close. - I abort the pass and fly overhead again, and lo and behold the JHMCS designation point is not on the TGT. At this point I have not touched the FLIR pod, but on the second active pause, I redesignate with the ATFLIR to get the point to jump to its correct location. This is also repeatable in the Syria instant action ground attack mission. I can upload a track of that as well if needed. It doesn't matter if the point is designated as an AG waypoint through a preplanned point, or the initial designation occurs with a pod (also doesn't matter which pod is used). Also, the use of active pause is just to highlight how far off the diamond is from the supposed TGT designation, but this can be observed repeatedly without using active pause as well - that's not what is causing this. I've also included the .miz file for what I used to test this. I just added wind to the mission editor of 8kts at surface (thus 17 at 1600) and then 30 kts above that. Thoughts? P.S. One final sidenote, I also notice that during high crosswind scenarios, the ASL will often drift quite significantly as you approach the final few seconds before drop (not the "jump," but an actual smooth drifitng). Is this correct behavior? Makes high crosswind deliveries super hard to track, and can lead to an AUTO drop with significant bank angle. Someone let me know if this is correct behavior, I've always wondered. F-18 AUTO Desg Jump-No Wind Mk82.trk F-18 AUTO Desg Jump-8kts sfc Mk82.trk F-18 AUTO Desg Jump-No Wind 82Y.trk F-18 AUTO Desg Jump-8kts sfc 82Y.trk F-18 AUTO Test.miz
- 1 reply
-
- 1
-
-
DCS: F-5E is the hardest fast jet to fly in bad IMC weather
Mikaa replied to DmitriKozlowsky's topic in DCS: F-5E
Much appreciated. I just dug up the TO 1F-5E-1 AFM, and had a look at the instrumentation section. The description of the ARU-20A (which I believe is the correct AI for our version aircraft) specifically makes mention of the Fast Erect use and gyro stabilization. TO F-5E-1 pg. 1-73 (Emphasis mine) - "The attitude sphere is stabilized by the displacement gyro (two-gyro platform) powered by the left ac bus and the dc bus. The AHRS rate gyro balances electrical inputs to the displacement gyros so that the attitude sphere maintains position through all aircraft maneuvering. The AI can be tumbled by power interruptions which cause an OFF flag to appear in the lower left of the indicator face. If power failure occurs in any flight condition other than straight and level, the AI may erect to a false vertical when power is returned. The FAST-ERECT switch on the instrument panel next to the AI is provided to expedite gyro erection." My understanding of the above paragraph is that the FAST-ERECT switch is utilized to recover from power loss based gyro precession (from the gyro spooling down with no power applied to the system). Secondly, there is no mention that the FAST-ERECT switch has any relation to the HSI, which currently falsely cages to North when pressed (it shouldn't). Finally, I found some relevant information regarding the standby attitude indicator - There's a very specific warning after paragraphs for the ARU-32/A or ARU-42/A-1 standby AI models: - "The indicator may precess following sustained acceleration or deceleration periods and may tumble during maneuvering flight near the vertical." That's not terriblly interesting or unexpected for a standby, but what is of interest is the fact that the primary Attitude Indicator ARU-20/A has no such warnings associated with it. I think ED may have accidentally incorrectly interpreted these warnings in the AFM as to apply to all the AI's in the cockpit, not just the standby. Edit: just saw the replies. I'd actually be happy if ED fixed the primary to not drift at all unless power is lost, and leave the standby as-is - clearly the AFM makes mention of the standby being susceptible to drift. -
DCS: F-5E is the hardest fast jet to fly in bad IMC weather
Mikaa replied to DmitriKozlowsky's topic in DCS: F-5E
Having never flown the F-5/T-38, I can't comment on the specifics of the model of attitude indicator installed, and would have to dig to source documentation that comments on its (lack of) self-righting capabilities. As for a broad definition of accuracy, FAA documentation (AC 91-46 amongst others) states anything more than 5 degrees pitch and bank during ground ops (taxiing and instrument checks) is considered unreliable. It also states that 'mild precession from horizontal' is possible during sharp turns while taxiing. Idk what the FAA deems 'mild,' but from the wording, one could infer that it's less than 5 degrees. I'd probably start there and set the max precession to about 5 degrees (though in my opinion it should never be more than a few degrees, unless documentation specifically mentions this AI's susceptibility to precessing). Most often, the parallax error to the adjustable 'miniature aircraft reference' is larger than the total precession of the instrument. From my experience, the most I've gotten an attitude indicator to precess was a few degrees during severe turbulence or hard maneuvering, but once those conditions ceased, it was instantly reading correctly again. If the vacuum pump has failed, or electric power cutoff if elec. operated, then we're talking about a very different scenario, plus you'd get a gyro flag to indicate unreliability. The only way I've gotten an attitude indicator to (somewhat) reliably fail is to aggravate a fully developed spin - The gyro backup AI would often tumble at about the fifth or sixth rotation, and even then, I couldn't always get it to tumble, and if it didn't, on recovery it would still be indicating correctly, even after the 4G pullup to level. If it did tumble, usually by the time we'd gotten back in the pattern would it have fixed itself, even if I didn't manually re-cage the AI (maybe 10 minutes). Agreed. It's a humbling experience first time in IMC. Especially once you realize that your vestibular system is constantly attempting to kill you. edit: clarity -
DCS: F-5E is the hardest fast jet to fly in bad IMC weather
Mikaa replied to DmitriKozlowsky's topic in DCS: F-5E
So you can use altimeter and vsi to infer a rough pitch attitude, and you’re going to use the HSI for bank angle? At best it’s a rough rate of turn indication, not roll. That’s not a bet I’d take. Regardless, this discussion isn’t about the finer points of BAIF, it’s about how the F-5’s attitude indications are unrealistic, and make it unnecessarily tedious to fly for more than 2 min in IMC and shoot approaches. It doesn’t matter if the F-5 was a Day-VFR only fighter during RL ops. An attitude indicator is an attitude indicator, and flying TACAN or PAR approaches without at TFR or modern niceties like glass and gps, is not difficult at all assuming your instruments work properly. If you want to simulate partial panel ops, then go nuts, but don’t say that this instrument behaviour is realistic. Of course normal rules apply of “this is just a game, not real life” and at the end of the day, this has little to no affect on DCS missions outside of very niche situations, because you’re not ironsight bombing or dogfighting in IMC. But does this irk me somewhat? Absolutely. -
DCS: F-5E is the hardest fast jet to fly in bad IMC weather
Mikaa replied to DmitriKozlowsky's topic in DCS: F-5E
IMC - instrument meteorological conditions, meaning you don’t have a reference outside. So you can’t know what straight and level is, thus negating the usefulness of this false caging function even if it was realistic. And I’m not talking about climbing through a layer to VFR on top - Once I have horizon reference, I couldn’t care less what the attitude indicator is displaying - I’m talking about extended flying in the soup, which is impossible with the ridiculous levels of precession. Also, hilariously, the backup AI has the exact same precession problem, meaning the gauge mounted for redundancy is just as unreliable as the main gauge. Not how it works IRL.