virgo47

I've updated the L-39 dashboard: https://www.digitalcombatsimulator.com/en/files/3336442/ There are various tweaks and fixes to the button behavior and visuals, minor reshuffling of some of the buttons - but also rework of the secondary Alt page with button covers (again, me learning Photoshop): Thanks to the Aircraft Model I was able to fix C/ZA discrepancies for the Start Regime button - and also indicate the variant in the upper left corner (for those who forgot where they sit :-)).

Sure, no problem, attached here are only the changed lines. Also thanks for the future adjustments, no rush with those. BTW: If I have some changes, like the lines I attached, is it enough to just slap them at the end of the original PP file, or do I need to fix the changed lines? That is, are the lines later in the file overriding keys mentioned before during the TP plugin file creation? L-39.pp

@xoomigo I went through the L-39 switches and the attached PP file matches cold-started L-39 100% (I hope :-)) and hot-started with just one minor difference. Obviously, the defaults are not universal for each way how to start or fly the plane, but in general, when OFF is in the middle, it is a good default. If you go over the differences, yes ENG_START_MODE for C and ZA is different, FRONT_BOMB_REL_SEL really is UP whenever I enter the plane (this one is not 3-way) and FRONT_ROCKET_MODE is also mostly set to 4RS. Thank you in advance for accepting the changes. L-39.pp

Thanks, very useful info, I started to play with the defaults for the switches with the default set to 1 (middle position) - which applies to many in L-39, although not to all, of course. The results are much more consistent and the dashboard switches don't switch to the 0 position when changing the slots. I'll provide the improved L-39 PP file soon after I tune it a bit. I wanted to ask about CommonData.pp as well. I've noticed that some ANGULAR_VELOCITY_* parameters are now sent very often, even when I just sit in a cold aircraft. What are these and do you want to send them? (I personally disabled them just to make my debugging sessions easier. ;-)) Thinking about that I realized that L-39 dashboard also needs IAS_EU (km/h) which is disabled by default, I even forgot to mention that people need to enable it, otherwise I'd need to provide some event that would calculate it from IAS_US (like I do for altitude which is not available in meters at all). Please, do you think it would be a problem to enable IAS_EU by default? I regularly use it and don't see any problem with it.

@xoomigoSorry to bother you again but I've got a question about 3-way switches. The thing is, that sometimes they are strangely initialized, although otherwise they work just fine for both pushing to DCS and reacting to the actual events. This mostly happens when I switch "client" slots. E.g. I get into L-39C and my Spotlight switch in TP moves to a different position than in the cockpit. To use a concrete example: FRONT_LAND_LIGHTS|front_land_lights|Front Taxi and Landing Lights Control Switch, TAXI/OFF/LANDING|1|0|UpTo2|0 What exactly does the order of values after the text mean? |1|0|UpTo2|0 Because this kind of 3-way switches (at least in L-39) have 0 for one of the ON positions (typically down or towards the pilot), 1 is OFF, and 2 is up/fwd position. For some reason, when I switch the planes to L-39 (or between the variants) I get wrong values for some of these 3-way switches. I check the values in TP application, I don't claim to have all 100% right, but the ones I checked, I use 1 (OFF) as the default position, so something is definitely changing it to 0. From the verbose output, I see all-caps output such as: FRONT_LAND_LIGHTS: 1 ...but no event that should switch the state. But the TP app still switches my button. I even created a separate test page where I have only this single button, then I switch the plane to L-39ZA, I get this line (and no events): FRONT_LAND_LIGHTS: 1 Yet the button switches to TAXI positon (value 0, instead of 1). The button looks like this: I know the value-backed button looks complicated (but hopefully not to you ;-)), but only the events should be considered, I don't press the button when strange things happen. Pressing it makes it all right, eventually (when the state and value sync). Please, do you have any hint on what can be wrong?

I'd also have no problem with removing simplified arcade modes which would save quite a lot of pages at the front of some plane manuals as well. FC3 model - OK, arcade model - no, thank you. If it helps streamline the development, great.

@xoomigo Thanks a lot for adding the Aircraft Model. It helped me to fix the button that was susceptible to strange behavior because of the both L-39 ZA/C events coming from the cockpit (in any of the variant), because now I can guard C/ZA event with corresponding C/ZA IF check. I'm pretty sure I'll use this for other pages in the future and it can be a be also used for hiding buttons that are not available in some variants (e.g. older P-47, etc.). I'm not going to hide ZA buttons in my L-39 page (that would be a lot of work that is not really essential), but this "type" information is a great help when some things behave differently. It works great! Big thanks again.

Thanks a lot, seems to work fine now. There is still minor itch with module selection, the first time I do it, it does not offer my modules, but if I just go Back and Next (or Next and then Select Module again, not sure right now), then it autodetects my modules just fine. Not sure why, but this is hardly a deal-breaker. Now, I'm going to play with that Aircraft Model.

Great, thanks! I've already downloaded it and before I'll let you know about the model addition, just a quick head-up: Something is fishy with F86 Sabre, when I want to add it the following popup appears a few times in a row and the module is skipped: I've tried to run it from console, but no output. @xoomigo One more issue, CommonData.json does not get into the TPP file although the checkbox is by default checked (and disabled).

Sometimes, Invert can be module-dependent - and also depending on the global setup you have for the pedals - you just need to check it, ideally hot start on the runway, check control indicators (RCtrl+Enter by default) and see there. Most modules also show the action of pedals in the cockpit, some don't (at least F-15C from FC3 does not). Slider is always a logical choice for non-centered axes... although now I see I forgot to check it but I'd definitely find out the moment when I'd start playing with curvature. Yes, you want wheel brakes as sliders.

I'd rather have this fixed than those other 3D errors, because this gives me feedback for the setting. If it can be fixed by some LUA adjustment as suggested above (I haven't tried it myself) then I don't understand the reason for waiting unless there is 0 people working for ED who understand this module. In any case, any kind of bugs accumulating in any module over time are really sad.

F-86 and F-5 were developed by Belsimtek that was more or less ED branch. There is no similarity to the current situation.

I had the complete T.16000M and TWCS+TFRP combo - and TFRP is part of TWCS as it is connected via the same USB cable. There is no separate TFRP (device or column in DCS) if you connect it through that RJ-style connector. Then: I didn't use toe-brakes on TFRP for single-handle-style brakes of East-bloc planes (e.g. L-39)... it doesn't make much sense, find another axis far away from toe-brakes for that. Otherwise, you risk interference between the axes. It is possible, but it is not the best solution, really. Finally: Enjoy the pedals while they work OK-ish... From the three products combo, I wish I omitted those. Yes, they are pedals, but they are jittery, jumpy, sticky... and too narrow for a male (not to mention too narrow in general).

I also agree with comments turned off under some YouTube videos, even some serious media do it, as it often does not bring anything constructive (or anything constructive is lost). I commend the effort and the format of the video, not to mention how easy it is to listen to Matts anytime.

The main server seems to go down quite often lately. Sure, it's not a mission-critical application, but a secondary server would be a neat idea indeed. It wouldn't have to deal with web, shop, etc., just the authentication.

While off-topic, I'll chime in about Yak-52 as well... Everybody has their poison. I like flying in Yak-52, and because it's not a fighter, I don't mind the damage model. Yes, it's arcade-like when you crash, and yes, I believe it is not complete - and that's probably one of the reasons why it's in EA. But what I don't understand are the easy things - like why don't we have working toggle bindings (toggles work only as ON), so we have to bind both ON and OFF for most switches? I appreciate it when something gets fixed. I believe ED has to fix more and more because more and more modules will simply force it - or at least deprecate some modules, or clearly say in the shop "We don't have time/manpower for this for any foreseeable future". I'm not long with DCS (if I don't count my short tenure during 2014) and I can see the progress, but even during ~2 years with DCS I've encountered bugs reported for years. Not just watching them for no reason. I returned to TF-51D after the flaps and canopy were fixed after a long time that was hard to understand. On the other hand, I can always focus on the module that feels good. And I try to do that. But just because something is not game-breaking, it doesn't mean it doesn't stand in the way to some people (arguably it doesn't to others, which is fine for them and I appreciate their attitude as well). DCS is still fun (or work/life, however you look at it ). It's just sometimes a labor of love or what... (in Slovak we have a metaphor along the lines "life of a monk/being in an order"). BTW: Originally, I got to this thread to see what release cadence can I expect with the single version now... did I understand it right it will be between 1 and 3 months? So... around two?

Terrains are by far the biggest chunk, check how much Mods\terrains is of those 228 GB.

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: