Promotions team

@arma473 This particular value is in the engine. I do not think the solution here is to change the behavior for all players.

Instead, if you just want to reclaim and share it with allies - just write/request a UI mod that you can toggle on/off to start sharing resources automatically (via gifting it programmatically) at a click of a button when your mass reached say 70% of storage. I do not think such a mod is against the rules that only mention auto clickers and reclaim macros. But you can always ask the moderators before trying to implement it.

You use more heap memory then you allocated, see also:

• debug: Session time: 00:00:25 Game time: 00:00:00 Heap: 288.0M / 254.7M

Do you have an Intel CPU? Specifically, one of the Intel CPUs of the series that are prone to the chip bug that is widely discussed online? If so, then that is your issue.

@miki1900 said in New update desyncr without error message:

Here:

#23313751

I destroy all his mexes, I rule the map, and he has double units than me.
Not descynr, just write up the software data?

I don't get it - you won the game:

Nothing strange happened. He was reclaiming the wrecks, that is why he was able to make units with no extractors. What is the problem exactly?

Whether the unit is considered underwater is a single point (the root bone, that usually has the name of the unit), where as each weapon determines on its own whether it is underwater. The former is used to determine intel and whether the target as a whole is legit to shoot at. See also the field FireTargetLayerCapsTable in a weapon blueprint. This is a fundamental flaw in how the game works, and sadly it shows up more the bigger the unit is.

From a script perspective, you could check and verify for experimental units that they're not idling near a shore. Occasionally polling every 5 to 10 seconds should suffice. That way users are at least not confronted with this behavior, but you can't prevent users from doing it themselves

Based on:

warning: Connection dialogue opening due to disconnection by players:
info: TheCrimsonKnight
debug: Session time: 00:09:52	Game time: 00:06:51	Heap: 320.0M / 283.8M
debug: Session time: 00:10:12	Game time: 00:07:09	Heap: 320.0M / 284.8M
debug: Session time: 00:10:22	Game time: 00:07:19	Heap: 320.0M / 285.1M
debug: Session time: 00:10:42	Game time: 00:07:38	Heap: 320.0M / 284.7M
debug: Moderator event for %USER%OfTheStars: Is changing focus army from 6 to -1 via ConExecute!
debug: Moderator event for %USER%OfTheStars: Switched focus army from 6 to -1!
warning: Error running HandleEvent script in CScriptObject at 148b6300: Invalid army -1. (Use a 1-based index)
         stack traceback:
         	[C]: in function `IsNeutral'
         	...rever\gamedata\lua.nx2\lua\ui\game\multifunction.lua(1200): in function <...rever\gamedata\lua.nx2\lua\ui\game\multifunction.lua:1187>
         	...rever\gamedata\lua.nx2\lua\ui\game\multifunction.lua(1400): in function `TeamColorHandler'
         	...rever\gamedata\lua.nx2\lua\ui\game\multifunction.lua(87): in function `OnClick'
         	...ata\faforever\gamedata\lua.nx2\lua\maui\checkbox.lua(143): in function <...ata\faforever\gamedata\lua.nx2\lua\maui\checkbox.lua:121>

You apparently switched focus army. You switched to the observer army. it indicates that cheats were likely enabled. I've not run the replay, but that's likely what happened.

@giebmasse said in A very rhythmic micro-stutter:

Don't think it should be that obvious in frametimes as for the OP?

That depends on your processor. If it is fast, then you barely notice it and they turn into micro-stutters. A lot of YouTube videos of the game show these stutters.

@zhanghm18 said in A very rhythmic micro-stutter:

But if faf continues to update and improve, perhaps more new mod creators will join in, creating more compatible ui mods, or improving old ui mods to make them compatible with new games.

I'm afraid that we can not base a strategy like this on hope. By alienating the current player base we're guaranteed to lose players and the contributors responsible are also guaranteed to receive quite a bit of flak for it which doesn't quite boost the morale of said contributors.

I've also experienced this and the stutter originates from the garbage collection. We reduced it quite a bit in 2022 and 2023, but we're no where complete. The game creates a lot of garbage that it doesn't have to. And by far majority of it originates from Lua.

It is fixable, but it requires to make various changes that are incompatible with a lot of (UI) mods. And once you go down that route you'll alienate a large chunk of the community.

@Rama I think a lot of the issues related to transports and simulation freezes that you reported are resolved now with game version 3812. If this is not the case, then do make a (new) report about it.

@Rama try again in a few minutes. I forgot to update the executable after merging in #79. This change should already be on the release branch (regular FAF game type)

@Rama I've made a small pull request that definitively fixes the previous issue that caused simulation freezes, see also #6398.

I'll update FAF Develop shortly. Best to encourage people to play on FAF Develop, see if the issue still occurs.