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.

Christmas miracle anyone?

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

The socket button head M2x6 alloy steel screws are delivered.The next minor modification is already being printed. What you see here is assembled outside the tube. But the reality is that the bottom plate has to slip into the tube from the side slits and flipped around inside the tube into position. Then, the top one has to go in from the other opening end of the tube, and then screwed into the bottom plate directly in-situ. My SwissTools 1.5mm by 80mm long Allen Wrench is just barely long enough. After magnetizing my Allen Wrench, the new alloy steel screws worked well, except that the "bite" into the nuts is a bit shallow. So, I am adding an 1mm recess for the button head to sit in, increasing the bite of the threads. I didn't model the self-lubricating bronze sleeve bearing in the 3D model, but did designed the hole for it with correct tolerance accounting for a 0.4mm nozzle so that it needs to be pressed into the hole, just like proper interference fit. It took several trial-n-error print to get the right number dialed in. The next thing to tackle... the shaft and sensor seat, and wire routing.

i am with you. what i hate is watching documentaries and seeing video of planes, ships, tanks that are from a different era. i recently saw a documentary that showed B29 flying and the narrator inferred it was a B17. grrr.

A repair does not touch your dcs folder in C:\Users\miste\Saved Games\DCS.openbeta So any mods or scripts you have there will remain, make sure the dice mod is completely removed and then run another repair to be sure

Nothin is simple and straightforward in world of paints, especially luftwaffe late-war ones. Not to even mention how much colour shade can change depending on how many layers was painted etc. So i'd say Doughguy's version of rlm 81 is very close to v.3 for example.

Upuauts Mods --> https://my.hidrive.com/share/lwer0.o024#$/

Wow, that's awesome.

+1 absolutely, PLEAAASE

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.

Did someone mention a preorder??? 27

Neither can I, but I think the Chair Force has figured out that 'Return Precontact' actually causes the spar bolts to loosen a little every time they say it. Probably some kind of resonance with their radios, because after enough of them a wing falls off. In flames. This is what I'm down to. Much like crashing on a carrier there's no magic throttle setting, so stroke the throttle and back off the stick input before it has a chance to do anything. My formations with the tanker look really good...from Mars. Where I sit there is still a long way to go. I'm just fortunate that Israel, Lebanon, Syria, and Turkey don't mind me failing to refuel while the tanker flies a straight line though their air space. As for the people who can refuel an F/A-18 inverted using only their keyboards and mice for input I think it was all just computer graphics...

Do you have anything that states there shouldn't be a difference between them? We would need some form of evidence. I have asked our team and its expected in daylight the H would be better. Thanks.

The only thing that one currently lacks is VR support. I'm waiting on that to check it out, the devs are supposedly working on this. EDIT: It looks like it's in closed beta since early this year, so it should come out sooner or later.

it's more of an incredibly annoying thing than it not being my first language. It looks like a 12 year old wrote it

I stopped reading your post when I saw the underlined words, italics, and arrows.

To piggyback off my last post: The long range AIM-54 test was a 44kft 1.5M launch from 110nm on a 50kft 1.5M head on target. The missile reached 103,500ft and flew 72.5nm to the impact point. Last year news reports came out of an F-15 firing an AIM-120 resulting in a kill from the longest distance ever recorded. Even if we ignore the R-37 claims, this means the AIM-120D flew further than 72.5nm to impact. My sim shows the AIM-54 test profile would result in the kill occurring at 76.5nm, and my estimations of onboard power for the AIM-120D indicate the launch could have been from up to 139nm with up to a 96nm flight to impact. If the AIM-54 test was done with a Meteor I see a 75nm impact point. I see a max of 135nm and 92nm flight to impact. What if these planes were on a CAP station of .8M at 34,000ft? The AIM-120D could still barely make the 110nm launch with a 67.5nm flight to impact. The Meteor could make the 110nm shot with over 16 seconds of powered flight to spare with a 70.9nm flight to impact. THAT is the power of Meteor. It nearly matches a 1.5M 44kft launched AIM-54 from a CAP hold. No runup. No acceleration. No prep. Sorry the topic of this post was F-15E vs F/A-18C. Meteor has no place here. F-15E will be able to get 2 AIM-120C5s higher and faster than an F/A-18C will (assuming it has two), and it will have the stronger radar, so in self escort BVR the Eagle has an edge.

What did you expect exactly from a flight simulation that strives for realism? It's one thing to ask and that's totally fair... it's another to come to literally one of two high-fidelty combat simulation communities and then be salty when hearing what you don't want to hear. Then on top of it, act like you're entitled for the developer to develop the uneducated guess of two lines of code it would take to make the feature. If it's that easy, make the mod yourself.

Do I need popcorn? The only important question regarding the E-Eagle is: When will it finally arrive?

I don't think VR is particularly competitive for other reasons. TIR is actually more efficient, from pure competitiveness standpoint, because you can turn your head at unrealistic speeds and easily reach extreme angles. The ability of the VR users to see outside the canopy is minor. I disabled that restriction in the other WWII sim, mostly because I felt I didn't have my head close enough to bump into the glass (plus, the kind of leather cap pilots there wear would compress a little in such situation, anyway). I just try to avoid sticking my head through the glass.

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.

записал еще раз) по мере доступности ресурса..