Octav

Hello Han, Can you tell me your source? My sources tend to say the contrary. The missile is doing inertial navigation in the first phase, and the radar sends target coordinates updates, during this phase. So, if the lock is broken, the missile will navigate to the last known interception point, and if the radar reaquires lock, it will start sending new information. Octav

Bug... At least in the inertial/radio correction phase, the fighter's datalink sends corrections to send the missile to the target it tracks, so if you switch targets the missile will follow you. In the final, semi-acive phase, if the targets are too spaced apart, the missile might loose the target, and miss. Octav

Sort of... whilst the maximum RPM indication of the RD-33 is 103%, it usually happens only during transients - when engaging or disengaging the afterbuner, or during rapid spool-up. For normal operation, nominal RPM at full military thrust or afterburner modes should be 98%. Octav

Actually, it detects them, but since TWS is actually a scan mode, not a lock mode, it won't provide a lock warning. Actually, this has no effect - the radar duty cylce (the transmitting/non transmitting ratio) is very small, and since the receiving antennas can sense the signal strength, they can reject the plane's radar interference - there's no problem in seeing your opponent, in a head-on fight, with both fighters locking each other, on the RWR - this has been tried.

Being a close combat mode (that's actually it's name in Russian), this mode has to go thorough a lot of challenges. It has to be able to track both recceding and approaching targets, attain and maintain lock even in the case of zero doppler, and avoid beng fooled by ground reflections. In order to do that, it uses medum PRF (same as in D mode), it has a different set of doppler filters, to avoid loosing contact of a zero-doppler target, the radar receiver is set to a lower gain, in order to reject clutter, and the computer rejects any reflections beyond about 10 km. Octav

A HUGE one... Vertical Scan shouldn't work by design at more than 10-12 km Octav

Mine should be in excess of 1 km :D Quite a lot of mistakes - small, most of them, but it's enough to loose your trust in all the info. That would be a very useful feature - in Lockon the 29 isn't used at all as it should - none of it's 2 ways of obtaining situational awareness are implemented - neither the voice command system or the lazur system. Both of them would require some sort of GCI code to be implemented. The best solution (I think), would be to implement some sort of LAZUR system for the primary target, which will be selected by the computer-controlled GCI operator by the same principles used in target prioritisation in SNP mode, but at the same time implementing the voice-based GCI system for the other info, regarding other targets. Also, some sort of command to allow the player to request another target should be implemented. Wel, this seems to me to be quite complicated, and I think it would be quite time consuming. Maybe a better (yet less realistic sollution), would be to implement the main target on the LAZUR system, and use a secondary mode on the HDD, which would display (when enabled), a STATIC picture of the airspace around the player's plane, what would update only let's say 10 seconds after the HDD has been switched back to it's primary display data. On that static picture, which would provide some info for a limited number of planes (let's say the closest 4-8), the player would have the option to cycle through them to select it's target to be used for the LAZUR system. This could be used to simulate the info a pilot would get via voice from the ground, about the airspace situation around him. The ones that consider this sysem unreallistic could just switch it off from the options menu. It's an ideea - maybe someone else would think more about that, for 1.2 Octav

Our MiG-29's had the LAZUR datalink system. The panel to select the channel, and ecryption key was located on the lower right panel, in the middle (I'll try to find a pic). Transmitted data to the pilot included target altitude, speed and heading (both on the HUD and as separate small needles on the analog instruments). Also, the system allowed the GCI operator to remotely set radar elevation, azimuth and mode, input the distance to the target via the trarget designator box, and to switch on the radar illumination remotely, when the target was at the proper distance. Also, when coordinated with the GCI via the LAZUR system, the radar used a 6-bar scan mode, instead of the normal 4-bar mode. It was quite a useful system, when used by a skilled pilot and a good GCI operator. Also, some commands were given to the pilot, as symbols illuminating on the HUD - the ones I remember now were "Afterburner" - an F was illuminating on the left center side of the HUD, and steep climb (I don't remember the term exctly right now) - a G appeared below the F, on the HUD Octav

Looks to me to be the real thing...

The day/night switch on the hud brings up a red filter on the hud projector. So, whilst the day image is yellow-green, the night image is dark red. The air/ground switch is what selects the A/G mode - there's no sepparate zemlya mode, as in lomac - you switch to the opt mode and place the switch in ground position. And the switch you labeled "main engine start" is actually the master weapons system switch. The one labeled by you emergency canopy jettison is "emergency drop" -used for dropping bombs throuhgh the backup circuit. Octavian

Thanks for the thumbs up :) Regarding the new radar modes, I didn't have the time to test the demo, yet, but from the mode descriptions, unfortunately (and I've checked that with a retired pilot a few days ago), they've made them too reallistic this time (they made things more complicated than in real life :( ) Hope for something better in 1.1x or 1.2 Cheers, Octavian

Supesonic shockwaves, present in the jet gas flow, bouncin on the boundry between the hot gas and the surroundin air (somewnat the same as the light bounces in water when it hits the water-air interface) Cheers, Octavian

They can be removed and replaced - in order to drop bombs off pylons 1 and 2 on the MiG-29, you have to install different pylons than those used for the R-27 Octav

No way.... It would prevent you seeing the target in the first place - the clutter presents much more problems in search mode than in lock mode. Octav

I can still see the bandit - the line is there on the HUD and the icon is in the MFD. I just can't lock it . . . . like I'm in detection range, but still not within lock range. I've also encountered this problem - and I think it's a bug, normally, if you see the target, and you are within locking distance, you should be able to acieve a lock. Octav

Hm... depends on a lot of things - usually it's not gone - and this is from the manual and a pilot... If the situation is critical, and you loose lock during terminal SAR guidance, the missile can use the radar's emission in scan mode to home on the target - but because this isn't a continuous illumination mode, it has a much lower PK. And if it manages to fly outside the radar's scan pattern, it's gone...If you loose lock during the inertial guidance part, all you have to do is to re-lock the target. Now back to the original post - the R-60M, whilst credited to have an all-aspect seeker, has some limitations in the frontal hemisphere - it needs the target to be in afterburner, to get a stable lock - in max dry thrust, you may not get a lock, and to get a lock, the seeker must be informed by the weapons system to expect a front aspect target - either automatically, when you have a distance to the target in the system (from the radar or laser designator) or manually, via the ZPS/PPS switch. If you set the switch to the wrong position, you have a problem. Octav P.S. Regarding the MiG-23's EOS, I don't know for sure the specs for the ML/D, but the one installed on the MF had at best a range of 10 km, on a non-afterburning target. Let's say that you could expect up to double that, for an afterburning target, but no way 100 km - let's be serious...

No, you're right - there are a lot of gears inside, mostly reducing the engine speed - that's why it's called accessory gearbox. Octav

Nope - the best translation is Aircraft Accessory Gearbox. Because everithing not engine related is mounted on it (in contrast with the engine's accessories, which are mounted on the two KDA's). DC generator, AC generator with it's constant speed hydraulic transmission, main and booster hydraulic pumps, and the GTDE-117 gas turbine is also mounted on the KSA, and not on the ground start unit. The KSA is full of gears, and electrohydraulic clutches, for distributing power to/from engines, generators and pumps. Octav

My thoughts exactly 8) I support the ideea... Gues why .... :D Octav

I don't know if this would simplify matters, in programming - the offset rotation would still be calculated as a rotation+translation movement. And to provide enough, the camera would have to be WAY OFF the pivot point - don't forget that human eyes aren't on the pivot point of the head either, but we still have to translate our heads, to improve FOV, if the torso is fixed. Octav EDIT: if you are referring to the controls, and not to the actual movement implementation, I am suggesting combining by default the rotation with the translation - so if you rotate the head (with the left/roght controls), automatically the head will also be translated in the appropriate direction - no separate controls for rotation and translation - the keyboard is already full.

Re: Natural head movement, combining turning with tilting Of course within limits - the real limit is until your head hits the canopy's plexiglass. :D Octav

Hello guys, One day, I was thinking about this issue, of the way mirrors are made almost useless, by the fact that the pilot's field of view is just rotated around the Z-axis, instead of translating among the Y-axis (left-right, so there aren't any confusions) as well. In real life, you don't just rotate your head, you usually couple that with a Y translation, to improve your FOV, especially when looking backwards. This combined movement, if implemented, would put the mirrors to a better use, and provide more situational awareness in a furball, in a more realistiv way. I don't know how are the mirror images rendered (depending on that, this could be easy or vrry difficult to implement), but I'd like to hear an opinion regarding this, from the devs and the rest of you. Would you like to see something like this, and is it possible? Octav

I'll wait to see what you can find out - but at least, on the radar function of the ZPS/PPS switch do we agree on? Octav

Allrigh Andrew, I understand your point - but at least we can agree with the fact that the switch has nothing to do with the radar modes, except enabling SNP in one of it's positions. At the moment I'm not whining about seeker gain adjustment options, so that's ok with me - I'm only bothered by the fact that radar operation was complicated more than realistically necessary. Regardink keyboard layout - I've read that from the time it was in the F-15 thread, I find it very interesting, although it will take some time to master - maybe someone should start designing a hardware cockpit and connecting it to the PC via USB. Cheers, Octavian

Andrew, read my previous post - the ZPS/PPS switch is also used in FI0 mode, where neither the radar nor the electro-optical systems are used - just the missile seeker. Octav