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.

@jip I have been looking through the navutils.lua at all the functions. Using the PathToWithThreatThreshold() could make for much more responsive waves.

Thank you for the information. That is very helpful!

Solved: Validated files via Steam. One was corrupted. Replacing file failed to fix the issue. Uninstalled and reinstalled the game. That appears to have solved the issue.

I believe I have found the problem. Looks like the function GetTerrainHeight(posX, posZ) was calling a value it didn't have access to, which must have been causing the infinite loop. Error wasn't getting written to the log in prior playthroughs, so hopefully that is it.

Can you have the T1 unit self-destruct at the end of the process? You probably want the T1 unit to leave no reclaim behind And it would be nice if you could transfer or copy orders from the T1 unit into the T2 unit