virgo47

Ah, that would make sense. I guess, the RKL direction to the next (I) beacon is meant by that, at least that makes the most sense to me. Thank you very much for all this information, @portman!

I have a simple mission, L-39 starting at Mozdok, hot on runway, bit of a crosswind towards 201°. RWY 08 is chosen for me - in this case probably any runway would do, but that's not the problem. NDBs for Mozdok are tuned in, but the wrong ones are activated (R and RM codes, instead of D and DO ones). Both NDB sets have the same frequency, so L-39 tuning doesn't care, but ADF clearly shows me the way ahead instead of pointing behind me. ADF morse codes confirm the wrong NDBs as well. Because the mission was "old", I decided to recreate it, not being sure when the ATC "makes the decision" (I hope it's when the mission is loaded, for the progress' sake) - both tracks are attached. Strangely, when I fiddle with the wind a bit, the right NDBs can be activated. The bottom line is: Why am I on one end of the runway and NDBs are activated for the opposite runway? The logic here should be tight together. I don't know whether I'm on the wrong runway, or wrong NDBs are activated, but it should at least be consistent. BTW: If I ask ATC for an approach, it suggests 08 which is consistent with the RWY I started on - which means it sends me to over the non-active NDBs. mozdok-l39-wrong-beacons.trk mozdok-l39-wrong-beacons2.trk

I've tested the behavior around Mozdok which has two NDBs, and I turned off RSBN/SDU just in case it is somehow involved as well (although it definitely is not necessary as this works with aerodromes without RSBN as well). After a few tests, these are the findings for C AUT behavior: As mentioned above, landing gear must be extended (down). This works only on NDB with a marker. If you overfly non-marker NDB, nothing special happens. If on course to the RWY: If there are two markers and you overfly the outer one it switches from O to I, as advertised. If there is a single marker (e.g. Kutaisi), both O/I blink very rapidly. (If you have I selected, no switching occurs, of course.) If you are not on course to the RWY - that is you overfly the marker e.g. in the perpendicular direction, or fly straight away from the RWY: For two markers: It switches to I if you overfly the inner marker. Around the outer marker, it keeps switching between O and I, eventually settling on O. This switching is slower than rapid blinking over the single marker. For a single marker, the behavior is the same as when you approach the RWY properly - it blinks rapidly. The course to the RWY is somehow detected without RMI course set and it is not RSBN-related (there are a few two-marker aerodromes without RSBN in the Caucasus anyway). I've found a manual T.O. 1T-L39C-1 where this is described on p1-80. It doesn't mention the direction of flight necessarily - instead, it says: "If the aircraft drifts from the approach entry sector, i.e. ± 30° from the runway axis, the system is automatically re-tuned back to outer beacon frequency to enable to initiate the missed approach procedure." So, somehow it works and it works well for 2 markers and the proper approach. The details are still a mystery to me and I couldn't find more, but I can leave it at that.

I'm also curious about this TLF/TLG and signal strength behavior. TLG obviously activates the signal indicator, but is it normal that it stays at that position when TLF is selected? There is no spring or something? It still goes down to indicate lower signal, if you are in TLG, so it works, but in most measuring devices I'd expect the needle going back to 0 when not active.

Yes, check this video: There are other video tutorials on this topic, just search "VKB encoder axis", but I have my reservations to this: When switched to axis, there are significant steps (each step of the encoder ~15° of rotation) - if you make these steps smaller then it requires tons of turning. So no fine/precise axis, good only for axes where precision is not important - or speed for that matter. You'll lose the button functions unless you duplicate the encoder button first and then create axis from the duplicated buttons - but this is very laggy. That said, in the end I use it as axes, because I didn't find anything useful for encoders - unlike the encoders on the base/STEM, for which I found good usage (e.g. radio channels, waypoint switching, etc.).

I have to admit I'm buying virtually everything during sales, it is still legitimate (I hope )... and I often also buy stuff I don't play that much in the end, but there is no remorse. L-39, whatever state it is in, was my first paid module and it is a great trainer and a joy to fly. It is probably not useful for anything serious online, but it still is quite fun. And while not that complex, it has its depth and the systems are modelled really well. That said, yeah, bugs like these, some small, some bigger, are annoying - especially when they often take years to fix. Priorities are priorities, but I think that long-time bugs kinda "integrate" (in the math sense) over that time. Not to mention things getting broken with updates. But I still like L-39. Forever it will be my first module, after all.

@xoomigo, thanks for your work and nice words. I have a question, or even "feature request". There are some minor nuances between L-39C and ZA, and even worse, DCS sends events for both variants when something changes. This means that just by listening to the events, I have no idea what variant is on. Connection event ON/OFF does not distinguish variants either. Now, I could create a separate dashboard for each which would also have some benefits - so the user would select it for me. But I've noticed that the COINS log knows the variant - those are the lines starting with Aircracft: Aircraft: [NO]: Unavailable in installed DCS-COINS module list! Aircraft: [F-NE]: Unavailable in installed DCS-COINS module list! Aircraft: [F-86F Sabre] Loading aircraft parameters from ./acdb/F-86F Sabre.pp Event: mgdc_f-86f sabre_st_aircraft_connection [ON] (f-86f sabre: F-86F Sabre) Aircraft: [L-86F Sabre]: Unavailable in installed DCS-COINS module list! Event: mgdc_f-86f sabre_st_aircraft_connection [OFF] Removing listeners for previous aircraft Aircraft: [L-39ZA] Loading aircraft parameters from ./acdb/L-39.pp Event: mgdc_l-39_st_aircraft_connection [ON] (l-39: L-39 Albatros) Aircraft: [P-39ZA]: Unavailable in installed DCS-COINS module list! Event: mgdc_l-39_st_aircraft_connection [OFF] Removing listeners for previous aircraft Aircraft: [P-47D-30bl1] Loading aircraft parameters from ./acdb/P-47D.pp Event: mgdc_p-47d_st_aircraft_connection [ON] (p-47d: P-47D Thunderbolt) Do you think it would be possible to find that string (which is a unit type string, used also in SnapView.lua and other places) in some COINS common variable?

My COINS and Touch Portal friends, with COINS now supporting TP4 I totally forgot that you can actually play DCS... because who would do that when you can create or revamp your COINS dashboard, right? So here is my new redesigned L-39 dashboard! The main page: And the Alt page (you switch between them by pressing the heading/speed/alt "button" near the top left corner): This time I made it right and it is available as a user file: https://www.digitalcombatsimulator.com/en/files/3336442/ All the instructions are there, don't forget about the "event" for ft->m conversion. The great thing about TP4 is that now you can import both pages at once and the values they share are imported only once. Since my older attempt (for TP3) I remade a lot of switches from the previous icon pack, although some remnants are still there around the engine management on the alt page (which I rework later). New switches should be more obvious, some even mimic actual L-39 elements (I hope you like the pitot heating and weapon carrier selectors), there is much more feedback on the panel (flight recorder, beacon O/I elements)... and of course, you can reshuffle it as you like if you want. Enjoy! You can also watch this hodge-podge video I made about TP, COINS and this panel:

The de-ice check (right console hidden under IFF) light is dark when not lit, but its "body" disappears when the light is on. Only the glow is visible: Happens in both variants.

I can't confirm this. Both variants taxi-turn just like before, both with wheel brake axis and button. Do you have any mods or something like that? Even seemingly unrelated mods can affect modules in unexpected ways sometimes. Also, check with Controls indicator, whether there is no other input on the rudder for instance.

The title says it all. I have bindings for Emergency Wheel Brake - Down/Up and they work in reverse in each cockpit. I assume that Down is forwards and Up is backwards - that is up engages the brakes. In that case the rear cockpit seems to be working right, and the front one has it reversed. But in any case it is very confusing when hopping between the cockpits. I nearly rearranged my bindings because of this. Applies to both variants.

I'm just confirming that it works fine on my end. It really sounds strange. I can use LAlt+C and also another custom binding on my mouse. No problem.

If you don't see a regular flow of events from DCS in the verbose output, there is definitely something not right between COINS and DCS-BIOS or, more likely, between DCS-BIOS and DCS. However, I can't help with that that much. Did you uninstall DCS BIOS or just try to reinstall it? It's better to uninstall it first and then try again. After you uninstall it, inspect your Saved Games/<dcs>/Scripts folder for any remnants.

That means you're not using COINS and its powers. In most cases previously, I had problems with DCS BIOS itself. COINS can install it for you, but sometimes something got stuck and I had to uninstall DCS BIOS, clean up relevant lines in Saved Games/<dcs>/Scripts/Export.lua and reinstall BIOS again (the right version used by COINS). I don't have exact steps for this, sometimes it was kinda messing around until it all started working. Last time there were no problems really.

Thank you, great stuff! I wanted to understand it because I was creating an element for it on my Android panel and was wondering when/how the other letter (I/O) can be highlighted when the switch is the opposite way. Now I tested it and it works as you mentioned, the landing gear is the key, and if the approach is not right, then the I/O changes back and forth. Do you know how does it know that I'm ±30° to the runway? Does it use some other system for it? Because this kind of NDB should ignore the actual azimuth or am I wrong?

In the L-39 manual, p154, one can read this about the mode switch selector of RKL-41: “C AUT” (Compass automatic) and “C MAN” (Compass Manual) are RKL primary operating modes, NDBs’ direction determines automatically. The only difference is that in “C MAN” mode there is no automatic switching from outer NDBs to the near one. My question is: How exactly does that C AUT switching from outer to inner NDB show? I flew over the outer NDB of Mozdok aerodrome, the radio compass turned around to 18 and nothing else happened. I thought that highlighted O next to the beacon switch would change to highlighted I or something and also that my radio compass would start tracking the other beacon (which clearly points to 15 when I switch to it manually). I can't find more specific info about this automatic working of NDB. Please, L-39 pilots, if you know more, let me know.

Funny, I had much fewer problems with the Touch Portal app delay when editing the buttons (without any changes or updates), so it's actually pretty good since I mentioned it in the post! I'm now revamping my L-39 pages using some own Photoshop experiments for icons, I'm quite excited about it, so hopefully in a week or two I'll be ready to publish it. So far so good with the TP and COINS, everything seems to be working!

You run the exe from another directory. Go to Desktop\DCS-COINS\Munt.G_DCS-COINS first, then run it from there and it will work. It's sensitive to the current working dir. BTW: mentioned on the User file page: ... 3. Type "cd " and followed by your DCS-COIN install folder, and hit ENTER. 4. Type "DCS-COINS -v" to run in verbose mode. In this case the instructions matter. Happy "COINSing".

When using Forward key, it travels something above 1000 km/h. When using Fast forward key, the speed is ~120 km/h. With Slow forward key, it is 28800 km/h - the fastest one. I tried forward/backward and camera height (all speeds are lower, which is a feature) - all is flipped, I guess left/right is also affected. Fast is slow and slow is fast. Can anyone confirm? If so, can ED just flip the labels, please?

Hola @xoomigo, now I've got something to do for the next few days or weeks. First touches look promising. True, I had to switch the actions, but the events seem to work without changes, so it's not SUCH a pain. I don't understand the note about 5-second loading time, so far the experience is snappy for me - when does it occur? EDIT: Never mind, now I see it. It's not 5-sec. It's ever longer with each button edited. It seems to be COINS related. When I delete the plugin, TP click on button is fast again (for non-related buttons), but with your plugin, the click on buttons (even unrelated ones) seems to be slower and slower. From a simple look to Task Manager, I can't understand it, the plugin doesn't seem to take CPU or much memory, neither TP memory is going up and CPU is not excessive... Can it be caused by all the new available actions and actually being a TP4 scaling problem? One minor issue I spotted right away after migrating my first switch is that the default in the select box is none of the actual values: The default in this case is OFF, but I need to change it to [0] OFF for it to actually work. Not sure whether it's module-specific, but I saw it on both of the first buttons I migrated. Also, if possible, please, make it an open-source eventually, just in case. I'm not seeing anything bad happening to you (God forbid), but I know from my own experience, that sometimes enough is enough with any project, or something with higher priority appears, or whatever - and then we're all hostages with unusable pages. Maybe nobody forks it... but at least anybody can. Thanks for coming alive with this project, there is also a competition for Matric available now (quite serious, as Matric can do more in some cases), but I already started this endeavour with TP and I like it even with some TP-inherent limitations. TP gets better as well, so we don't know where the road will lead us in the end. I hope for the best.

I've just found this the bad way as well... Back should not kick you out of the current seat. It is a serious UX problem. I clicked the Choose Slot accidentally instead of Adjust Controls - and as I had the mouse in my hand already, I naturally clicked Back. If I press the Escape key, no problem. Why is Back doing something different than Escape? It may make sense before you choose any slot, but not when you are already in one. There should be a clear cancel button (call it back or not) and another one clearly labelled such as Leave slot or Choose Coalition, anything that sounds "dangerous" enough - perhaps even with a confirmation to get out of the seat (but that is not such a big deal if the label and function are clear). Sad end to my evening, next time I'll try to be more careful. But UI should not be misleading, especially when better alternatives are quite obvious.

Thanks a lot! I suspected this needle, but your quotation adds a lot of clarity to it.

Hello aviators! In the real-life manual for P-47 (AAF Manual No. 50-5), in the Instrument flying section (p 88, left column, bottom) there is one of the exercises worded as: What exactly is that "half needle width turn"? I can't google anything around it (except for some completely different hand-craft not related to flying ), some obscure suggestions were related to VOR navigation and fine course correction - but how is that "half-needle-width"? What needle? Turn needle? Compass needle?

I believe that's a matter of preference, spare money and how well the Warthog works for you at this moment. I wanted dual throttle, but if TWCS kept working as new, I'd probably wait (price sensitivity). Because it failed (constant pot maintenance needed, TDC unreliable) I decided to upgrade and STECS Standard was my natural choice. I also considered Virpil's throttle. I recently compared STECS Standard with both Virpil (theoretically, as I don't have it, but did some research about it when considering it) and TWCS (more from the upgrade perspective, as these are not comparable):

I'm looking forward to it, I really like this as a universal and flexible addition to HOTAS. Great to hear from you.