Scripts, but no mods, per se. If you're focusing on the enableDebugConsole error, don't. I have a description.ext that specifies that value, and I will randomly see the enableDebugConsole/ error during most sessions. It produces a dialog that must be dismissed, and logs to the report file. If you have any thoughts on that, that would be much appreciated, but I'm really just focusing on the simple script error in this report. In this session, the enableDebugConsole error did happen during the same 1 second interval in the report file as the script error, but I see the enableDebugConsole error once during most sessions, and not at the same time as this script error. It appears to be coincidental. If you like, i can report that separately.

The backpacks I_HMG_02_weapon_F and I_HMG_02_high_weapon_F both have their assembleInfo >> assembleTo as I_HMG_02_F, and both assemble to the low variant. I_HMG_02_high_weapon_F should assemble to I_HMG_02_high_F. I would consider this a fairly high priority as players cannot assemble the high variant from arsenal backpacks.

Ah. One change was made. I went from

And now it's working correctly. Same code, same game session, but the knee baseball now shows up where it should.

Also "on" after destruction, if that helps any.

You can control that behavior with allowCrewInImmobile

In the same vein, an unclosed quoted string will also produce no error. The specific case I ran into was a quoted string that was closed, but lacked a semicolon after it. No error was generated and the file's contents were not available at runtime.

Thanks for the pointer. It's an absurd exception, flying in the face of KK's prior comment, but after two years of constant development with this mess I've come to expect so little from SQF that such an exception seems to comfort me in some strange way.

Please create a folder with the suffix Altis and put the file in it. Thank you.

The mission file places two soldiers and a Zeus. You're locked into Zeus. Rise straight up about 10 meters for the best view. The first soldier will attempt to visit every building position of the House_F closest to it via waypointAttachObject and setWaypointHousePosition. The second soldier will attempt to visit every building position of the House_F closest to it via coordinate. The second is provided as a sanity check as well as for contrast.

The use case is not spamming the button. It is one of pressing the button at one time, doing other things, then coming back and pressing it again. If the user knows that the code is in error then he's not going to press the LOCAL EXEC button. But he did press it, so he was either confused, in doubt or simply forgot the state of the code. Regardless, if a user presses a button that says that it does something, it should simply do it. If the button can't perform the function that it advertises, then it should be disabled.

You've misunderstood the report

I thought I had been doing this in a dedicated server, but I guess not. I just tried it again on a dedicated and it works just fine - the Marid routes around the mines.

I can reliably reproduce this by going into Zeus, switching to the map view, dropping a NATO infantry squad and deleting members. Sometimes it survives one or two deletes, but it'll crash. It will not crash in the 3D view, and that's been our workaround. Unfortunately, it's a painful workaround on a big map like Altis.