sc_neo

Personally, i am less concerned with some bugs on certain modules. I am more interested in getting an update every now and then on where DCS is headed on a bigger scale. And that could and in my eyes should be done by the very people working on and implementing stuff. Even if this means that the less english proficient ones have theri blogpost be translated by someone on the team who can do it. For instance, Yoyo's wake turbulence stuff looks amazing. But it would have been more impactuful and probably be appreciated way more if he had written a proper blogpost showing off how he researched it, how it was implemented, what issues he was facing when connecting it to the sim, maybe a bit of background about the real world physics and how difficult it must be to translate that into code. And the icing would be if this is then connected to broader "sim and evnrionment" enhancements that ED is thinking about or already working on. Heatblur is not the uberdev., the Viggen is pushing close to being in EA for 3 years. But what they are really, really good at and why the community is full of praise and forgiveness, is their detailed and instructive blogposts about the various features leading up to product release. Especially that the various people on that team wrote those posts themselves as the experst on it. - Delineate a vision/roadmap for DCS as a sim/game where modules are just part of the picture. - Let every team working on a given area of DCS write a detailed blogpost themselves about what they have been working on and how it connects to the roadmap or vision of DCS 1 to 2 times a year. If there is like for instance 6-8 teams that should easily be 10-15 blogposts a year where the community can read about what has been achieved or is being worked on with first hand knowledge.

Still, a roadmap laying out a vision of where DCS will be going from here over the next 10 years or so would really be something! From what i have seen over the last six months or so, a couple of heavy wheights from back in the day are coming back to the flight sim market (FS 2020 and something from Micropose) and their new tech atm sure looks enticing. And at this point we have no real idea where DCS is going and whether the general world fidelity, graphically and simulationwise, will be able to compete.

Mein Problem mit dem kneeboard ist die umständliche Steuerung. Deshalb blende ich mir das pdf Handbuch im pdf-reader ein. Wenn man das per autohotscript macht, dann ist der Wechsel zwischen DCS Bedienung und scrollen im PDF nur einen Tastendruck entfernt, und umschschauen und Bedienen des Flugzeugs geht ja auch noch. Nur halt nicht in dem Moment wo man mit der Maus direkt im Handbuch scrollt oder was per Tastatur sucht. Ich hatte meine Methode etwas umständlich schon mal hier beschrieben: https://forums.eagle.ru/showthread.php?t=246756 Ich benutze hier Windows eigene "always on top" Funktion die ich per Tastendruck durch ein autohotkey script benutze, um das Handbuch-pdf über DCS borderless Bild einzubldenen. Maus und Keyboard und Joysticks etc. steuern weiterhin DCS/das Flugzeug, nur wenn ich mit der Maus über das PDF fahre und klicke wird das der aktive Fokus und Steuereingaben beziehen sich darauf. Ein Klick irgendwo ins Cockpit außerhalb des Pdfs und die Steuerung bezieht sich wieder auf DCS. Bin im Moment gar nicht sicher, ob Joystick/TrackIR-eingaben sich nicht sogar weiterhin auf DCS beziehen, während Maus und Tastatur das PDF ansteurn. Jedenfalls muß ich das script mal noch erweitern, sodass nur ein Tastendruck das PDF überblendet/ausblendet und Maus/Tastatureingaben sich automatisch aufs pdf oder das cockpit beziehen, je nachdem wo sich die Maus befindet. Also das ganze ohne die Notwendigkeit per Mausklick entweder erst das Pdf aktiv zu machen, und dann wieder einmal ins cockpit klicken zu müssen, um DCS aktiv zu machen.

Also das interessiert mich jetzt aber auch, als N1 im Verhältnis zu N2. Und sollen die 82% N1 sich jetzt direkt von den 98-100% von N2 ableiten? Hab mal die Frage im 467th discord gestellt, da wird schon einer der A-10C chefs ne Antwort haben.

Well,...i personally did not have any grave issues with the Gazelle over the last 3 years. Only small stuff. I can kinda understand the devs idea of finishing the Gazelle by backporting or midlife overhauling that was due when the current project was being released. That only took too long and mere months became 1-2 years. And Polychop owned up to this very optimisticly judged timeframe and i can easily let it rest and see what comes next. Apparently there is only 2 fulltime guys atm with Polychop, so things naturally elvolve at a much lower pace than anyone likes to think. Actually, the one thing i don't get is why Polychop chose to not take a hint from other 3rd pary devs and write a piece every couple of months on what they are doing. And i reckon this could be fairly generic and disclosing too much about their current project. For instance, Heatblur posted about various systems of the Tomcat and how they implemnted things, what blockers they ran into, that sort of things. PC could have done the same thing in regards to their new ideas and ways of modeling a better helo FM, how they create HD 3d art, the usual stuff we have seen from other 3rd parties. And that is the stuff that reasure its customers that new and better stuff is being worked on and coming at some point.

...and additionally, will all the community made programs like OvGME, VAICOM for Voicetacck etc. work on Linux. If i have to forgo the entire DCS ecosystem then....

Good luck with changing things up! I, for one, actually was fine with PC going the route of backporting the new tech to the Gazelle once the main dev. thrust on this was done. Making a progress update on things every couple of months would have gone a long way....but making progress updates on something not officially disclosed and anoucend wouldn't make a lot of sense i reckon :) In the end it seems reasonalbe to me that a dev gets better and better with each project and module being developt. And if that tech is then backported to some degree to old modules as an improvement upgrade, that is really great.

I'd pay for a "Breating World Update"! I have a lot of modules and i am sure more than enough modules would come to DCS still. What i really want is a realistic environment where those high fidelity modules can come into play. Additionally, those who argue that core gameplay and engine development should not be monetized; what did the classic game addon or expansion nowadays usually get you? Enhancement of the core game. Usually more assets were the icing on the cake but not the reason why you bought it. With ED it's the other way around. We purchase assets and hope this will be enough to fund a richer environment to immerse those assets in. I'd rather start directly funding core game/sim enhancements and pick up a module on a secondary basis. But, everyone can already go in this direction by purchasing maps and the upcoming carrier module. Yes, these things are not full on environment enhancers like the OP "breathing world" addon could be. But still a starting point to broaden the way DCS dev. can be funded and put more dev. power behind specific aspects of DCS.

@MemphisBelle Yep that feature i was referring to. But what i was asking was whether we could define the actual length in milli seconds that long key press takes. Afaik RS mapper registers a long key press after 1000ms like it is setup in the A-10c. I feel this is quite long and i'd think it useful if we could define how long a "long" button press should be. For isntance, 500ms would probably work equally well and be much faster.

Afaik Vulkan does not change DCS when it comes to threading. That is something ED has to work on in addition to implementing Vulkan. If i understand it correctly, the graphics API is not of primary concern when it comes to multithreading or the application scheduler. The big issue with the Edge engine is of course how to make hundreds and hundreds of ai units and their actions/projectiles work together seamlessly when spread over multiple threads. And this type of stuff is apparently so difficult that to this day no generic way on the hardware level exists that unburdens game developers. So i see adding Vulkan as one of the necessary steps to keep DCS relevant and Edge staying up to date, but that will mainly help a bit on the rendering side, probably not so much for the bigger issues of the job scheduler and multithreading. And that is something every dev has to implemnt for each engine and game, whether its DX 11 or Vulkan.

Yep, please do. Because i have played around with this setting numerous times over the years and i could not for the life of me make head or tails of it in sense for actual performance differences, loading times nor RAM load.

@BIGNEWY "It is what it says it is, a radius from your position where objects are preloaded, depending on your machine spec you will need to decide what is best." And what exactly does this mean? Does this include buildings that are part of the map like the Las Vegas area, or only dynamic objects that are placed in the ME like ground units, static airfiled objects and such?

Looking forward to this once my new gpu arrives! And yeah,....consecutive missions that are somewhat linked are great :)

Yep, apparently Intel bought a startup company that was making headways on the software independent multi-threading front. If somethign comes off of those efforts, it will probably yeare before we can reap the benefits.

Quite honestly,...the "it is a flight sim point" might have been valid aslong as there was no proof that it can be done. Man, i wish EDs non module tech devs would post 2-3 times a year in detail what they are working for the overall sim. Right now, we have no clue whether anything akin to improved ground surfaces in even remotely plannend or in the works.

Actually, better ground fidelity is on the top of my wishlist, even before better weather and clouds. And i feel the problem is less with the effort invested into blending of ground textures, but a lack of engine tech. If we look at the handful of current space games that have been in development over the last 6-7 years, all invested heavily into procedural generation of planetary ground surface tech. And without such a procedural tech that creates uneven, rough, high fidelty ground surfaces that through various blending techniques fit to the overall real-world sattelite images. Caucasus 2.5 is very nice and a great improvment over the 1.5, and although the ground mesh is much improved, it still is very much on the level of early 2000ish fps games. The texures ain't bad, but it is still flat squares with a bit of grass popped on top of it in places. And the aforementioned space games are a good proof of concept that these high fidelity ground surfaces neither need tons and tons of disk realestate, nor that you need a monste pc with hundreds of GBs of memory. Its a question of the underlying core engine in being able to display that hugh and detailed maps, and of crouse of the map dev. kit technology. ED mentioned plans for a full sperical globe map in the future. At the latest then, then we definetely need this procedural ground tech.

Great to see this coming to the Harrier! And dude, your mission covers rock :) May i ask, any reason why mission 3 is not being ported as well?

@twistking I can easily relate to your issues and i do belive sometime in early 2019 something changed in DCS that is "akin" to a memory leak, either ram or VRAM. For me, DCS has become practically unplayable since, i reckon since maybe early March or so. Unfortunately my GPU is dead (actually id died starting DCS from the desktop haha) and i don't have a replacement to run a couple more tests. And i think you raised a valid point, that yes, 16gb memory is pretty much a must right now, that does still mean that DCS should not have any "memory leaky" issues. So, i had an amd 7870 2GB card (which is of course blatendly vram understocked for DCS 2.5) paired with 16gb memory. And i could run DCS at pretty much max settings really well on NTTR, with 25-30ish fps around Vegas, and 40-55fps anywhere else. Caucasus was running not as well since it is more Vram intensive since its 2.5 release in January, but i did not get those complete freezes after playing for some time that i experience since march or so. So even on NTTR, even on very light missions with not much going on, i could run into complete system freezes due to system memory being filled up to the brim after 30-60 min playtime, even when returning to homebase that was running fine on mission start. Again, i cannot recall that DCS was ever so taxing on system memory since it seems to be since March/April this year. Something must have changed. What i noticed was: loading up a fresh ME NTTR mission with nothing than my aircraft more than once would on the second or third load pretty much completely fill my system memory to the point of completely freezing my sytem, unless i killed every background task like my browser etc. Again, this was not happning pre 2.5 and not in Jan/Feb 2019. Now; i kinda feel that DCS is offloading VRAM content to system memory on low Vram cards, and that DCS is not flushing this content from system memory early enough when it is not needed anymore, or when loading a new scenario. Restarting DCS clears everything and you have one good mission load again. With my 2GB vram card, vram gets maxed out instantly when loading any mission or map, and i reckon off-loading to system memory begins pretty much right away. And yeah, i know that a 2gb vram card is not up to min specs, and thus i am not complaining. The question still is; does dcs handle vram loading and flushing as intended by the devs, or do we indeed have some behaviour going on that is akin to a Vram leak that off-loads vram content to system memory until everything clogs up, and people with 8gb vram cards and 16gb memory are affected the same, albeit at a later point so that the issue does not arise that often if at all. I will get an 8 gb vram card later this year and i guess this will make for a much better situation. Still, i would like to know whether everything is working as intended or whether bruteforcing dcs with a 11-16gb vram card and 32gb system memory will be the norm. @BIGNEWY Could you inquire with the devs whether DCS is actually off-loading Vram content to system memory? Is this a thing or am i dreaming things up here?

Bookmarks...yiphiiii! Great stuff charly, thanks for adding those :)

This sounds very useful. Damn it, my gpu just passed away a couple of weeks ago and i am looking to get a proper replacement soon. I will sure give this a go then. I have been trying to get EDs Red Flags working in coop with my brother. We both own the campaigns and it should be a blast to play them together. So best of luck developing this further, especially adding a UI sound good. It's really great that more and more useful tools around DCS see the light of day. BTW: this sounds like all i need to do manually is to open a mission with a zip tool, extract the mission file, change the AIs for clients and drop that changed mission file back into the original zip? I did the manual way just now and sure enough, i could host that mission and could join either of two client slots. Great. Can't test this with my brother atm, but this looks very promising. No idea why this way of doing this has not been posted here before. Anyway, your tool will make this a breeze i reckon! Cheers :)

I always feel the animated pilot body in some cockpits is a mixed bag, and i usually fly without it since it is rather static thus blocking so vital knobs and switches on some panels. So for pilot bodys to be really fun and useful, these needed to be animated to that it always moves the legs, knees, elbows or shoulder slightly to one side when you try to look at a console etc. Additionally, this would really add to immersion if one sees the pilots body leaning forward or twisting the upper torso when looking backwards.

Hey, as the title says, i am wondering whether the upcoming A-10C cockpit rework will improve the eyepoint position so that the eyepoint gets seperated from the neck. Afaik right now, the A-10C eyepoint and neck conincide, thus when you look around (especially with head tracking) it feels a bit off. But more importantly, the HUD is unrealistic because it stays perfectly visible when you turn your head unless you start actually moving it up/down and left/right. When the eyepoint is moved a bit forward from the neck, turning your head will automatically move your eyepoint a bit to the side and thus affecting your angle to the collimated HUD, which will start moving the HUD gradually to the opposite site until it starts moving out of view. This has been implemented for all the HD reworks of ED's modules like the Flaming Cliffs 3 modules. So i reckon the devs will do this as well for the A-10C. For reference; the viewpoint in the cockpit is defined in the Server.lua and most of the FC3 reworks call the eyepoint position from the "default_fighter_player(t)" config defined at the file's top. I believe the first value of the eyepoint line is the forward shift from the neck, the second value the vertical seperation and the third lateral, which we obviously don't want. As you can see, the default fighter player config has an eyepoint moved 5cm forward from the neck, but no vertical shift unfortunately. For a proper neck like PeterPs "Proper Neck" mod, there should be a bit of vertical shift as well, but the 5cm forward shift is good for now. function default_fighter_player(t) local res = { CameraViewAngleLimits = {20.000000,140.000000}, CameraAngleRestriction = {false ,90.000000,0.500000}, EyePoint = {0.05 ,0.000000 ,0.000000}, limits_6DOF = {x = {-0.050000,0.4500000},y ={-0.300000,0.100000},z = {-0.220000,0.220000},roll = 90.000000}, Allow360rotation = false, CameraAngleLimits = {200,-80.000000,110.000000}, ShoulderSize = 0.2, -- move body when azimuth value more then 90 degrees Now all FC3 modules don't define there own eyepoint but call on the default_fighter_player(t) config. The A-10C defines an eyepoint, but has as of yet no 5cm forward shift. ViewSettings["A-10C"] = { Cockpit = { [1] = default_fighter_player({CockpitLocalPoint = {4.300000,1.282000,0.000000}, EyePoint = {0.000000,0.000000,0.000000}, limits_6DOF = {x = {-0.050000,0.600000}, y = {-0.300000,0.100000}, z = {-0.250000,0.250000}, roll = 90.000000}}), Yes, one can easily modify that server.lua and add these 5cm forward shift, but then you run into a whole lot of trouble gettintg the FOV corrected, not really an option. I reckon, ideally the neck needs to be moved 5cm backward so that the eypoint can be move 5cm foward and be in the exact same position we are used to for years.

Great to see the F-14 has been covered, and with a whopping 400+ pages, wow! On question: could add a table of content or better bookmarks (thats what my PC pdf viewer calls them at least) to your guides that is accessable from ones pdf readers bookmark section? I know klicking on one of the headers on the content page at the beginning of your guides gets you where you want. But you still need to revert all the way back to that page look up which sections contains what and do the jump from there. And reading on a smartphone makes this a bit more cumbersome. ED's A-10c guide has great bookmarks section where it is really easy to find what you are looking for from whereever you are reading atm.

So yeah, the kneeboard sure is handy, but it has limitations and is quite cumbersome and a good deal of work even with kneeboard builder if you simply want to superimpose a pdf manual, image or whatever (browser, video player,...) over dcs when running in borderless window mode. The stuff below is pretty similar to what David_OC posted a while ago for superimposing your browser via a browser plugin. https://forums.eagle.ru/showthread.php?t=187754 The method below is not program/app specific and should in theory work for.....anything you throw at it. So windows itself has an 'always on top' functionality, but this is not accesseable unless the program in question supports this, correct me if i am wrong here. Now, many of you might know the incredible powerful scripting tool autohotkey. With a very simple script autohotkey can make use of window's own always on top functionality and thus make any active window to stay 'always on top'. At the most basic level i currently use the following script: #IfWinActive, ahk_exe PDFXCview.exe #<:: Winset, AlwaysOnTop, toggle The first line simply states that when the program PDFXCview.exe in my case (you put any filename of whatever program/exe you want to be always on top in it's place) is the active window... that once i press the key combo defined at the very beginning of line two, to make that window to 'stay always on top'. #<:: is the key combo i set up right now, but it can be anything that you need to define as per the autohotkey syntax. With this very basic script, the workflow looks like this: once you want your pdf viewer to stay on top of your borderless dcs window, you alt+tab and click the pdf viewer and press your key-combo you setup in the autohokey script. You can of course adjust the format and size of your pdf viewer like any other window and place it whereever you want. Now your pdf viewer is superimosed on top of dcs, and you can still look around your cockpit and click away at your heats content as long as your mouse stays away from the superimposed pdf viewer (or whatever have you). If you move your mouse over the pdf viewer window and click once you can scroll and normally use that viewer, and dcs becomes unfocused but does not collapse to the windows sidebar, so you can easily click anywhere on the dcs window to make it focused again. To stop whatever you superimposed from being always on simply make it the active window with one click as described directly above and press your script key combo again. Now one more click on the dcs window and dcs gets your undevided attention again. I reckon autohotkey allows for more advanced and convenient ways like for instance to have a set key combo that superimposes your pdf viewer without the need to first alt+tab and even stop the mouse from focusing on your superimposed window if you clicked on it by accident. Here are some links to the autohotkey documentation that explains that stuff a bit more: https://autohotkey.com/board/topic/53249-transparent-andor-always-on-top/ https://www.autohotkey.com/docs/commands/WinSet.htm The links below are useful for understanding how to set up you key-combo you want your autohotkey script to execute on pressing. https://www.autohotkey.com/docs/Hotkeys.htm https://www.autohotkey.com/docs/KeyList.htm Last but not least; use that stuff at your own risk, you might run your expensive jets into the ground once you start watching youtube or netflix :book: superimposed on route to the AO :doh:

Could you add the option to let us define the length of a press needed? For instance, i feel the A-10c's long press is quite long, i figure 500ms might be enough. If we could freely choose a value...