Jump to content

Py

Members
  • Posts

    193
  • Joined

  • Last visited

1 Follower

Personal Information

  • Location
    Sydney AU/Tokyo JP
  • Occupation
    Engineer, robotics

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The ellipse is pointing the radar to attempt a HMCS boresight lock, but the missile seeker is still caged and doesn't slew to the target until you get a radar lock (in slave mode, the default). Holding Radar Cursor/Enable temporarily swaps modes (to bore mode in this case) which slews the actual missile seeker, so you can fire a sidewinder immediately without a radar lock just by looking at the target. Sometimes it takes a few seconds to get a radar lock so this can be a lifesaver. Also the AIM-9X can be fired at a wider angle than the radar can slew, and they will get no radar lock warning.
  2. By something active I mean when is the range update from AGR triggered? A) Any time the TGP points anywhere, AGR sweeps it and updates range B) When a position is area tracked? point tracked? Also must the AGR scan height be manually adjusted to cover the point targeted by TGP?
  3. Few questions: 1. How does laser vs radar vs PP accuracy compare? 2. And is there something that needs to be actively done to range with ground radar, or is it automatic? 3. Is the precision maintained if lased/GRd points are saved as markpoints?
  4. ... at a certain USB polling rate. If you've ever used an extremely crappy mouse, it's actually quite noticable. Decent ones use a polling rate of 500 Hz or higher so it feels smooth regardless of the montor refresh rate. In regards to trackIR, if it's using raw position data then yes syncing it to the monitor refresh rate will eliminate inconsistant update timing due to aliasing, but personally I haven't noticed a difference using G-sync. If the trackIR software is doing things properly then it should be interpolating/extrapolating the instantaneous position at the frame time and this won't be an issue (but I have my doubts).
  5. I also spent a lot of time trying to figure out why a simple export script was ruining my FPS, eventually I found the problem is some functions in the aircraft export files (that in my opinion should not be enabled by default). Check the export script for each aircraft you fly for a section like this: Eg for F-16 in Scripts/DCS-ExportScript/ExportsModules/F-16C_50.lua if LoIsObjectExportAllowed() then -- returns true if world objects data is available if LoIsOwnshipExportAllowed() then -- returns true if ownship data is available ExportScript.LoAircraftInfo(mainPanelDevice) -- Provides a lot of aircraft properties ExportScript.AirportInfo(mainPanelDevice) -- Provides info on the two closest airports ExportScript.WindsAloft(mainPanelDevice) -- Gets winds at the aircraft ExportScript.GroundRadar(mainPanelDevice) -- Reports 2 closest friendlies and 2 enemies (Use in Single Player) ExportScript.AirRadar(mainPanelDevice) -- Reports 2 closest friendlies and 2 enemies (Use in Single Player) ExportScript.IglaHunter(mainPanelDevice) -- Locates closest Igla (Use in Single Player) end end Disabling that section for me instantly increased FPS by a lot and stopped the horrible microstutter.
  6. Could tables be precalculated and interpolated for a realtime approximation? There are many variables, but even a fairly coarse precalculated set of solutions might give significant improvements.
  7. Yes the blue pill uses a STM32F103C8T6 which has 12-bit ADCs. FreeJoy is a really well done project - I've used it to add some 5-way buttons and sliders to my warthog throttle. The 5-way buttons use shift registers and can be daisy-chained, so any number of them only uses 3 pins on the bluepill (+2 for power).
  8. Don't stress about the fuelling part - just practice flying in close formation first until you feel like you can control your position smoothly. Then the refuelling part is just choosing the right position (watch the fuselage/engines, don't focus on the boom). Good luck!
  9. 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.
  10. 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).
  11. 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.
  12. 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/
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...