BuzzLine

For me the issue is only on user campaigns, not paid campaigns. I saw both symptoms: the EndMission button not working as well as the Campaign page resetting all user campaigns to 'inactive'. I dug in the code and I found an extra slash in the path DCS generates when listing campaigns. Because of that, that path does not exactly match the one listed in logbook.lua. I could provide a (very ugly) fix, but then I'm not sure how to explain the miraculous recovery of all the campaign statuses that is mentioned in the other thread ("Incorrect status in Campaigns Page"). So I'm not confident in that fix for now, I need to dig some more. I have to sleep a bit for now but I'll take another look tomorrow night if ED has not fixed it already. If anyone wants to pickup the trail: look at function "findCampaigns(dirName, a_modulId, a_developerName)" in me_campaigns.lua, if dirName ends with '/' already, there will be double slashes in the paths inserted in campaignsByPath. Those will/may not match the path "game.campaign" in "function onReceiveMissionResults()" that (for me at least) has no extra slash. That will cause nil unhappiness in various places. e.g.: C:/Users/BuzzLine/Saved Games/DCS/Missions/Campaigns/en//_debug_campaign_parse/debug_campaign_parse.cmp <= generated by findCampaigns C:/Users/BuzzLine/Saved Games/DCS/Missions/Campaigns/en/_debug_campaign_parse/debug_campaign_parse.cmp <= read from logbook.lua Does anyone knows if Lua has standard path.normalize or at least path.join ? It'd be nicer than doing it by hand. Cheers, Buzz

@Flappie : this may be another issue than my "favorite" bug. There might be something fishy in the parsing of campaigns, I have this brand new error in my DCS log : 2023-01-29 23:14:33.503 DEBUG LuaGUI (Main): GUI Error: [string "./MissionEditor/modules/me_campaign.lua"]:854: attempt to index local 'campaign' (a nil value) GUI debug.traceback: stack traceback: [C]: ? [string "./MissionEditor/modules/me_campaign.lua"]:854: in function 'chooseNextMission' [string "./MissionEditor/modules/me_campaign.lua"]:1040: in function 'onReceiveMissionResults' [string "./MissionEditor/modules/me_debriefing.lua"]:391: in function 'endMission' [string "./MissionEditor/modules/me_debriefing.lua"]:351: in function 'onChange' [string "./dxgui/bind/Button.lua"]:22: in function 'callback' [string "./dxgui/bind/Widget.lua"]:368: in function <[string "./dxgui/bind/Widget.lua"]:363> I have the same symptoms as here : Investigating ...

Check this (these) thread(s) :

Alright, here's a short track and miz file. Just shoot the first autogenerated train you see. It seems to trigger the problem : 2023-01-26 21:37:56.365 ERROR Lua::Config (Main): Call error onShowMainInterface:[string "./MissionEditor/modules/me_logbook.lua"]:1129: attempt to index local 'unitTarget' (a nil value) stack traceback: [C]: ? [string "./MissionEditor/modules/me_logbook.lua"]:1129: in function 'updateUserStatistics' [string "./MissionEditor/modules/me_debriefing.lua"]:361: in function 'updateStatistic' [string "./MissionEditor/modules/me_debriefing.lua"]:413: in function 'show' [string "./MissionEditor/MissionEditor.lua"]:655: in function 'openReturnScreen' [string "./MissionEditor/MissionEditor.lua"]:671: in function <[string "./MissionEditor/MissionEditor.lua"]:667>. @Flappie, this one's for you my friend. Switching my fix back on. Fly safe everyone ! BUG_endmission_train2.trk endmission_bug_train2.log debug_endmission_bug2_train.miz

Indeed, that seems to be the offending part in your debrief.log (a kill event by the player with a zero/empty/null targetMissionID) : [1955] = { ["initiatorMissionID"] = "393", ["initiator_coalition"] = 1, ["initiator_object_id"] = 16910080, ["initiator_unit_type"] = "Su-25T", ["initiator_ws_type1"] = 1, ["t"] = 3001.842, ["target"] = "coach a platform", ["targetMissionID"] = "0", ["target_coalition"] = 0, ["target_object_id"] = 6002022, ["target_unit_type"] = "coach a platform", ["target_ws_type1"] = 2, ["type"] = "kill", ["weapon"] = "", }, There used to be another issue with trains but it does not seem to be the case here. This is the standard vanilla bug, my fix should protect against it. BTW, no changes came with yesterday's openbeta, so you can keep using the file I posted previously. Interestingly enough, there is no trigger attached to that unit, nor is it in a trigger zone (I seem to see you were shooting the T-72s northwest of recon objective 1). I used to have a theory that it happened when objects were tied to a trigger (reason for my asking for a full mission file, not hidden/encrypted).

Let's see... I'm not home so I don't have my DCS installation at hand but just looking at the logs and the line where the nullref occurs (1128), it does look like my old friend. Grab my fix, it should solve your issue. 2023-01-14 20:32:22.131 ALERT LUACOMMON (Main): Error: GUI Error: [string "./MissionEditor/modules/me_logbook.lua"]:1128: attempt to index local 'unitTarget' (a nil value) GUI debug.traceback: stack traceback: [C]: ? [string "./MissionEditor/modules/me_logbook.lua"]:1128: in function 'updateUserStatistics' [string "./MissionEditor/modules/me_debriefing.lua"]:361: in function 'updateStatistic' [string "./MissionEditor/modules/me_debriefing.lua"]:385: in function 'endMission' [string "./MissionEditor/modules/me_debriefing.lua"]:351: in function 'onChange'

Well, I'll be ... Same here, I can't reproduce. Weird. It's the same openbeta version as before and I don't think that I changed a thing since then. I've just launched DCS to try and reproduce, nobug on a freshly started instance. It even does honor the "no afterburner" flag. I'll give it another go after I've done other things and flown around a bit, just in case there is some leftover stuff after a flight that gets the AI confused in the following missions. Thanks for looking ! BRB in a few hours. And ... there it is. It did take me several tries to get it "right". I think the bug appears in two conditions : 1. to miss the "restrict afterburner" at wp1 (or to ignore it, no idea) and 2. to fly in a certain trajectory compared to lead's speed (here I flew at 300kts) that causes oscillations when it rejoins at mach 1+ on max AB. The airbrakes don't brake fast enough, the wingman overshoots and goes for another round again at max AB. In some tests, it worked and the wingman was able to match the right position, in this one it didn't. That choice of trajectory may be highly dependent on initial conditions (speed, initial positions and trajectories of the two planes, time at which the 'go trail' order is sent, etc), hence the difficulty in reproducing it consistently in the track replay. Track and tacview attached. Good luck, Jim. (even featuring our old friend "2, bingo ... 2, ejecting" ) HTH, Buzz Bug_AB_trail_formation_take2.trk Tacview-20230112-210245-DCS-debug_ab_trail.zip.acmi

We could do with older Cold War bombers, like a B-47 or an Avro Vulcan. I'm not sure the B47 ever carried conventional bombs so it's probably out, but we all know the Vulcan did ! And ... we do have a South Atlantic map

No worries, friend. Simulations can be frustrating at times. I've only ever flown GA prop planes but there I hold the stick between thumb and forefinger and I have a precise control that I don't have on my desktop joystick. But here I can pause the game if I need to ! A trick I read somewhere in the forums is to "zoom out" as much as possible for take-off and landing. It sort of brings into view the peripheral vision that is lacking. Or VR, it helps too. There's lots of different techniques you can find in this thread or in videos, try them out and pick the one that works for you. Best luck ! Fly safe.

Helicopters are awfully fun to fly. Assuming you overcome the frustrations of the first 100hrs until you understand how to land them (I'm a slow learner). Practice, practice, practice and it will click. One piece of advice : the collective is very sensitive so when you're approaching hover (or landing) your adjustments will need to be almost imperceptible. Gaz has stability assists and a simpler flight model, that will help you, but in exchange it needs to be handled with a delicate touch ! Many people have posted the curves they use so do take inspiration from them and experiment what works best for you. GLHF !

It takes practice and a gentle touch to get it in the air, especially when heavily loaded, but it's a great module. It still has a few defects, or so I've heard purists say, but as far as I can tell they are really, *really*, minor and do not detract me from having fun. I too use a pedal brake axis for the brake lever, but only one because I find that binding *both* pedal brake axis to the same output tends to cause conflicts. I don't coordinate my feet well enough, I guess. I'm a terrible dancer, so that explains it, most likely. Then lots and lots of practice, accelerating very very gently, quite a bit of right rudder trim (more than written in the manual or the training missions), and now I have no problems flying it off the ground. So good luck @JG11Preusse , I hope it 'clicks' for you at some point because it is a great plane (both IRL and in DCS).

Just finished the campaign. What a truly epic masterpiece. Having finished The Great Show (book & campaign), I was reading Hugh Dundas' "Flying Start" in parallel and you managed to render the atmosphere very well, a great companion to the book. And I've started to really appreciate the Spit ! The outro cutscene was beautiful and poignant, even better than that of Paradise Lost, but I'm a sucker for Beethoven so that helps. Thanks once again for a lot of good time and looking forward to "V for Victory" ! (PS: oh, by the way, have you noticed they are building a Lancaster mod ? I'm just throwing this out there, you know, just in case someone needed a bit of time to assemble documentation for a campaign. -goes away whistling innocently- )

Whoa , that is an excellent status report ! Many thanks for sharing. And congrats on getting a slot amongs all those NASA speakers, fricking impressive. Really looking forward to seeing, hearing, and flying the A-7. (I'm already a happy customer of yours, elsewhere ) Keep up the good work and thanks again for sharing all those details that make us appreciate the immense amount of work required for a quality simulation. And happy 2023 to everyone.

I haven’t checked if they updated the file recently. If so then the fix will have been overwritten. Or it can be a new cause. I’ll look at that tonight when I’m home. The fix is trivial indeed, just move a null check up two lines. If you have encountered the issue despite having this fix then by all means post your dcs.log and debrief.log files here and I’ll try to understand where the new cause is from.

Indeed, you are correct, I see the same things. I'm a bit confused by that "reset the ADI to level", it looks a bit fishy to me as I don't see any reference to this in the litterature. Also, the ATT alignment mode is not working as I'd expect it. Maybe someone with more knowledge can explain, I am out of my depth. However, the IFA alignment mode works : punch in the magnetic heading from the backup compass and in a few seconds, your attitude is correct and the position after a minute or so. That matches my understanding of the flight manual. Some fun reading: SNU84-1, the specs for the INU that was fitted in the F16 and other contemporary planes, https://apps.dtic.mil/sti/pdfs/ADB165119.pdf (unclassified) It does mention that the unit should have its own battery to provide basic functionality in case the AC power is interrupted... Maybe that part of the spec was not followed, or our implementation is incorrect, who knows... Cheers, buddy ! Fly safe.

Plenty. And nuke depth charges, too. And artillery shells. Anything vaguely large enough to contain a nuke, they put a nuke on them at some point (see Davy Crockett nuclear recoilless rifle). In case you never heard of it, you may be interested in looking up Operation Crossroads and the effects of nukes on ships made with actual battle steel.

The source of attitude (EGI/INS) may have been degraded when the generators dropped offline and before the EPU kicked in. It is normal, as the main ADI is powered by the Emergency AC bus that is tied to the EPU, not by the battery. EPU should start working as soon as the main and standby generators fail. It may take a couple of seconds to spin up and may have disrupted the power to your INS, causing the calibration issue. The SAI is powered by the battery, so should work until battery power is depleted. When that happens, the unpowered gyros continue to provide usable attitude information for 9 minutes. So your EPU has started and is feeding power to the emergency bus so the ADI is working again. I think your switch to battery/main caused the INS to start a realignment (ATT first) and that recovered the proper data to feed the ADI. I guess that switching off the INS, leveling the plane, then switching it back on (to IFA or just to ATT) would have brought the same result.

The proper soundtrack for any Viper fan is provided by Dos Gringos (caution: often explicit lyrics).

Hey @Reflected, thanks for all the good content you produce, campaigns, skins, videos, etc. Speaking of which, one of the (many) things I love about your campaigns, is the cutscenes. Would you maybe one day in the future do a little video tutorial on how you do that ? And what can or cannot be done with the engine ? Happy holidays and, again, thanks for your work. Buzz

Thanks, Badger ! (and happy holidays)

Thanks for the correction !

Yes, "Abort refuel" will stop fuel transfer, you can move away and let another plane get a drink or just continue on your flight. Right-side basket is used when there is already a plane in the left-side one. So the first one to call "intent to refuel" will get left-side basket and the second one will get the right-side.

Observed: Squadron flies back to base, does a 180 over BH, and heads back towards the sea (in a Dover-ish direction, maybe an earlier waypoint ?). Expected: Squadron flies back to base, circles and lands at Biggin Hill. (Unsure if it's ED's AI or an issue in the mission. I don't think a track would be useful but I'll keep the Tacview log if needed) Cheers, Buzz (having a lot of fun regardless )

We don't know if it is the same root cause as the one I've spotted, which has been reported 18 months ago. It is quite rare and hard to reproduce reliably so "please provide a track" does not work, as it happens usually in large and complex missions with hours of flight, where tracks are unreliable. The unfortunate part is that the fix I provide is absolutely trivial and would make obvious sense to any dev actually looking at the code. But it is being held up by the cerberuses at the gate of "provide track".

@theoklahomaaviator Could be my old friend: (sorry, lots of messages and several threads, it's an old bug) Attach your dcs.log and debrief.log files and I'll take a look. Or grab my fix from that thread and fly the mission again and hope for the best. (Copy the fixed me_logbook.lua file in DCSWorld\MissionEditor\modules and overwrite the existing one. If the problem you encountered was the same as I did, that will fix it.)