Leaderboard

RAZBAM F-15E developing

I've had absolutely no interest in the Viggen but there's been a couple of sales lately and I got curious. Took a bit of figuring out as it's so different from everything else but is easily one of my favorite modules now. I can't post a steam review because I play standalone so I'll just say thanks here, great module, love your work. Between this and F-14, Heatblur could probably release a microlight for DCS and I'd buy it.

Heatblur Viggen update on Twitter:

All Mirage F1s should be capable of using the Super 530F. I can't imagine any changes done to the radar for the F1M would remove that functionality. You can even see in our F1CE cockpit a little switch for the altitude difference mode which is only functional for Super 530F missiles. Switch #19 in this photo

The video was called 2022 and Beyond, that should answer all your concerns. Thanks.

Looks like there is an error with Patriot targeting, so I will be reporting this, thanks!

Yes we don't know the AC config in videos but in DCS the lightest config cannot do it.

Wow! It’s been a while since I posted here! The year has flown by, and real life has been keeping me busy. But I have still found time to work on my pit with some new developments, and some upgrades to the older parts. Currently working on upgrading the cyclic magnetic brake and trimming system using 3D printed parts to mount linear actuators and electro-magnets, new better quality slide rails, more suitable bearings etc. Modelling the whole thing in Fusion 360, and currently trying to 3D print a flexible boot for the cyclic base. It’s a 24 hour print, so fingers crossed. The gimbal is a mix of aluminium extrusion cut to shape and 3d printed components, and I am following the structure of the authentic Mi-24 cyclic and connectors. A major tidy up of wiring harness and connectors for this is anticipated, with 3D printed mounts for relays, wiring runs etc. An R60 Controller box has been added. Glare shields have been rebuilt using aluminium sheet and massive flat head rivets, Mil pedals have been finally integrated and have functioning micro-switches, and a damper to hold position and control turn rate. Oh, and rotor brake has been implemented too. An authentic JADRO is a work in progress to get it to talk to DCS-BIOS.... The dashboard has been rebuilt and a new Map-Box also to correct some scale errors which were messing up a lot of other aspects.

With the upcoming Kola Map, I'd really love to see either a Saab Erieye or GlobalEye:

How about something unusual for a change - A Shackleton AEW, or an MR3, that will test your skills, Contra Rotating props, tail dragger for the AEW. They were still flying in the DCS era, just !! I do like the 295 Casa as well, or a Spartan, both quite rare beasts in military guise of course.

Enjoy!

Actually, I think it's a ME thing where it sets the direction the wind is blowing to instead of from.

Thank you for report! We check MIM-104 missile params and found out issue with guidance accuracy. It will be adjusted.

From what I heard (anecdotically, but from people who'd know), the Hornet has some capabilities of the HTS built in. Its RWR gear is more advanced and better integrated than that of the Viper, and while it doesn't provide all the capabilities HTS does, it's possible that the workflow for the pilot was streamlined and some things automated.

Thanks I have reproduced, and it is fixed internally so should be in a future patch

Welcome to DCS and thank you for your support, we hope you enjoy the flying.

Bis aufs Radar versteh ich garnicht warum alle auf die D so heiß sind. Ja, anderes HUD, flashy new PTID oder wie es heißt, JDAMs,... Alles nichts neues, ein paar mehr MFDs im Spiel, juche, reihen sich dann neben die MFDs von F-16C, F/A-18C, F-15E, usw. Die F-14 bleibt einfach irgendwie der Top Gun Vogel und kein Bomb Truck. Die B ist schon fast zu krass für mich, auch wenn ich sie nicht missen möchte. Das TF-30 wurde einfach nicht für den Schubkarren gebaut. Und doch hat die A einfach den interessanteren Charakter. Diese Befriedigung mit der A zu performen, herrlich.

Being a software developer usually dealing with UX and the whole user flow, I cannot be alone in thinking that having the Mission Editor (ME) and the F-10 look almost identical and have the same user interactions but that require the clicking, dragging, measuring, etc. to use DIFFERENT buttons a really unnecessary "friction point" or learning curve. Those of use that spend more than a couple of minutes in Mission Editor and then jump into a multiplayer game start to use the wrong button to drag, the wrong button to measure, the wrong button to select. Please, unify them? I'm sure that it even complicate things from the programmers point of view to keep two different interactions with the map. Thanks!

I didn't say they were. Again, this entire conversation has digressed from a point I never mentioned.

I had to check that I'm in the correct forum. this is starting to look like the wish list thread I'm still waiting for ED to approve the deuce so I can post the link here

I think people greatly overestimate the performance gains that the use of multiple cores will likely produce. For things that need to be done every frame, you get about 16 milliseconds to get everything done for each frame if you're doing 60 fps. Multithreading is most efficient when you have highly independent, long-running tasks. Games are usually the opposite of that: very interdependent, extremely short-running tasks. Now you need to delegate to multiple threads from the main thread, then it takes time until all those threads start running, modifying data that multiple threads need to access now requires acquiring and releasing synchronization objects, also implying that the CPUs would often have to write through their fast local CPU cache to slower caches or the even slower RAM so that the data is kept in sync for all CPUs, and then you need to wait for all the threads to complete, and you don't know when that will be, and the chance that one of the threads will not complete in time is probably higher too. Add in that none of the general purpose operating system kernels - be it NT (Windows), XNU (macOS), Linux or any of the various BSDs - have hard-realtime capable schedulers, and you will slowly begin to see the almost infinite multitude of problems and performance-adverse conditions that you will typically run into whenever you try to make use of multiple processors under such conditions.

For me, honestly I’d rather get an all new aircraft like the A-6, rather than another version of an already existing aircraft.

Your optimism is a nice refreshment and not to rain on anyone's parade here, but for all we know, multicore support in DCS could still be a year away. And also, it's still very much a question how much we will actually notice it at all. We already received news a few months ago that initial internal tests looked promising, so I don't really see any actual new "news" tbh. I'm normally a "glass half full" kinda person, but to avoid being disappointed, I'm not getting my hopes up too much and I'm certainly not expecting performance miracles.

Check Six Simulations Top End Australia

A. Definition of Multi- Combining Prefix | meaning more than one | So Logical + Rendering + Sound = 3 = Multi. So despite the negative waves, it's Multi-Threaded. I mean if people want to be negative about it, then they honestly have no knowledge of programming and allocated resources. Here's the part those users don't understand, you simply CANNOT give everything it's own thread, the CPU would spend more time Syncing these threads, than anything else, and the performance would actually decline. DCS as a Whole has 2 Main Bottle Necks: Sim-Calculations and DirectX11 API CPU Overhead, Which are very apparent in 2 Scenarios: A. Large Scripted Missions with a lot of sim-calculations B. Large Scenes w/ a lot of objects being rendered. Splitting the DCS Process into Logical and Render Removes Bottleneck A. All the sim-calculations on One thread, and the Render instructions on another separates the Bottlenecking item into it's own thread. Large Scripted Missions will not overload the thread with Sim-Calculations causing delay in render instructions, which will allow for better performance in larger scripted missions with a lot happening. So if we break this down into something everyone can understand, ROADS / LANES. We have right now 1 Lane. DCS-CORE (SIM / RENDER), w/ RENDER Technically going to an Off-Ramp to DX11API's Thread/Road Leading to the GPU. When You load a Large Scripted Mission, that 1 Lane Road becomes Saturated with DCS-SIM Traffic, and DCS-RENDER Traffic gets delayed getting to their Offramp to DX11's Thread/Road. Which causes delay in traffic reaching the GPU, which causes Low FPS. Splitting the DCS-CORE into DCS-SIM CALCULATION and DCS-RENDER, Makes the Road 2 Lanes. DCS-SIM CALCULATIONS and DCS-RENDER. So Traffic for both DCS-Sim Calculation and DCS-Render flows smoother, Even when DCS-Sim Calculation Traffic gets heavier, DCS-Render instructions will flow efficiently down the road to it's offramp to DX11API, and onto the GPU more efficiently. Effectively Removing Traffic bottleneck A. Now The Remaining Bottleneck is the DX11API Lane. With DX11, there is Heavy Overhead on draw calls, so every object/shape, texture, effect, is a draw call, and with every draw call per cycle, the DX11API generates Processing time overhead, thus lowing the speed at which commands are processed by the CPU and Sent to the GPU, lowering Utilization and FPS/Performance. This 1 Lane DX11API Road to the GPU, basically decreases it's speed limit as traffic increases, thus slowing down traffic flow to the GPU, Lowing GPU Utilization and FPS/Performance. The next step is replacing the DX11 Graphics API w/ Vulkan, this effectively eliminates bottleneck B. Moving to Vulkan Removes CPU Overhead with Draw Calls as well as DX11 API's Single Threaded Core and GPU Scheduling, and replaces it with a Multo-Threaded API that can process commands Asynchronously. Large Scenes with hundreds of objects and thousands of draw calls per frame, will no longer get bottlenecked by the DX11 API Overhead, and performance will allow for better performance in scenes with large object counts. Which Takes the 1 Lane Road of DX11API to the GPU and makes it a 4+ Lane Road of Vulkan. Vulkan removes the Speed limit decreasing as traffic increases, as well as letting each lane move at it's optimal speed limit depending on traffic type. Allowing DCS to Render Sim-Calculations in 1 Lane, Render Instructions in its own Lane, with the Render Traffic taking the Offramp to the Vulkan 4 Lane highway running at variable speed limits per lane. So the Final Layout would be: 1 Lane for DCS-Sim Calculations 1 Lane for DCS-Render Instructions, w/ Offramp to Vulkan 4+ Lanes Variable Speed Limit for Vulkan to the GPU. Considering the current Layout is: 1 Lane for DCS-CORE, w/ Offramp to DX11 API 1 Lane for DX11 API to GPU. Seeing as DCS-Sound is its own lightly used thread, we can say DCS-SOUND uses the shoulder of the Road, lol.

And a new one from this week on PC discord.

FAQ Note: This FAQ is very much subject to change, and nothing should be construed as a "promise". This the current intention as of 27 September 2022. Who is developing this map? OnReTech was formed in October 2021 to develop terrains. With more than seven years of experience creating terrains for flight simulators, including DCS, we have assembled a team of dedicated artists, engineers, researchers, and managers to create new and interesting battlefields for DCS World. Why Sinai? The Sinai map is of great historical importance that includes several past conflicts. The map will include different types of surfaces, large and small rivers, forests, fields, and mountains. Large and small cities, many military airfields, road and rail networks, ports will also be included. Despite large portions of desert, the map will also include greenery and forests along the Nile Delta and in Israel. What does the Sinai roadmap include? The project is divided into three phases in total. Early access: first + second phase. Map update: bonus phase with expansion of the detailed territory with 3-4 additional airfields (it's a secret for now; we're still considering which ones). Final release: third phase First phase This will Include a 1500 x 1000 km area. Of this, a 700 by 700 km will be created in high detail and accuracy. Phase 1 will include many large and small cities like Cairo and include landmarks like the pyramids of Giza. Both natural and manmade features will be included. Airfields of the first phase: Egypt: Al Ismailiyah Air Base Faid Kibrit Air Base Abu Sultan Abu Suwayr As Salihiyah Bir Jifjafa/Malez Wadi al Jandali Israel: Nevatim Airbase Hatzerim Airbase Ramon Airbase Uvda/Ovda Second phase. Additional unique objects and scenery for Israel and Egypt will be added. Airfields of the second phase: Egypt: Al Mansurah Az Zaqaziq Inshas Airbase Cairo International Airport Cairo West (Almaza) Bilbeis Air Base Israel: Sde Dov Airport Palmachim Airbase Hatzor Tel Nof Ben Gurion Third phase. Airfields of the third phase: Egypt: Quwaysina Birma/Tanta Air Base Al Rahmaniyah Borg-el-Arab/Intl Jiyanklis New Gebel el Basur Al Khatatbah Kom Awshim Beni Suef Wadi Abu Rish El Minya Hurghada Wadi Abu Shihat When will this map be available? We are planning an early access release in the first quarter of 2023. This is subject to change. How much will this map cost? Base price - $49.99 USD Early access - $39.99 USD What period is this map based on? The map is being designed to represent the 2000s to the present.

Hello all, just bought the recently released VelocityOne Flightstick from Turtle Beach and tried it on DCS. I made a quite complete profile --> see attachment. If somebody has other profiles or ideas, feel free to post them here. If someone is interested in having a visual mapping, please let me know, I'm happy to make one ! VeloOneFS.diff.lua

The PATRIOT is extremely unreliable for shooting incoming munitions such as PGMs(JSOWs) and ARMs(HARMs). The missiles often self detonate before reaching the target, or miss the target by a small margin. At closer ranges the missiles dont seem to guide at all and just go straight, obviously missing the target. First track shows a lone patriot site attempting to intercept one(1) incoming AGM-88. The site fires a total of 9 missiles at the target, all of which miss. The second track shows the same patriot site attempting to intercept two incoming AGM-154s. It takes the patriot site a whopping 25 missiles to intercept these two slow moving targets going perfectly straight. Last track shows the patriot attempt to intercept two incoming mavericks. This shows the missiles self detonating inexplicably before reaching the target very well. patrior_jsw.acmi patriot.acmi patriot_mav.acmi patriot.trk patriot_jsw.trk patriot_mav.trk

June last year i decided to make a vr pit First Cuts taking shape first time soldering.... Need to learn cable management... TekCreation Panels Side Console early build Test Fit Left Console Flood lighting test About this point I transition from VR to full pit.... DDI's AMPCD and Tekcreation UFC and IEFI in place Night lighting work has commenced How I feel when I am in it.

I think some run into a great mis-understanding what a - at least fixed base - simulator can simulate at all. Plus never mix what cameras record in a moving and shaking environment with what a human beeing 'feels' beeing in the same place: the human system - eyes, vestibular system and seat of one's pants - compensates for a lot of different aspects and mixes them in the right way so that one at least trained or used to person would normally rarely really see that shaking but just feel it mostly. That is something that can hardly if at all be simulated and there is no chance to simulate it right for the most use cases without a proper motion rig and then, if you don't get it right, even experienced pilots would get motion sick very easily because it doesn't fit to the real experience. In rather every clip I have seen, where real pilots 'tested' and experienced DCS they told that the aircraft systems are simulated very properly, but it lacks of course the feeling of the real thing because there are no G-forces, no moving parts etc. So even if the simulation would be able to push all those environmental data and physics through the PCs processing power onto the screen you wouldn't think its right, because your are not connected to the simulation like in the real thing. So besides the technical restrictions modern hardware and its limits provide, it makes only sense to a certain degree to simulate that all like nature works and even sometimes you have to do something 'wrong' to trick the human experience. Just my 2 cents. Pushing the boundaries is always a good thing but you have to know the limits that make sense.

Yeah, I mean you can certainly smoke your hopeium if you got it, but honestly I'd be pretty surprised if it was out in Dec with like 0 hype/marketing. Which I'd assume we would see by now if it was happening.

They are similar enough and different enough that the order doesn't matter. As both are US fighters the same general ideas apply to controls and they have very similar weapons options. They're both light fighters with weaker radars. Specific HOTAS logic is different, and I'd say that F-16 is better here with less steps needed to setup systems in general. Both are fly by wire, but the Hornet's is a little more hand holding, however the twin tails on the F-18 allow for a lot more high AoA performance. Conversely the F-16 is much much faster than the F-18. Flying each in combat is slightly different because of this. The last major difference is that the F-18 is carrier capable while the F-16 is not. If you're interested in naval aviation, lean toward the Hornet to learn carrier operations and drogue refueling. If you prefer air force, go with the F-16 and practice land operation and boom refueling.

The fact that someone can spend 7 years to attempt making a single simple plane for this game is deeply troubling…

Hi, I would like to have the ability to access the DCS game engine to change the weather as a mission is running. A weather control API ? eg I set the weather in the editor to clear weather but some ground fog About 1 hour into the mission make the fog dissappear via a timed trigger the action of this trigger is to set parameters of the weather It would be nice to be able to access all the weather control parameters from a mission file such data looks like ["weather"] = { ["atmosphere_type"] = 0, ["wind"] = { ["at8000"] = { ["speed"] = 0, ["dir"] = 0, }, -- end of ["at8000"] ["at2000"] = { ["speed"] = 0, ["dir"] = 0, }, -- end of ["at2000"] ["atGround"] = { ["speed"] = 0, ["dir"] = 0, }, -- end of ["atGround"] }, -- end of ["wind"] ["enable_fog"] = false, ["season"] = { ["temperature"] = 20, }, -- end of ["season"] ["type_weather"] = 0, ["qnh"] = 760, ["cyclones"] = { }, -- end of ["cyclones"] ["name"] = "Winter, clean sky", ["fog"] = { ["thickness"] = 0, ["visibility"] = 25, ["density"] = 7, }, -- end of ["fog"] ["groundTurbulence"] = 0, ["visibility"] = { ["distance"] = 80000, }, -- end of ["visibility"] ["clouds"] = { ["thickness"] = 200, ["density"] = 0, ["base"] = 300, ["iprecptns"] = 0, }, -- end of ["clouds"] }, -- end of ["weather"]

That's not openxr, simply VR below refresh rate, nothing you can do about it. If you want perfectly smooth without reprojection then you have to get your fps above the headset refresh rate. The is no other way about it. The 5800x3D has lifted the framerates significantly but still not enough to beat refresh. You could shoot for setting the headset to 60hz and reduce some settings to keep your framerates above 60 or you could leave it at 90hz and embrace the stutter. Note that at a locked framerate, the stutters can appear to be reduced, around 56fps is about as good as it gets from my testing. Adjust the framerate throttle in the toolkit whilst flying along and looking sideways and find the sweet spot for you.

You can through VAICOM so there must be some way of doing it. (Except of course the Apache doesn’t really work in VAICOM) but it works for other aircraft.

Did someone mention a preorder??? 27

So we will have multithreading in 2025, great news

RAZBAM Twitter

I had the opportunity to try the Meteor missile when flying the Gripen E simulator at Saab in Linköping. It´s really a monster missile. Coupled to the ability to "look over the shoulder" with the AESA radar and the great SA provided by the WAD with datalink- and sensor data overlayed over a clean digital map display I felt really invincible. If the Meteor that is said to be included in the Eurofighter module has similar performance, it will be able to reach out and kill anything on the map. After dispatching four enemy aircraft heading for Norrköping I shot down two aircraft that was fleeing across the Baltic sea from a safe BVR distance. In DCS you will have to be "almost within gun range" to do that with an AMRAAM. Maybe the AIM-120D will be equal, better or slightly worse, I don't know. I am not privy to such data. But I do know that the AMRAAM we have in the game is almost toylike in comparison. Anyway, modernities aside, I still enjoy good old fashioned vintage aircraft like the Strike Eagle in DCS!

It seems to me, you are not very acquainted to how a tactical scenario of any real use in RL works. As you rightly point out speed in Bvr combat is key, first it gives your missile additional range and second it will make your life easier when defending in a agressive slice maneuver increasing the F-pole and reducing your enemy one. But having said that, there is no possible scenario where a fighter like an F15 will have time and range to accelerate to something remotely close to M2.3, less so with a full missile loadout. Actually getting to M1.5/M1.7 for an amraam shot with a normal CAP loadout is already massive, and difficult to achieve. With that in mind, the fighter that better accelerate to that launching speed will have an edge. According to pilots, the eurofighter goes from m0.9 (normal CAP speed) to M1.5 with ease and second only to a Raptor. Enviado desde mi ELE-L29 mediante Tapatalk

This is quite wrong, the ef2000 has massive acceleration up to M1.8, if I'm not wrong superior to the F15. On top of that, which is much better it has a confirmed supercruise of M1.2something (this is from memory I need to retrieve the info) with an Air to air loadout (4 MRM + 2SRM) and tanks, which is massive for the air superiority role. Also much better frontal RCS and one of the best mechanical radar it exist so they will both detect each other at a considerable distance. Enviado desde mi ELE-L29 mediante Tapatalk

When you fly the Tomcat, wake turbulence should always be turned off, as it else doubles with ED's wake turbulence. It does not affect anyone else if you do it in your special options.

The Su-27 very much can be beaten by geometry and also the MiG etc can lose their energy if you are patient enough. By the book, means what book exactly? 30 seconds is your ideal window, which means your main goal is to win the merge and shoot them right there and then. After the 30 seconds your chances to win decrease dramatically. Especially with human opponents. I forgot the calculus, but it is quite dramatic. In the end, your job is to shoot the guy, not to display some geometry. And, ofc, knowing how to do this or that, especially in PvP, helps a ton to get into a favorable position, flip a position, etc etc. But you're still not there to display an airshow, but to shoot the guy. However you can. The AI now just pulls too hard too consistently for long periods of time, inhumanly so, hence insisting on some geometry is pointless. I leave the fight with a) enough fuel and b) almost 2/3rds of gun ammo left, despite snapshots. Snapshots are super important, especially when flying against humans. The big difference with Ai and humans is that a human will always try to pull the nose on you, when you come head to head again, even if he sacrifices for that, but on a nose to nose you will have ammo flying your way. The AI, when shot at first, will just not do that, which can be exploited. The 1nm pole: Imagine the aircraft is set on a 1nm stick. In most cases you need to fly around that stick first to get into a good shooting position. A lot of folks want to just get nose on and force it, getting in a non favorable position. That's just a mental/visual aid, which a Gripen pilot told me who got that from his BFM instructor, an oldschool Viggen guy. Just imagine that stick, and try to fly around it first. But sometimes, like with the AI pulling a constant 9Gs or similar shenanigans, that is not really possible. Hence you need to be able to do snapshots well. Snapshots are not luck, it is something you need to practice. Flying geometry is nice, being able to hold your turnrate is something one needs to know anyway, but if it doesn't serve you to kill the guy, it is worthless, too. And btw, if you want to fly BFM PvP, practicing against the AI is a very bad thing. All my advice here is predominantly meant for how to beat the AI as is, not on how to develop a skillset in human vs human BFM. But in parts, it applies there, too, ofc. Do what works, not what someone told you one should do. Finally, explain a bit more what regime you mean, cause I showed you 4 different ones. (I would also carefully suggest, if it takes you 8 minutes to kill the flanker from the IA mission, it is not the same regime, it should never take you that long.) Which is the whole point, to be flexible to go from a sustained turn to instantenious to forcing the angles to creating separation, etc.. as needed. The bottom line of this remains: the AI is still extremely easy to kill, because it isn't as flexible as you can be, while a human opponent can be exactly that and turn it on your head. EDIT: One more thing that slipped my mind: going from slow to fast and vice versa: it can be done very quickly, but you need to manage your pull. There is a technique, which I call simply "fapping" the stick, lol, and it works basically both ways: if I want to gain speed, I go from pull -> release -> pull -> release, which works also if you want to pull more G without bleeding off speed, which goes a bit like pull -> increase -> ease off to (initial) pull -> increase -> ease off to a bit more pull -> increase -> ease of to yet a bit more pull than before -> increase ... gently. Try to practice that quickly going from 150 to 250 to 350 to 450 at a constant between 4 and 6 G (choose one and hold it) for the first, and for the second train holding around corner speed while going 3G to 4G to 5G to 6G to 7G while not losing corner speed. For me both these skills do much more than geometry. Also against humans.

Got a little work done today. Laser engraved the Asym limiter and UHF panels. Sanded and clear coated the translucent resin print of the LED cover, used my Brother P-touch to print out the freq list label. Put my knobs on and mounted it in the side panel. I haven't yet programmed the arduino for the frequency LEDS but that will come after I get all the panels finished and functional. There's kind of a jankiness to the engraving that I sorta like, makes it look more used and worn. I'm definitely not going for factory fresh. null

Не знаю, писал ли кто, Chuck выпустил мануал..... https://drive.google.com/file/d/13nEcygdRPBBWQrAiRjOAwqr98JWthGw7/view