jubuttib

Nope. F-16C and even the Hornet are still in early access officially.

I mean I still have a crapton of fun with helicopters, even with the issues.

"Aaah! You smell that? Smells like..." *HURK* *DEAD*

I don't even mind that guy so much. What I mind a lot more is the goddamn RPG-7 hero who nails me in the ear from what seems to be beyond the max range of the launcher, while I'm flying perpendicular to him at 100+ knots in a helicopter, not doing a particularly good job of maintaining my altitude either. Yes, I know RPGs have killed a <profanity>ton of helis in the middle east, but usually slow flying and stationary ones, or ones at specific distances where the self-destruction mechanism causes an airburst. I haven't heard many stories of them hitting a helicopter flying left-to-right at full speed pretty far away, and nailing the cockpit exactly...

Just wondering if anyone else has run into this behavior so far. I'm on the MT client, haven't started trying to replicate this consistently yet so no tracks yet, an early inquiry basically. Sometimes during a mission I just randomly seem to lose my ability to contact anyone via the radio menu system, including ground crew. Even if initially I am able to contact the ATC for startup, I might not be able to ask them for taxi or takeoff after I finish the startup. And by "not able to contact" I don't mean like I have the wrong frequency or the cockpit is closed for the ground crew, I mean that selecting the options in the menu doesn't do anything, not even trigger my pilot's line. Today for example I landed after exhausting all my munitions, taxi'd to parking, opened my cockpit and asked the ground crew to refuel and rearm me. Usually I'd hear the "requesting refueling" and "requesting rearming" lines, which the ground crew either copies or says they're "unable to comply", but I don't get anything, just silence. Same when trying to contact ATC or AWACS, my pilot stays silent and there's no response either. This doesn't happen always, and never at mission start (I have so far always been able to at least contact the ground crew enough to rearm and take off the wheel chocks), but sometimes between a few minutes or even an hour I just lose the ability to communicate. Anyone else run into similar issues?

And before the 20th century too, they were the first to design a rifle that used smokeless powder in the ammunition in the late 1800s, with the Mle 1886 Lebel rifle. This improved accuracy, range and rate of fire massively. Granted, they also slightly cocked that one up, by rushing the design of the cartridge and the gun to get the rifles into the hands of soldiers. The double taper on the cartridge made magazine designs for later rifles a lot more difficult (anyone who has seen the magazine on the Chauchat knows why this is an issue when trying to stack rounds, though the holes don't help on that), and the round nosed bullet wasn't very good aerodynamically. Both worked fine on the Lebel, because it had a tube magazine though, and the bullet was later changed to a Spitzer boat tail style, but the cartridge design hanging around until after WW1 certainly made subsequent firearms designs harder.

Really wouldn't mind NS430 integration, like in the Hip!

Noticed this while trying to get a hang of the gain and contrast controls on the Harrier. When you zoom your view (not the sensor, just your cockpit view) all the way in towards the MFD showing the FLIR sensor, the hot spot detection results change. Images taken in active pause, only thing that changes between them is how zoomed in my view is: First image is zoomed out slightly, two groups of units are consistently being detected by the FLIR, and marked. The markers flicker around a bit, but they stay perfectly on the groups. Second image is zoomed all the way in. The groups are no longer being detected by the hot spot detection, instead it's just kinda randomly sprinkling the markers around every now and then. A lot of the time it's not detecting anything.

Not sure if related/the same thing, but at least one video (from RedKite, I think?) mentioned off-axis aimpoints being used IRL with targeting pods because often the target you might want to hit isn't high contrast enough for a solid, reliable lock, so you'd lock up something nearby that is higher contrast, and then offset from that to the actual target. Hence them not being that useful in DCS, since we kinda either don't have that problem, or can't use that as a workaround. Can anyone shed some light on whether this is true or not?

Really hoping that one day this will be true in DCS... I'm interested in learning to be a good dumb bomber, but requiring direct hits on armor is making it real tough to care. When showing off the ARBS/DMT system Hughes showed several near misses in their promotional footage, none of which would have achieved anything in DCS...

Reject USAF, embrace PAF. GB-6 SFW is de way. Oh, and the new LS-6 100s, too, since we're in the SDB thread. I kinda know what you mean, but also seeing how crap damage modeling on armor is on anything except a direct hit...

Thanks, marked as solved.

Yeah, that was my main thought as well, channels being weapon pylons would get seriously cramped in MP.

Short and sweet, can you or can you not? Tried searching for an answer via google and forum search, but didn't find any mention of this subject. Buddy of mine's been reading some books about naval aviation, and this seems to be a thing that's done sometimes, so that the launching plane can focus on their egress. Would be fun to team up and try something like this in DCS too, but so far haven't found any mention of whether it's possible or not.

tl;dr: Currently it seems like there are at least two issues going on: Doing S2 Push twice does _not_ revert the SPI/DST 40 to the selected waypoint (assuming that's what is supposed to happen), you actually have to re-select the waypoint to do that, and neither does it consistently point the tpod to the SPI/DST 40, whether it does seems to depend either on just pure luck, or what is shown on the tpod video feed? (Having very little motion, and a zoomed out picture with lots of contrasting features seems to make it more likely to work, while lots of movement and an indistinct image seems like it prevents it from working?) Been trying to replicate the A-A slaved issue, but not having any luck, it's working exactly like I'd expect it to today... Dang Heisenbugs... Just a quick question to make sure I'm understanding this right: If you do S2 Push twice, the system is supposed to revert the SPI/DST 40 back to the currently selected waypoint, correct? Assuming that's correct, here are some of my findings today: A-G slaving still gets borked after you've tried to lock/ground stabilize it, though it seems a bit more complicated than I though? Just slewing the tpod isn't enough to trigger the behavior, if you just slave it away from the waypoint, then do S2 Push, the tpod will jump to the waypoint. But if you press T5 to attempt a ground stabilization/do an area lock, you can't use S2 Push anymore to get back to the waypoint. Additionally if I find a ground target and lock it up with the tpod, then slew away from it, I can do an S2 Push and it'll hop back to the ground target. So right now it kind of feels like this, if I have the logic somewhat correctly in my head: 1. If you just turn the tpod on, it'll slew to the currently selected waypoint, and track it. It jitters around if you're not flying right at it, but it works. In this situation the waypoint is the SPI. 2. If you slew the tpod around, it won't automatically ground stabilize, and it'll keep turning with the plane, but you can do S2 Push to get it to hop back to the waypoint. Waypoint is still the SPI, and the S2 Push will slew to it. 3. If you if you do T5 Push to ground stabilize/area lock, the tpod will update that as the current SPI, but if you then unlock that by doing S2 Push, and then try to revert back to the waypoint with another S2 Push, that won't happen. Looking at coordinates for DST 40, the current active SPI, on one of the MFDs while doing this also shows that the SPI doesn't revert to the waypoint, whatever the tpod was looking at when you did S2 Push the first time to undesignate the area track will stay as DST 40. Here's where it gets really confusing for me right now: 4. If at this point you hammer on the S2 Push, one of two things happens: a) Nothing. The tpod will keep traveling over the ground with the plane, neither ground stabilizing (as it shouldn't) nor hopping back to the waypoint, or even the SPI/DST 40. This seems to happen particularly when the video feed on the tpod is moving a lot or has a very flat/non-contrasting image. So if you've set the plane to orbit, or are flying parallel to where the tpod is looking, or are super zoomed in on an indistinct piece of sand, doing S2 Push tends to do absolutely nothing. b) It snaps to DST 40, which is whatever the tpod was looking at when you last did S2 Push to undesignate the track. This seems to happen especially if the tpod is looking in the direction of travel (there's very little movement on the screen) and you're somewhat zoomed out, with lots of stuff visible on the screen. If you run into a), where doing S2 Push does nothing, you can often zoom out a bit, slew the camera around, then try again, and the next time you do S2 Push you might actually snap back to DST 40 (which, again, isn't the currently selected waypoint). Or you might not, it seems partially random, partially dependent on what's happening on the screen... If you want to actually revert SPI/DST 40 to the current waypoint, you need to re-enter the waypoint. Might even have to select another waypoint, then go back to the one you want, not 100%, didn't test specifically for that. I have two short tracks, one with me starting with doing a circle on autopilot, and faffing around with the tpod, then heading towards the target (an IFV) and shooting it with a laser guided rocket. In this case you can see how even mashing the S2 Push while turning doesn't really seem to work to point the camera at a spot, instead it just keeps turning with the plane. Cycling between SP and Slav doesn't really achieve anything either. The other test is just me flying straight towards the target and faffing around with the tpod, dst page etc., and in this one sometimes the tpod hops back to looking at DST 40, sometimes it doesn't, feels mostly random. I'll try to record video too later, just in case the tracks play differently on your end... JF-17 Slaving test.trkJF-17 Slaving test 2.trk

I work in game dev too (racing sims), and I know EXACTLY what you guys are feeling right now w.r.t. this... Stay strong.

Tried the tpod in A-A mode yesterday, trying to slave it to a plane locked by the radar. It snaps to the plane, but doesn't stay slaved afterwards, the circle indicating where the tpod is looking on the HUD being stationary on it, moving with the plane. So seems like something got broken in the slave mechanism after you've moved the targeting manually with the slew. It seems like both in A-A and A-G situations the tpod snaps to the waypoint or selected target on the radar, but doesn't stay slaved to it, just acting as if it's in snowplow with an offset. If you ground stabilize or lock up a target on it it will keep following that, but slaving seems broken. @codyj007 Noticed this behavior as well when testing again yesterday. Used to be that ground stabilized was fine, just slaved juddered like that, but now it's juddering like heck all the time, unless you're flying at the target in a very stable manner. Will try to get track files for all of these issues.

I've seen that kind of judder/shaking in the past when the WMD7 is following a waypoint, not ground stabilized... Today I ran into an issue where if I aimed at a far away waypoint, too far away to be able to ground stabilize on it (using the new increased rendering range <3), and then moved the cursor, I could not get the WMD7 to stick to the waypoint again any more without caging and uncaging. 2xS2 press to unlock and revert back to waypoint SPI didn't work, neither did swapping to SP when back to SLAV. I mean the pod did turn back to the target, but then immediately drifted off again.

Thanks for that tech-op2000! Will mark it as a solution for now, but if anyone else has some other hints, please do share!

Will try next time and make absolutely sure that the pilot doesn't touch a single thing before I'm onboard, see if that helps.

Hey, tried searching if anyone had created guidelines for this, but couldn't find any, hopefully you don't mind the thread. Last night I was front-seating for my friend on our dedicated server, and if I was onboard during starting up the helicopter, we tended to run into a lot of desync issues. Things like my cockpit saying that the rotor brake was activated when it wasn't for the pilot (which caused the torque numbers on my cockpit to be very high, like 120% when he was seeing 80%), tail wheel lock status being wrong, APU being on for me and not for them (constant sound from it being a bit annoying), RLWR being on on my end but off on his, and when he turned his on it went out for me, etc. The only way to get around this seemed to basically be to wait for him to finish starting and setting up everything, then join him when he's ready to take off. Even then the rotor brake would be on in my cockpit sometimes. Our missions went off without a hitch though, so that's something. So, are there any good guidelines for how to avoid as many desync issues as possible right now?

Thanks @Luiz Renault for your continued work on the mod! It's really impressive how you've managed to implement so many new modern features to modded planes, and now with EFM coming it might fly as well as the rest of it deserves. And thanks @Rudel_chw for your work as well, I'm eagerly looking forward to the FLIR guide.

FWIW you can look at Casmo's video and see what the SCAS does during these maneuvers (both in the input viewer on the top left, as well as the SCAS channels on the top right). When Casmo pushes the cyclic forward hard, the green + sign indication the SCAS' output, as well as the roll channel on the top right, both move hard to the right, trying to compensate for the roll. If the SCAS was deactivated, the Apache would roll to the left even harder than it does now.

Really love the Viggen, but I've struggled with the accuracy of the waypoints for a while now. I understand that INS systems drift over time, but in testing where I've had barely 10 minutes of flight time when it comes time to attack, the target waypoint is already far enough off the target that if I was NAV bombing without visual aiming, I'd have no chances of hitting even a factory/tech combine a lot of the time. Anything I can do to improve the situation?

Yeah it seems like it's the wrong way around in the English cockpit? Chuck's guide explains it with STDBY being rangefinder and MANUAL being designate, but the old BS2 manual at least seems to be the other way around: EDIT: Apparently "ЛД-ЛДП" translates to LD-LDP, whatever that means... And I think you can get laser ranging with a very weak laser, so it would make sense that it works in both modes.