Have fun with this one, Boss. I have no idea how much the save will do without the assorted mods to go with it, but I can provide those if necessary.

 For some details on what happened, I had just destroyed a ship with a continuousBeam secondary weapon. Nothing I haven’t done plenty of times before, but now, for some reason, the game is randomly just locking up without even having the decency to crash properly.

 It’s happened to me a few times tonight, actually. Several times, I never even got out of the starting system; this time I was about three or so systems in.

assumedpseudonym 27 Feb 2022:

 I’ve done a bit of poking at this. I’ll add to the list as I find out more, but so far I have ruled out the following as being the cause of the crash:

» Using continuousBeam instead of beam or missile on the secondary weapons.
» Using continuousBeam instead of beam or missile on the virtual weapon used as the primary weapon.
» The <GetHUDName> event.
» Using secondaryWeapon="true" as opposed to linkedFire="whenInFireArc" in the <DeviceSlot>.

 As for why there’s a virtual weapon, that’s because linked fire weapons won’t fire if there’s no primary weapon to fire (which did not used to be the case several versions ago). Also, putting a weapon there gives me the opportunity to use <GetHUDName> to display what the two secondary weapons are.

 Also, a further data point that just occurred to me: The older version of the code in question did not use <DeviceSlots> at all, there was code in <OnGlobalUniverseCreated> and <OnGlobalPaneInit> that added linked fire and fire arcs to the weapon itself. This did not cause crashes when I tested prior to converting to the <DeviceSlot> method.

 Further, I will not be testing this any further. The last few tests have resulted in loss of ability to click anything with my mouse after the ensuing game crash, requiring a full reboot to fix.