

ldnz
Members-
Posts
106 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
ldnz started following Bombing solution seems to use Barometric Altitude only
-
In opt mode, a2g, in a dive with a good steady solution bombs appear to always fall short. In active pause, the only thing that appears to affect the indicated slant range is the altimeter setting, laser makes no difference. It appears that radar altimeter and laser aren't being used for slant range calculation, only baro alt. Unsure, but in previous mission in mountainous terrain I found a2g cannon with laser (I think, but altimeter would have been no use) to be pinpoint accurate, so possibly just not right with bombs. LastMissionTrack.trk
-
Yep, with no idea how barometric/radar/laser ranging is supposed to interact, let alone whether (ED known) bug fixes have been delivered yet its pretty tricky to proceed.
-
I tried this on Nevada and saw similar. I was trying to zero the altimeter (for Groom Lake QFE) and found that my bombs were miles out and I go NOLA warnings. Also using pre-desig when set with altimeter far from QNH I noticed the desig symbol altitude is wrong. Had A for laser on the hud, but it seems almost like only barometric altitude is being used (in a dive so probably too steep for radar?) not laser range
-
Yep, my design was as close to a paper approach as I could get while still being usable in VR - so although it has the slide rule, it will do the basic calcs for you as well. But no gps, everything is manual, POI, sam locations, the lot. Fixes are placed by double tapping where you think you are - so if you don't plan well with good landmarks its easy to misjudge and get lost. I've found I can comfortably get TOT within +/- 10 seconds with this approach, with or without INS (though INS more useful higher you get/more cloud cover/night - blue ticks are at 5nm (or 5km if in metric) from waypoint so you can glance down and see where you should be up to compared to INS distance to go, and purple ticks are minutes to go as planned. I was improving fix logging and got this flight through South Atlantic in a gazelle with its tablet disabled and no INS that was cool image.pngimage.png
-
I kinda built this sorta thing for my own use - a simple little server app that pulls the map tiles and navaids from DCS, and is designed for manual, warbird, helo, F-4 style nav. I use it within openkneeboard with a wacom tablet. You can double tap to select a point and use it as a waypoint, threat mark or a nav fix, or can use the new alt-click in the F10 map and then copy to clipboard to get coords easily from DCS. If anyone is interested I've been meaning to polish it up for an opensource release.null
-
Try full dirty, 80kn, left turn and apply throttle anything other than smoothly - you'll definitely see an aggressive snap roll. Easy to avoid if you're conscious of it, but I've replicated all the spin into the drink footage by accident
-
Huh my apologies for poor information earlier - quite right it doesn't trim follow. In VR I'd just naturally been adding in trim and centering my stick, just checked in pancake and yeah, even at 80 kn with full flap and heaps of nose up trim the stick position is centered.
-
Changes to the behaviour of net.dostring_in()
ldnz replied to BIGNEWY's topic in Scripting Tips, Tricks & Issues
I got this to work from the hooks environment: return net.dostring_in('scripting', "local mps = world.getMarkPanels(); local mps2 = {}; for k,v in pairs(mps) do table.insert(mps2,v['text']); end; return table.concat(mps2, '|')") It seems that only trivial return values are being passed - single number or string, no complex objects. I wish there was a way for this to work online too. I can't believe its not possible to get the mark panels which are literally user generated points, would be so handy for any DTC type tool (or in my case plotting board style nav kneeboard) -
I'll have another look - but I don't have a centre detent configured in VPForce, and its reasonably long given I've got a VKB grip on it (the adaptor adds ~5cm to an already long arm on the VPForce), so I can't feel/don't care about the exact centre position - I just trim until forces are neutral which works fine in both roll and pitch. I have noted that at cruising speeds the trim does tend to get to near centred on all 3 axis (back from the +6/+6/0.5 you takeoff with) so may be thats what you're noticing? It seems well rigged for normal speeds. Solved any rudder issue with a healthy curve, have all the control and stability I need now!
-
I struggled with this initially, get the RPM over 500 before you kick in mixture and let go of the start switch. Might need to bump the throttle a little bit once it fires to get it over 500. Start switch must be let go after mixture is on, otherwise it seems to flood and stop,
-
Yes, definitely responds to trim.
-
I've been only testing with custom missions, and have never missed a wire (well outside of completely clowning it and landing way long), however that is with me consciously watching attitude - I would have the thought from the external view that the hook was plenty low enough.
-
One thing I've noticed is that once hitting the deck I really pull back on the stick to plant the tail and ensure it catches a wire. at 90kn it wants to be up on 2 wheels and I wonder if that has the hook passing too high? Haven't had a close look on external view to see whats going on
-
After a number of hours last night I've found it a joy with a VPForce FFB - responding well to trim and giving plenty of feedback. It feels heavy to me with FFB, and I can't follow some of the extreme negative comments above at all with my setup. I do wish for FFB rudder - its got a huge rudder and with my fairly light springs it feels sensitive to it, but I'd imagine with FFB there would be enough weight in the pedals to completely change that (like it does for the stick)
-
KA-50 ABRIS - map not scaling with symbology
ldnz replied to MortalMando's topic in Bugs and Problems
Seeing exactly this. I can't spot a pattern as to what makes the background map update or not, symbology overlayed (route etc) is always correct/live updated. Map freeze is very disorientating, as there is no indication its happened other than spotting desync between where you think your route should be taking you. Its almost like the background texture is only periodically getting updated