funkyfranky

Definitely +1 for an option to turn off the big fire and smoke effects or letting them burn for a defined period of time. They look nice but also eat up resources.

Looks like we have two rather different approaches here :)

Of course, I'm scared ;) But also excited. Good news.

+1, pretty is nice to have. Usable without too many issues would be key.

Das geht leider nicht, weder mit Moose noch sonstwie. Die SAMs feuern, soweit ich weiß, nach ihrer eigenen KI-Logik. Du kannst nur, nachdem die Rakete abgefeuert wurde, rausfinden, wer das Ziel ist. Da Du anscheinend als Player nicht getroffen werden willst, könntest Du alternativ den Missile Trainer einsetzen. Der würde Raketen, die auf Dich gefeuert werden zerstören, kurz bevor sie dich treffen.

yes, but dont ;)

Thanks Holton :thumbup:

Well, don't take just my word for it. Read a bit through the feedback in this thread https://forums.eagle.ru/showthread.php?t=175028 I know, it's a lot :D

If I don't have my jetseat on, flying feels completely empty for me meanwhile. No words - it's one of those things you have to try for yourself to know the difference. Many people say the same. Once you flew with it, you're hooked and don't want to miss it. There are not many things we can do to increase our "butt feeling" and get feedback from the sim except visual and audio - at least not for an affordable amount of money. But this is definitely the best thing I bought to increase the immersion. Just firing a gun or dropping a bomb is so nice. To some extend it also makes you a better pilot I would say. You have just one more channel of feedback in certain situations, e.g. how close you are to a stall. Also when you lower your flaps or extend the speed brake gives valuable additional input.

I always use a stepwise linear curves. Non-linear curves are difficult because of the derivative constantly changing. But having two linear parts helps to compensate for my shorter desktop stick/lever in the critical area of small deflections (assuming the aircraft response in DCS to be modeled correctly for a linear behaviour with a stick length corresponding to the RL one). In principle one could even derive the proper slope around the origin of the curve by the fraction of the RL aircraft and the available physical stick. That should give the best agreement for small elongations.

Yeah, tried to report it some time ago here https://forums.eagle.ru/showthread.php?t=235628 Looks like they did not fix it yet unfortunately as the function is an important workaround for me and others because of another DCS bug :( E: But I was not aware that there are even more combinations depending on host and client - sigh!

Same here. I have not had time to mess around with so many settings but everything I tried had judder when turning the heat quickly or looking left or right out of the canopy when flying fast near the ground. I hope pimax can improve it or anyone can enlighten me with the proper settings.

What do you think about their Brainwarp implementation? I have the feeling this needs to be improved quite a bit compared to the Oculus ASW for example. When turning my head or looking left/right out of the canopy, I have some stuttering despite rather high and constant FPS.

Why do all variants of the Gazelle have to share the exact same keyboard bindings? This is a big waste of my physical hardware as buttons that are used only on the L cannot be used for something else in the M and vice versa. Any change that could be improved? This does not seem too complicated as other modules for which different variants exist all have their own entry in the controls options (e.g. C-101CC and C-101EB, L-39C and L-39ZA).

https://wiki.hoggitworld.com/view/DCS_func_getAirbases returns a table of airbase objects https://wiki.hoggitworld.com/view/DCS_Class_Airbase So you can use getName(), i.e. something like -- get airbases of coalition local ab=coalition.getAirbases(coalition.side.BLUE) -- loop over airbases for _,airbase in pairs(ab) do local _id=airbase:getID() local _p=airbase:getPosition().p local _name=airbase:getName() -- your stuff end

Number of max AC activated and time parameters for activating, c.f. https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Functional.Rat.html##(RAT).ActivateUncontrolled

https://forums.eagle.ru/showthread.php?t=238618 Just one example. It is definitely not a general problem to turn ASW off. It appears like FPS are stuck to 45 even if they could be a bit higher (say ~60) but above that you should see a difference.

There are other means to tell wether it is on or off. Even though FPS are sometimes stuck at 45 you can clearly see the difference. Your real problem is that you either misinterpret what you are seeing or not provide enough information.

Great stuff :thumbup: Just wondering, why are there changes in the graphics.lua which seem to be unnecessary wrt the default one?

Well, I would not draw too many conclusions between the maps to be honest. For that the situations are too different. For example, on PG the track was recorded directly over Dubai. So the object count is probably way higher than on the other maps even NTTR over Vegas. This comparison was meant more for the two graphics cards under otherwise identical conditions (per map).

You have ASW off? Because otherwise you will mostly see the 45 FPS in "normal" missions. PD 1.8 compared to 1.5 is quite a bit more demanding already. Also bear in mind this is a free flight mission in the F-86. With more AI units around and say and a Hornet or Tomcat you also loose some FPS. Therefore, I think you are just fine.

I did not know it's a bug but that's definitely what I observe for quite a while now. Well, also the 1080Ti shows values between 45 and 90. But is seems it only happens when it is well above 45. So yeah, the comparison gives more a rough idea and the number should be taken with care.

Don't know exactly. Somehow the FPS like to snap to 45 FPS even with ASW off. And it was definitely off as one can see from FPS being between 45 and 90. That does not happen with ASW off. Also OTT shows ASW status off. I just turned it off for testing purposes for the reason above, i.e. not having only 45 or 90 FPS. Usually I have it on as it makes things much smoother.

Situation: Free flight in the F-86F on different maps in areas with high object counts (large cities). Measurement: Replaying same track file with identical DCS settings. FPS saved to csv using FRAPS. DCS version: 2.5.4.29167 NVIDIA driver: 419.67 Oculus home: 1.37 (beta) Pixel density: 1.5 Hardware: Oculus Rift, ASW off Asus GTX 1080Ti Strix OC Asus RTX 2080Ti Strix OC Caucasus: Batumi (Click to enlarge) NTTR: Las Vegas (Click to enlarge) Normandy: Caen (Click to enlarge) Persian Gulf: Dubai (Click to enlarge) Now, is it worth it? Dunno, your choice :)

Airbases in MOOSE Guys, I have the impression that there is sometimes a little confusion about the airbases that are "supported" by MOOSE. So to explain briefly: MOOSE retrieves all airbases of the map from the DCS API function getAirbases at the start of the mission. This includes also all FARPS and ships. Also those that are spawned. For the airdromes, there are additionally "enumerators". These are added by hand to the Moose.lua and need to be updated as new airbases or even maps are added to DCS. However, the sole purpose of these enumerators is that they avoid typos when using the LDT intellisense. For example, the enumerator AIRBASE.Caucasus.Senaki_Kolkhi is the same as the string "Senaki-Kolkhi". Therefore the two lines AIRBASE:FindByName(AIRBASE.Caucasus.Senaki_Kolkhi) AIRBASE:FindByName("Senaki-Kolkhi") are absolutely equivalent. So if a new airbase is added in DCS and there is no enumerator in MOOSE (yet), you can always use the simple string. Only make sure that you use the exact same spelling as you find on the map in the mission editor (including blanks and dashes, these are allowed in strings but not in variable names).