Py

60/120 FPS are US-centric framerates, in countries with 50 Hz power cameras should run at 50/100 FPS for consistent brightness when using mains-powered lighting. That doesn't apply to trackIR though, as it provides it's own IR lighting (with no flicker). It does seem likely that the asynchronous updates of camera position from trackIR vs frame render time are causing stuttering, as smooth head motion is being chopped up into uneven steps for display. Locking display refresh rate to 60/120 Hz *should* fix it, if that's the only cause, but it shouldn't be necessary and removes the benefit of g-sync etc. I can think of two ways to fix it properly, one by naturalpoint (doubt they will bother), and one by ED: 1. Change trackIR position reporting from a fixed rate set by the camera, to a request from the user (eg from DCS). The software already does motion smoothing so should be able to give interpolated/extrapolated position at the exact render time, eliminating uneven motion even if the frame rate is varying. 2. DCS could get the polled 120 Hz data and do it's own motion smoothing/estimation, then use the position estimated at the time of render. That would probably need to be done in a separate thread, but would be pretty simple to do. ED already has a huge TODO list, but if this feature can be added to the new multi-threaded engine they are working on it *should* solve the issue. I think this isn't a problem for VR because steamVR etc is already doing the motion smoothing and extrapolation of position data before providing it to DCS.

I can't comment on how it feels now, but have used both a MS FFB2 (force feedback) in the past and a FSSB-R3 Lighting (force sensing, like the real F-16) currently in DCS. It would be technically possible to emulate a force sensing stick with a FFB stick, but I don't think the MS FFB2 provides the needed data. It would need to always force the stick towards the centre, then report motor current instead of stick position to DCS. The FFB is also a bit wobbly around the centre which would kind of ruin the feel. So if the manufacturer of a more modern FFB stick makes the driving current available to DCS, it would be possible for ED to make it feel kind of like a force-sensing stick. But without that data, there isn't really anything they can do and it will have to act like a spring-centred stick with no feedback from the plane.

What doesn't make sense to me is only allowing a single GBU-12 on the inner pylons (in DCS). Is that a real limitation? 3xMK-82 or 3xCBU-87/97 fit, so why not 3xGBU-12?

I also had this problem, no track unfortunately but it was also in the Persian gulf on a Tarawa, moving at 15-20kts I think, light wind (DCS "stable"). I spawned in a Huey, and when trying to start up it began bouncing around even more wildly than usual, then sliding back, then seemed to flip back and hit the helicopter behind and exploded. I've spawned in the same spot many times previously, and before the last stable patch it was never this bad.

The changes have great potential to improve the realism when all missiles use the updated system, and will allow better ECM modelling in the future. So firstly well done to ED for implementing this. It's expected that things will be a bit buggy at first, but closed beta should really find major problems like this. Even then, it was reported in open beta and there is really no excuse for pushing it to stable. ED's improved testing procedures seem to be slipping back to the old ways, making the stable version pointless again. PLEASE ED, hold back stable releases until major issues like this are fixed in open beta.

Point/area track from a TGP or GMT radar lock are just used to direct the maverick seeker to look in the right place, the maverick must lock with it's own seeker before it can launch (based on image contrast except in force correlate mode), and then will follow the target by itself even if it moves. So you can fire several mavericks at different targets in one pass, even on a moving convoy. It's possible that the lock will flip to another nearby target in flight eg if your targeted tank drives close to another tank though.

It was a good idea to create that thread to stop the CONSTANT "when is the update" questions... But 90% of the time it just says "TBA" which kind of defeats the purpose!

Yes please!

You need to set each one separately, use the STEP button to switch between them.

Also try alt-enter to go fullscreen. I get a weird 1 sec chugging if I have alt-tabbed to check something else, but alt-enter fixes it.

Oh wow. <deleted angry rant> The current price is 24.99 which is the same as I paid for the preorder discount including the additional hornet discount. So at least for me it's not cheaper, but for those who bought it without the hornet, it would have been cheaper to not try and support ED by preordering. It is good of them to offer discounts...but think about things like this first! I wish ED great success, but every time their PR reminds me of the phrase "snatching defeat from the jaws of victory".

One thought - have you tried going for the left drogue? I think it expects the first plane to fuel on the left, the right is used if a second plane refuels at the same time.

I'm in a similar position of being pretty new to the boom, and though I'm not good at keeping in the right spot I think I get it and just need more practice. I think the key is not trying to use cockpit visual references for position (ony use the lights), but use your peripheral vision to judge and control your rate of relative motion. If you can keep your relative motion at a low speed, then you can carefully drift in the correct direction to centre the lights without them jumping too quickly. Also currently I get confused if trying to move in more than one axis at a time as I forget which light means what, just slowly drift in one axis at a time while keeping stationary or very slow in the other axes. I think it will become easier with practice when the lights' meaning doesn't require thought. I find if I start moving too rapidly it's best do go down and away then get controlled and try again. Same thing as when going for the drogue, it's pointless to try and plug while in rapid PIO, it's better to fall back and go in again for a smoother plug in.

Not only for users, it would help ED a lot to have consistent test results they can compare and trust for debugging and comparison purposes. I'm sure they know this, hopefully they will add it in the future when things are a bit less frantic... :vertag:

I'd say it doesn't make financial sense for the game to run on linux as there are just too few users. What does make a lot of sense is a linux dedicated server. A significant proportion of the expense of a DCS server is windows licensing (for our server anyway), and it constantly wants to be updated. A linux server would be lower cost, more reliable, and there are more hosting options available. I doubt ED staff are still reading this thread, but I hope they eventually consider the idea.

Wow it's not just a few phrases like "Tiananmen square", though of course that is in the list. There are over 21,000 entries! I know they want the chinese money, but I'm kind of disappointed that ED would do this.

BIGNEWY, People are trying to help by posting specs and performance measurements and observations, but every one is different and I can't imagine that it is easy to compare and use this information. I think it would really be worth ED's time to implement a basic benchmarking function into DCS. Then everyone can perform the same controlled tests, making comparisons actually useful both for users tweaking options and for ED to collect performance data. You can also record the system information and log all the important stats during the test. Even if you just play back a reference track file with performance logging, it would be a good start and may help you solve the current performance issues. If you make the results packageable then users can post their results in forum posts when there are issues (as they do now with track files), but you will have all the information you need in a standard format. Maybe have an option to send the result directly to ED for gathering info from a wide range of sytem setups.

It's normal to target the base of the object to prevent this problem. However this is not the issue as it happens even when you get the coordinates from directly overhead.

Yes PLEASE do this, it's a very simple change but has a huge impact on usability (and user frustration). Especially the A-10C needs to be updated for consistency.

It makes clearing an area extremely difficult, and is just immersion-breaking. What a waste of time trying to find this last guy, stuck vertically in the side of a building:

I have found that the CCRP line wanders off to the side at low level when I try to do this, then moves back closer to the target when I am pulling up but wanders around which makes it rather hard to know where to aim. Do you have this issue? Maybe only when there's some wind? It doesn't seem right to me.

Tell us more about the type of flying you want to do for better suggestions. A-A or A-G or multirole? Modern/older/WW2? Helicopters? Simple or complex? FC3 gives a bunch of planes but they are simplified, personally I think high-fidelity modules are much more interesting. Combined arms is also very limited. If you've watched plenty of videos and know what you're getting then ok, but that's not what I'd recommend. Aircraft carriers are included in the base game, only the "coming soon" high fidelity carrier is a paid extra.

Hehe thanks for investigating, I thought it was a limitation in TARGET but it being Microsoft's fault is somehow not surprising! :doh:

Thanks, your SyncVirtualBtn function does the same thing as the code I added to the end of main. I still couldn't find a way to trigger an update of the outputs without having to press a button or move an axis, but that's not much trouble so I'm satisfied with how it is working.

I have a total of 1 day of experience in this, and the documentation is terrible, but it seems .tmc and .tmh are basically equivalent to .c and .h files in C programming. That is, .ttc is the main script file to be compiled and .tth are header files that provide definitions and functions for the .ttc. .ttm are some kind of macro file, not sure how they are used. Just enabling more virtual buttons wouldn't really do anything useful by itself. The files by sedenion map all of the buttons and switches so that each switch state has a separate directX button which can be used in DCS. For example, the 2 position switches on the throttle eg EAC only give one output that is either on or off. So in the DCS F/A-18 if you want to use it for gear up/down you can't properly (without .lua editing). If you map it to "gear down" then it will put the gear down, but switching it the other way does nothing because there is no opposite signal to map to "gear up". Sedenion's script gives you the required 2 directX outputs so you can map it properly: one when the button is up and another when it is down. Similarly, 3-position switches give 3 outputs instead of just being off in the centre position. There are also extra functions to increase the number of buttons, it is commented well so easy to understand. The files you want are in this post: https://forums.eagle.ru/showpost.php?p=4016316&postcount=41 Get the TM Warthog Universal HID.zip one, there's a readme and plenty of comments in the files. The main.tmc is the script that does all the mappings, the .tmh files in the include directory define constants and functions to make the main code clean and understandable. Add my code in post 50 if the buttons don't synchronise properly...