fixed Issues related to EPLRS setCommand()

[Pizzicato]

Hey all,

Is there a way to set up an IDE without MOOSE? I used to use Eclipse LDT with MOOSE many years ago, but I'm not a fan of MOOSE these days (no shade thrown - just personal preference).

I've been using Notepad++ for my Lua scripting over the past few months which has been fine until now. Unfortunately, I've managed to introduce a bug somewhere in my scripts that causes DCS to silently crash with no error messages. I could really do with being able to set breakpoints and monitor callstacks, but I'm not sure how to get set up.

Can anyone point me in the right direction, please? (I'm not asking for a detailed walkthrough. A link to a relevant forum topic would be enough, but I never seem to be able to find what I'm looking for via the forum's search function).

[cfrag]

4 hours ago, Pizzicato said:

Can anyone point me in the right direction, please?

While I can't help with the IDE (I'm currently resigned to writing all DCS code in notepad++ and a rapidly receding hair line), I might help with another issue you are having:

4 hours ago, Pizzicato said:

I've managed to introduce a bug somewhere in my scripts that causes DCS to silently crash with no error messages.

This happens if a scrip (any script at any time) invokes 

env.setErrorMessageBoxEnabled(false)

Now, the really bad thing about this is that this env setting remains active, even after the mission ends, and you MUST RESTART DCS to have it reset (or, maybe, invoke env.setErrorMessageBoxEnabled(true) )

Now, to get rid if this,

- scan all the missions you are running for the string 

- scan all the mods and other scripts (including server scripts) for this invocation

Maybe do a clean install. That should get rid of the suppressed error. Just remember: *any* mission that you run may invoke that (I've once had a rotor ops mission do that, and it took me almost a day to find out why my debugging didn't debug, even though I knew that there was a bug), and from that point on forward all error messages are suppressed on all consecutive missions. You may be able to turn it back on with the 'true' invocation, if you manage to get that in after the 'false' invocation.

 

 

Edited June 22, 2024 by cfrag

[Pizzicato]

Thanks for the really detailed response and suggestions, @cfrag.

I'm not sure that the env.setErrorMessageBoxEnabled(false) issue applies in my case, though. I wasn't aware of that flag, so I'm certainly not setting that myself, and the only other script I'm running is MiST which also doesn't set it. I don't run any mods, so there's nothing else going on aside from vanilla DCS as far as I'm aware.

I really appreciate you taking the time to make the suggestion, though. 

 

[cfrag]

9 minutes ago, Pizzicato said:

I wasn't aware of that flag, so I'm certainly not setting that myself, and the only other script I'm running is MiST which also doesn't set it.

When I was hit by that I ran a mission that (unbeknownst to me) set the flag and I didn't restart DCS. You may get around this by explicitly setting this flag in you mission at start to true, and maybe you'll then see the error dialog again. Might be worth a shot.  

[Pizzicato]

Yep. I'll give it a go now.

[Pizzicato]

So that flag didn't change anything unfortunately, but I've managed to pinpoint the function that's triggering the silent crash. It simply applies a bunch of default behaviours to my CAP and GCI groups. Frustratingly, though, the crash is completely random:

• Sometimes it'll happen, sometimes it won't.
• Sometimes it's on one group, sometimes another.
• Sometimes it'll happen when setting one particular option, sometimes a different one.

I'm doing it at Mission Start, so none of the groups have been destroyed. I'm also checking that they exist, so they've all (presumably) been spawned.

It's deeply infuriating, but I'll figure it out... eventually.

Maybe..

--- SET BEHAVIOURS
-- Set the behaviours for the Group
-- @param self
function AW.GroupGCICAP:SetBehaviours()

	if Group.isExist( self:GetGroupDCS()) then
		
		local controller = self:GetGroupDCS():getController()
		
		AW.Utils.DBG( "TEMP", "Processing behaviours for " .. self:GetName() )
		
		controller:setOption( AI.Option.Air.id.REACTION_ON_THREAT, AI.Option.Air.val.REACTION_ON_THREAT.EVADE_FIRE )
		controller:setOption( AI.Option.Air.id.RADAR_USING, AI.Option.Air.val.RADAR_USING.FOR_SEARCH_IF_REQUIRED )
		controller:setOption( AI.Option.Air.id.FLARE_USING, AI.Option.Air.val.FLARE_USING.WHEN_FLYING_NEAR_ENEMIES )
		controller:setOption( AI.Option.Air.id.MISSILE_ATTACK, AI.Option.Air.val.MISSILE_ATTACK.RANDOM_RANGE )
		controller:setOption( AI.Option.Air.id.JETT_TANKS_IF_EMPTY, true )
		controller:setOption( AI.Option.Air.id.PROHIBIT_AG, true )
		controller:setOption( AI.Option.Air.id.PROHIBIT_WP_PASS_REPORT, true )
		controller:setOption( AI.Option.Air.id.OPTION_RADIO_USAGE_CONTACT, false )
		controller:setOption( AI.Option.Air.id.RTB_ON_BINGO, true )
		controller:setOption( AI.Option.Air.id.RTB_ON_OUT_OF_AMMO, 264241152 )	-- See https://wiki.hoggitworld.com/view/DCS_enum_weapon_flag
		controller:setCommand( { id = 'EPLRS', params = { value = true, } } )
		
		if math.random(1, 100) > 50 then controller:setOption( AI.Option.Air.id.ECM_USING, AI.Option.Air.val.ECM_USING.USE_IF_ONLY_LOCK_BY_RADAR )
		else controller:setOption( AI.Option.Air.id.ECM_USING, AI.Option.Air.val.ECM_USING.USE_IF_DETECTED_LOCK_BY_RADAR ) 
		end
		
		AW.Utils.DBG("TEMP", "Finished processing.")

	else
		AW.Utils.DBG( "WARN", "Invalid or missing DCS Group. Is it dead? [AW.GroupGCICAP.SetBehaviours( tbl )]" )
	end

end

 

[cfrag]

21 minutes ago, Pizzicato said:

Frustratingly, though, the crash is completely random:

• Sometimes it'll happen, sometimes it won't.
• Sometimes it's on one group, sometimes another.
• Sometimes it'll happen when setting one particular option, sometimes a different one.

I'm doing it at Mission Start, so none of the groups have been destroyed. [emphasis CFrag]

Uh... wait. You are getting/setting controllers at mission start? Here's something I remember from way back when I tried something on newly spawned groups (like, for example, groups that spawn at mission start) that was in the NOTES section of coalition.addGroup()

You MUST have a built in delay before accessing the group or units controllers and issuing tasks, commands or options of the group spawned. Otherwise the you are likely to cause a game crash.

Can you try a timer.scheduleTask() on those behaviors and see if those crashes go away?

 

 

[TEMPEST.114]

Visual Studio Code + Lua extensions

[AKA_Clutter]

I setup Eclipse IDE with MOOSE a few years back.

 

I have used this to develop several different scripts and haven't used MOOSE yet.  For the most part I don't recall MOOSE being intrusive, or being an issue.

 

I have used MIST in several of  these scripts and there weren't any conflicts or issues in those cases as well.

 

I've also used Visual Studio code with the lua extensions as suggested by tempest.114 above as well as notepad++.

Edited June 22, 2024 by AKA_Clutter

[Pizzicato]

1 hour ago, cfrag said:

Uh... wait. You are getting/setting controllers at mission start? Here's something I remember from way back when I tried something on newly spawned groups (like, for example, groups that spawn at mission start) that was in the NOTES section of coalition.addGroup()

You MUST have a built in delay before accessing the group or units controllers and issuing tasks, commands or options of the group spawned. Otherwise the you are likely to cause a game crash.

Can you try a timer.scheduleTask() on those behaviors and see if those crashes go away?

 

 

Yeah, I had that same thought. I already had a 3 second delay in there, but I pushed it to 15 and I’m still seeing the crash. I totally agree that this still seems like the most likely cause, though. I’ll go back and triple-check that this really isn’t the issue  

I’m going this try putting a one second delay before processing each group in case it’s choking on doing too much in the same frame. Doesn’t seem very likely,  but I guess it’s one more thing to try to rule out. 

I did check my assumption about it before this first function. I commented out all the code and was able to run the mission ten times in a row without trouble. Most bewildering. 

Edited June 22, 2024 by Pizzicato

[Pizzicato]

After an embarrassing and excruciating 4+  hour session of experimentation, debugging and re-writing chunks of script I eventually discovered the root cause. It turns out that it was down to calling: 

controller:setCommand( { id = 'EPLRS', params = { value = true, } } )

My initial thought was that it might have been a result of calling it on a Flanker (which obviously doesn't have EPLRS). That turned out to be wrong, though, as calling it on an already airborne Flanker worked without incident.

In the end, it turns out that it only causes issues with Uncontrolled aircraft Groups, not Late Activated ones. Regardless of whether I set the flag before issuing the Start command or 5 minutes afterwards (yes, I checked), it invariably resulted in a silent crash to the desktop. 

I eventually removed that line from my script, and I've been crash free for the last 10+ test runs.

Edited June 23, 2024 by Pizzicato

[cfrag]

On 6/23/2024 at 6:27 AM, Pizzicato said:

In the end, it turns out that it only causes issues with Uncontrolled aircraft Groups, not Late Activated ones. Regardless of whether I set the flag before issuing the Start command or 5 minutes afterwards (yes, I checked), it invariably resulted in a silent crash to the desktop. 

I believe that is incredibly valuable information. No matter what, setting an option through a legal API invocation should never result in a silent CTD. Maybe @Flappie may find this something worthwhile to look at.

[Flappie]

@Pizzicato Can you please attach an example .miz containing the script that causes the crash?

[Pizzicato]

@Flappie Not easily, unfortunately. The script is one of a self-made library of about 15 that I'm loading dynamically from my hard drive. I'd need to look into restructuring the mission so that they all get loaded via Do Script File. Should be doable though. I'll take a look later today and report back.

[Pizzicato]

@Flappie 

Here you go. I created a new simple mission that demonstrates the issue without requiring my scripts. It just calls setCommand( { id = 'EPLRS', params = { value = true, } } ) and a few other setOption calls on a bunch of parked Flankers.

It turns out that the likelihood of the crash increases with the number of aircraft that are being processed. I filled up Krasnodar with Su-27s and it crashes pretty much every time. You might need to run it a couple of times, but probably not - it's close to 100% reproducible now. 

Reduce it down to 4 or 5 aircraft, though, and it barely happens at all. Hope that helps. Let me know if you need anything else.

EPLRS_Crash.miz

Edited June 24, 2024 by Pizzicato

[Flappie]

Thank you! Issue reproduced and reported.

[Pizzicato]

Great. Thanks @Flappie

[Pizzicato]

On 6/24/2024 at 3:00 PM, Flappie said:

Thank you! Issue reproduced and reported.

@Flappie So... I just spent four hours trying to figure out the cause of DCS silently crashing to desktop during a mission I'm building, and it turns out that it's this exact same issue from nearly a year ago (i.e. too many EPLRS setCommand calls in too short a space of time). Very frustrating waste of an evening.

Can you check the bug database and see if the issue is still there, please? 11 months to address a 100% reproducible Class A crash bug (albeit something of an edge-case) is a little disappointing. 

[Flappie]

Hi @Pizzicato. A fix was issued in July 2024. Here's the short version:

• Devs said one shouldn't call `controller:setCommand` function with Uncontrolled aircraft groups.
• They then implemented a fix to prevent the crash. I tested it and could not reproduce the crash anymore (with you mission above). I realize I forgot to tag this thread as "fixed".

Do you still use `controller:setCommand` function with Uncontrolled aircraft groups?

[Pizzicato]

8 hours ago, Flappie said:

Do you still use `controller:setCommand` function with Uncontrolled aircraft groups?

Hmm... yeah, that's possible. I'm not at my home PC right now, but I'll check my scripts tonight and see if that's what's going on. I'll report back and let you know if that's what was going on.

Thanks for the clarification and the quick response, @Flappie. Much appreciated.

[Pizzicato]

@Flappie I checked my scripts last night and it turns out that the issue was that I was calling the EPLRS setCommand() immediately after the Start setCommand. I used timer.scheduleFunction() to introduce a 2 second delay and everything started working fine. Thanks for pointing me in the right direction.

On the flip side, I was easily able to replicate the silent-crash-back-to-desktop by calling the EPLRS setCommand on Uncontrolled groups. It's not a major issue given that I now have a workaround, but it still seems that the engine should be able to cope with this issue a little more gracefully (and ideally with some feedback to the scripter).

Regardless, thanks again for the quick reply and helping me figure out what was going on.

[Pizzicato]

Hey @Flappie

Unfortunately, it appears that the EPLRS bug is very much still alive and kicking unless the engineer you mentioned meant "Never apply EPLRS to an uncontrolled aircraft even if it was STARTED several seconds earlier."

I put together a simple stress test which demonstrates that the crash is reproducible:

• 50 uncontrolled Hornets on the Caucasus map.
• One Hornet receives the Start command
• 3 seconds later, the same Hornet receives the EPLRS command
• This sequence repeats every 6 seconds.

There is onscreen and debug log feedback to mark the progression of the test.

I ran this test three times:

• On the first run it crashed after 4 aircraft had been processed.
• On the second run it crashed after 3 aircraft had been processed.
• On the third run it crashed after 14 aircraft had been processed.

This really needs fixing as it makes setCommand() EPLRS a really nasty and unpredictable scripting-landmine.

EPLRS Stress Test.miz

Edited May 16 by Pizzicato
Adding .miz

[Pizzicato]

PS - Do you have the admin rights to give this thread a more relevant name? It's not really about MOOSE and IDEs now, really.

[Flappie]

1 hour ago, Pizzicato said:

PS - Do you have the admin rights to give this thread a more relevant name? It's not really about MOOSE and IDEs now, really.

Done. I'll check your mission, thank you.

[Pizzicato]

Thanks Flappie. Much appreciated.