okopanja

Last time I checked the warning was going off once TWS2 was replaced with mode guiding 2 missiles on launch (I do not thing they were pitbul). I did not test this recently. lapsus linguae. I corrected it, but kept also original. Regarding the general topic of RWR warnings: in DCS many of these things were implemented on assumptions and initial balancing and subsequent nerf wars had a lot to do with it. In this case I am pointing out this is very likely pulse guided missile (while others believe theory of additional signals or switching to CW), which means there is no difference between STT and after when the missile goes out. Again I will remember that range of both the radar and missile are within visual range. Not really the need to go after fancy stuff. To give launch warning you need some change in the operation of radar: e.g. sudden intensity burst or other detectable change. Bottom line: the RWR should give launch warning only if this is detectable. In DCS this is simply if then line, but in reality you might not be able to detect this.

Which signal? Again talking based on assumptions. This is not AIM-7 and later company.

We have similar exception in form of AIM-120 for which there is no indication of the launch, although it is well know that the signal is there. R-77 also has the signal, but that one gets detected . In both cases until certain point signal is a secret until the other side figures it out. ED is assuming that this signal is known (they may be even right, since the soviet radar program was compromised in 80s). However with pitiful R-3R, there is no evidence that the main radar carrier changes to CW (except for sending pulses) or that it encodes the hidden signal. Simply put for 8km distance you do not need to bother with this. It's actually within visual range and you will simply see the smoke. In theory as @GGTharoshas suggested we can talk about pulse vs CW, in which case CW would offer somewhat better flare chaff resistance and better clutter resistance. This could be even supported by the fact that first soviet SARH on KUB in later variant did support CW to deal with clutter, but this does not appear to be modeled in DCS. RP-22 radar itself is not meant for work in radar clutter, in fact it's directed upwards in order to avoid this. Hence, I do not see the reason why would missile need CW. CW could offer somewhat better flare chaff resistance if the target is notching, but in this case time for reaction is rather limited. It's more likely that e.g. F-5 pilot would maneuver before it enters into firing zone of the mig-21 head on.

I am not the one grasping here at straws, but rather you trying to hint that there is a "signal" for the radar/missile in order to accommodate the assumption that RWR is able to detect something. This is an early SARH, fired from limited platform and expectations of fancy features are probably not based on reality. Again this missile is fired within visual range, if you have a documentation for radar/missile and the corresponding RWR, then it would have made sense to argue about giving RWR warning. On the contrary, the initial claim of this topic is that RWR should give launch warning, so understanding what is detectable if at all is rather important. I would agree with @Pavlin_33that most likely the pilot would assume the missile was fired if they were in STT and certain maximal range from the target, or based on the signal level.

I would like to point out that we are talking about the missile that was developed from short range heat seeker, by replacing guidance with SARH, thus giving it all aspect capability. At such range and weapon weight having the additional signal would kind of pointless and wastful. This is not a soviet AIM-7. The RWR could therefore not distinguish STT from launch. It should be noted that radar lock and launch authorization occur at different ranges. This is due to 2 reasons: kinetic and ability of seeker to receive the signal pass s/n threshold(missile antenna is tiny compared to rp2322). The only possible method to signal the launch with RWR is to pass certain signal threshold, and even then aspect would complicate the things. Realistically speaking the pilot would launch in PPS with r-3r, since in ZPS he would likely use a heat seeker. Therefore for this era the most reliable "RWR" are pilot's eyes trained to spot the smoke.

When it comes to the lights there is a whole class of devices that can be used to provide indications outside of the DCS: other stick/throttle manufacturers devices with controllable lights, e.g.: keyboards, those with groups of LED lights or even LEDs for individual keys, mouses, Alienware devices (e.g. monitors, keyboards, cases), different LED based external solutions Great effort, although I do not have the Thrustmaster devices it is amazing that they do care. I recently asked VKB to provide command line utility to switch the profiles for their device, however I got the negative answer since it is too much effort from them to code this. Although I am extremely satisfied with Gladiator EVO, I am seriously considering to obtain Warthog throttle instead of certain new throttle option, mostly due to non-existent interface other than what is provided with standard DirectX devices.

v1.5.1 Another release bringing updates and keybindings, improved documentation for modules and very important bugfix: Shark Planner was rounding the DD MM SS format toward nearest for increased precision, however this rounding was not perfect and could have result with e.g. 60 minutes or 60 seconds without incrementing the overflow handling to next component. Comments on potential additional hotkeys are welcome. What's Changed Implemented keyboard hotkeys in #110 SPACE: add way/fix/target point DEL: remove last add way/fix/target point SHIFT+DEL: reset ENTER/RETURN: transfer data SHIFT+ENTER/RETURN: execute experimental code (no significance for common users) Most of the module hotkeys are blocked, except for function keys and User Documentation for Ka-50 in #102 https://github.com/okopanja/SharkPlanner/blob/main/Documentation/Ka-50/README.md User documentation for SA-342 in #104 https://github.com/okopanja/SharkPlanner/blob/main/Documentation/SA-342 Gazelle/README.md User documentation for F-16C in #105 https://github.com/okopanja/SharkPlanner/blob/main/Documentation/F-16C/README.md User documentation for CA in #106 https://github.com/okopanja/SharkPlanner/blob/main/Documentation/CA/README.md Updated used documentation for JF-17 in #103 https://github.com/okopanja/SharkPlanner/blob/main/Documentation/JF-17/README.md BUGFIX: Coordinates displayed in DD MM SS may end up being rounded to 60 in #101 Full Changelog: v1.5.0...v1.5.1

I think there is screen variable defined that always gives you a true size of the screen. I do not have the example here. In your case section under GUI your screen is devided into (1/4 + 1/2 + 1/4): - 5120 / 4 offsets for 1/4 of your screen - width/2 is it to draw on 1/2 of your screen

It should be possible if you repeat the command. You can also move aircraft few meters. This will be followed by angry comment from ground crew.

Yes round screen on the right. On the left side you can see thr aiming stick. The left hand of the pilot was back on the throttle at launch. Once launched you do not get picture since your sensor AGM-65A/B already flew away. Wings on J-22 are high hence a great view on the Mav. Amazing that they work after at least 40 years.

Someone asked Wags about sukhois, and answer was that there may be a red FF in the line. 29 has be not directly confirmed. For everyone who did not listen the full interview, in a way from cheerful mood at some point things ventured into areas that were more darker and related to interpersonal relationship both at work, side activities and online communities and social networks. I will not comment on that further, but I must say that this part actually made me think and compare. At the end I could say nothing but to agree with them (I hope they read this). Sadly, I believe that many people missed therefore the important things Wags said toward end of the interview.

It's a g-limiter allowing 33% more load. You can over-stress the frame with this. "Abuse" part I will not comment for obvious reasons.

Hornet paddle abuse will be adressed. Near the very end.

Do you download them separately or together?

FC3 will still be present in DCS even if MAC get released. MAC is there fore more gamey people oscillating between DCS and XXX YYYYYYY. Its a though call to challenge existing market segment ruler in their area.

I think @uboats suggested to us to test the latest release, since the ka-50 DL got fixed. I am a newbie (in Jeff) and do not have contacts who own JF-17 to test with. Also one question from my side: does this DL work only with other Jeffs or also others (e.g. Vipers) can be donors?

Update from my side: I tried several times to create a reliable reproductions. In the same mission where I observed the issue I could just marginally detect this. Then later when not focusing on this issue, I had rather pronounced effect. Unsure what was a difference. I still do not have reliable track that demonstrates this.

Which version do you use? The interface did show up on LCTRL+:SHIFT+SPACE? Can you send me via PM the dcs.log and SharkPlanner.log, which can be found in: C:\Users\USER\Saved Games\DCS.openbeta\Logs (replace USER with your username) For now, when you leave the F10 screen the SharkPlanner will be visible. This is intentional in order to allow you to click transfer and watch the show. Note: while the entry takes place you can completely hide the SharkPlanner and it will still continue the entry.

I believe you provided a very good summary, and perhaps it would be wise for all of us to stop commenting any further and let ED crunch the problems.

The thing is, the spotting dots serve both those goals, so there's really no contradiction there that needs to be prioritised between. The point of the dots is not to make the game easier – it's to make it more equitable over a wider range of displays and settings than had to be served a decade ago. Just because it's not there yet as far as VR goes does not mean there's some grand conspiracy to cater to any specific group over another. It just means exactly that: it's not there for VR yet. That's all. When there is question of equitability, I would prefer more fairness, but not at the cost of reality. The problem here is that, as this thread has begun hinting at, that advise rather works in the opposite direction: a calibrated good-quality device means the spots are working better, meaning they are less visible. A bad display and bad settings make them stand out more. Doubly so if the dots are turned off and you revert to the old system where they were already more visible to being with. A mission-enforce setting would most likely do the exact opposite of what everyone expects when doing that. Not really, mission enforce means you get to choose where you play. There are servers that offer more realistic vs those that provide the gamey environment. As the comment on this topic, when I played with 3440x1440 monitor on Enigma's server I very soon discovered that despite the super-accurate GCI and me turning onto the bandit, roughly knowing where he will appear, I simply do not see him before he starts firing the tracer rounds at me. That was the point when I realized that we do not see the same way ( tried playing in 1080 with not much improvement). Some people found the way for the dots to stand out even back before the new changes. In such gameplay visual range is really critical and decided not to play there for now. However adding dots the way they are added atm makes it rather ridiculous. As I stated before: this is not just about the dots, there are also other subjects like size of the monitor (resulting dots), distance, zooming features, etc. I do not think realistic system can be built without addressing all of this factors together. The infamous zoom feature is what effectively made almost all users map their HOTAS as one of the most important options both A-A and A-G. I personally try hard to utilize it only without my own cockpit and not peep outside of physical capabilities of human eye. So for me choice is very clear: I would pick a realistic system that does not allow the users to utilize different "helps".

Sadly there will be always 2 groups of people: realism group, interested in reality as much as possible convenience group, interested in easier of game play. I can imagine which one is more vocal. However, at minimum: server admin must be able to disable this setting and enforce on all clients. I do think ED should reconsider which one is the priority: realism or convenience and work toward providing more unified experience and limitations of built-in and external Mk1 Eyeball zoom. If someone does not still see the aircraft, ED can not do much except to advise: 1. make sure you have quality device 2. calibrate your display device. For the second, perhaps DCS should include a wizard that could help people configure their monitors, or advise them to use built-in windows wizard.

I do not thing there is anything to talk about. This actually happens all the time: many people fly very very regularly, while they focus on radar work. AIM-120 has the INS so it will go to last known position. E.g. if you do not STT them, they will mostly fly straight, in order to maximize their own speed and altitude. The longer you provide the guidance, the less likely the missile will be surprised by deviations from originally calculated intercept point. Off course the more you provide the guidance the more time is distance closing.

When you use the shkval for fix point update, the Rubikon does not know the altitude of the fix point. However, it knows fix point coordinates + own altitude and azimuth (there is electronic compass among the devices). When you point the shkval to fix point and perform the action it will record shkval azimuth, and elevation angle, while measuring direct distance (not horizontal), based on that it will calculate the coordinate update.

Well dcs.world only redirects now. But perhaps ED has future plans other than the forum itself.