MadKreator

Thanks for the tip. I did not know that! That would help I’m sure for the standard “exposed” viewports, but will still run into the issues with the non-exposed viewports that need “patched”, of course. Maybe already understood by the powers that be, but maybe not efficient enough yet to re-write Helios while still having to “patch” some of the core file to expose other viewports… @BluFinBima have you ever played around setting up the basic viewports like this? Btw @jonsky7 your guides helped me greatly when I started exporting things. Thanks for always being generous with your time and staying supportive of the “exporting” community. Your knowledge is well received!

Okay copy that, I wasn’t sure. They are old mechanical dials from the 60’s Thanks for the reply!

Title is pretty self explanatory Is it just mine or like this for everyone? I assume that's not intended behavior...Track attached. F5e Chaff Flare Drum.trk

Being forthcoming and honest about it is most commendable! Keep up the good work!

Very excited for this! Been flying a lot of F5e lately and it always seemed very wrong to have to switch between radars that are searching and radars tracking you.

Everyone using Helios and my f-15 profile. In the newest version of Helios, releasing soon (1.6.608) the f-15e plugin will no longer be required. It has been integrated into Helios. IMPORTANT- The new version will still work fine if you keep the plugin installed, BUT if you want to uninstall the plugin PLEASE uninstall it BEFORE updating to Helios 1.6.608! If you update first, then uninstall the plugin, it will delete all of the f-15 items from Helios and you will have to re-install 1.6.608 again.

Everyone using Helios and my f-15 profile. In the newest version of Helios, releasing soon (1.6.608) the f-15e plugin will no longer be required. It has been integrated into Helios. IMPORTANT- The new version will still work fine if you keep the plugin installed, BUT if you want to uninstall the plugin PLEASE uninstall it BEFORE updating to Helios 1.6.608! If you update first, then uninstall the plugin, it will delete all of the f-15 items from Helios and you will have to re-install 1.6.608 again.

@bluefin I suppose I didn’t read this with the right mindset either. I was taking it as him sayin that THEY can just do it on their end. I wasn’t realizing that he was ( hopefully) implying that he CAN expose the same functionality to all of us…. Falls right in line with our conversation yesterday.. now I’m the guilty one If the tool is already there on their end then that seems like the most logical route to take, IF that was in fact an offer for a solution

I'm currently developing a helios profile for the f-5 and the Reticle Depression Knob only works as a rotary encoder, not a linear axis. I do find it odd that it since in clickabledata.lua its simply a "defaulit axis" leading me to believe a linear axis/ potentiometer should work, but it doesn't. Full step change moves the sight one degree... I just tested it binding it to a rotary encoder on my throttle and it does work as it should ( essentially the same as binding a button for increase and another for decrease). I DO agree with you that a linear axis would be more feasible for most users as most hotas setups don't necessarily have an abundance of rotary encoders....except for my STECs, which is oddly loaded with them lol

Thank you @NineLine You're the man!

Streamdeck are great! I use an XL but with just game functions( f keys, briefing,rearm, comm menu, pause, ff, etc). I run the DCS-UFC app along side as well, for certain aircraft. You can never have too many controls. Clickable cockpit is a cool concept but I absolutely HATED looking down and zooming in and out, using the mouse to do everything. I like VR for free flight here and there or MSFS where the same 5 buttons controls every aircraft

maybe I’m a lucky one . I’ve been using Helios for several years ( not as long as when Gadroc dropped it initially) and developing profiles for the last couple of years and I have never had the slightest issue with it. Performance or stability-wise ( obviously very system dependent). I will wholeheartedly agree that learning to mess with DCS scripts, writing monitor files, even using mods, is almost a must to get the most out if dcs. Even if a person doesn’t ever learn to write/ script or code. A basic understanding of what it’s trying to do can be invaluable, even a basic monitor setup. I exported displays for a long time manually. But once I found helios and using a single touchscreen for all the aircraft controls I was hooked! The current dev is very good and is very dedicated to it. It may disappear someday but I will ride the wave until that day comes!… or until VR/Mixed reality takes a big step forward. I’m just a sucker for the best graphics possible and seeing my actual controls.

@RickJamesBish As a pro helios advocate .. to accomplish the same as Scott suggested with the RWR and DED, since the core file must be modified to “allow” that viewport to be exportable, which will break IC anyway, Helios can also do that for you if you aren’t comfortable modifying files yourself. It will add “patches” which is mostly adding the “dofile” to the proper cockpit scripts, the same way as you would do it manually as Scott suggested. But when it comes to placing and sizing the viewports it will be just dragging and dropping and sizing with your mouse to the screen you want. Again since either way will break IC and block you from MP servers with “pure scripts” enabled. As Scott mentioned too, if you want the rwr rings or anything like that then you would need to use something like helios anyway. if you decide to just stick with mfd’s then just stay the way you are now…. If it ain’t broke, don’t fix it There isn’t a right or wrong way, but there is options. Some people like using helios, some prefer to do it manually. The choice is yours.

The ic issues with exports has been reported officially and acknowledged by an ED dev, a week or so ago( in the “Multiplayer” thread). I lent some info as well as the helios dev, hoping the communication will continue as long as there is an ED dev with an open ear to the “violations” caused by exports and the viewporthandling.lua I just added a comment to the thread to mention the kneeboard as a side effect of the exported display and IC issues.

Removed my first response. @RickJamesBish… @Scott-S6 is very correct!. You do NOT need Helios or Simapp to export viewports. Many, are available natively through dcs’ export api. You just need to create a monitor file accordingly( there’s good writeips and walkthroughs in the forums here). Helios can cause IC issues depending on how you use it when exporting viewports. But you most definitely don’t NEED it for basic mfd, ded , rwr exports etc. You will need it for exporting things like the gauges as those are user created and not a direct function of DCS’s exporting. You CAN use Helios for exporting mfd’s ( like SimAppPro) if you aren’t comfortable writing your own monitor file.( although simapp already wrote you one) Where Helios and SimApp MAY start to conflict is if you have devices such as the WinWing MIP that uses is own scripts and export.lua to use the switches and knobs and such on say the ufc. With both software trying to send and receive device commands, it can get messy. Your best bet would be to scrap SimAppPro if you don’t NEED its other functionality( delete its lines of script from the export.lua that it writes in there when you install it), keep using the monitor file it created for you, then use Helios to export things like the analog gauges

No prob! He will be more tactful than I in his words and he speaks the language only a software developer could love If it would be better for him to DM you, I will relay it to him.

@NineLine Helios dev is going to reply soon. Please await his more educated response

Option to enable or disable a “background”/ window/ something behind the comm menu in game and the messages to be able to see them easier. Or maybe an option to change the color of the fonts to something other than white

@NineLine #1 reason : The “patches” helios applies places the export script “ try_find_assigned_viewport_…”custom name” “ in each of the appropriate aircraft “viewport” files. Doing this along with the custom names allow helios to place viewports ( mfd’s, ehsi, cdu, ded, rwr’s etc etc) in different locations in different sizes for each aircraft using a SINGLE monitor file. F_16_ left mfd, a10c_left mfd, av8b_ left mfd, can all be exported in different sizes in different locations on a single screen when flying the appropriate aircraft, without switching monitor types each time. - in the ka-50 example, it allows the arbis for the ka_50, ka_50_2, and ka_50_3 to be placed in different places depending on the profile layout a person chooses to create for each aircraft / variant. Using the standard method of exporting confines the viewports, say left_mfcd and right_mfcd to be in the same location and same size across ALL aircraft, unless you create a new monitor setup and switch monitor types for each aircraft. Helios also configures files like this to be able to export some things which may not be exportable natively.. the DED in the f-16 and CDU in the a-10. <— I could be wrong on if some of these are available or not. I work closely with the Helios Dev quite often and without clogging up too much of this thread, we can DM, if you want, and I can send you the very specific files and examples of “patches”, monitor setups and all that. Helios isn’t maliciously pulling info from DCS core files, it simply “allows them, using the tools built into dcs, to export items in different places for each different aircraft. BUT because it needs to have the custom names inserted and called from the appropriate cockpit viewport file, it fails IC. Also if you are willing, maybe through discord, I can help get you in touch with the Helios Dev ( maybe you already know who he is) If you would like some more detailed code/script level explanation and examples from the man himself. Helios, the program is just for creating a graphical interface for cockpit functions. The software itself causes no issues. When it comes to the exported displays, all helios is doing is creating the monitor setup file for you within the format that DCS expects. However the custom names and “patches” are necessary to facilitate the “#1 reason” above. I think the bottom line is, if each “viewport” for each aircraft already had a specific/ alternate name (av8b_left_mfd, f5e_rwr etc) that could be called , instead of a generic “ left_mfcd, right_mfcd” blanket covering all aircraft, then there wouldn’t be a reason for helios to “patch” anything and create the custom naming using “try_find_assigned_viewport_“custom name”. This would, in turn, negate the IC failures from modified scripts… OR if this sort of API was exposed and available on the user end and not an internal SDK, then that could completely change the game, being able to drag and drop exports

I always disconnect boost and use it only at higher altitudes when required to keep MP nominal. I’m sure there are many reasons/ situations where one could/ should use it, but I find no real advantage at lower altitudes. I’ve also read that when using it at low altitudes that it draws more power than it can produce… although I’m not sure if that performance metric is really modeled in DCS.. I can’t really tell a difference one way or the other

I noticed this as well. I’ve got everything tuned to where flight/motion is silky smooth in every aircraft I own, even flying low over big cities( Sinai excluded) through valleys with nothing but trees in view, up close and personal. But in the f-5e, and it alone, I get “microstutters” while banking, turning slow and rolling. Even in Caucuses while not flying NOE.

This is interesting. I have some difficulties in the f-5 as well. As you mentioned, I’m one who have just delt with “inaccuracies” and trial -and-errored my way to a solution. I wonder if you get the same results adjusting the “pilot head position”( r-ctrl + r-shift + numberpad keys) as using the physical seat height adjustment. If so that would be handy to just r-alt+ numpad 0, to save that view position instead of adjusting the seat height every time.

Oh I see… So I have always had an issue trying to exclude a monitor on the far left from the dcs screenspace. You will probably need to pick the monitor type- 3 screen, but you will probably have to do some manual editing of the monitor setup file. That’s going to go a bit beyond me since I’ve never setup a monitor file for triple screens… I know quite a few people do it but I think the tricky part will be trying to exclude the TV from DCS’s screenspace, so you can use it for other things. There are a couple guides on setting up multi-monitors on the forum ( bugs and problems—>multi-display bugs thread). You might get a few answers searching through that section. Sorry I can’t be of much help. I’ve just never done it. Although maybe inconvenient for mouse movement, in windows you could try moving your tv to the right side of your other monitors, that way the dcs UI isn’t trying to start at the top left of your tv ( coordinate 0,0) where dcs expects its screenspace to start. This would essentially make you far left triple the starting point as DCS expects, and your resolution width would stop before your tv, leaving it open for other uses. I still believe you want to select 3 screen in the monitor type, unless you have the three setup in Nvidia Surround, to act as a single screen.

No problem! I did the exact same thing when I set up multi-monitors the first time.

For custom resolutions, you can just type it in the box.