jubuttib

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.

I would have paid the ~10€ upgrade price just for the missile warning system (whether you use auto flaring or not). That's the moneymaker for me. It's easy to miss a single soldier with an IGLA standing somewhere in the trees (especially since you don't get any kind of FLIR), and in the past you used to just be doing your job merrily, and all of a sudden you were dead, with no warning. At least now you get a warning and a chance to do something. I also love this feature in the Apache.

You can still make them work, but it is a faff... =(

Yes, and the way to do it is how Tarres said. When the helicopter is placed in the mission editor, you can select the configuration in the right most tab (...). Selecting the 2011 version will remove the MWS and ODS, will put the laser warning system back, remove access to the extra pylons for the IGLAs, and probably some other things I'm missing. You still get the new INU modeling (for better or worse). Not totally 100%, you _can_ edit the files to use the BS3 instead, but that is of course a massive hassle for someone who just wants to use it...

Well the BS3 can be set to the "Version 2011" configuration with the laser warning system, no ODS, so that's normal.

Campaigns and multiplayer are probably the main reasons you'd want to keep it even if you could uninstall. Which I'm not sure you can, the BS3 installation folder is smaller than the BS2 one, they might be sharing stuff.

The fact that it has the IGLAs on would suggest it's the "Version 2022", so should have MWS. Or can you enable the pylons for the 2011 forcefully?

Hypothetical, but when we saw some of the early shots of the BS3, it was looking quite different, had the DIRCM eggs etc. Then the Russian govt got in the way, and things changed. It wouldn't surprise me if they're what's preventing a more realistic implementation, and ED didn't want the work on the systems to go to waste so added a somewhat plausible implementation. Just talking outta my ass tho.

I'm loving the update in just about every regard (I was fully aware what kind of a prototype frankenheli it was becoming, thankfully reverting back to BS2 spec is super easy), but the INU alignment when using Normal or Precision alignment, and stand-by ADI seem to be completely borked. There are several discussions about the INU issues, and I don't think anyone has yet found real consistency with it, right now the most basic accelerated alignment + manual heading correction seems to give the best results. That, or starting hot. Both drift a fair bit though (something like 1.5 km per hour of flight at 210 km/h is what I'm seeing when doing a figure of 8 pattern), especially when you're making harder turns (square pattern was more stable than the figure of 8 pattern, probably because of the less aggressive turns?). The backup ADI just drifts out of whack during turns, and no amount of resetting it helps. It's useless right now.

After testing rrasfly2's new method, which didn't work for me, I ran tests with a "start from parking, hot" helicopter with the "Normal Alignment with Gyrocompassing" selected in the ME, and wanted to compare that to the accelerated alignment. I also tested this on a figure of 8 pattern this time. Short story, didn't really see any real differences in accuracy between the two, both were much better than trying to do precision alignment yourself from what I could see. The figure of 8 pattern seems to make the INU drift more and faster vs. just doing a square pattern (the waypoints were the same, just the order was different). I recorded the PVI-800 self coords vs. the ABRIS self coords after each turn, and sometimes before as well, to try and gauge whether the INU drifts more when turning or when flying straight. Used the same website I mentioned a couple of posts before for measurements. Right now it seems that the worst thing for accuracy are counterclockwise turns, but honestly the whole thing is such a mess that it's hard to make any solid conclusions... Here are my notes. First is whether measurement was taken after/before however many turns I'd done, then how long I'd flown by then (approximate, not exact but close enough), what the heading was AFTER the turn, what the drift was at that point, and what direction the previous turn had been in (CW = clockwise, CCW = counterclockwise): Hot helicopter using "Normal Alignment with Gyrocompassing": After 1 turn, 5 minutes, E = ~100 meters CW After 2 turns, 10 minutes, SW = 333 meters CW After 3 turns, 15 minutes, E = 543 meters CCW After 4 turns, 20 minutes, NW = 841 meters CCW After 5 turns, 25 minutes, E = 1 021 meters CW After 6 turns, 30 minutes, SW = 1 218 meters CW After 7 turns, 35 minutes, E = 1 368 meters CCW After 8 turns, 40 minutes, NW = 1 540 meters CCW Before 9 turns, 45 minutes = 1 660 meters After 9 turns, 45 minutes, E = 1 563 meters CW Cold helicopter using accelerated alignment done using APU power: After 1 turn, 5 minutes, E = 732 meters CW After 2 turns, 10 minutes, SW = 623 meters CW After 3 turns, 15 minutes, E = 834 meters CCW After 4 turns, 20 minutes, NW = 1 116 meters CCW After 5 turns, 25 minutes, E = 1 273 meters CW After 6 turns, 30 minutes, SW = 190 meters CW After 7 turns, 35 minutes, E = 1 230 meters CCW After 8 turns, 40 minutes, NW = 1 229 meters CCW Before 9 turns, 45 minutes = 1 160 meters After 9 turns, 45 minutes, E = 1 529 meters CW After 10 turns, 50 minutes, SW = 403 meters CW Before 11 turns, 55 minutes = 414 meters After 11 turns, 55 minutes, E = 1 871 meters CCW And no, the drift going down from over 1 km to just a couple of hundred meters after turns 6 and 10 in the second test are not typos, I checked the numbers multiple times and they're correct as given by the game. (EDIT2: The difference was smaller at first, but every time the helicopter turned to SW, the error got smaller. Interesting.) EDIT: Also noticed that the autopilot has SEVERE problems making left turns vs. right turns. After it has turned left, it then tries to straighten the helicopter out, but uses so much anti-torque to the right that the nose turns hard to the right while the helicopter is still banking left. This doesn't seem to happen after right hand turns. Oh, and here's an image of what the flown path on the "accelerated alignment using APU power" flight looked like after about 50 minutes of flying:

Trying to test this right now, and am seeing a fair bit of drift within the first 10-20 minutes (around 1.3 km when comparing PVI-800 vs. ABRIS self-coordinates). Could you upload a video of how exactly you do your startup? EDIT: 2.3 km after 30 minutes.

Certainly from what I've seen the quick and dirty accelerated alignment is giving great results with fairly low drift. The positions of waypoints don't seem to be entirely accurate vs. ABRIS, but then again the PVI-800 is working with tenths of a minute accuracy, vs. ABRIS at hundreths of a minute. Using coordinates of Novorossiysk as an example, 1° of longitude would be ~79km, so one minute would be 79 000m/60 = ~1 317m, one tenth of that = ~131.7 meters, one hundredth = ~13.17 meters. So an offset of somewhere around 100 meters between ABRIS and PVI-800 doesn't seem too bad. (Please someone check my math and tell me if I made a mistake. I used LAT 44.712993418734854 and LONG 37.76625581947498, and this website to get the distance between the points: https://gps-coordinates.org/distance-between-coordinates.php)

In a pinch you can manually edit the files to include the BS3, but that's not really the greatest user experience...

Ach, to be fair what I meant was that it prioritizes emptying out the outer ones first, but does shoot from both. I have this image in my head of my friend's Hind in a recent session having like 3 rockets left on the outer pods, but most of the ones still in the inner pods. The Mi-8 also does things in a funky way, if you do small taps of the weapon release button it seems to only shoot part of a "burst" of rockets, and towards the end you might find that sometimes when you press the button it doesn't shoot anything, then you press again and it shoots a couple of stragglers, etc.