Py

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...

Sorry I don't think I was clear enough on the issue. Maybe it doesn't happen to you? But for me, the new DX buttons don't get set until I move the associated switch. Eg on the throttle a 3 position switch has positions UP/MID/DN, which are mapped to 3 DX buttons DX1/DX2/DX3. There should always be one of those DX buttons active, no matter what position the switch is in. But when running the TARGET script, all 3 DX outputs are 0, so in DCS the switches are in the default state and not the same as the real switch. The DCS option of "synchronise to HOTAS on mission start" is on, but the DX buttons are all zero so it has no effect. The switch has to be moved eg to UP and the state will change to 1/0/0 then back to mid -> 0/1/0 for the state to be synchronised. PULSE mode will not help, as the initial state of the switches will still not be synchronised. For me, I had to move EVERY mapped switch to get the correct synchronised outputs. Does this not happen to you? The code I added at the end of main improves this so any switch or axis change will synchronise all buttons at once, but still one manual action is needed.

OK there seems to be a pretty major issue... The buttons on the virtual joystick don't synchronise to the real buttons when you run the script, so all directx buttons stay off until you move the switch they are driven by. So you have to toggle EVERY switch, EVERY time you run the script to get the output buttons to be properly synchronised. I found a kind of dodgy way to synchronise them all at once, but you still need to cause a single update by pressing any button/moving any axis. Add this at the end of the main function: // Update all the throttle inputs to synchronise the mapped outputs with the actual device state // Not needed for the joystick as all buttons are momentary int i=0; while(i < 52) { DefEventHandler(EV_HID_INPUT_DATA, &Throttle, i); i = i + 1; } Do you know of any way to trigger an update so it will work without any manual actions at all?

Ahh ok, that makes sense. I knew there must be some kind of logic to it!

The choice to put extra functions on some buttons but not others. eg on the throttle the up/down directions have long-press but not left right, and the stick TMS is the opposite with long-press on left/right but not up/down. It's not important and simple to change thanks to your organised code, I just wondered if you had figured out some really efficient control scheme or something that was the reason for those choices.

This is really nicely done sedenion, the code is clear, easily customisable, and well commented. Thanks for providing it! Just wondering, what is the logic behind which buttons you chose to add the submode and long press functions to?

The F-14 can fire in TWS mode which gives you no warning until the missile turns on it's own radar. The phoenix missile only turns it's radar on a few miles from impact, which doesn't give you very long to react, which is the whole point!

On most controllers it is more up/down than fwd/aft, and depending on the controller it can be either on the front (away from the user) or back (toward the user). This is why an option to reverse the direction would be useful. Example - Warthog throttle slew control or coolie hat (away from the user) If you set it logically so that up=antenna up and down=antenna down, then up=zoom in and down=zoom out which does not make sense! Example - Warthog stick TMS or DMS (towards the user) If you set it logically so that up=antenna up and down=antenna down, then up=zoom out and down=zoom in which is logical (this is how DCS does it currently) So an option to reverse it would allow a logical mapping to be used in both situation. Saying it is not "realistic" is not valid because we are not using a realistic hornet HOTAS and have to map functions to non-realistic locations.

Yes please! The current sort by only date is not useful at all, searching manually for popular/highly rated files takes a long time.

So nothing to do with the actual input data then... Are you sure it isn't just something aerodynamic? What speed are you testing this at? Maybe the plane is forced into a high AoA and low speed when you use the end region of the stick and the plane is not happy. Does it happen when the plane is on the ground? Also you could try it on another module to see if it's the same, eg the free TF-51D or Su-25T No need to set up all the controls, just the stick/throttle and do an air-start instant action

What happens if you go to the Axis Tune menu for your joystick axes, are they smooth there? It really does sound like an axis assignment conflict, you triple checked it?

Actually I think it IS a bug. Sure takeoffs shouldn't be done in auto flaps, but something seems to be wrong with the flight model if you do. I thought it might be the FCS doing something odd due to the incorrect procedure so I tried watching the stabilizers while "resetting" the violent pitch up with a quick auto-half-auto on the flaps switch (too fast for them to actually move). If it was the FCS, I would expect a sudden change in the pitch of the stabilizers as it is "reset" and stops trying to pull up hard. I saw no visible movement at all after the "reset", but the plane suddenly stopped pulling up, suggesting that it is not actually the control surfaces causing the odd behaviour. That would definitely be a bug if the plane is being influenced strongly by something besides the control surfaces. I'll watch the other surfaces when I have time, but such a strong pitching moment seems unlikely to be possible with the other control surfaces at low speed.