virgo47

I visited Touch Portal Discord where it was confirmed that currently this is the behavior. I asked for some toggle to merge the Values with the same ID - but if and when this is available is unclear. Until then, however, the pages that share some buttons are virtually unusable after import. We'll see...

Hello, Touch Portal users... I have 2 pages for L-39C/ZA ready (Main+Alt page) and I finally wanted to share them, but I discovered kind of show stopper for me and I hope there is some elegant solution for this. The two pages for L-39 use some shared buttons - each button is backed by a single value (e.g. for the state of the Invertor I). The problem is that after I export both pages, I decided to test the reimport - so I removed all the values as well. I was badly surprised that the values for all the shared buttons got duplicated - which is incredibly silly. Not to mention the original folder for them got lost as well. In general, Touch Portal page organization is pretty horrible. There is no scoping or grouping of anything - everything is global, nothing belongs to anything else. The disconnect in values and pages is the prime example. Ideally, there should be some "module" where I can export both pages and their values together... OK, importing two pages one by one instead of doing it in one step is not a big deal - but the value duplication is super silly - they have the same name, so you don't even know which of the two exactly same values is which. Does anyone have any tips regarding this problem? It's not practical to de-duplicate the values and fix many buttons on one of the pages. Anyone had similar problems with multi-page setup?

I'd like to have it as a Campaign actually. The disk space is no problem for me - we're talking DCS after all, so gigabyte here and there... what is it? I'd also rather not to mess with the original files, so I prefer using Saved Games (user files). BTW: For a short while I was considering doing the voice-over in pseudo-Russian accent... something like this: I really didn't get too far with it though. But I could do more if it makes any sense.

I've tested this in Kursant campaign mission one - and indeed, if I don't set RMI the plane is glued to the apron. I have no idea how he (IP) does it, because if he was on the brakes, the gauges in my cockpit should show it. He has no parking brake, so I hope he doesn't use emergency brake - which I believe is not to be used normally.

I'm trying mission 3 from the Kursant campaign, and while it's not a showstopper, I repeatedly see this scene at the end of the mission: The marked Mig stays there and is not able to park. The propeller taxiing around is waiting for it. What is going on? I've seen a recording where this definitely does not happen, the MiGs are nicely parked and the propeller can pass around them easily (from 47:20): Is this caused by the recent updates somehow? Messed up AI?

The first mission has quite strict parameters, but it's also the shortest one and the instructions are quite clear - after re-reading them couple of times. It definitely isn't a mission to be done on the first time. You should stay between 150 and 250 m, and the speed should not deviate much either. There are warnings first, but if you stay out of the tolerance, or go way over it, the mission ends right away. Now, the first circle is not evaluated, it's just a warm-up for you. So in any case you have to not screw it up too much to get to the second - evaluated - attempt. And there you can get like 2-3 warnings. Exact triggers are possible to find in the mission file, but simply said - stay in the tolerance. Practice makes perfect. It is doable. It can be frustrating if you miss some trigger, but in that case you probably did something very wrong (like a turn way too soon, etc.). Otherwise this mission is pretty well sand-boxed and I like I can actually go AGAIN after a successful attempt. If the attempt is not successful, you indeed get the order to repeat it - but the IP will also tell you: "You're not maintaining..." and after moment he lists all the things you're not maintaining. Like speed, altitude, etc. It's also good idea to start with some free flying quick mission where you practice turns with the right roll without dropping or lifting your nose too much. No reason to practice it after the cold start really.

Fixed itself somehow, works fine in 2.8.0.32235

Nah, it wasn't that - I was always on the front seat. But I figured it out, because the idea with the rear seat got me experimenting more. In some of my missions starting in the air the STOP worked, in some it didn't. It worked in solo flights. So I checked the rear cockpit where it doesn't work - and indeed - the rear pilot used what is called a "throttle limiter" in the in-cockpit tooltip. I reviewed the docs and it is described from page 87, picture in 88: Now, sure I read it, but I didn't digest it at the moment and forgot it in the meantime. Now it all makes sense. Thanks for the push to the right direction - that is to the rear seat.

After upgrading to 2.8, pressing the hotkey or binding (joystick/throttle buttons) don't focus on the action in the Control Options anymore - in any section. This was a very useful feature and it's sorely missed now.

I have L-39C set all right and have been flying it for months now, without any problem with throttle STOP/IDLE at all. But today I tried one of the provided missions - "Emergency CAS1" - and I was surprised I cannot switch the engine off (toggle STOP). I restarted the mission - and I couldn't toggle the throttle in idle position to stop and back at all - in flight, or right after I landed. I checked other missions - and Mountain Flying and One Pass... also don't allow STOP position at all - doesn't matter whether I use joystick binding or keyboard, toggle or STOP binding, it is totally not responding. Visual navigation starts hot on ground, but I can switch to STOP. All my custom missions (as far as I tried) have no problem - whether I'm starting in the air or not. Is there any logic to it or is it a bug?

No complaints at this moment - good job, it works great. I like the solution in the PP files, seems flexible into the future as well. Thank you.

This threw me off a bit when setting up my panels - but yeah, it works in C version, but not in ZA version. Quite a cheap bug indeed.

BTW: It would be great if COINS could do some transformations - now you do this % thing - but what about some simple math? E.g. for East bloc planes (like L-39) the altitude is typically in meters - but in commons there are only feet. I there was an option to divide that number by some float constant and cast it back to integer it would open some nice possibilities. This could be all in PP files, so it would be on top of DCS-BIOS and before it gets to TP which (AFAIK) can't do math in those text updaters. Another question that is on my mind... do you have a repository with that project, e.g. GitHub or so? I'd not be afraid about forks, while you maintain it, you're the boss - that's how it typically is with solid projects. But it would be a shame to lost this all if anything happens. I don't mean a plane crash necessarily, sometimes people just get bored. Also pull-requests would be a possibility (if allowed), people can test before releases, etc. In any case, it would be kind of a backup for you and us as well, if you don't mind.

No problem, thanks for the info. I tried search & replace and most of the stuff works fine (I just had to be careful about genuine use of L39ZA). One more question though - I had a auto-updated info from common data and this stopped working. I un-commented the lines in CommonsData.pp, recreated the TP plugin file and it started working - but in a strange way. This is the button: But instead of proper numbers it shows 0 deg (always), 0% km/h (yes, with %) and 4% ft. Do you know what went wrong with that? Speed can be fixed by using TEXT and not numbers (not sure though why numbers contain that %). But altitude and heading have no alternatives... Ouch, I've just got a suspicion - you translate all the numbers to % now? Can you make it switchable somehow? Not everything is %.

Thanks for the update, no complaints about the plane! Now my single new button I tested (with L39 prefix) works, so it seems promising. Does it mean that for version 3 I need to redo the actions and events? Is it intentional or is there a chance the prefix in TP actions/events will be L39ZA again? It's OK either way, I just want to be sure before I jump into the overhaul of the panel. Also, the slider for knobs (e.g. light intensity) is welcome addition - works like a charm (one way only, but that is TP limitation as I understand it) - great work!

I suspected I have some old DCS-BIOS installation I used for DCS OpenBeta (not my main installation), I uninstalled that as well just to be sure - that was installed as a Windows application. But that wasn't an issue. I tried the complete COINS install again with clean Script directory and only L-39 module (no FC3 and P-51D) and the log is just a bit different: 2022-10-06T06:32:13.372Z : Munt.G_DCS-COINS :DEBUG: Unhandled type received shortConnectorIdNotification Aircraft: [NO]: Unavailable in installed DCS-COINS module list! Aircraft: [L-NE]: Unavailable in installed DCS-COINS module list! Aircraft: [L-39C]: Unavailable in installed DCS-COINS module list! 2022-10-06T06:33:57.903Z : Munt.G_DCS-COINS :DEBUG: Action Message received Not sure what NO and L-NE means, but perhaps you know. I noticed that in entry.tp file the prefix was L-39ZA in COINS v2 and is L-39 only now - this matches the change shown in the picture above. L-39ZA was used for both L-39C and L-39ZA and worked for both planes.

Hi, I wanted to check it out and my L-39 TP panel for COINS v2 did not work at all. When I started to check the buttons, it seems all the actions and events need to be changed: I guess this is caused by DCS-BIOS and I'm fine with that (it's kinda a mix of boring and fun at the same time). But... it doesn't work even after change. I checked the verbose log and I see this: $ ./DCS-COINS.exe -v DCS-COINS Version 3 (2210.03): Verbose mode enabled. 2022-10-05T20:48:40.164Z [INFO] dcs-bios-api: parsed aircraft JSON - CommonData 2022-10-05T20:48:40.167Z [INFO] dcs-bios-api: parsed aircraft JSON - FC3 2022-10-05T20:48:40.172Z [INFO] dcs-bios-api: parsed aircraft JSON - L-39 2022-10-05T20:48:40.173Z [INFO] dcs-bios-api: parsed aircraft JSON - MetadataEnd 2022-10-05T20:48:40.174Z [INFO] dcs-bios-api: parsed aircraft JSON - MetadataStart 2022-10-05T20:48:40.176Z [INFO] dcs-bios-api: parsed aircraft JSON - P-51D 2022-10-05T20:48:40.186Z [INFO] dcs-bios-api: UDP client listening on 0.0.0.0:5010 2022-10-05T20:48:40.188Z : Munt.G_DCS-COINS :INFO: Connected to TouchPortal 2022-10-05T20:48:40.190Z : Munt.G_DCS-COINS :DEBUG: Info Message received 2022-10-05T20:48:40.197Z : Munt.G_DCS-COINS :DEBUG: Unhandled type received shortConnectorIdNotification Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: []: Unavailable in installed DCS-COINS module list! Aircraft: [L-39C]: Unavailable in installed DCS-COINS module list! Is it a bug or do I do something wrong? For the record, I deleted old Script/DCS-BIOS directory + removed the line for it in Export.lua to get the right version of DCS-BIOS.

That must be some misunderstanding, currently I'm only working on L-39, I don't own A-10C.

Today is getting better and better. Great news, I hoped it had been just a hiccup and everything would be OK in the end. Thanks for the clarification. I install both from COINS, so I'll be fine.

I still don't understand this - is this related only to the new versions of DCS-BIOS and/or DCS-COINS? There is a single file for both L-39C and L-39ZA planes (either L-39ZA.json in DCS-BIOS or L-39ZA.pp) and both planes work fine in version 2, I use one unified custom TP page with both and I'm very happy having this extension of the controls. Now I'm confused whether I should stick to DCS-COINS version 2.2202.02 and not update in the future or what. What is the problem and can someone with the L-39 Albatros module (like me) help in any way to fix it?

I was using L-39 just fine with DCS-COINS version 2. What does the exclusion mean to the future? Will COINS be unusable now with that or can I somehow add the plane there later?

Great info, I didn't realize (or forgot) that while the arms are ready above 310 km/h, guns in particular require 400 km/h. The "deblock" button is interesting though. It can't be mapped with a key/joystick bind, which is probably a bug (definitely a missing feature), but it can be mapped using anything that goes over DCS-BIOS (for cockpit panels), e.g. DCS-COINS plugin for Touch Portal Android application. I was afraid the button has to be pressed - like RSBN tune button, for instance - but luckily, this one works as a toggle every time you press it. This also means that there is no indication of the deblock state, sans the AoA light itself when in the situation where it would likely be alight. (And yes, I was shooting down transport plane as well. )

Thank you guys very much, the answers came so fast. There is definitely a lot to desire - although I'm in a position where I don't know the current capabilities. But this cockpit setup stuff shows just how awkward it is now. Instead of somehow saying "RSBN Navigation to 20" I need to know it's 1 at the start and repeat the click 19 times. But the same solution will not work for mission where the plane doesn't start with RSBN set to 1 - that is, even in the same mission if I change the plane from flying to hot start on the runway (imagine scenario I want some other RSBN channel there). I was afraid it will come to this. I didn't see noticeable difference hence I didn't try to clone it many a times there. But this is semi-usable, because, again, when I move the plane, I have to reconsider the initial position of the RMI - which is ridiculous. That doesn't take away from your answer, of course, I appreciate that. I'll probably just instruct myself via a message to set RMI. Or use first WP when convenient. Interesting info, thanks - but RMI goes round and round - so I can't imagine getting to any known (e.g. end) position anyway. But I'll think about this when/if working with some non-continuous rotary knobs. At least I know that in the current state of things I don't need to chase this chimera of how to set RMI precisely to a known value, which is also a good thing.

Hello Recently I've created various landing scenarios for my practice, but it was very annoying that I need to set everything in the cockpit again and again. It would be great if the plane started with the same setting like "hot" for the target aerodrome, I'm not sure whether such a shortcut exists. However, I started to experiment with triggers and go most of the stuff I needed. I love the OPTIONS_ADD_COMMAND_CODES_TO_TOOLTIP=true setting, very useful - although first I thought it does not work until I found out it works on the right side of the Controls table, not on the left where it shows the original description. In my case, I fly L-39, I managed to disable arms, click 19x on RSBN to set channel 20, etc. I'd like to learn to do the same in script eventually, because cloning something for 20+ clicks is indeed ridiculous. Funny that some clicks are COCKPIT PERFORM CLICKABLE ACTION (like RSBN channels) and some are SET COMMAND WITH VALUE (switching radio channel) - but it’s easy to recognize which is which (based on the presence of the device id). It’s cumbersome, but it works, no problem there. What puzzles me is how to set RMI course selector which is on a rotary knob. Controls say “cockpit id: 25, pressed: 3004” both for CW and CCW rotation, I tried to add COCKPIT PERFORM CLICKABLE ACTION (because there is device id) but I have no idea whether this works, what the value does, etc. I tried values from -1 to 1… but I don’t see any difference on the RMI course. Not even in units of degrees. How can one set such an instrument in a Mission Editor? BTW: I never made Prepare mission work for me and this plane (manual is also half-clear on this), not to mention it moves the time as well, so the trigger way is much better. If someone knows how to do it in DO SCRIPT, even better. I’m at the beginning of the scripting road and most materials are about other units, dynamic missions, etc. I couldn’t find anything about setting single player cockpit. It’s probably out there but buried under more advanced stuff. Thanks

So, with the values of light intensity knob coming to the TP I could display it ("Update Button text each cycle" event), but sliders do not seem usable at this moment. There are a few issues: TP has no On Event for sliders - so the visual update of the slider seems not possible. The actions provided for the slider are quite limited. These are mostly very specific actions - or I can set a value 0-100. So I tried that. I thought I can create some global event when the value is changed and update the value in DCS. But currently I'm in a dead end with an event like this: I'm not sure how to listen for ANY change - this is obviously more a TP related question, maybe when I don't provide any value, it listens to any change, but I doubt it. I have no idea how to even try that. But even after the calculation of the final value, I have only two options for the DCS action - increase or decrease the value by 3200. I'd need an action to set it precisely. This is perhaps something that DCS-COINS can help with. Now with all these limitations - most of them on the TP part (e.g. "any change" event and no way to set the slider based on other event) I'm not going to do this. Even using it for buttons (two or multi-state) is a big benefit already and I'm going to tune the setup for these first.