Krinje

I didn't appear to have any luck by including those as exceptions, but some time after it is working again. I think a small update occurred? Or maybe it just redownloaded somthing? Whatever happened Bill Gates smiled on me from Windows Heaven and everything is working again. Thank you for the timely response!

I can't seem to get SimShaker Sound Module past Windows (10) Defender. SSA will launch, but when I start the sound module (SSSM) crashes because Defender has removed something (The system cannot find the file specified), SSA will continue to load. I've tried several exceptions, including the folder in users/*user*/appdata/local/SimShaker for Aviators and the simshaker.exe Is there a different, or specific file, folder or process I can add to the exception? is SSSM in a different location than SSA? Thanks for your help

I've had some success with the extension and issues. To be 3d printed Nylon was a must for the replica of the base's threads on the top of the extension. With other materials the thin ring of plastic (the threaded part) would shear off. Nylon was not ideal, as it isn't very ridged but it is very tough, and very good layer adhesion. At 8" of extension, center play was considerable, but the center wasn't so important anymore. The heaviest spring was a good load. Fitting a PCB with pogo pins and fitting it into the extension assembly was very tedious. My extension didn't have a bend, and because the stick had to be so far away (base size), it was uncomfortable to use for long when center mounted. If I remember when I get home I'll throw up the models, it is sized for a 3/4" shaft + extra because printers/slicers tend to under-size holes.

I think pretty broken is a generous understatement. It's supposed to be an all aspect missile (afaik) but I have had a head-on collision (mig 21) with not even a hint of growl the whole way.

Mechanical Keyboard Switches (cherry mx) make poor switches for Nav/INU panels (like a PVI-800), far too much travel and not enough click, they may be good for a number pad on a keyboard, not so much on a panel (IMO). Lessons learned right?

I'm really unfamiliar with MOOSE, I've just started reading into it, and watching the (very helpful) videos. If I had an AI CAP setup and happily patrolling a zone, how difficult would it be to redirect that flight for a different mission? IE: a GCI. Or can the AI's 'detection' be extended by the ground radar? Is this easy, simple, and built into MOOSE? A little head scratching? Or face plant and give up if I don't really understand the depth what I'm doing. I've written a couple of LUA scripts, one-offs for a few missions, maybe totaling a few thousand lines.

That just simply isn't true, and over simplifies frame rate. As soon as an animation becomes interactive, the bar for "smooth" changes. Think of all the people using VR who need 90 frames, their bodies can feel and have a reaction to it. Your brain knits together images and it can't do that if it doesn't see what it is expecting to see when it expects to see it. Because of this cycling frame rates from 45 to 60 can make the whole experience feel choppy, this cycling is a pretty common occurrence in DCS. Evidence: https://us.hardware.info/reviews/4592/vast-majority-of-gamers-prefers-120-hz-monitors

Some TIR units years ago, 6, 7? were shipped with apparently micro scratched covers that lead to similar looking issues. (mine was one). It sounds dumb but a good fix was some black nylons stretched taught over the lens. It serves as a filter, has no effect on accuracy/resolution, and can also help with IR saturated situations/setups. (I cut out a toe, stretched it over and zip tied it in the back around the USB. The magnet holds well enough through the nylons.)

Yes, it isn't very hard, but you're not going to get the results that *I* would want. Look up PROGRAMMING THE X55 on youtube, at about 14 minuets.

Just a stab here, but I'm fairly certain the QFE is just used for the HUD target designation circle so that you can visually identify the target. After radar takes over (you flip the switch and put the piper on the poor sod in a jeep.) QFE is irrelevant. But that's just one dudes opinion on how it could be working. I offer more evidence: because of an artifact we've all experienced. When you unsafe and your HUD jumps/falls like crazy. That's the radar information ranging. The above documents have the exact answer, but I can't read Swedish well enough. I can tell you that Radar ranging overrides QFE if the target is in the air "luftmal" and that there are some filters on QFE and possibly some triangulation blending too?

Hmm, If that picture is the right way to do it then the editor is going to be a big pain in the ass every time. (because the waypoint after the M will have ~60km or ~160km added to the ETA) Thank you very much for this info, I'd rather make it right than make it 'easy/lazy'.

I have a mission written as a practice for using the RB04. I'm wondering not how to set a way point as an "M" but rather where should I set this waypoint? If I set the waypoint on the target, all of the times are screwed up, and you won't cycle to the next B point because you where 30km away when you launched. So this adds give or take 60km of 'connect the dots' in the editor, that you aren't intended to fly. If I set the waypoint to the intended release point, everything is more or less fine as far as 'connect the dots' is concerned, but, there isn't a "target" reference, or anything pointing out the actual intended targets. If there where for instance 2 groups of ships, this causes some confusion. Does anyone have a clue about the "right way" to do this? IRL where would the M point be located for this kind of operation? (I think I have a hack-ish way to do the first, by manually correcting the B (after M) flight speed to insane values to match the intended arrival time, though annoyingly I can't lock the time because then it would be an M...)

Wow yeah, sometimes you get really wrapped up. It used to be n=1, Earlier I was so frustrated with the loops I wanted to make sure there wasn't a problem, and I apparently missed changing all the 'n's to 'i's Thanks, I'll give that a shot and see if she runs Edit: Yup that did it. I can't believe I overlooked that about a hundred times.

Hello, I'm learning how to script. I've taken some inspiration from a SAR mission I saw, cracked it open and looked at how the author approached the scripting. From there I started with similar structures to do a similar mission. I've been adding on single pieces of functionality at a time. IE: find an oil platforms world position with getPoint(), then subtract a helicopter's position from that to get the delta. At each stage I've managed to fix my mistakes and continue but I now feel I've hit an invisible wall, some detail isn't working and I can't see it. Before I added "for j = 1, #oil do" loop everything was fine, I only checked oil[1]. After adding in this loop, and then even with "for j = 1, 1 do" It seems to have broken. Excuse my rambling, I'm just a bit frustrated. I'm clearly doing something incorrectly I just don't know what. My only guess is variable scope, but again I'm not *seeing* a problem, but that may be because I'm not understanding lua's scope correctly. do local Heli = { [1] = { name = "Mi-8 Pilot #001" }, [2] = { name = "Mi-8 Pilot #002" } } local oil = { [1] = { name = "Oil Rig #001", Crew = 55, VIP = 1, HpadOffset = {x = -26.5, y = 39.08, z = 21.5}, HpadRadius = 12, bearing = 0 }, [2] = { name = "Oil Rig #002", Crew = 55, VIP = 1, HpadOffset = {x = -26.5, y = 39.08, z = 21.5}, HpadRadius = 12, bearing = 0 }, } local function Pickup() for i = 1, #Heli do local unit = Unit.getByName(Heli[n].name) if unit ~= nil then local heliPos = unit:getPoint() local heliGroup = unit:getGroup():getID() for j = 1, 1 do local rig = StaticObject.getByName(oil[j].name) local rigPos = rig:getPoint() local HpadOffset = oil[j].HpadOffset local deltaPos = { x = heliPos.x - rigPos.x - HpadOffset.x, y = heliPos.y - rigPos.y - HpadOffset.y, z = heliPos.z - rigPos.z - HpadOffset.z } trigger.action.outTextForGroup(heliGroup, " Delta X: " .. deltaPos.x .. " Delta Y: " .. deltaPos.y .. " Delta Z: " .. deltaPos.z, 3) end end end return timer.getTime() + 3 end timer.scheduleFunction(Pickup, nil, timer.getTime() + 5) end Thanks for any help! Eventually I will use this to detect landings on the Oil Platform helipad and moving cruiser helipads.

No that isn't an actual button seen by the stick's hardware, it merely opens or closes the circuit for the LED under the button. Sorry :(

I'm making the suggestion and wondering if there is any possibility (can it be achieved technically within DCS's framework, and is there any dev willingness?) that the Viggen data cartridge could have an alternative to the .miz via a .lua file? This would allow a pilot to create (and share with his flight) his way points prior to wheels up easily, and the ability to create a functional 3rd party map or mission planning utility. While a well crafted single player, or even coop mission may not need this, they can still benefit from different pilot approaches, strategically and literally. Multiplayer, especially PvP, missions are notorious for poor way points, with incomplete information, or simply used as "markers" for general areas. Even if this isn't the case then the field changes greatly over time in many of the more open and sandbox like environments that great map designers have made. An externally accessible Lua would enhance the experience greatly. While this idea could work well for all DCS aircraft (with WP navigation systems) The Viggen especially could really demonstrate how effective a tool like this could be, and could affect change in other and future modules. Thanks for any consideration given. I can't wait for the Viggy!

This is just keeps popping into my head every time I see the HUD.

A little math may help here: Missile starts leading at 4km, @ say .8 mach (990km/h). If we assume at that time it locks onto a chaff bundle and starts leading it and we assume the chaff is stationary, with no forward momentum from the ship. The ship (Kirov) is moving at 32 Knots (59km/h). Missile travel is 14.5 seconds. Ship travels 237 meters in 14.5 seconds. Length of that ship: 252 meters. The missile with no lead calculation (b/c of chaff @4km) against a perpendicularly traveling Kirov could potentially score a hit.

That is a very interesting proposition. At the very least you could right now, with no dev involvement, create an application that you could create a flight plan in, generate a coordinate list and plop that into the knee board folder for the aircraft or all aircraft of your choice. From that you would then manually enter way points into navigation from a list. That is about 50% better than what you'd have to do now, and 100% better than not using waypoints at all because of the hassle. Is there any better, or more real time way to import information *into* DCS? I know that you would have to create the knee board before loading into the aircraft, and probably before connecting to the server.

I think you're right, I'll be opening a thread soon and start documenting (pictures) more too. Yesterday I did turn a 9" x .75"dia aluminium tube to fit the socket. While I didn't have the grip or buttons of any kind, I did fly the mi-8 with the end of the pipe and it was fabulous, finger tip precision. Just do to my personal setup (desk, chair, mounting etc) I think the best length will be closer to 8" for me. I won't adjust that until the extension is completed and I know it's too long for sure.

Right now it's just an extension, but I've had it in mind to make a custom su-27 inspired stick. Not as a replica, just a style choice. I like to keep my equipment generic and flexible.

I've made some more advances. I replicated just the engagement (no picture), and it fit perfectly so I continued and designed the rest of the male portion including the socket engagement, room for the PCB and the shaft. I also used the design for the test nut and designed a nut that would hold the socket as it should. Overall strength I'm sure could be an issue, but for now it seems robust. I'm going to complete the PCBs today (mill them), and then design the female socket for the top of the extension. When I'm done this I'll probably share my work through some open license for people to print their own.

On further investigation, the thread profile is also non standard. It is actually quite square (even more so than acme)rather than a 60* triangle. I Modeled up a test nut and printed it yesterday, while the print didn't reproduce perfect threads, support material being impossible, they where sufficient to work!

No you don't often refuel an Mi-8 Lol. But if you had the data you could fuel up to what you need and have better performance. Not usually as big a concern in helicopters compared to fighters but it's still a good reason. For example an over-fueled Gazelle especially when using 4 HOT 3s, can struggle to climb in a hover. It has a direct impact on combat effectiveness. I make sure to run that heli as lean as possible because that weapon system (and optics) are so heavy. I think it's good practice and habit to plan accordingly for all aircraft.

Does anyone (devs?) know the approximate length from the fulcrum to the top of the cyclic? Also the length of the collective and the zero to full collective delta (difference in) angle? I've asked similar in the input-output sub forum with little luck, but I'm hoping a dev with specific knowledge may be able to tell me. -Thanks