Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Py

  1. The 'in range' cue for all the GPS guided bombs (GBU-38/31 and CBU-103/105) is also incorrect a large fraction of the time, and bombs fall short. It may be related.
  2. In terms of the pixellation/jagginess, it seems that none of the antialiasing/supersampling used for the main game graphics is applied to sensor images. Real FLIR images look much more smoothed and there is no pixellation (unless at digital zoom scales). Another thing to note - make sure your DCS setting for "cockpit displays" is set to 1024, and remember that unless you have one of the "every frame" options selected your PNVS/TADS etc will be at half your framerate which makes a huge difference when operating at night (unless you have great framerates).
  3. It's set mechnically, in reality it can't be changed in the air (for paveway II -> GBU-12 etc) The newer ones with electrical interface probably can, but these have no electrical connection to the plane.
  4. Keep the curve linear and no deadzone, it's more adjusting the force settings and force bias ("NASA sensibility" they call it) to your liking. Have a look at https://forums.eagle.ru/topic/258187-fssb-force-and-curves-settings/
  5. There isn't just a single filter, and yes there will usually be one that filters relative 0 to the aircraft as well as the one you mentioned. All leakage from TX to RX, scattering from within the aircraft eg the radome, and reflections from the ground perpendicular to the aircraft (eg from sidelobes) will have no doppler shift.
  6. You're probably entering degree/min/sec cordinates while the jet uses degree/min/decimal min format. Left Alt + Y to change formats in the F10 map screen. The correct formt should have a decimal point not a ' before the last set of digits.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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!
  14. You need to set each one separately, use the STEP button to switch between them.
  15. 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.
  16. 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".
  17. 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.
  18. 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.
  19. 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:
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  • Create New...