xxJohnxx

Yes those lights will come. However, they will probably come with EDGE due to some texture incompatibilities.

Hmm, interesting. Yesterday I have been flying online and with the help of the data link (to find the approximate direction and range) I could get a lock on an enemy AWACS at a range of about 160km only using the IRST. At the same time the target seemed to be outside the range off the radar, as I had no luck even finding it with the radar. I am not sure if this is a bug or not, but it seems quit optimistic to me. I can provide a track later on this evening if necessary.

That definitely shouldn't happen. Over voltages on the 5V line during boot or normal operation of the PC is definitely a sing for a very bad power supply. If you got any quality brand power supply I would say that is nearly impossible. Sure, you can have a power supply malfunction, but that would destroy much more than just an external USB device. If you have a bad PSU and you are worried about it might destroying your Warthog, you better go ahead and exchange the PSU instead of just unplugging your stick. The PSU is probably the most underrated part when buying PC components. When it dies, it definitely will take some other components with it. They should only be lit up when the PC is running. If you leave them plugged in (as probably most people do), your hard drive, monitor and generally anything in the PC will fail before your TrackIR leds will fail. If we assume that the IR Leds have a minimum lifespan of 20000 hours (which is easily achievable today) and you operate your PC for 10 hours every day, the LEDs will last for at least 5 years. Given that the 20000 hours are easily exceeded, they probably will run 10 year at 10 hours per day operation before they fail. And especially with the ProClip, you will have broken that damn thing long before the LEDs will fail. So no, I don't disconnect my joystick, throttle, rudder pedals, TrackIR camera and ProClip. Neither do I disconnect my mouse, keyboard, several Arduinos as well as the 3 monitors that also serve as USB hubs whenever I boot my PC.

If we ignore the fact that you forget to turn on the nose cone power switch, the auxiliary hydro pump and the trimmer, we can assume that this is the affects caused by pitot freezing, which indeed seems to be simulated.

I installed the 344.75 drivers today, and I still get that flickering of programs like windows explorer and Firefox that where introduced after 344.11. Not sure what the cause for the flickering is, but it is getting a bit annoying (the aero parts of the windows randomly start to flicker for a few seconds every then, while the rest of the program is unaffected). Additionally GeForce Experience does not recognize my dual GTX 780 properly anymore, and it says that my system is not ready for game optimisation. Not that it really matter, just wanted to mention it anyway. For me it seems to be back to 344.11.

Yeah, either upgrade the card or go for a second one. I am running on 5760x1080 on two SLI'ed, overclocked GTX780 with 3GB of Vram each. It runs okay and keep at a solid 40fps most of the time. But even with that setup I get low frame rates now and then.

No

As far as I know the engine sounds where WIP anyways. An official confirmation sure would bring some more light on this though!

The engine has it's own mechanically driven pump that should be able to get fuel from the dispenser tank to the engine. However, getting to fuel to dispenser tank might be a bigger problem. There is a presurization system that uses bleedair to press the fuel out of the tanks, but it is usually operated together with the fuel pumps, so I am not sure if it the pressurization system is sufficient to bring enough fuel to the engine.

They also fixed that the nosecone-power switch would go to the off position upon rearming.

Hi, In version 0.0.5 I addressed the problem of a wrong (to0 high) speed being displayed. Thanks for fable2omg for pointing that out! I also addressed some crashes that could occur in some situations. Download version 0.0.5: www.blumen-huschle.at/John/SARPP/J-SARPPV0.0.5.zip Changelog: - Fixed the problem where a too high speed would be displayed. (The SARPP recording was changed from m/s to km/h, therefore this problem started to appear. Yes, this was exact the opposite in the last update. They tend to change this around a lot it seems. - Addressed causes for several possible crashes. Userguide: After opening the programm add one or several graphs by clicking on "Add Graph" (1). Now, select the SARPP-log which you want to view from the list (2). By default the last log is displayed. Now select which data you want to view on the "Primary" (3A, left axis) and "Secondary" (3B, right axis) to view. You can make as many selections as you want, however you must select at least one option from the primary axis for the graph to be displayed. Once you made the selections, click on "Draw Graph" (4), and the graph will be drawn. You can repeat this process as many times as you want. You can also "re-draw" the same graph again, or remove it altogether. Your feedback is appricated! Thanks, John

SARPP is just recording fine for me. Got 3 recordings from the flight I did today.

No my friend, that is crazy. 360-370km/h is the maximum speed the tyres can survive. Anything in that speed is crazy.

Yes, I noticed that as well. Even without any wind the aircraft seems to be leaning a little bit to either side.

I have to correct myself there. I just flew a couple of approaches with the latest update installed and it seems approaching at 320km/h (and with an allowed amount of fuel remaining) works quit good now. The visibility is within what you would expect, the decent rate is within reasonable limits and only a little flare is required. See the attached track. MiG-21Landing.trk

In theory (as stated in the handbook) the approach should be flown at 320km/h and the touchdown should happen at a speed of about 290km/h. This however is very hard to accomplish in the DCS MiG-21Bis mainly because of visibility. At a safe decent rate at least. Another thing that is apparently not simulated is the SPS throttle interlock. Once the SPS system goes active (rpm between 50% - 100% and flaps > 30°) it should not be possible to reduce the throttle to idle because of an interlock system. The interlock system is designed to prevent the SPS system from getting ineffective due to too low engine rpm and therefore too little bleed air being produced.

Thanks for the response! That is very interesting indeed, I thought for the most DCS aircraft no-curves represent the most accurate input configuration. Will adjust my curves then!

Given how the system is set up (using compressed air from a bottle) I do assume that you don't need electrical power for the oxygen system.

Yes, the MiG indeed is a great module! none

This website states that the fuel system uses bleed air, auxiliary pumps and engine driven pumps to pump the fuel to the engine. The engine driven pump sure would explain why you could start and run the engine. The bleed air would help as well, once the engine reached idle RPM. However, the question is, why would the engine stall again, once you increase RPM. Could be because of higher necessary fuel flow, that the engine driven pump and bleed air system can't provide. Could have other reasons as well.

I am not sure what point you are trying to make here, but neither a resolution of 1024 nor 512 is very good. The Warthog for example, has a 16-bit ADU which results in a resolution of 65536. Back to topic though, I personally have not seen any of that stick-jerking in DCS. My stick here moves smoothly and is far of from being like in the videos you gave as an example. However, the stick and especially throttle movement is indeed delayed by a tiny bit. This could have various reasons, but I assume that it has to do with either of both: - Simulating a slow movement because of the control forces the pilot had to overcome. - Using filters on the axis to prevent any control spikes. When filtering movement axis inputs a delay will be created that causes the simulated axis lag behind the real one.

If you want the problem to be fixed, attach a track. Such problems are not easy to reproduce, therfore a track will definatelly help.

Searching for Calverton and Tomcat gave me this: http://en.wikipedia.org/wiki/Calverton,_New_York

Another thing you can try is to use the Low Altitude Radar modes. When elevating the radar by 1.5° you might be able to pick up the helo at 1500m when you are flying at 1300m.

While this is not directly regarding the problem you have, there is a diffrent kind of problem behind the Kh-66 and RS-2US. Both the Kh-66 and RS-2US where developed for the MiGs with the RP-21 radar. The MiG-21Bis had the RP-22 radar. There are a lot of diffrences, but the most significant changes that matter here are the frequency and the way the radar works (Glimmertracking (1) (RP-21) vs. Monopulse-Tracking (RP-22)). A lot of signal processing was changed to. Also the RP-22 could track targets that where 30° off-bore in all directions (as long as there is no ground in the background) where as with the RP-21 the target had to be straight ahead of you. Now to the problem: The RS-2US used the Glimmertracking (1) plus additionally by the radar sent, oriantation info to guide itselfe to target. Now as the RP-22 uses a diffrent aquisation mode (monopuose-tracking), the RS-2US is not usable by that radar. (When adding wiring to the pylons you might have been able to fire it as a unguided missile. This was considered to be used by the Jak-25 and Su-9 against ground targets) Basically the RS-2US was more or less replaced by the R-3R with semi-active radar seeker that was capable of locking up on the reflected signals of the radar by iself. Against ground targets the RP-21 had to be brought into the fixed beam mode to fire the Kh-66. The fixed beam mode was actually developed to range (!) airborne targets in jamming conditions. The inital desing did not send out oriantation information for missiles. As the Kh-66 and RS-2US were introduced, the RP-21 complex was modified to send out oriantation info in the fixed beam mode to guide those missiles. This is also the reason why you have to fly and dive towards the target, because that oriantation info was constant. The RP-22s fixed beam mode is very similar, however there where two major changes: - The frequency has been increased from 2.4GHz to 3.2GHz. - There was no oriantation info send. (this is belived by the source I am quoting (ex-MiG technican). It is a major IF, because there could have been modifcations to the radar, but at least the source does not belive so). These changes had the following result: The RS-2US was definatelly not operatable together with the RP-22 radar and the Kh-66 might also has been unusable with the RP-22. I unfortunatly lack further proof to confirm if the RS-2US was realy not usable with the MiG-21Bis, but the technical evidence points into that direction. (1) This is the best translation of "Flimmerpeilung" I could come up with. I am not sure what the exact technical english term is. Note: This is not a request to get the RS-2US removed from the DCS MiG-21Bis, it should just be an argumentation if the RS-2US was available on the real MiG-21Bis.