nomdeplume

Have you adjusted the 'reaction to threat' option for the SEAD flight? The default setting is 'evasive vertical maneuver' which tends to result in the aircraft hitting the deck at the first sign of something on their RWR, which is often unhelpful behaviour, especially for SEAD flights. If you set it to 'evade fire' you might get better behaviour. Apologies if you've already done that, at work and can't run the mission...

It's normal for those units. They don't have walking animations.

RPG and MANPADS are not mobile [in the sim]. The AK infantry don't have standing/walking animations so they just slide. If you want them to walk you'll need to use one of the other types. Russian Paratroopers and the US M4/M249 infantry have walking animations. Probably the new Russian Infantry Soldier would have walking animations too, but you need to install the hotfix to make them visible in-game.

Most of these things I put down to a case of "someone felt like doing it". For example, why have certain models been updated lately? Conspiracy theories abound, but my suspicion is that in a lot of cases it's simply because someone felt like doing it. That someone may or may not be part of the development team itself. Not everything is the result of a high-level management decision to devote X% of their resources to a particular thing. This I think would be especially true in a simulation of this scope with a fairly small team. There's essentially an unlimited number of small details that could be added to the sim. The fact that a tiny number of those details have been isn't really indicative of misguided priorities or anything of that nature. I'm not really sure what you mean by this. My previous post was mostly to say that I believe what you're seeing in the shells gives the impression of some pretty spectacular physics, but is really pretty simplistic. I don't know about you, but just about every mission I fly has various things being fired by various AI at various other AI, and that often includes cannons that spit out shells like they're going out of fashion. I've never seen a framerate rate that coincides with it. That's what I'm basing my assumptions here on: it seems like it really does take a negligible amount of additional processing, even if it does look like it'd be expensive. I'd argue the weapon impacts have pretty much exactly the same 'mass-physics simulation' as these shells do... Not sure what you mean by aircraft crashes. One of the things I like about the DCS series is that when I **** up a landing, I can see exactly how much I ****ed it up. Bent landing gear, etc. Seems like there's quite a bit of physics going on there. If you mean in terms of aircraft bits being scattered around and visible results of clanging into things, that's a massive amount of work. You may as well gripe that they added the cockpit boarding ladder in one of the patches instead of a dynamic campaign, as if they're somehow comparable pieces of work and the absence of the ladder would've given them time to implement a dynamic campaign system. Separating aircraft into umpteen recognisable component parts that can be strewn around the landscape requires much more effort than having a few hundred identical shell casings falling to the ground. Let alone actually linking a more detailed graphical damage model to actual system failures. But again, I doubt there was some high-level meeting where they said "okay, we've got 3 days of programmer/artist time to use up, shall we a) improve explosions, b) improve physics or c) model falling shells?". Maybe improving the explosions are on the roadmap, but it's either a big piece of work and there's higher priority things, or it may be dependent on some other engine upgrade work which has yet to take place. Or maybe just nobody happens to have a bee in their bonnett about the explosion effects, or if they have, they haven't been able to create a substantial improvement without excessive adverse effects. Not every expenditure of programmer/artist effort results in something usable. That said, the smoke effects received a big upgrade with DCS Warthog; and I think it was actually toned down from the betas due to performance issues. There's also been changes to the burning effect. So, some effort was done in this area already. Also keep in mind that there's often things being addressed which aren't visible to us, or not obvious. You mentioned the terrain, so it's probably worth reflecting that ED/TFC decided to pull the Nevada terrain that was already looking pretty promising in the beta so they could spend over a year completely redoing it with a new terrain engine. If that doesn't scream "we care about improving the terrain quality" I don't know what does.

The AI do make calls when the targets are destroyed. However it can be difficult to track, especially if you have multiple flights which may engage the same target. You may therefore hear two "in from the south engaging sam at bulls x for y" and then one "kill sam at bulls x for y". Does that mean they got the one target, or were there two sams at that location and one is still active? They will also call out when they're passing waypoints, so if you're confident the flight will always take out all the SAMs, you could in the briefing instruct players to wait until the flights announce that they're passing waypoint X, where X is their egress waypoint.

If you use the 'go advanced' button you'll get an option to upload attachments to your post. That's probably the easiest way. You might need to zip the kmz file first though if it's not one the accepted extensions for attachments.

Vertices and shadows etc. only matter if they're being rendered, and they're only being rendered if you're actually looking at them. LOD also probably comes into play to make them much cheaper to render unless you're up close. So the graphics hit only comes into play if you're actually admiring their prettiness. It's not really a major task to track an object until it hits the ground. I'd be surprised if these things even detected collisions with other shells, let alone other game world objects. If they were actually doing collision detection against every other game object then you'd probably see a performance hit, but IMO this is a pretty negligible bit of processing for the 99% case -- shots being fired while you're not looking in that direction or are too far away to see details. There's no AI and only be most basic "physics" calculations being applied. Anyway, it's only a few hundred shells, and as noted before, most of the graphical models in DCS are very detailed: the engine is designed to render a lot of polygons. In most cases that you're close enough to see the shells in any kind of detail, you're going to have very few other objects in view (e.g. the example screenshots you posted), so you may as well give the engine something to render. :) People making cool videos would mind that the shells looked crap. People not making cool videos won't incur the 'cost' of rendering the shells up close, so what does it matter?

You might've already worked it out by now, but for the refueling whenever an AI group is told to execute a "Perform Task: Refuel" command, they'll seek out the nearest tanker and refuel from it. The task finishes once all members of the flight have tanked.

No, trigger zones don't have an altitude. If you want to only trigger something if a unit is above a certain altitude, you'd need to use an additional condition, i.e. 'unit in <zone>' and 'unit altitude above 500'. However that's only helpful if you're able to design the trigger around specific units.

Yes, there's a 'Set option' command relating to formation in the advanced waypoint properties.

The scroll wheel can also be used to 'zoom' around the terrain without having to hold a key down. It basically works like an accelerator, i.e. scroll it one way and you'll start moving forward slowly. Keep scrolling that direction and you'll go faster. Scroll it the other way to slow down. Also LCtrl+F11 gives you the free camera from anywhere. So you can use it in the cockpit view to jump to the external free-roaming camera at the same spot. Or if you're viewing a vehicle with F7 hit Ctrl+F11 to be able to roam freely around the area.

Unless they added that so Black Shark pilots could take off from and land on rolling ships... ;)

You can easily check - the corrected installer is known as DCS_BS2_EN_Upgrade while the original was DCS_BS2_Patch_EN.

Not through the UI. You'd have to edit the mission file itself (make a backup first!). Maybe try saving a new mission with the coalitions you want and then compare the mission file to your original. I do want to do this myself, but I suspect I'll be living in Skyrim for the forseeable future so I probably won't have a chance to look at it for a while... :music_whistling:

There's (at least) three issues. One is the ability of the graphics engine to render highly detailed terrain from altitude. That can be solved by having various mechanisms for reducing the complexity of the visual environment when you're a long way from it. It's still a very complex problem to solve though, especially if you're flying something with for example a targeting pod. You can't simply not load any detailed object and terrain data for things that are more than a few km from the player's position, because you can point the TGP at anything at any time and expect to see what's there in high detail. Nobody's going to appreciate playing a sim that thrashes the drive constantly every time you try to pan the targeting pod around. The next issue is with AI and related things. Just because the player can't see something, doesn't mean it's not happening, doesn't mean it's not going to have some effect on them, and doesn't mean it can necessarily be simplified. Combat can be going on in any location across the entire DCS map at any time, and for that to be resolved 'correctly' requires a constant level of detail of the environment for pathfinding, collision, evasion, etc. If you have a "bubble" of detail around the player and less detail elsewhere, you can easily have situations where a particular force vs force encounter will go one way if the player happens to be nearby and go a completely different way if the player happens to be elsewhere. The third and maybe largest issue is actually generating a large expanse of very highly detailed terrain in the first place. This is the thing that results in the vast gulf between 'flight sim' terrain and 'shooter' terrain. Flight sims need to cover massive areas and it's impractical for people to make every part of it look really nice. It's mostly computer generated from various sources of topographic data, with human touch-ups where needed - which still tends to be a massive amount of work. The terrain in Arma gets the human touch across its entire expanse - which is why it's a much, much smaller area. Also, the flying aspect of Arma 2 is pretty... well, it leaves something to be desired. The draw distance is so short in order to get playable frame rates it's hard to fly in anything resembling a realistic manner, and if you do fly in a realistic manner regardless of not being able to see your targets you spend half your time off the map. I think including fleshing out the part of Turkey that's currently in the map (at least) would be useful. That way US aircraft could be based in Turkey and have to cross the Black Sea to get to Russia/Georgia, which would burn a fair bit of fuel.

Speed is 100% correct. In addition even if the unit is armed, if you set its ROE to 'hold fire' or 'return fire' it won't initiate hostilities with anyone. If it's also invisible to AI, nobody else will initiate hostilities against it. It will therefore behave like a neutral unit.

...and rudder, which is easy to forget.

Ctrl+Z increases time compression, Shift+Z resets it to 1x, Alt+Z reduces it. I think. It's definitely those keys but I'm only 99% sure I got their functions right.

Some fishy guy reported there's a hotfix for what I'm assuming is this issue.

Logs would be helpful, including the actual fault message - normally you can get it to give you information about the module it faulted in which may be useful to people familiar with these things. Also - check C:\Users\yourusername\Saved Games\DCS BlackShark 2\Logs and see if there's any files there. If so, delete them, then start the game and do something that causes a crash (e.g. load a mission from editor and try to fly it). After it crashes you should find some new files in that folder. Zip them up and attach them to a post here (use the 'Go Avanced' button to get options for attaching files).

Also from my observations, preparing an open beta release is no less of a challenge than preparing a non-beta release, so I don't think you'd really see any change in the frequency of updates. Maybe if they had an easy way for us to sync the latest build and they felt comfortable with breaking it frequently -- perhaps by encouraging everyone to also have a stable version installed so if you just want to play the damned thing you can -- it might work better. On the other hand, a lot of people wouldn't bother with builds that were frequently broken in various ways, and they already have quite a lot of beta testers; so a lot of issues would still slip through. True "betas" aren't really something most people would want to do deal with. Google's lulled everyone into a false sense of security, I think...

^^ Hehe. :D You don't need ground power, and I'd be surprised if it was commonly used. The batteries are sufficient for the fuel pumps and you can get the APU up and then once your engines are up to normal power they'll supply all the power you need via their generators and the inverter. With the door open and your engines off, ground crew can hear you so you just use the normal comms menu (\). However it sounds like the ground crew might be absent in some missions so if you're not getting a response it's possibly just because that mission doesn't have the needed ground vehicles to provide service.

Yes, almost. Just bare in mind that "LESS THAN" and "MORE THAN" are quite literally that, as opposed to "less than or equal to" and "more than or equal to". Or if you're familiar with the commonly used notation in many programming languages, the conditions implemented are < and > as opposed to <= and >=. So, you probably want to do FLAG30 LESS THAN 11 FLAG30 MORE THAN 10 FLAG30 LESS THAN 21 FLAG30 MORE THAN 20 in order to cover all possibilities. Otherwise if the flag gets set to e.g. 10, none of the conditions will actually match for it. Yes, that's exactly right. The 'equal to' condition will just make it a bit easier to implement.

Aw you beat me to it, but mine's bigger. :P Mine's in two parts: a single CBU-97 drop with slow-motion close-ups showing the mechanism, followed by a string of 6 in real-time. Since you kind of need to watch it in high-def to see the submunitions I'll just link it rather than embed it: Video: The video description has links to the times of the actual bomb drops, for the chronically impatient. The start of the video tries to show the ground units formation, but I've also attached a screenshot of their layout in the mission editor for those who care about such things.

You could try hitting ctrl+scroll-lock twice to get the detailed FPS display which shows you where the renderer is spending its time. Might tell you something interesting. Then again, it might not. And it might be worth waiting for the 1.1.1.0 patch for Warthog before comparing.