Ahmed
-
Posts
409 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Ahmed
-
-
Not specifically ownship related, so it may not be the same issue that OP reports, but this happens all the time in MP with other humans. I haven't had time to reproduce into a short track:
-
1
-
-
Hi,
1. Set up a mission with me and a single group hostile
2. within 25nm head on, NCTR prints single group hostile as Su-27, trackfile gets a hostile HAFU, as expected.
3. Lost lock, flowed North for a while to ensure that there are no trackfiles left
4. Turned South. As soon as I locked the previous group, it gets unexpectedly ID'd as hostile with print Su-27 while outside of the 25nm "NCTR range"
It seems like the code caches previous per-object NCTR prints but doesn't clear cached prints when the trackfiles are dropped, and thus stores them forever, leading to a new trackfile on the same object getting automatically ID'd as hostile and it's type to be known when it should not.
I originally noticed this when reacquiring targets from a side aspect. The procedure above and the track are just a way of consistently reproducing it.
-
2
-
-
I don't think there is any clear definition of "flared landing" other than a landing in which descent rate is arrested prior to touchdown. There is a semi-relevant note about 500 fpm with asymmetrical stores, that could be a reasonable threshold to call something flared (although 500 is definitely on the "positive" side). Not to be confused with aerobraking, as mentioned above.
-
1
-
-
Hi,
Running a test to investigate the issues trying to maintain on-speed during turns in not-auto flaps up operation, I noticed the following:
1. Started test by setting on-speed (~152 KCAS)
2. Entered turn, applied aft stick input up to maximum (limited to 3.55 inches aft in not auto flaps up logic, and also to a ~70% of travel in DCS)
3. Noted that pitch stick command and pitch trim bias allow to pull up to ~14º AOA (stab deflection up to 24º teu). All within expectation.
4. Accelerated to ~230 KCAS, trim untouched, entered turn attempting to capture on-speed.
5. Max pitch stick command won't achieve the previously trimmed 8º AOA, max resulting stab deflection is now only 6º teu.
6. Finally, accelerated to ~243 KCAS to force transition to auto flaps up logic. On transition, noted big AOA and pitch rate spikes as the FCS command transitions between 6º teu and up-to-24. (Note that these spikes will also happen in case of only applying the ~70%/3.55" stick limit mentioned above, and smaller deflections too -- this is not in the attached track, where I used full deflection, but the result will be similar)
I'm unsure of what exactly is wrong here. The pitch stick command, trim bias, and aircraft sensor feedbacks are scheduled by airspeed in not-auto flaps up operation, and the gains and limits may benefit from some tuning. I couldn't find a reference to the 6º teu limit observed above at higher speeds anywhere. The aircraft seems to have very little pitch authority in the above test conditions with the current gains. I'd appreciate if you can run this report by your dev team FCS expert, as this particular test case may have slipped through them.
-
1
-
1
-
-
Edited the title as this is not related to crossing from one elevation hemisphere to the other, it has some other cause.
In response to your question: it is not, as evident in the track. It can be reproduced at near zero az/el from the emitter.
-
As per the thread tittle. It seems to randomly lose handed off target.
EDIT: it is not related to hemisphere change, thus the edit. Added second non-maneuvering track where it also happens.
-
+1, there are still quite a few inconsistencies in the INS modeling, update modes that are not implemented, and also some shortcuts taken, such as this one:
-
2
-
-
I'd advise though to keep anything that is not directly related to the WOW issue in a different thread, or we may get everything marked as "correct as is", if both reports get intermixed. My initial report is intended to address the apparent lack of WOW logic since the last update, and the associated unexpected FCS stab commands during the take-off/landing rolls.
-
Hi BIGNEWY,
I understood that the changelog item meant that they were supposed to hold throughout the whole MIL check range (they don't past ~95% in current DCS). If it is intended, then disregard.
-
1
-
-
Hi,
Looking for the cause behind the takeoff/landing issues noted after the FM update, I think that I have found an issue with the new FCS code. It looks like the transition to WOW mode, at least in pitch command, is not happening, or that WOW mode logic has been changed to a wrong one.
According to documentation, for stabilator command in WOW operation, aircraft sensor feedbacks are set to fixed values or do not exist. This was how it seemed to work in DCS prior to the FM update, but now it seems to receive the same feedbacks than in "Not auto flaps up operation".
I did the following tests:
- taxi.trk: noted that the stabilator reacts to changes in pitch rate/aoa while taxiing (like it would on a viper, but should not in a hornet, as seen in any YT video)
- takeoff_12.trk: take off with 12º ANU stabilator. Rotation speed for this configuration is about 145kt. At approximately 100 knots the FCS starts commanding ANU stabilator, as in seeking to capture an AOA. The aircraft lifts off by itself. FCS reverses the ANU stabilator command and captures 6º AOA.
- takeoff_16.trk: take off with 16º ANU stabilator. Same observations than above, just the FCS captures 10º AOA.
- landing.trk: notice that immediately after touchdown, the FCS commands 24º ANU trying to recapture the trimmed AOA and holds it throughout the landing rollout until the speed reduces to near zero.
It seems that the FCS logic after the update disregards WOW mode and just remains in "Not auto flaps up operation" logic, trying to capture the command trim AOA. This explains all the weird things observed after the update, such as:
- Aircraft taking off by itself prior to rotation speed (due to FCS commanding unrequested ANU stabilator)
- Nose strut staying extended after nose gear touchdown (due to FCS commanding 24º ANU stabilator on touchdown)
- Possibly also explains the uncontrolled pitch up issues that people have reported if taking off with flaps auto
The correct behavior would be as documented in the WOW operation description (and as it seemed to work prior to the update)
Aside from the quoted documentation reference to "WOW operation" logic, I link below the following videos:
- Taxi out (little-to-nil stabilator motion)
- Landing (no such thing as sudden command of permanent 24º ANU on touchdown.
- Another example (notice that the pilot commands aft stick later on during the rollout to aid in braking, but there is no such thing as a FCS 24º ANU command on touchdown)
This was working well before the update, so it must be an issue with the new code and WOW logic.
Probably some of the SMEs in the forum can amplify on this.
-
4
-
1
-
-
Last changelog included:
- Fixed: Brake check holding at Mil power.
However, they don't.
The FCS commanding aft stabilator deflection to rotate the nose also looks suspicious, as the NATOPS technique states that the pilot must apply aft input at the nose wheel liftoff speed.
-
2
-
Noticed unusually high fuel burn against planned.
At a reasonable M .80 cruise at 25k in ISA with a DI 100 loadout and 46000 lbs:
- Expected FF: 6300
- Observed FF: 7900
That's a +25% error in an area of the envelope that should be quite commonly encountered, near optimum cruise aoa. Either FF or drag seem to be significantly off.
Ref: specific range chart for 25k 46klbs
Most likely other data points will render similar errors.
-
No, I don't, other than this highly unusual handling characteristic that the DCS hornet shows not being documented in the NFM handling characteristics, which should be enough evidence by itself. Any conventional aircraft is not expected to roll further into the turn as that would make it display negative static lateral stability.
-
Hi,
After the last FCS/FM update, the hornet still overbanks considerably when in PA mode.
-
1
-
-
Not a bug as such, but definitely something to raise as a dubious gameplay decision.
For a few updates already, the controls freeze when the salute command is given, until after catapult launch.
While the intent behind this may be to simulate that no inputs are possible when the pilot models' hand away from the stick, this can result in very undesired behaviors. For example, if the salute is given with the controls in a "wrong" position, the player will be unable to return the controls to center. This is completely unrealistic. Another example is if a prompt correction is needed after launch, this is also not possible until the pilot model animation finishes and the game allows the player to make any new inputs. In both cases the player may end up crashing, while nothing would prevent a pilot irl from actuating the controls.
Please consider reverting this change, or at the very least adding an option in the module settings to toggle it on/off. For those of us that don't use the pilot model, this is just a nuisance.
I don't think that a track is needed for this but let me know if you need one.
-
1
-
-
Hi,
2.8.2 introduced some scripting changes regarding when Group script objects get deleted. Previously, they existed even after all Unit objects had been removed.
This has highlighted the fact that DCS currently doesn't trigger any event when an aerial Unit gets despawned after engine shutdown and will make any scripts that make reference to that Unit or Group crash after the Unit/Group gets despawned.
Please consider adding a new event that gets triggered on unit despawn, or triggering S_EVENT_UNIT_LOST also at that point.
-
1
-
-
The OP is correct regarding the SA-2 and other non-CW waveforms in DCS wrongly illuminating the CW light. The SAM light turning off at the missile launch is also wrong.
The CW light indicates that the system has detected continuous wave illumination (@BIGNEWY refer to the FRM, among other documents, for evidence of that).
As a rule of thumb, CW illumination would normally be linked to SARH guidance. DCS seems to not distinguish between command guidance and SARH guidance for SAMs, the same way that it doesn't support different tracking/guidance methods for the different phases of the engagement.
This is one of the many issues affecting the implementation of the DCS Hornet's ALR-67, together with the wrong implementation of the different lethality categories, missing HUD EW symbology (flashing long stem being the main miss), tones wrongly playing together, etc. Hopefully ED will pay a visit to the Hornet's RWR at some point to fix all these points.
-
1
-
-
what's exactly wrong here? Tuning the paired channel of a VOR/DME station should receive DME from it, the same way that a VOR/DME receiver can tune a TACAN paired frequency to receive DME for it.
-
2
-
-
Also, a lot of useful things for the player happen there, such as setting voice callsign or flight lead/mission commander status. With the new L16 improvements in other modules, it needs to be implemented in the hornet to access basic stuff such as the voice callsign.
-
1
-
1
-
-
With the wings folded, the AIL row should be Xd out, as no hydraulic pressure is being supplied to the aileron actuators.
Source: multiple checks and cautions through the NFM-000 to ensure that AIL row is Xd out with the wings folded, including after a FCS reset and FCS BIT.
-
Thanks for the reply @Lord Vader.
Are you sure that the MC switch has no function? Part of the logic at least seems to be implemented (MC1 OFF -> loss of various SUPT menu options, MC2 OFF -> loss of STORES option on TAC menu). What is missing is getting the associated MC1/MC2 cautions, when the switch is moved to those positions.
Thank you!
-
Xs should appear on the FCS status monnitor PROC row for CH1 and CH3 when the INS ATT caution is displayed or ATT switch set to SBY.
Source: DCS F/A-18C Early Access Guide (DE) F/A-18C (digitalcombatsimulator.com page 71 (and NFM)
-
The MC1 and MC2 cautions don't show when the respective MC is off.
("Functional Check Procedures"), Before Taxi, Mission computer operation, and Status Monitoring Backup.
-
Hello,
The L FLAMEOUT and R FLAMEOUT cautions and their associated "engine left, engine left" or "engine right, engine right" aurals don't sound when RPM drops below 60% with the throttle at or above IDLE.
("Functional Check Procedures"), Engine Start, Engine Fire Light Shutdown.
-
1
-
Q: Why is the Hornet's rudder the only one that works the other way around? (below ~4.7 AoA)
in DCS: F/A-18C
Posted
Not a Hornet but:
Regardless of being FBW or not, aircraft are usually designed to fly like..... aircraft.