osram

thank you @Abadron and welcome aboard. I suppose that's what you refer to. Else for the MFD's its all explained in detail in the installation instructions.

We will centralize/channel this lovely variation and contribution together to be included as a variation for those in "need" Thank you for this contribution. It is very much appreciated. I'll hit you up as discussed to get this included in the original opening post.

Make sure to check out @Devrim's amazing monitor to touch display conversion and upgrade path! Well done. It is a new, very economic path to provide touch functionality to your old, used or spare standard monitor.

I'm not sure if that really helps, but no - that's not only you: You are not alone in this. The issue is worst so far in the JF-17 especially during night. Last update I got from deka is that they look into the issue with ED. Also I seem to have inconsistent behavior in the AH-64D using DCS lua command-interface as in displays/brightness not being able to be turned completely off/dark where they should. But hard to say where the problem is with the number of potential sources and general state of viewport-export functionality, might as well be my fault, unrelated. No idea.

This kind of poll is hardly representative, imho. As the number of JF17 owners (and also fanboys :P) is probably much smaller than that of an F16 or F/A18. I'm gonna be honest, I own almost all modules; and am admittedly not a big fan of either F16 or F18, neither do I have much flight-time there at all, but specifically due to their avionics and "logic"/handling seemed rather underwhelming. Like the modal master-modes in the F16 depending on the "previous" mode. Not a fan of that kind of "modal" states anyways. Not on my hotas config, and not in a plane either. Very unnecessary and counter-intuitive. The king of modal dependencies, " decision flowchart mechanics" and confusion must probably be the Harrier. And also compared to the rather logical example of an A10-C II for instance - the F18 in relation to TGP and modes also has that occasional unintuitive "dependency" thing going, imho. In any case: You get the "grain of salt" fanboy opinion from the 'minority' here - from the other side of the "spectrum". The JF-17 is by far one of the most modern jets in DCS: And it shows very clearly. It therefore has a rather no "BS" and simple, modern straightforward dependencies, ergonomics, usability and avionics. With some other limitations, or missing "features" due to being a lower-budget plane. But that doesn't hurt it's modern simplicity and usability either. I say these poll results are very misleading: imho a dry and empiric analysis, or averaged "numbers" of owners actually owning all three... would possibly lead to the very opposite result. Imho the JF-17 is extremely underrated. Somewhat "niche" in a sense. And very straight-forward. Dead simple to refresh for sure. Even after longer breaks. Not even going to mention the SA and combined Radar/SA/RWR page with datalink. etc. even if I'm more of a CAS/A2G guy. Since you specifically ask for "intuitive use". It is the Jeff: 100%.

From what I understood the DCS replay system is very old and cumbersome for content creators: After a multiplayer session of multiple hours it basically seems impossible to retrieve any of the amazing situations and potential content to create videos from. Not even with a top 1% machine. I'm able to speed up to 2000x (or more?) without crashing the replay; haven't verified the actual correct outcome though. And it won't be able to actually truly speed up above anything than 8x/16x, if at all - Since the processing/speed will no longer be able to keep up in practice anyways. So in practice I'd have to wait for hours to get one single chance of "recording" and setting up the actual scene that takes place around 3-4+h into the multiplayer session. Wouldn't it be possible to create a new Intermediary Replay system using Dedicated Server builds? As in having the inputs and everything be processed without actual DirectX/GPU/Video Output... to accelerate things? And then only activate the GPU/Video output when the replay/calculations moved to the desired time? Maybe that way your DCS users would sort of get an ability to somewhat "Rewind" or at least "Jump" to specific times more quickly. This state or the input/replay-processing could then even be "snapshotted" to continue the next calculations from. Maybe? Or at least to repeatedly jump to specific "bookmarks" and times more quickly.. to record or view the actual replay at the relevant times. It could possibly enable more ways to verify state or possibly circumvent corruption of replay-outcomes. Possibly with users having more options to go "step by step", and avoid corruption. Would something with such intermediary replay system be somehow possible? I am sure everyone would appreciate an improved DCS replay system that's at least somewhat usable in practice; With an actual ROI - As more potential customers could be attracted with much more and much better content in return.

it's ok, it's still on the software side though - I'm sure it's doable although never used or needed it. once mastered we can maybe one day venture into using actual midi audio devices as virtual or hardware axises and devices in dcs or for most sims/applications.

I believe I'm relatively calm for having someone provide rather useless and confusing "information" and being somewhat provocative, or at least without constructive criticism, for no good reason. I hope it's not too 'unnerving' for you, if I speak my mind about things in my own thread. @Chrischan

And now what? I'm not sure what you are trying to "contribute" or achieve here other than telling people about your fantastic story of doing something marginally "different"? Like the difference of a click here. Or a click there. Even if you saved 1 click. Tastes are always different, that's perfectly fine. At least I don't go around in people's threads and work, trumpeting around how I enjoy someone else's work more... while providing zero substantial information or wisdom. To the contrary: Possibly even confusing information - Certainly nothing of much value, to the people normally/regularly using this profile at least. "Yes the first time it was more clicking. But now! I save 1 click each time!" No offense mate, but maybe you see what I'm getting at. I don't see any benefit in that "other" 'workflow'.. at all. Unless you want to talk about saving like 3 clicks per week.

That's not really a simpler "solution". Nor is it "yours". Imho it takes more clicks to change things. I presume you did not quite read the installation readme, but whatever. Else you would have realized? Anyone can do as they please. The example you show contains multiple extra/added and also completely obsolete viewport-entries. Completely unnecessary when using my profile and following the instructions. Not quite sure what you are doing there, or maybe not even related to the Multiseat Touchpit profile... but if it is... What you really need to do is: Is simply comment out the CPG Left and Right MFD. That's all. Not 3-4 Viewports. Takes me literally... 3 seconds. To comment-out or -in... the two CPG lines, Ctrl + S And then restart DCS. Over moving/renaming around files (apart from overkill OVGME or other modmanagers for this purpose, maybe?) and having the extra clicks to change the dropdown in DCS system as well, I believe. O.o Don't even need to stop/start or change the Helios profile. It just works, with minimal effort. But hey. You can always make things extra complicated. If you like

Not maybe. That's absolutely possible, yes. It's been discussed or I think at least rather basic knowledge for those creating profiles for the Apache Some also had the PLT or their MFD's of preference running in the corners of the main screen. But it's not what this profile is about. I'm not going to cater my helios profile or viewport exports, and designing them around a "broken" state when ED (afaik) doesn't even acknowledge the viewport issues for F14 and AH-64D. People can edit and use the profile in whichever way seems best for their needs as well. More than welcome to, just not redistribute without consent. And if it's useful variations they can always get back to me, so I can verify and include them as variation in this thread. Also the time/effort/testing needed to maintain even just 2-3 different, moderately deviating "variations" (for the specific MFD issue) without much user-feedback in first place - Is just not worth it. Quite frankly. With a bit of practice in worst case, it means a 3-second file-edit and dcs-restart to switch to the other MFD's. Can't "hot-switch" without RTB/Re-Role in MP anyways. So yea, it's unfortunate and annoying, yes. But still manageable. Let's just hope one day the F14/AH-64D mp situation, viewport-exports, hot-seating and hot-switching of MFD's... is improved. We will see. Should it happen, this profile is ready and waiting, and should work exactly that way, as intended, without any modification. The way it imho should work for users in a comfortable manner; in first place. Time will tell.

Aw thatt's very kind of you, m8. Just nice to see what kind of ideas or developments grow from this. That's rather awesome to see and that it works. Congrats! If you can specify actual "marketing"name(s) or "model/brand" of that touch-foil upgrade for people to find more easily. Not necessarily any specific store-links, but for people to have an easier time to find, or maybe even find alternatives. Pretty awesome if it works well and quite cheap so people can try and upgrade any old/unused monitors with touch capability. And try DCS Helios with touch-cockpits on a budget Touch works good enough so far? Turning radial knobs, pushing buttons or dragging/toggling switches works well? I presume the touch-foil's have the "usual" USB-C input to connect for touch functionality? With extra third-party software/drivers or just vanilla Windows "plug&play"?

Obviously! - DCS multiseat modules currently do not support positioning the PLT/CPG MFD’s on the same X/Y position: I'm not sure. or maybe Comic Sans would somewhat help people to actually read what's written in front of them. On the screen?

Being a dude that dislikes uncertainty, missing clarity and confusing forms of communication; (Be that in life, or on "occasion" on DCS forums as well..) Even if I have quite an associative mind and usually try to cover many if not all ends. I'm not quite sure how to communicate or put things more clearly?

hi. what's the status of these issues? I use no mods and in the current OB version the MFD issues at night for viewport exports still seem to persist. no matter if tgp-pod, HSD etc. the exported mfd's are way too dark at night.

@Goblin 1-1I don't think so. The appreciation is deserved; As so far you are one of the first to actually work with the profile in a practical manner and provide some actual, substantial feedback to potential "issues" etc. I have a suspicion; I presume you use an older version of BunnyClark's profile. Or your own modified versions of his and/or my profile. Afaik his older versions are separate - But his newest version is a combined PLT/CPG helios profile as well. I have put quite some effort in reproducing and pinpointing this issue and adjusting things. Can you try using his newest update, combined PLT/CPG. And tell me what happens with the behaviour of the BRT knobs?

Afaik Control Manager support for CH Gear is long gone and from my experience not recommended. It can or most probably will lead to all sorts of issues as it's no longer supported and updated. My old gear was USB Pro Throttle and Fighterstick as well. Only the Rudder pedals remain nowadays. I recommend uninstalling all of that or googling how to do it, potentially. And then just using the vanilla Windows "Plug&Play" Drivers and mode. That setup still works without any issues and actually works best. Ditch CH gear Control Manager. It might even be the cause for your current issue.

Probably depends on the map-data, i.e. Syria seemed not to have any useful grid underlay. Maybe there are other maps with a more useful grid on the underlay. I think we are repeating ourselves here; the core separation and focus of Apache-Grid on distance-measurement should be clear by now. I answered that part after finding out myself after a few calmer, SP attempts already. The potential grid on the map-data inside the Apache charts might be an alternative on certain maps. Possibly? Thank you for that extra information and your time in any case.

I'm not sure or into any F14 profiles at all. But if you are somewhat technical (not too much). One of the creators of one of few 2-3 AH-64D profiles here so far. Was my first profile. And think it came out rather nice so far. You can hit me up on helios-discord if you like - And we can maybe look at it some time. Especially if the F14 native interface or profile is not up to date (?), and you don't mind creating your own lua-interface for it instead. CaptZeen's Helios Discord server https://discord.gg/hq7MaVBU

Uhm I have rechecked. On the screenshot your VID button is not set to the max. Are you sure you tested/compared with VID on max. in all comparisons? There might be an issue I'm looking into and testing - However from what I see the difference should certainly not make like 95% in brightness difference. It's actually rather marginal. Anyways, good input. I'm on it. Seems rather hard to test so far. It strongly depends on the brightness of the displays as well; Set another settings brt/con profile for my secondary touch now - And it's even brighter than a rather bright monitor-setting on my primary monitor already. That shows how relative it is; What I notice though is that the viewport does not seem to jump between NT/DAY at all, compared to the cockpit. Just hard to say if it's due to brightness limits or something. I tested another setup for the profile and interface-data as well. I had initially switched the argument-values since my Modal Day/NT/Mono Knobs were already set up for wrong/reversed NT/DAY state and afaik it should only matter for the interface to lua. The DCS side of things should usually work with the "argument-value" mainly. But haven't looked into that specific function much yet. Also I'm not sure if you use two "overlaid" PLT/CPG viewports at the same X/Y position or just PLT/CPG separately at different locations or in separate profiles. At least for other, simpler types of overlaid viewports the BRT can also act wierd and inconsistenly. Not sure if you tested against bunny's newest version. Or if that version has PLT/CPG viewports at the same X/Y position as well. So as you see, even a single knob and it's brightness with the layers of factors can quickly become more challenging than expected. I can offer to send you a profile which should have the exact same data and profile/content for you to test on your end. Even though I believe that little change should not actually matter. And then again; Testing or discussing these things is probably easier on discord. Here it's just really painful to explain in detail.

That's very interesting and a very good find @Goblin 1-1 I really thought it to be the behaviour or limitation of the Apache, but seems like I did not apply this AH-64D/DCS function or data-structure correctly after all. Not that this has much to do with software dev, but that side is comparable - Hard or better; impossible to dev and test things at the same time. That's why back in the days there were dedicated alpha/beta-testers. Since it's always tedious and dry. Sometimes they would even get some compensation or pay. Crazy eh? All of that is too expensive nowadays. We, the consumers are beta-testers for early-access - And even fully released games/software. Interesting that it moves correctly for the visuals and animation, but uses the wrong value "scale" underneath. Already pretty sure I visually see where the problem is in my mind. Remember something. I will re-check, test and release a little hotfix. Obviously you will be accredited, I am very thankful for such feedback. That usually only comes when people truly start using or learning things in a deeper sense. I like your progress and solution-attempts so far. If you can align the content and style somewhat more with the original Multiseat Touchpit - I wouldn't mind having a session on discord together - So we can possibly release a verified, tested and optimized version for mobile users. If you like.

I'm thankful for any reply @Raptor9- Not meaning to be mean or so. But that's not really a solution to the question even if no one is to blame for no available solution, it's just the decisions, possible/available tech and engineering of the Apache at that time; Unless I missed something in your reply. When I zoom to level 50 on the TSD chart I can see the "major" grid and grid-letters I presume you refer to, yes. (Unless you meant something else in your short reply) But those correspond to the grids of the F10 map when you zoom all the way out. They are so large, they could probably contain Andorra in a single grid-cell. So that's not exactly useful or practical for the question at hand; To practically orient or target via a corresponding grid or any sort of indicator/helper - corresponding to the (smaller, higher-resolution) F10 grid in the Apache. Also your reasoning seems a bit off, Imho. You make it sound as if the (for example) "10km" scale or resolution indicator makes it perfectly clear that it is basically a completely dumb, detached and basically useless grid. At least in the usual flight sim or DCS sense. At least for us "spoiled" players, that is. You know the F10 map for the small, named grid we enjoy to use seems to be defaulting to approx 5.5nm, so 10km. I can set both F10 and the Apache to a 10km grid. In a technical sense It has nothing to do with why the Apache's grid is static.

After looking at it in some hot-start instant action; It seems to be literally like an "oldschool", purely for distance-measuring purposes... oldschool grid which behaves as if it was stuck to the back of the MFD's. Completely unrelated, detached from the actual map or any coordinate system whatsoever. That explains much, I presume. Basically useless for coordinate-grid orientation. Sadly.

I presume it's an INU/alignment or "FRZ" map thing, possibly? Maybe someone can try to explain? Why does the TSD coordinate grid move with panning and heading? I am trying to use the grid-names from the F10 map using the XY and 1234 1234 cursor info in the AH64's TSD to try and quickly/roughly place target and waypoints. However the grid seems to move all sorts of places when panning, with the movement of the pilot etc.? Is that intentional? So sadly almost impossible to properly and correctly target grid-names or keypads "in-flight"? Or how is that done in practice. Any advice?

Yes you can just copy/rename the file, edit, move or delete elements as you please. if you edit the viewport sizes in their respective "panels", reposition things etc. and just save the profile reset or set the monitor setup indication - it will also export a new monitor-setup file based on the new MFD sizes and positions. If anyone creates clean/modified alternatives, maybe for mobile I can accredit and include them in the main post as well. With some form of exchange/teamwork, discussion and verification. What I wouldn't like are minimally modified versions redistributed by other people via other channels. Which might then create additional support requests for entirely different mistakes, versions or issues that possibly end up with questions directed to me eitherway. In any case or form consent/request has to be requested and granted. Always open to help and assist somewhat as well. I'd just prefer that to happen over voice and discord though. Certainly easier than having to cover all ends in my usual text-walls.