Draken35

OB 2.7.7 - Oculus (QUEST 2) hand controllers Y & B buttons not responding while in cockpit (KA-50, A-10CII and AV8B at least, haven't tried in others yet) No hardware issue... they work fine outside the cockpits and in other apps.

That's a very interesting idea...Could you post picts and review when you get it working please? I've been playing with counter weights to improve the feeling but your idea looks better

I received my collective a few days ago. Overall, I think it is quite nice but using the extension requires too much friction for my liking and reduces the "smoothness" of the operation. So, I came with the idea of reducing the friction and adding a counterweight: As you can see, it is very crude. Done with stuff at had at hand for a proof of concept / prototype ... But it worked so well for me that I decided to share the idea at this early stage... I'm still playing with the friction adjustment and weight to get the perfect balance. Mounting system also needs to be a little more solid to prevent counter weight movement

thanks for reporting back.... And sorry to hear that... I, knock on wood, haven't seen the issue since I made the change.

It is compatible with all modules in DCS. You can either add the unit name you are using to the whitelist or add the hind type (I don't own that module and don't know the name) to the valid unit types. In both cases you can use the default profile and tweak it at your leisure but if you add the Hind to the types list, you can also add a Hind specific profile. See the screenshots in the post above yours.

Thank you!

Nope.. I've had the issue with TacView installed and uninstalled ... Now, couple of days ago, I changed the encode resolution and bit rate and I haven seen the issue since... Of course that can be a coincidence

Bump... Still happening

I have HAGS off, had the issue twice last night, while flying in Syria with the A10CIi … That seems to be the combination that triggers it for me, but not really sure

Exact same issue here i9 11900F, NVME, RTX3080, 64Gb at 3200 ... All drivers up to date, latest OB ... Glad (:() I'm not alone Note: I think that it happens to me while in Syria and flying the A10CII ... Started happening a week or so ago...

v1.06 is posted... Details in the OP but basically I modified it to use a tangential release vector and added some training wheels to help pilots like me, navigate the path... They are off by default (turn on in settings) and can be easily disabled from the script. Now, lets talk bomb accuracy... Surprisingly a topic that has not come up yet... from https://digital-library.theiet.org/content/journals/10.1049/ji-3a-1.1946.0133 And "within 1400ft from the target" in operations from a source I cannot remember...

3-4 degrees? you are a hell of. lot better pilot than me! I'm using 108ft, based on the FB mk VI wingspan .... I have options in the settings to make it wider, at the cost of accuracy... And you are right, been on the path, could be crossing it perpendicularly! This has been a very interesting conversation!

That is how I think it works. Matter of fact, I just had to do minor changes to my code to allow for that. If the pilot is on the path then the correction (not considering wind) should be minimal if any... That's for a target at about 112nm and headings are tangential ... As you can see it is a 2-3 degrees per minute (at that distance from Cat and Speed) , so, that 7.5 seconds release signal should be enough to get to the release heading, assuming a properly trained and competent pilot of course... The key is flying the profile on the path (no surprises here). This is how it looks in the map: The difference between the Cat-Target distance and the path radius doesn't see much.... Of course, that's assuming that my late evening math is correct... I'll test it over the weekend but if somebody volunteers to help testing I wouldn't complain (pm me if interested) @Reflected I'm actually curios to see how you implemented it with triggers! Looking forward to that campaign and to the Huey one....

Just made a small modification in a test mission and added a heading from the 3 minutes mark to the target.... For this particular target, at 78nm from CAT, there is a difference of 5 degrees between the prebriefed release heading and the w3-target heading.... I think that would put it far enough from the release point over the track to prevent the Mouse to send the release signal... So, if the "few minutes before" is correct, then, the release point should be calculated over that vector and not over the track... The more I think about it, the "real" time corrections from mouse don't fit the system... But, of course, what do I know, I'm not a pathfinder or mouse/cat operator, wasn't there and didn't stay at a Holyday Inn last night....

So, that video says that a few minutes before release, the crew sends, by radio, their speed and the mouse operator calculates the final course and release point... Now, does that conversation happens in voice or morse? How long did those calculation took? I don't know, that "conversation and recalculations" seems to defeat the point of the prebriefed... But, "forget" about flying the track and flying a prebriefed release course at a prebriefed speed and altitude (the video doesn't mention that the crew sends back its altitude to Mouse, seems like a very important omission) makes a lot of sense, and the 3 minutes point seems like ideal. Watcha think?

Yeah, that has been one of my problems while developing this: no clear "requirements" and too much open for interpretation... My other problem is lack of flying skills to accurately test the script ... And a third problem I discover in the past few days is the weirdness of the magnetic variation in the channel map and the fact that we cannot get (afaik) the actual MagVar from DCS in lua. Nice video... Haven't seen it before... Need to watch it again to digest it. Version 1.05 is up. It has the 7.5 bomb release signal.

@RamsayThat explains it... Thank you!

My flying skills with the Mosquito are lacking so I was using my beloved Harrier to the test my OBOE script... And couldn't figure out the issue with the script, since there was none... Turned out that the Harrier is by default or error display TRUE heading in The Channel Map. Very easy to reproduce: 1) Place Harrier, hot start from the ground facing 0° in the ME 2) Jump into it and see for yourself... Screenshots attached Am I missing something (always a strong possibility!) or is this a bug? Couldn't find any reports ... Granted, perhaps not to many people fly the Harrier in The Channel....

@Retnek Thanks for that!!! The 5T (release signal) is only 3 seconds long currently)... I'll adjust it when I have a chance (have to change the sound and the duration in the script, since it is taken into account in the calculations) and will release v1.05 with that change. They really where extraordinaire! The closest I've gotten in the demo mission is about 800 feet from the target... bouncing from long to short of track all the way since the intercept point. This is gold: "five dots and a two-and-a-half-second-dash " !

That would be cool... I've been thinking on how to make the AI (I'm a SP type of guy) target the place where I put the bombs...

Thanks! I have this one in my reading queue: https://www.amazon.com/Night-Flyer-Mosquito-Pathfinder-Operations-ebook/dp/B01H7UJ5TM/ref=sr_1_1?dchild=1&keywords=Mosquito+Pathfinder&qid=1633222632&s=books&sr=1-1

1.04 posted... Bug fixing, no new features (For some positions of Mouse, it was giving bomb release signals well outside the track)

Updated to version 1.03. Details at the first post.

Well... it seems to me that BIGNEWY (or somebody from the team) read the book and created a mission/teaser/article/whatever from it... I'm sure the ability to launch for ships is in their radar...