Spectrum Legacy

Nay, not in Eng, at least I haven't heard about possible translations for now. In any case, the book is super-fresh and apparently not even biggest bookstores have it in stock yet . Some details in slovak language about the book: http://www.siaf.sk/aktuality/siaf-2016-s-novou-publikaciou-pre-fanusikov-letectva.html Maybe it was mentioned in some other thread already, but I've recently rediscovered one old Czechoslovak documentary regarding Mig21 & 23 operating from the temporary base (highway drill). Apart from the period propaganda and filler material, it contains couple of nice shots: Consider it a bonus instead of the book in question! :D

You know, it might be by design this time... It appears as if the background matches the colour of the cockpit and red says cccp like nothing else. You can always look elsewhere if you don't like though.

From what I read, the kh-66 grom could be carried by Mig21PFM (RP-21M 'spin scan') and some variants of Mig23 (sapphire 23 'high lark' with the note that it has to continually illuminate the target and the missile in flight as well). Shortly after, the missile was upgraded with manual steering by joystick in the cockpit and it says that it could be carried by Mig23, Mig27, Yak38, Su17, Su20 and Su24 variants. RS2US could be carried by Mig21 PF / PFS / PFM / R / S and Su9 / U. Radar used was RP-9/-21 'spin scan' or RP-22S sapphire-21 'jay bird' in the S variant of Mig21).

Why not dropping the campaign files into both planes directories during the install? It seems simple enough. One pre-selected Mig15, another with F86, each in their respective folders. It would possibly require more harddrive space, but you would get to play the version you want if you have the corresponding plane required without any hassle. In theory you retain single entry in the store, single key/activation/registry entry etc that way.

Ah thanks for clarification. I didn't realise that ewr/gci utilises the same comm channel called awacs! :doh: I know it is not much of help, but if you are on the ground with L39 and the radio is deaf, make sure you have enabled battery, both invertors and the radio station. At least I sometimes have forgotten the invertors, when in mood of just sitting on the ground and talking via radio. :P Just tested all 4 L39 slots, awacs communicated all the time from the ground, so all works great - noticed as well the soloflight+no ifr hood slots! :thumbup: Cheers for the sehr geil server, I personally love it because of the no-bs attitude (no external views and other crutches enabled)! However some people reported lower-than-ideal fps because of those huge regiments of ground units in rectangle shaped formations, if they are still there in the same numbers. Maybe they are just temporary, or for weapons blast radius / effectiveness testing? I thought nuke testing included targets in circular pattern, not dense rectangle, but I'm no expert! :D Thanks again and keep it up!

That's where the ambiguity in the pdf comes from. It is not stated clearly, where I could say with certainty it is either of those two cases. I got the impression that the whole table is regarding the movement of antenna and its limits. If the author or translator instead mixed in plane attitude of pitch and roll, it would be confusing, but it could of happened (especially because of usage of those two words 'zdvih' and 'pad', where the former is more appropriate for the antenna, while latter would be more suitable for the plane). I'm more inclined to the symmetrical operation, as the antenna in tracking/locked mode can follow the target 30° either way from the centre. But again, it's just my interpretation and the pdf itself is far from being detailed - so I don't know exact scan pattern, or the overlap zones, or whether the beam width is taken into account where those limits and angles are stated. 3sec repeating scan time is in search mode. Basically it takes 3sec to get the updated picture on the screen. In target tracking/lock mode, I reckon it is much higher frequency because the beam is focused and as stated, it can endure 10chaff charges per 100m of distance travelled by the target.

I'm not very experienced in the mission editor, so I don't know what might cause the issue. The multiplayer mission in question is utilising the awacs plane and Mig21 has channel 0 set to 124Mhz AM for communications with it, which works. I've loaded up the singleplayer mission of Mig21 module called Intercept, swapped Mig21 with L39ZA and edited radio preset on radio station channel 0 to 124Mhz and awacs responded to me every time. I'm using the simulation preset, so no easy comms, radio assists etc.

After reading the pdf, the only ambiguity comes from the table of operation. However since it's about the radar, I assume those angles belong to radar antenna movement limits when it tries to compensate and gyro-stabilise (as long as it's within those limits mentioned in the table). Also the second part which describes the radar screen itself and lazur system is translated less carefully both in czech and slovak language and contains some typos, more ambiguity etc unlike the first part, so the sources might vary. It states scan area to be ±30° horizontal and +17° ±1,5° vertical in search mode (which would coincide with game manual), with gyro- stabilisation of ±70° on longitudinal axis and +8°, -25° on lateral axis. (The words used are little bit misleading as 'zdvih' might mean here in context the tilting upwards, but usually it means rise, or stroke (for piston engines), while word 'pad' literally means the fall or rapid descent, but most likely it means here downward tilt) - yet the latter word would fit more describing the attitude of plane in dive, instead of radar antenna movement). Following the target in the tracking mode is ±30° vertically and horizontally, 3sec repeating scan time, 500m blind zone in front of radar, max time with radar on is 30min and standby+on is max 90min per flight. Of note is the ability to search, lock and track the target reliably even if it utilises passive countermeasures in frequency of 10 chaff charges per 100m of distance - in other words almost impossible to disrupt by passive countermeasures. The width of radar band/beam is 3°. Altitude compensation mode is as we know it: off, signal filtering/compensation and tilting the antenna upwards (it states +1,5° +2° above horizon). Fixed beam mode is at -1,5° downward tilt, horizontally centred (the lower X mark on the fixed net). Also confirmation about button #2 being used for locking targets which are flying at low speeds, #6 anti passive countermeasures filter, #7 anti active and passive countermeasures filter, #8 anti active countermeasures filter (where the range is fixed between 12 and 18km distance). Only one filter might be active at the time. If you have any questions regarding other parts of the pdf, let me know and I will doublecheck.

Could you please enable awacs radio frequency also for L39ZA? I've cycled through all 20 radio channel presets, but couldn't find the working one. Also it would be interesting to have solo flight (leaving the instructor home) & shroud (hood) off...for improved rearward visibility. Maybe currently 2 out of 4 planes spawned as solo would do the trick. Cheers!

Fred, I've missed your question earlier. The possible misinformation about radar comes from the manual which states that it operates in ±30° in azimuth, -1,5° and +17° in elevation (p.136 - I reckon it is search mode, although these numbers would be more suitable for target tracking mode). I believe this is how it was modeled since the beginning. I have no idea whether the version of radar LNS studied was any different from the stock one, so I don't know the details. Example also here: http://www.digitalcombatsimulator.com/en/files/921515/

So it was the cold wind's direction responsible for all this?? Next time I will bring my trusty ushanka! :prop: Great that you guys figured the cause. Hopefully it can be fixed in the future patch (along with that missing high-AoA sound, would be sweet). Cheers!

I've read the manual when the module came out and remember it stating that 100 is default, hence I never adjusted it. But the option is there made available for reason, so why not to use it. Also I've observed no difference with the ground shake issue reported here between values 0 and 100, so it might be unrelated. After double-checking, it reads: "COCKPIT SHAKE LEVEL - you can tune the level of cockpit shake with this slider. The default value is 100%, meaning normal cockpit shake level. If you fly precise aerobatics for example, you might want to set 0% cockpit shake for increased flight precision. Maximum shake level (e.g. for video filming) is 200%."

Most likely it's what I call "so veeeery cold" frantic microshake introduced with the latest patch. Cockpit shake level set to 100 at my end since ever, no trackir - simple mouselook used. Default 'Take off' Mig21 instant mission. Also note the AoA indicator gauge acting funny, though I'm not sure whether it is related to the issue. My only guess is that I've parked on some kind of binary "bump" which should shake your cockpit a little as you pass over it. Please excuse the poor quality of recording, it was done in haste, YT re-encoded it and compressed even further. However I commend YT for detecting that something is amiss indeed and offering me some assistance :P "Improve your video We detected your video may be shaky. Would you like us to stabilise it?"

At 2:36 in the first Hadwell's vid, the bandit is flying lower, so he dives for him from ~2km agl but can't pick him up on the radar. In attempt to do so, he levels up and inverts, utilizing the 17° cone above his nose instead. The altitude is getting a little bit low ~1km agl, but there is still some distance left to the target before it gets masked by the ground reflection (flat surface of sea in this case). Lock is achieved kinda in the last moment in this case before it enters into ground clutter - any closer in that scenario and you have to switch to fixed beam. On the side note, notice the piper tracking IR sources - most likely courtesy of forced settings by the server. As Cobra said, they will check the 1,5° downward angle of detection for the radar. Also for people experiencing issues, I suggest testing it in singleplayer where you remove variables of server settings (even those hidden from you), netcode, possible latency issues, etc. Also stating if you are using all the sim/realistic settings or game avionics mode (or whatever it is caused), easy radar, etc could help. Also what Frederf mentioned before, selecting and deselecting these settings might help with overwriting "stuck" values in the config file, especially after updates.

Basis server has some assistance enabled, like easy comms and radio, from the quick glance at least. Grunf if you can, try ACG f5e vs mig21 server or singleplayer. I've just tested the Basis server and indeed piper follows the ir sources there, so I believe the less realistic behaviour and/or other assists are forced there, as I don't experience this on other two servers where I fly, nor in the SP. When there is some kind of doubt about possible bug, SP is your first stop as it offers controlled environment for you to 'experiment' in as MP server settings may vary and only makes life harder by adding more variables to determine whether there is something wrong or not.

OP, do you mean the ⊤ and ⊥ symbols on the radar being inverted, at least according to the instructions in the manual?

I'm not really bummed about the rotor blades being static too much - it's been a while like this. Not every plane in dcs has them animated...it is nice little touch though and knowing LNS are striving for perfection and attention to details, it might be remedied at some point. However there are more important things right now I reckon. About the update, does anyone experience cockpit shaking in the 21 when you make a full stop during/after taxi? I didn't have that takeoff shaking some users reported earlier, but after this last patch, introduced this "so veeery cold" frantic micro-shake (with trackir off).

I personally don't have the old IR reticle following targets in the mp, but it would be worthwhile to check more servers and/or backup your config file and let dcs create a new one at least for trying if it helps or not. On a side note, I remember flying Dora on one server and noticed different behaviour during takeoffs. Then I noticed it moves the rudder itself, so take off assist was forced on iirc. There were servers with some slots labeled as 'easy' and others as 'sim', so I would suspect the easy ones were with assists. Was a while ago though, either late v1.2 or early 1.5.

Because there are possibly 2 buttons in the plane. One is SPRD Drop (near throttle under red cover and it either drops rato booster, or dispenses flare/chaff if ASO is installed there), another button is when you use SPS pod, which is located on the additional panel installed on top of optical sight. Third button you mentioned is SPRD start, it is on front panel under black cover and it acts as manual starter for the rato/sprd boosters (should be unrelated to chaff/flares themselves though). Pairing sprd drop + sps countermeasure release button into single command is practical for those who have <100 button joysticks imo :D

In the current version, ASO chaff/flare dispenser bug happens to me as well both SP and MP. To reproduce it, spawn mig21 in mission editor already in the air, create new payload profile with ASO equipped (48f+16ch as recommended). In flight enabling SPRD on & drop switches on the right horizontal console and removing the Drop switch cap on left side. Hold the button down until you empty the dispenser. First time it works every time at least for me. Quit > Fly again (without going back into editor). Repeat the steps above in attempt to drop flares/chaff. For me, second time there is a good chance it will not work (it acts as if the cover was closed, but you see&hear the button click) and any further attempt will fail. Simply put, if the second attempt works, most likely it will keep working for subsequent flights with that plane and flare/chaff amount, but if it fails, it will remain broken. If the issue happens, the only way so far I found to alter this behaviour is going back into the mission editor and slightly change the amount of chaff/flare, e.g. to 18/46 and fly the scenario again. With changed amount the dispenser should work at least for that first flight. I will try the same thing in MP today, rearming each time slightly different amount into ASO to see if it works. Haven't tested SPS yet, so can't say if it is affected on my end.

For temporary fix, you will have to find a way to disable ffb entirely for g25 device when you fly dcs and re-enable it for Assetto or anything else. I don't have the device, so can't guide you step by step... However I would check first the utility software that comes with the wheels and pedals, save/backup all the profiles you currently have and then look if there is any option to turn forcefeedback off in the utility. If not, there might be custom or at least some kind of simple/generic driver without ffb replacement on the web that could allow you to use at least the pedals for dcs. Another chance is it might store the settings in the system registry, so you wouldn't have to swap drivers everytime you want to fly dcs. Basically for dcs, you want to temporarily remove FFB-enabled flag from the second device (g25), so dcs will ignore it and trim will work. Or we can wait and hope that the current implementation will be reconsidered and changed by ED for those who use multiple devices (ffb and nonffb at the same time).

No problem Yo-yo, it was joke on me! :D Just to clarify again, it is not bug in L39 itself, but how DCS detects forcefeedback devices in general I believe. When you use full FFB stick (g940, ms sidewinder ff2, etc) there is no problem. When you use completely non-FFB stick (vkb cobra, non-ffb saiteks, etc), there is no problem as well. If you use non-FFB stick + partial or full FFB device connected at the same time (racing wheel pedals, DirectInput gamepad, etc), there will be controller conflict in DCS and it will break the trim function. In this last case, Forcefeedack on/off switch in DCS options will no longer work or change anything. For now, only way to fix this for users is to remove the secondary device completely, or disable FFB property in that second device by editing driver or registry values.

Probably DCS doesn't consider Jetseat as controller then, since it doesn't have any axis/buttons in the first place and just uses dinput and ffe profiles to convey the vibrations. I will try to disable any control aspects of my rumble-kneepad (and will leave it as passive rumblepack too) in the custom driver to see if it solves the trim interference. Thanks for the idea. Same for me. I have stick that is not FFB capable and second controller/device which is flagged as FFB capable (only vibrations though). Conflict happens when dcs expects my flight stick to change position when I trim the plane, regardless of ffb setting in the dcs options as long as the second device is plugged in and detected (despite I don't have anything mapped to that device in the dcs options). That's how it is implemented in the game it seems. Either ED considers to tweak the implementation, or we have to disable the FFB in the driver of affected device (or possibly only in the api or registry, depending on your hardware). Please keep in mind, that I only have this behaviour with L39 as I don't have every module, so it is only my guess after reading the comments that it is the same for Belsimtek planes.

Tango & TheJay, you guys are absolutely right, that is common knowledge about R60M. The reason why people ask about R60M in conjunction with dcs Mig21 (although there is no lock tone in the L39za either from the front, so i believe it is more of missile issue than mig21 module) is that there seems to be a longer standing issue, where you will not get lock tone from the front hemisphere almost ever and it acts just like standard R60. There is something not completely right with the IR feedback in this case and it prevents the launch completely. You can, however, enable the bomb arms switch as workaround and launch it when you think it should track. You might be surprised at what angles the seeker can track (head on only at ~3km from target, which is very close considering closing speed), if you bypass that launcher lock/light. It is somewhat dirty workaround, but for the time being will have to do ... :P

I reckon it is the implementation of ffb-capable hardware/driver and what dcs expects from it. I've written a little about it yesterday with added possible solution today, but that is up to ED coders to implement or not. http://forums.eagle.ru/showpost.php?p=2850891&postcount=13 We can only work around by disabling the device or removing the ffb-capable flag from the driver. However doing so will almost certainly result in loss of rumble/vibration effect on direct input device. Still, trim is more important feature imo. I wonder, anyone here with Jetseat rumbler have these issues too?