[124th FS is recruiting Viper pilots (One Actual)]

The 124th FS is recruiting Viper pilots for weekly missions as part of the One Actual community. We fly weekly in a realism environment, and utilize real-world tactics, techniques and procedures. Each week, we work on tactical problems in preparation for large-force exercises. Training and mission nights often include human AIC, JTAC, and ATC players.

We fly on Thursdays and Saturdays at 2100 ET, with lots of ad-hoc activities during the week. If you are looking for a high-quality multiplayer experience in the Viper, join our discord and introduce yourself: https://discord.gg/d5fYjBadrc

Prerequisites:

• DCS Open Beta

• NTTR and Syria modules

• Must be 18 or over

See us in action: DCS Red Flag 23-5 (flying as Dagger 1 and Cutlass 3 as REFOR)

Some additional info:

What are the goals of the 124th FS?

• Work towards higher-order tactical problem solving and situational awareness
• Excel in multi-ship, large-force operations
• Build a culture of learning and constructive feedback
• Build a solid foundation of aircraft knowledge
• Build and maintain a reputation of professionalism and quality

What sort of things will we be doing?

• Thursday Night Vipes: every Thursday night at 9ET will be some sort of activity. Could be a training op, created mission, public server raid, etc.
• Large-force community events, such as Red Flag, AMVI, One Actual etc.
• Ad-hoc pickup missions or public server raids

For more information about One Actual: https://forum.dcs.world/topic/325979-one-actual-sim-meets-reality/

[Waypoint TOS changes based on when a user slots (using "Fix Time" on waypoint)]

I was attempting to set a fixed ToT for a waypoint for a Client/Player slot jet. I realized that the TOS values were off if the user slots in after the mission has started. I would expect the ToT to be fixed no matter when the pilot slots into the jet.

This is especially problematic in multiplayer (where someone might slot in after the server is un-paused), but reproducible in single player.

Reproduction Steps:

1. Add a waypoint with an ETA and "FIx Time" enabled

2. Slot in at mission launch and observe the STPT page for the steerpoint

3. Un-slot and let the server tick for a few seconds

4. Re-slot in the same jet (or another), and observe that the TOS value for the STPT is incorrect.

 

Expected Behavior:

The TOS value should be consistent with the Fix Time set in the Mission Editor.

 

Actual Behavior:

The amount of time the mission has been running will be added to the TOS. For example, if you re-slot at mission start + 17 seconds, your TOS value will be increased by 17 seconds.

I attempted to reproduce this in the Hornet, but it doesn't seem to take any "Fix Time" values for waypoints. Not sure if that is a bug or just  hasn't been implemented yet.

Workaround for this is to have everyone slot with the mission paused.

viper_tot.trk tot_test.miz

[VHF Radio freq formatted incorrectly when set in the Mission Editor]

The DED "COM2" page seems to have a decimal out of place.

Reproduction Steps:

1. Configure a preset channel in the mission editor for COM2 (VHF)

2. Hop in the jet and press the COM2 button

3. Compare the two freqs listed on the page

Expected Result:

The corresponding freq values match

Actual Result:

The one below PRE appears to be off by a decimal place.

 

Screensots, miz and track attached.

 

 

fm_radio_test.miz viper_radio_2.trk

[WCMD and JDAM VIS mode slew won't slew up]

When using the VIS mode for INS/GPS guided weapons, it is not possible to slew up after designating

Reproduction steps:

1. Using a JDAM or WCMD, set the mode to VIS

2. Slew onto the target

3. TMS UP SHORT to designate

4. Attempt to slew the target designator box in the UP direction

Note: I am using an axis on my VIRPIL CM3 to slew. I did not test with buttons.

 

Expected Behavior:

The TD box in the HUD should slew up

Actual Behavior:

The TD box continues to slew down or just goes off in an unexpected direction.

 

Tracks and Mission attached.

hud_slew_broken.trk hud_slew_broken_jdam.trk hud_slew_broken.miz

[ECM pod in "Standby" mode results in a NO RAD condition]

It appears that after enabling or triggering ECM emission in a jamming mode that stops the radar (XMIT 3 or XMIT 2 after a lock), then changing the ECM pod to STBY, the FCR does not begin operating again. Not sure if this is a bug or a nuance of the IRL system.

Reproduction Steps:

1. Put the CMS system in MAN

2. Put the ECM control panel into XMIT 3

3. Enable ECM with CMS aft

4. Put the ECM power switch in STBY

Expected behavior: the FCR begins operating again when the ECM power is set to STBY

Actual behavior: FCR does not begin operating again until turning the ECM pod all the way off.

 

Might be somewhat related to this (although slightly different): 

 

 

ecm_norad.trk

[Viper INS Alignment stuck at 10]

As long as A/G weapon accuracy isn’t degraded by not going down to 6. Thanks @BIGNEWY

[Viper INS Alignment stuck at 10]

Reproduction steps:

 

1. Engine start

2. INS to "NORM ALIGN"

3. Wait for the alignment quality to tick down

 

Expected Result:

Alignment quality should hit 6 on "NORM ALIGN"

 

Actual Result:

Alignment quality stays at 10 and goes no further

 

Track was bigger than 5MB:

https://www.dropbox.com/s/lrv02mgigvsenig/viper_ins.trk?dl=0

[AIM-120C losing targets easily for chaff even at close ranges]

 

20 minutes ago, BIGNEWY said:

thanks we will take a look, and run it passed the team in the morning. 

 

Edit: I'm not an expert with missiles by any means, but I dont see a problem in these tracks. Looks good. 

I was just posting some low-to-high shots, which seem to have a higher Pk than the inverse. I'm just looking for confirmation around notching.

[AIM-120C losing targets easily for chaff even at close ranges]

@BIGNEWYCan you confirm that this effect is a result of the missile looking down at the target, which might cause the target to get lost in the ground clutter (notch)?

 

The effect does seem less pronounced when firing from low to high, which makes me think its being caused by a notch (high to low shots). Here are a couple low-to-high tracks:

fox3_test_3_30k_2.trkfox3_test_3_30k.trk

 

Corresponding tacviews:

Tacview-20210202-115344-DCS-fox3_test_low_hi.zip.acmiTacview-20210202-115726-DCS.zip_low_hi.acmi

 

I did see 1/6 missiles dive for chaff while looking up at a target, but anecdotally, when the missile is looking down there seems to be a very high chance (greater than 50%?). Given that AAMRAMs loft, this will mean that a high percentage of missile shots will be looking down.

 

I understand that a bigger sample size would be needed to determine anything empirically.

 

Any additional insight would be greatly appreciated.

[[REPORTED]A/A radar cannot STT outside of 30nm OB 2.5.6.54046]

The Hornet radar has trouble locking things up outside of 30nm. Steps to reproduce:

 

1. Attempt to STT lock a hot aspect target from greater than 30nm away

 

Expected result:

STT lock should acquire and hold

 

Actual result:

Radar goes to "MEM" state and eventually drops STT lock.

 

Track is attached.

 

RWS SAM (not sure if this is the name for it) mode can successfully bug a target, and TWS works for launching missiles. Both fail when you try to STT.

 

I tested on both Syria and PG (just in case) and its the same behavior.

radar_syria.trk

[[REPORTED] HARM lofts way over target DCS 2.5.6.52437]

HARMs appear to be lofting way over the target after the latest patch. Steps to reproduce:

 

1. Launch at a target from 6nm or greater at medium (~15k) altitude

2. If the target is fairly close, the missile will fly way too high over the target

 

Close in shots that do not trigger the lofting logic seem to be working okay. Mission and track file attached.

 

This was the search that I used; apologies if this has been posted earlier: https://forums.eagle.ru/search.php?searchid=36676252

harm_test.miz

HARM.trk