Capn kamikaze

Would it be possible to add a feature (with the ability to activate/deactivate) to the mission editor, so you can use a time-slider to preview the unit icons moving around the map following paths between their waypoints, so you can see where they would be if they were just flying/driving/sailing around but without killing each other, seeing weapons being fired would be helpful too, eg rockets/artillery and bombs being dropped. The point is to show the pace of the mission to the builder to highlight were the action is happening, to make it easier to make longer missions with a more consistent pace.

It looks like the trucks don't have any heat map from their engines, while the BTR's do...

I would expect to see the truck much easier.

The BTR80's nearby are far easier to spot, both are cammo'd, but ok they're hard to see, not invisible. However compared to other similar sized vehicles, in the same setting, it doesn't make any sense that one would be so easy to spot and the other not so, infact the BTR-80's should have been harder to spot, their camo was closer to the surrounding terrain than the trucks, the trucks in this are in their green camo, the BTR's are in a desert camo, yet they're easier to spot.

The truck is a Ural 4320T, and it is completely invisible on the TPOD screen, not sure if this is a pod issue, an issue with the truck, or the F-15E, or something else. This is a moving vehicle not a static, if that makes any difference.

Even if it is out of range, why would you get the video feed in the F6 view? I think you're right that it is a range issue having done further testing, however it's still a bug/exploit, as it allows "infinite" TV transmission range if you happen to have multimonitor setup.

Definitely a bug, both screenshots taken while paused, flicking between F1 view and F6 view.

It's defintiely a bug, you can try it yourself. Flicking between in cockpit view and weapon view makes the video change from a blank screen with the symbology on it to a video feed and back again on the exported MFD. It wouldn't be a big issue if the active screen was shown when in the cockpit, and the inactive one shown in the external weapons view, but that isn't the case.

When using the SLAM-ER (not tried the normal SLAM etc) in the cockpit view, I am not seeing anything on the exported MFD screen for the datalink, or on the MFD in the cockpit. However if I switch my main view to for example looking at the weapon in flight, my MFD view suddenly shows what I expect to be seeing, and if I switch back to the cockpit view, it goes back to a blank video feed.

That is in straight and level flight, and in another FW-190, I was in a Spitfire, also in a turning dogfight wake turbulence will be much higher as it is an effect created by creating lift, which is dependent on induced lift/load factor of the generating aircraft. When I have time, I'll try to create a video showing it in a turn when crossing the wake, it was an almost 45 degree change in the roll of the Spit.

I would estimate range was about 200ft

Didn't save a track, but from the tacview recording there's well over 100 hits the FW-190 took. I also noticed when shooting at it that the wake turbulence from the FW-190 is rather high, it was almost flipping over my spit if I hit it, either the wake itself is too strong or the spit is very susceptable to it, I find it hard to believe that it would be like that IRL from a small piston engined fighter.

You kind of missed my joke... Think "T'is but a scratch"

That's a lot of textures...

Pretty sure this isn't right, the other side looked almost as bad.

If you have the pilots body being visible and turn your head in the cockpit view, the camera moves outside the head and forward looking backwards and you can see your own head, in this view it would be better if the head of the model of the pilot was made invisible. Noticing this in the F/A-18, but likely effects other modules aswell. This obviously isn't an issue if you turn off the in cockpit body.

Pre-ordered. Are we talking weeks or months until this is released?

No, that's not problem solved, there should be something between STFU Jester, and non-stop jibber jabber.

Seeing the exact same thing on the 4YA servers, they're pretty much useless.

I've been getting crashes where the game will make a sort of beep or growl sound, the screen will freeze, and then I'll get a dialogue box come up saying it has crashed and then it dumps me back to the desk top, or I have to kill the DCS process. This is on the multithread version. I am not seeing the same thing in SP, and it is not dependent on what you're flying, I've had it while flying the F-16 and F-14 online, about half a dozen times over the last week or so. I have been playing on a couple of the [4YA] servers based in Europe, I am in the UK, and am getting low pings, however it does seem like DCS is loading things up more than it used to.

The photos I am seeing look like they're all moveable, so far I've only seen fixed welded ones on photos of inert bombs, and they are all the fins. https://www.everycrsreport.com/files/20200227_R45996_efe24af9217806533af112447842e2bb9ccf5b17.html#_Toc33692032 And... The guidance section can't be fitted in just any orientation, note that rectangular part on the top.

I noticed that the GUB-31 model has one of the fins as a fixed surface, with three moveable fins. This is incorrect, the only ones that have fixed fins are the training bombs, and all of those are fixed not just one. If the real one had one fixed fin it would immediately start spinning about the long axis of the bomb if that fin deflected. I think I know why this has happened, there's an old 3d cut away drawing of an aircraft with weapons out there, can't remember exactly where, but it shows one as being fixed, I think this drawing may be the source of the error. This stuck in my mind as I asked about this drawing on another forum years ago, and was told that it was incorrect, so perhaps someone has used this incorrect drawing as the basis for the 3D model?

You can work around this bug by using a fairly wide dead zone on both X and Y axis, like 15% on both. Cured it for me, I could even move it around diagonally without issue. I would also recommend reducing the Y graph axis saturation on both to about 20% to make it less sensitive.

There's going to be an expectation that the pilot in the other jet following you around the place will let you know they're running low and call bingo when they should have, and will have enough fuel at that point to either RTB with some margin, or head for a tanker.

A IRL flight lead would not have to babysit their wingmen like that, they have fuel guages in their aircraft, they can keep an eye on it, and will let their flight lead know they're bingo when they actually are, and not say so several thousand lbs of fuel later, and they'd know that if they're low they'd have to fly in a way that conserves fuel, or they'll say they need to go to a tanker or an abort/emergency strip. The AI however doesn't seem to do any of that, so the very least we could expect is for us to be able to ask them until their fuel management is fixed.