MadKreator

I was trying it last night and couldn’t get it to work. I tried on the CDU and MFD page.. I watched a video of creating flight plans and it seemed to work, but I tried the same thing and it didn’t. The video was pre- recent patch, so I wasn’t sure if maybe the patch broke it, like the mark button… If it is functional then we just chalk that up to skill issue on my end

I bought the map on first release and I think it has come a long way. I run on a 4k OLED screen so that could possibly make a difference in perceived quality, over 1440 or 1080 screens and VR. Of course in Heli land ( sub 2k/1500 agl) it’s not photo-quality, as per all (most)dcs maps, but I think they a very much on the right track. There’s probably a lot of areas still technically defined as “low detail” too. All in all when I first bought the map it was underwhelming to say the least. But it’s in a much better spot now and very much on the right path if they continue fine tuning it. Just my opinion. I will say as I’ve been flying helis a LOT more lately, terrain issues are starting to really stand out across all DCS maps. Not nearly as annoying as the horribly close range of grass and bush “pop-in” and full level scenery LOD’s ( DCS engine’s fault though, not ORBX). I have full faith that out of all map devs, that ORBX has the tech and ability, but DCS terrain engine/ tdk etc being the limiting factor in what they can/ could achieve. The have stated themselves that the EDGE engine is very limited in file size it can handle and they have to work within those constraints. ( I know nothing about terrain development and what’s possible, just relaying things I’ve read along the way)

I was just about to bring this up. The Mark and Direct To functions are very much desired … also MGRS

Also if you get moving too fast in a taxi, it can lift enough weight off of the wheels ( but not off the ground) to where the steering will not work.It doesn’t take much speed to induce that effect.

I pull the brake handle first, then press the brakes fully, release them, then release the brake handle to get the parking brake to set. To release, just tap the brakes. ( works the same way in the p-47). It’s very possible that they are not engaging if the axis/ sliders are not going to a full 100% travel. I have not read the manual but that technique works for me

I just installed v 5.5.2 of TrackIR software last night and it worked fine in DCS… Once I got the software to open.. .Kept getting DLL errors but I just had to run repairs on Visual c++ 2012and 2013 in windows. But compatibility with DCS in TrackIR v 5.5.2 seems to be just fine

Hey good find! Will have a go at this as well!

Those 2 will stay black. DCS still sees them as part of the total “screenspace” DCS monitor coordinates always reference the top left of the left-most monitor. You could exclude monitor three and use it for windows while playing. You can only really totally exclude monitors to the farthest right and below. I suppose you could unplug those two, start DCS, then plug them back in, that might trick it since DCS has already read the monitor file. Might work , idk, just a guess. But of course that exactly what you don’t want to do every time I would also love a way to totally exclude a left monitor to be able to use it for other things. But sadly I don’t believe it possible with the way DCS handles monitors currently.

It does indeed store and read it per “CustomX.lua”. Works like a champ.

I have done that in the past too. But can it be saved per preset? Or is that a universal setting? Ideally I only want the VR preset capped and 2D unlocked so I can play with the slider without it overriding the options.lua. ** I answered my own question, no it doesn't save per preset. If I change it to 72 in options .lua while preset 3 settings are applied ( the preset I use for vr), great it saves it. When I go to preset 1 it changes to whatever the slider was saved as for that one. But then going back to preset three, the fps slider and options.lua settings are now back where they started, not the 72 fps that I saved. ***found the custom presets in savedgames/config/OptionsPresets/ Custom1.lua, Custom2.lua, Custom3.lua.. changing in here does save it per preset as it should, as long as you don't touch the slider lol - for me personally its not really an issue. It was more of a thought/request for the community as a whole. If there's a slider, then I would assume it should be able to be set to whatever a person wanted. Then again, like most of us, I have a lot of opinions on what should or shouldn’t be done in DCS Not my call though, so a simple wish list request is the best I can do.

Standalone. I used his launcher for a long time, then I stopped as I hadn’t really done VR all that much. Then the fps slider and launcher came out, which I really do like. I only need two presets, 2d and vr, have them all set up well, but just think it’s a bit odd that the fps slider is only in 5 fps increments. Of course I’m not going to quit playing because of it.. just thought it’d be nice. If it never happens I won’t cry or lose any sleep

For us weirdo multi -screen users it would be handy to be able to manually type in the system resolution in the Launcher, just as you can do in the main game settings. -Low on the list but its just a thought

Would like to see the in-game FPS slider move in 1 fps increments or have the ability to type in the preferred fps. Such as 72fps for 72hz VR. -Playing more and more VR its a pain to go back into Nvidia Control and cap it at 72 to play vr for a bit, then go back in and un-cap it for 2D. Would be good to be able to leave it unlocked in Nvidia and set a cap for 2D(if necessary) and a correct one for VR in the Launcher. Mine happens to run best at 72 hz/fps as I’m sure many players’ also does.

It’s in early stages. Right now, just the way the Monitor file is formatted has changed, to basically separate each aircraft by _vehicle name, instead of it just having a list of the “Helios named exports/ patches”. If you want to use the default names right now, there is still a bit of a process.. you need to do a re-configure in monitor setup to get the new monitor file format written ( either placed in “Combined” or Separate if you like to manually edit it. Uninstall the patches, then disable the ones you are changing into the default names , so helios doesn’t write those files, then reinstall all the other patches. Then either go into the helios profile and change the name of the viewport in each profile you wish to change, or take the “Separate” monitor file and edit the names there. Although changing the viewport name in each profile then doing a monitor config is prob the best route.. DCS Monitor settings screen will give you a bunch of “conflicts” as the code is still WIP, but it will let you configure and the monitor file will work.

I would hope they do. They have it done already for some of the viewports in each aircraft. The viewport files I examined for each aircraft don’t seem to be copy/pasted across modules, so I’d assume they are each written from scratch and those lines are added only to a few select items. Each module maker of course needs to do their own. It has to be common knowledge I mean Deka did pretty much all of them in the Jf-17. I’m the last person anyone wants to talk to about scripting and I managed to trial and error my way through it in a few minutes. Bluefin and Jonsky’s lives would be much easier if devs would take a few minutes to do this. Hell, I would send ED a check to cover the hour of dev time it would take for them to copy/paste the two lines into each file

As an added note here. The same function ( two lines of code ) just need added to each “viewport” file and a name given. The same as is done for ( RIGHT_MFCD, LEFT_MFCD, CENTER_MFCD). It literally takes a few seconds. Every module has those mentioned defaults, but none for say the rwr, ded, iefi etc. In the CH-47 they added many more ( which aren’t activated or named yet) but not ALL of the available viewports are “exportable”. Some aircraft have more, some have less. I was just having this convo in another thread actually about the simplicity of it. There is no need to re-work the IC System or any of that. The solution is very simple. The devs just need to add the two lines of code and give each a name. - As far a Helios is concerned, of course no one can expect the devs to conform and rework IC around Helios patches because all helios patches do ( for the most part) is add those same two lines of code that are built into the DCS Export API and gives the viewport a name ( for the ones that aren’t setup natively). - @WRCRob in a recent Helios update, the monitor configuration/ writing was re-worked so that it now allows the default names ( right_mfcd, left_mfcd etc) to be used for each aircraft. The monitor config, now separates each aircraft instead of them all being lumped together. Helios has been changed to better conform with/ work with the DCS native exports and name. -This now makes the solution even more simple as now each module literally just needs each of its viewports to have the lines: dofile(LockOn_Options.commom_script_path..”ViewportHandling.lua”) try_find_assigned_viewport(“Name”) just as they are for the left, right, center mfd’s , TEDAC, etc. Again this is a native function to DCS, not a user-made-up process. Of course ED would be able to implement their modules and others like HB, RB, Aergis would need to follow suit with their, if they are willing to oblige. -I mean I could/would send each file in a zip( for the aircraft I own) , already modified, that the devs could literally drag and drop in place and the export IC issues would be gone -The continued frustration comes as external displays, simpits, MP etc are becoming ever more prevalent and the requested change would literally take a dev seconds to copy/paste into each file. Especially being something that is already part of the core that for whatever reason, is only applied to a select few viewports and not all of them. We do appreciate your assistance in this BigNewey, as well as NL’s!

Like Jonsky said. All that needs done is add the two lines in his last post to any “non-native” viewport file and give it a name, then use that name in your monitor file. Thats literally all the devs need to do to make all viewports exportable. I’m not sure why they only pick and choose a couple of them. A Helios “Patch” is literally the same thing. In some cases though a “patch” will modify another part of the file. Like in the CH-47 rwr, when you export it, it’s just a giant blob texture unless you also change the line “Draw as Wire” from false to true. Then the symbology is legible on the export. The f-18 rwr is the same way, except you tweak the “stroke thickness and fuzziness” values. Adding the lines yourself, of course break IC. Baffles me that the devs writing the scripts don’t just add the lines while they’re typing. It would probably take an extra 3 or 4 seconds

I will show this to Bluefin to see if he can get it modified for the new FC series naming

Yes two different worlds for sure. @jonsky7 does a hell of a job figuring these things out and always striving to improve the experience and ease the pain for people!( and thank you for posting that list of all of the default viewport names). Bluefin does a great job too working within the confines of the Helios software and trying to always improve it. Good work on combining the two different ways they are written @MAXsenna. I will for sure be stealing some of these ideas to try to help refine the Helios exportsAnd see if the FC exports can now be added, I think a lot of people would like that. If you get them all working and figured out, I may pester you for a copy of your monitor file, and maybe the entry.luas of the FC aircraft, if you don’t mind, someday Might make Bluefins life much easier seeing the key information first hand. - on a side note I don’t believe Helios has had much support for the FC aircraft since version 1.4. I’ve tried to get some of CZ’s profiles updated and working briefly but didn’t dive in too deep. I think even just some fc series viewports that don’t break IC would be a good start.

That I’m not sure of, Ive never used any of the fc fc/3 modules with helios.. I don’t think Bluefin has done anything with the fc, fc3 interface or anything yet. The monitor change is new, there was quite a few bumps getting to differentiate CZ’s generic interface in modules where its copy pasted ( like f-18 using the a-10 interface and Blackshark and gazelle using the same) so theres bound to be some more work done to it. He’s finishing up some stuff for the next helios release and the CH-47. Then I think he’ll be gone on vacation a couple weeks. But I will try to look into it and see if something he wants to tackle after. I’m not so much interested in the fc jets but a lot of people ask about profiles for them so it’s always something I’d like to try to get working. I have not dug into it much after the fc2024 releases, which I don’t have it anyway, but also have not looked at things like the f-5e yet. I asked Bluefin if he was going to redo all the patches and viewports to go with the standard naming, and while a little hesitant, he wasn’t opposed to it completely. More worried about breaking every single profile ever made with the “Patched” viewports lol

I completely agree. I don’t understand why the export API isn’t opened for all viewports. I know next to nothing about scripting and after following Jonsky’s findings on the CH-47, it took me no time at all to modify them into working “patches” for helios and make them exportable. The scripting is already built into DCS it literally just needs placed in the appropriate file for each aircraft and a name given to each. That being said, seeing as how the CH47 viewports ( most of them) are in a totally separate file from the aircraft, it makes me wonder if they aren’t working on something better. Keeping hopes up. Maybe one of us should compile a folder full of all the non-exportable viewports with the changes necessary to make them exportable natively and send it to them

Helios now structures the monitor file similar to this. Separating each aircraft so you can use default viewport names. Wasn’t sure if you caught that addition in one of the recent updates. ( you do have to rename them in Helios manually and disable the accompanying patch). But for simple setups with native DCS exports/ names it will no longer break IC.. The forced/patched exports still will though. And as always, Thanks Jonsky!

Ran this script on mine and it modified over 4000 files, saving around 70 gigs of space and couldn’t tell one bit of difference in quality. Used 2-3 less gigs of VRAM flying the CH-47 in Afghanistan. From maxed out 16 to 13.3 ish.It’s a much needed optimization across the board, I believe.

I’m with you there. I spent the last couple hours playing with all of the settings in the graphics.lua for my visibility range and nothing alleviated the super close pop in down low ( sub 200ish ft.) I was mainly trying to get the highest LOD level appear farther away so you don’t see things on buildings still coming into view 100ft in front of you. It’s not a first person shooter or rpg. Also the distance the ground bushes pop in is distractingly close( one of, if not the single most annoying aspect for me) . I even double and tripled settings to see if I could see any difference. The only things I found that worked was increasing the view distance multiplier ( on extreme in my case), from 1.5 to 3 made distant things come into view about the same as they do in the f2 view.. ( still wondering why you can see more ( farther )in f2 view than f1).. and one setting that didn’t work: increasing the lod multiplier setting to 10 instead of 1 actually nerfed the high level LOD’s and the wouldn’t even appear lol( probably past the engine capacity or out of the value range). But at lower settings like 2 or 3 I still saw no real difference. Not what I was looking for anyway. - just trying to get the scenery to be better.. placed objects/ units etc play by a different set of rules i think - not sure why we don’t have sliders to adjust everything by now, from minimum to system crippling settings in each category just thinking out loud.. - I’ll add a number 4 to your list of reasons… ( not in a rude way) doing things like this don’t make money, directly anyway. On the backend, yes core improvements and updates/upgrade increase the QOL and “fun factor” I guess you could say, and overall makes things feel better and more interesting. But may not be enough of a driving force as theres no direct(ish) return on investment. - things like this I’m not sure are “track worthy”. Anyone can fire it up in a free flight and fly down low and see what’s going on around you and where things could improve. -maybe were being too picky - don’t get me wrong, I still fire up dcs pretty much daily and develop some things for it, mods if you will, and enjoy it. But every patch I can’t help but hope to see some more advancements in some of these areas after literal years of users begging for them.

I tried a texture script from a guy in the Modding section. It automatically cuts ever texture it can find in DCS in half. My texture files went from around 130 gigs down to 61 gigs in size. I didn’t notice any difference in performance by reducing the texture sizes. Same results on Marianas flying the Chinook. Of course results can widely vary system to system. But a good part of me believes that texture size isn’t the “main” culprit. The texture files are huge in comparison with other modules so I’m sure it is playing a role too.