The LOG got over-written. I did try to recreate the crash but it ran without incident today. The system updated and shutdown after Windows Update last night, so this is a fresh restart and may have been a problem caused by Windows. To confirm, crashes did not happen on other replays, and not even all doobro's replays. These weird crashes only occurred on some of doobro's replays, even though he uses the same mod list in all his games. Restarting my computer wouldn't clear up the issue. I did have a Windows Update that stalled a few weeks back, and the issue appeared to show up after that update. I had Windows 11 run a verification, and it found and replaced some corrupted files. I am guessing the verification didn't fix everything, and the Windows Update last night may have corrected whatever was causing the unexplained crashes. At this point, i believe the crashes were caused by Windows.

Oh my god... I didn't realize I needed to copy the entire function CDRMV provided. I thought it was a built-in function like GetMapSize(). When it didn't work, I headed over to Github to look at more examples. Of course, they all used getPlayableArea(), which I copied. Then, it finally occurred to me CDRMV meant for me to copy the entire function. Except, I forgot I'd switch my syntax to getPlayableArea(). Only took an hour of troubleshooting to see it.

It's a faf bug caused by uef engi drones being near a structure when it completes or dies

@jip Hi Jip, read through the provided links a few times. Is there a function I use to get information on leafs? Or a mod that would be a good example of how to use these functions that I could look at to better understand how to use?

I was able to get FAF working again by just logging back in through the website. Don't know if the error is related to the observer bug.

Yeah 3.75 works easily but the tricky part is that if the offset is too much then units will target the underwater unit thinking it is on land, while its hitbox is covered by water (dbg c in console to see collision boxes). I think they start ignoring that unit after they hit the water too.

@nomander Thanks for the advice, but it doesn't work. I tried to play with VAC, set it up and nothing happened. The game goes fine only if you run it with the /notsound command written in the shortcut, that's only then you can play normally, although without sound. I don't understand how others run the game so well and stream it on modern platforms... I also stung the sup*** file from the sound folder, they say there may be a problem because of it.

@Jip Do you know if this issue has occurred in other games not using the AI Wave Survival mod, or is the issue exclusive AI Wave Survival mod game? Around the same time as the last FAF Patch, I increased the use of the following code that attaches orbs to a unit's bones. Now all units have a chance at having orbs attached to increase their DPS, depending on player strength. I've also noticed the freeze is most likely to occur during the endgame phase of the game, when many bosses are spawning and they will all have multiple orbs attached. Here is the code for attaching orbs to units. Note that the script first checks to make sure units have more than 1 bone before calling the function to attach the orbs. For Land Units: AttachedLandUnitSpawn = function(self, selfId, attachedUnitId, selfBoneId) local platOrient = self:GetOrientation() local location = self:GetPosition() local StellarCore = CreateUnit(attachedUnitId, self:GetArmy(), location[1], location[2], location[3], platOrient[1], platOrient[2], platOrient[3], platOrient[4], 'Land') WaitTicks(2) StellarCore:AttachTo(self, selfBoneId) StellarCore:SetCreator(self) self.Trash:Add(StellarCore) end For Air Units: AttachedAirUnitSpawn = function(self, selfId, attachedUnitId, selfBoneId) local platOrient = self:GetOrientation() local location = self:GetPosition() local StellarCore = CreateUnit(attachedUnitId, self:GetArmy(), location[1], location[2], location[3], platOrient[1], platOrient[2], platOrient[3], platOrient[4], 'Air') WaitTicks(2) StellarCore:AttachTo(self, selfBoneId) StellarCore:SetCreator(self) self.Trash:Add(StellarCore) end For Navy Units: AttachedNavyUnitSpawn = function(self, selfId, attachedUnitId, selfBoneId) local platOrient = self:GetOrientation() local location = self:GetPosition() local StellarCore = CreateUnit(attachedUnitId, self:GetArmy(), location[1], location[2], location[3], platOrient[1], platOrient[2], platOrient[3], platOrient[4], 'Naval') WaitTicks(2) StellarCore:AttachTo(self, selfBoneId) StellarCore:SetCreator(self) self.Trash:Add(StellarCore) end

@obituarypizza The first method: In your faf client /reply section, you can search for your own reply according to your account name. Second way: You can find the reply folder in the options at the top left corner of the FAF client. You can look in the folder according to the time when the reply was created Third method: Every time the game crashes, the client will pop up a window to record the game log. If you open this log file and search for "ID", you will find a text that reads "reply ID".

Looks like the Transport Bug has been squashed! Thank you very much! I am sure @Thracymachus14 will be pleased the unstoppable Airdrops are back.

@Rama Hey Rama, It is possible to get the Information of the Hidden Area outside the Map Uveso has Show me an Way how to do that. I primary use it for several Spawn Mechanics of callable Reinforcements and the Airstrikes which are included in my Commander Survival Kit. So maybe it could help you for what you want. But you will probably need to modify the Code for your purposes. GetPlayableArea: This Function checks for the existence of an playable rectangle (area) on the map. If one exists it returns the playable rectangle (area) If not it simple returns the size of the map GetNearestPlayablePoint This Function checks whether the given unit position is outside the playable rechtangle (area).. If the Unit is located outside the Map it returns a new generated Vector inside the Playable Area If Not it doesn't return anything. The included Check for ScenarioInfo.type == 'skirmish' is optional So If you want to use the Code for specific Game Modes only you can use the Check. For example: Campaign, Skirmish or anything else. If you have any additional Questions related to this. I still have Contact with Uveso on Discord to pass them on to him. GetPlayableArea = function() if ScenarioInfo.MapData.PlayableRect then return ScenarioInfo.MapData.PlayableRect end return {0, 0, ScenarioInfo.size[1], ScenarioInfo.size[2]} end, GetNearestPlayablePoint = function(self,position) local px, _, pz = unpack(position) if ScenarioInfo.type == 'skirmish' then local playableArea = self.GetPlayableArea() -- keep track whether the point is actually outside the map local isOutside = false if px < playableArea[1] then isOutside = true px = playableArea[1] + 1 elseif px > playableArea[3] then isOutside = true px = playableArea[3] - 1 end if pz < playableArea[2] then isOutside = true pz = playableArea[2] + 1 elseif pz > playableArea[4] then isOutside = true pz = playableArea[4] - 1 end -- if it really is outside the map then we allocate a new vector if isOutside then return { px, GetTerrainHeight(px, pz), pz } end end end, Best regards CDRMV

@rama but that's an assumption unless the log supports it.

It just means that defenses (tactical and/or torpedo) may behave suboptimal by either overkilling it (shooter cap > than its health, too many defenses trigger) or underkilling it (shooter cap < than its health, too few defenses trigger). It does not break the game or cause any further errors. The warnings exists as a reminder to what the optimal value is for in the blueprint.

@giebmasse Have hosted a few games with 2024.6.1, and looks like the issue has been cleared up.

I LOVE the CalculateTotalEnemyUnitsOfCategory! Wish I had known about it sooner. Very useful.

play with cheats. Spawn the boss in question, then look at the log. This will give you a starting point where the problem lies. I have tons of units attached to other units (buildings and mobile alike), they come and go based on which attachment or power-up was taken, or which enhancement built, so that part should not be an issue. But the log is your friend, use it.

The chance of a crash with Fullscreen when ALT+TAB is common to others as well. The game engine just hates it. Currently it looks like the crash can be more related to Fullscreen ALT+TAB or/and XACT3DApply. If a bot would go around hard freeze people's PC by crashing the entire game, there would be many more bells and whistle. Windows Event Log: Using the Start Menu: Click on the "Start" button or press the Windows key on your keyboard. Type "Event Viewer" and press Enter. Check Application and System events if any Supreme Commander related crashes are available. Alternate: Using the Run dialog: Press Win + R on your keyboard to open the Run dialog. Type "eventvwr.msc" and press Enter. Example for visualizing: [image: 1701092744373-a7092cc4-9c24-45fc-ac8e-add7eb33c3ad-image.png]

You need OnLayerChange and EnableShield/DisableShield in Unit.lua for when a unit is moving into/out of water. You'll also need to modify EnableShield to prevent them from being turned on when in the water.