ldnz

Hi guys! Found an issue where DCE causes openkneeboard to crash. This is due to the fact the mission.descriptionText and side briefing are written direct to mission, instead of into dictionary like DCS usually does. I've raised the issue with OpenKneeboard team (where we're doing a blind lookup in dictionary without checking whether the text starts with DictKey_) but this can also be fixed with a minor change to DC_Briefing.lua to change the destination from mission.descriptionText to dictionary.DictKey_descriptionText_1. What do you reckon? I don't know enough about DCS mission format to know where the fix should be, have also notified OpenKneeboard team and can send a patch there.

I was wondering that too. I've had no issues since the last patch. Yes it will go inaccurate when subject to continuous acceleration, but always returned to level

Re-alignment won't, repair should.

I made it to within sight of the English coast (at a casual cruising pace with the rest of the form) and got gunned down by a FW190 I didn't realise had chased us all the way haha. I ran it in multiplayer and the fog made it very very difficult to see anything, going to retry in ST now.

Yeah this is hopeless. I'm loving the V for Victory campaign, but the AH is really starting to annoy me. Such a fundamental instrument, and that campaign has plenty of clouds/nights/need for the damn AH. Please @NineLine can you give this a nudge?

Belay last - I can't find any reliable technique for the AH. Hopeless. The DI is also swinging wildly with engine RPM < 1500 which makes no sense to me - if its a gyro instrument, why would it swing back and forth with vacuum fluctuations? Surely if vacuum is low it would be more prone to drift, but thats a slow process.

Couple of things I found in V for Victory so far: Because its cold, I find the engines take a lot more priming to start. If I don't let them prime enough, and the first engine coughs and dies, then the AH is stuck oriented at whatever position it briefly got to. As you change course, that apparent angle will change as it seems fixed in a vertical position. If I prime the engines heaps and get a clean start, then the AH is ok. So it seems like as soon as first loss of vacuum occurs, its irretrievably broken?

double check motion blur is off - I saw this too after the update but went away (and gained 15 fps!) when turned off.

Check motion blur - I just turned off and went from 31 -> 40+ fps on PG AH-64 UAE weapons range instant action. No other setting (shadows etc) made any notable difference. But motion blur reliably causes that penalty

As above, the GameGUI callback onPlayerChangeSlot won't fire if a mission with multiple client slots is run in singleplayer mode. Works fine on multiplayer servers. Impact: Can't tell what aircraft a user is in, so can't drive external applications such as OpenKneeboard to display the correct kneeboard pages.

Yeah cheers mate, I'm happy with how to do it in a mission, or server side. Just looking for a way to get all the marks on the client side when they're not running the mission. The marks are obviously available (they appear in the F-10 view, Tomcat, Harrier, Viggen all use them etc) but don't seem to have a public API.

Thanks, that's the events I am after, but they aren't available from the GameGUI environment. I'm looking for a purely client side solution that supports multiplayer. I can't find any combination of net.dostring_in() that gets what I want, and I can imagine good reasons you wouldn't want those events available to a client (Weapon fired, at me?! SATAL will go even further off the rails!). I guess either in the GameGUI/DCS singleton, or the Export API would be best?

These are accessible from the mission environment, but I'd like them for inclusion in a tool I'm working on. I see no export risk as they're already available in F-10 map. Does anyone know how to access a list of markpanels from the the GameGUI scripting environment?

Love the orbit commands, iceman does a good job of intercepting and holding it, except he always seems to setup for a left hand orbit which is obviously not much use with the lantirn. Tried approaching from different distances with same result, always sets up for left hand.

Definitely the radar stuff here. Mirage team have done an awesome job showing the way. Yes it will upset people when they have to deal with more false contacts and RIOs actually have to work harder, but would be great to see the radar fully fleshed out.

Yeah sorry could have been clearer

turn up the brightness - knobs on far left.

Make sure you've turned up all the internal light brightness on far left, first time I didn't touch those knobs and I never saw the boresight targets.

The tid going blank is probably jester using the TCS to try for an id.

This is not a behaviour i've seen at all, and I've done a lot of 30 deg loft shots at many different ranges. The only time I've seen it go into space is if the track was immediately lost. Attached is a representative tacview of a ~30nm shot with a 30 deg loft, both track, one kill, one lost in the notch. Tacview-20220206-153720-DCS-f14 bvr range.zip.acmi

Ok, disregard then.

Hi, I've seen this mentioned but not sure if there is a ticket for it.. Assuming you have auto P-STT switching disabled, and have a valid PD-STT lock: 1. The first time you command jester to select P-STT (via wheel or direct button) he will attempt this, with limited success. 2. Any additional time you ask for this (after regaining PD-STT) jester will acknowledge, but not actually do anything (as shown by radar mode on ctrl-enter controls helper). So it becomes impossible to get a P-STT lock until it can be pilot acquired. This is costing me a lot of sparrows

Cheers will review. Appreciate the time in putting these tacviews together.

I am struggling now with just how good the AI is at notching. See attached tacview - what could I do better here? Doesn't look like there was any attempt to reacquire as they came out of the notch as well. But I can repeat this every time. Very hard to get a hit on these guys. Using Mk60s and a bigger loft + higher speed doesn't really change anything, doesn't seem to be a function of terminal speed. Tacview-20220206-090754-DCS-f14 bvr range.zip.acmi

Does TID range actually affect tracked targets? I don't think it does - I'm sure i've had the system decide that tracks at greater ranges were high priority.