Comrade Doge

That would be correct as is as far as I know.

Hello all, I have noticed that after the new RWR sounds were implemented, a particular old sound is still present in the game. When a new airborne contact is detected, the correct sound (2 high pitched chirps) plays together with the outdated one. I will attach a trackfile showing the behavior, and also the audio file of the outdated sound that's still playing, so that you can easily recognize it. They start playing at the same time but hopefully you can hear it, even in Wags' video. Hopefully this can be easily removed, since it's quite redundant at the moment. Thanks leftoverRWRsound.mp3 RWRoldSound.trk

The sounds shown in the video will still apply regardless of handoff mode. Handoff is not yet implemented even in Wags' video, and when it is, it will add even more sounds.

Yes, it seems to be problematic again... 2 things have to be done at the moment, the ellipse following the actual FCR LOS (which moves slower) and showing the X once it crosses the gimbal limits. Perhaps @BIGNEWYcan confirm if these 2 things are already on the to-do list.

It is curious how Wags told us that the pod and some other features will be actually delivered for early access. Guess it changed again?

You can also see the overlap for our block as well

Indeed I am running slmod, but I have also commented out the lines in the Slmodv7_6 file, and it still cannot find the http module for example....

hi guys, I tried commenting the 3 lines out, but on every server start they are overridden again and uncommented... any way to fix this?

The errors shouldn't do any harm, maybe I will take a look at them in more detail when I have time... Regarding the A10, PM me a video and I will have a look

Hello again, one more thing to note about the mechanization of the HMCS and the ACM BORE submode, about which I have seen other posts, but no bug report regarding this following matter: The Ellipse shown on the HMCS should be following the FCR Line Of Sight (which in turn follows the HMCS LOS). Currently in DCS, the Ellipse just follows the HMCS LOS, being fixed to the head of the pilot, and not showing the actual FCR LOS (which moves much slowly than the pilot's head can). The evidence for this behavior is present in the publicly available MLU M3 Update Manual, page 76, the bottom-most subtitle (Slaving ACM BORE). I am attaching a trackfile showing the current implementation, in which I move my head with a higher speed than the FCR can follow, and yet the ellipse does not lag behind, as it should. Thanks for the time and any further discussion is most welcome! HMCSellipseNotFollowingFCR.trk

Hello readers, I've recently decided to post this bug report in hopes that this small thing that I've been nitpicking about will be ironed out. That is, once a lock has been gained in DGFT mode, using the ACM BORE submode and the HMCS, the ellipse shown on the HMCS should dissapear. The evidence behind this is present in the underlying meaning of the ellipse, that is, to show the FCR Scan position on the HMCS to aid the pilot into locking the target. Once a lock is gained, the FCR points to the target itself, and the ellipse should no longer be tied to the HMCS, and disappear. This is supported by publicly available documentation such as the MLU M3 Update Manual, Page 77, first 2 lines below Figure 6-33. Furthermore, video evidence has been seen (2007 Viper with JHMCS), as I will attach below, timestamped: https://www.youtube.com/watch?v=LWh31qW3kAM&t=209s (notice the ellipse disappearing once a lock has been achieved, shown by the box) I will also attach a trackfile showing the current behavior, in which the ellipse still shows on the HMCS even after a lock is gained. Thank you for your time and I am waiting for more input on the matter! HMCSellipseNotGone.trk

Unfortunately at this point you have to be in a jet for TheWay to properly store the waypoints (since certain jets have a limit on how many you can choose, so the program must know how many to allow you to select). This could be adjusted for another version...

Greetings readers, This is a rather peculiar bug I've encountered, that triggers in the following situation: when DGFT mode is entered in BORE mode, and the HMCS is used to lock a target, then the said target gets out of the FCR gimbal limits, the ACM BORE ellipse gets glitched and refuses to follow the HMCS again, being stuck to only pointing to the nose of the jet. I am attaching a trackfile to document this behavior. Have a nice week! ACMBOREstuck.trk

That feature has been indeed highly requested and implemented already by some forks of my application by talented contributors, but hopefully I can integrate it into my own version when I can get back to working on it...

Could you PM me a video of the issue? I want to see what error you're talking about and if there's a bug to fix

You don't need to change the in-map coordinates for the program to work (hence why it's not a step listed in the instructions). TheWay uses the internal mechanism of DCS to get those coordinates, so feel free to set the map coordinates to whichever format you like, it will not affect the program. Have you tried cursor zero on the TGP beforehand? The TGP starts with an unknown amount of deviation from the steerpoint in the beginning, a cursor zero action should point it in the right direction.

At first glance it appears that DCS shows you the unit in a different coordinate format than the jet...

While the ellipse is now shown proper FCR limits it still does not follow and show the actual FCR LOS and it's still stuck to the HMCS LOS. Perhaps @BIGNEWY can help us with a status on this issue....

I see. Thanks for the information

In the case of the SD-10 and 120, the switch sets the distance from the target when the missile goes pitbull, just like the AIM-54 used to work. Is that possible to be done as well for the 54C, perhaps with the new API, just like the other missiles can?

I see... Correct me if I'm wrong but I've seen missiles such as the SD-10 and the AIM-120 being able to be set the target size switch from the jet (JF-17 and Hornet). Am I correct to assume that this is a feature of the new missile API?

Is this considered correct behavior, or is supposed to be fixed in the future?

Who knows maybe the Viper team has less people now, and the speed of doing things changed...

If you could PM me a video that would be great, I am currently in vacation though, but I'll have a look

I am sure many are waiting patiently for the next AIM-54 update... And since I am sure the following question would arise in any moment, I will ask it here if I may, if there is any chance that the AIM-54 improvements in question also include the self activation capability of the C variant. Many thanks