ldnz

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)

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

I swear I had the same thing happen at the same point... I manually hit the trim and got it under control, and was surprised later when I pulled up the controls indicator and my trim was centered - I thought it would be well to the left. I didn't change payload or anything, thought it was a deliberate failure (too early to have taken enemy fire)

Hi, wouldn't you use pull-up range from your loft calculation as release range in the WRCS? Its the distance at which the WRCS will trigger the pull-up timer. I believe the weapons delivery manual calls for adding 1s pull up timer so you have a moments notice - so need to add 1s worth of distance to release range. also, aural tone volume is now set to zero on cold start, not sure if that is the source of the beep?

Currently the scripting engine has hooks for dealing with map markers only in the mission scripting environment, and this has proven very powerful for dynamic multiplayer missions. An increasing number of aircraft use map markers as an interface to easily load in flight plans and mark points of interest, and I'd like the same information to be query-able via the Export API so I could use this in external tools - e.g. a dynamic VR kneeboard, or similar. And/Or the new dynamic flightplan feature - it would be great to access that via Export too.

Yeah, that was my issue. Wrong binding. Tip top now

I have the same issue as heloguy, CD Release does nothing at all with my VPForce. No TelemFFB or anything else. Annoying as I can't trim at all so its constant force

@Miguel21 - I've been debugging AI strikes particularly 3 issues: 1. target and action waypoint wasn't being skipped, so AI would hang around, drop 2 bombs, then have to go back to action -> target -> egress to get out. This also meant B-52 cruise missile strikes wouldn't work as the aircraft followed the missiles in. 2. With a multi LGB drop, it can take a couple of passes, which screws up the ETAs on egress waypoints, and sees the AI go full burner to get home, running out of fuel. 3. LGBs can't be used on map point targets. Fixes attached, I don't fully understand the behavour intended, so please this is indicative only. If you have a git repo, I could open a pull request which would make the changes easier to point to/discuss ATO_FlightPlan.lua CustomTasksScript.lua

Agreed, this is driving me mental. Blocking a bunch of missions

Interesting, I haven't seen any crashes, HARMs seem to be working fine in that region. Yes, this has caused a lot of grief in the scripting community, MIST and MOOSE have already had fixes. I've done a general scan through and this looked like the worst affected. Most of the event stuff is being recorded fine - statics being destroyed, aircraft airborne or on ground are fine. Possibly an issue with attacks of ground groups - I'm seeing F-15s just turn around and refuse with dumb bombs at the point the customgroupattack is triggered, but no crashes in logs. Attacks of statics are fine.

Hi, yes the behaviour of getCategory() apparently changed in the latest patch. I was getting GCIScript errors at line 180, and no interceptors launching. With the file I uploaded, its working again, but yes I'm not 100% sure its correct. @Miguel21

Minimum test case - F-16 bof15 ai wont lgb.mizmbs its target without hesitation. F-15ESE turns around and goes home (occasionally strafes it)

Small fix required to GCIScript after the last getCategory() changes. Not sure if this is correct, but seems to work: GCIscript.lua

Still not working for me . F-18 - will attack fine, F-15, flies towards target, turns away goes home

@Miguel21 - I think I've found a bug with the conf_mod updates. I'm trying to get my campaign generator to generate a conf_mod file, and that includes defaulting all the PruneScript behaviour to False (I don't feel its needed in these days with multithreading, and I like seeing the airbases populated!) Unfortunately, as part of Util_Functions::UpdateConfMod, it seems to replace PruneScriptConf table with values in conf_mod_check, which means the PruneScript is always forced on. I think its struggling with the fact the PruneScriptConf is a table, and just replacing it wholesale instead of iterating through its contents. I'm not sure what the fix is. Other parts of conf_mod seem to merge ok. Edit: Found that by adding the EjectedPilotFrequency table I can avoid UpdateConfMod being called. This will only work until the next time a new feature is added though

This is definitely still an issue. PDSTT -> PSTT from the front seat (either via jester button or wheel) seems to work once per session. You can tell from the ctrl-enter control indicator that in subsequent attempts jester says OK but nothing happens, and stays in PDSTT

Yep, broke my arm and couldn't code for a bit but working on it again now. Added Sinai support, and testing a fix now for AI not bombing ships. Major work outstanding before I consider a version 1.0 release is adding ability to upload briefing missions and assign them to targets, I think that's an awesome feature of DCE.

Had the same issue while trying to play the Kerman Campaign mission two. CCIP seemed ok, but Auto was 20m short.

These two modes need a competent RIO, and offer no visibility to the pilot, so I don't think they're in scope for Jester.

Nope, nothing at all sorry. It fails on selecting the campaign and clicking load, and also fails on trying to open it in the mission editor. Looks like War on Tchad uses CJTF Red and Libya