I'll see if I can get someone to look into it

Closed

List of banned exploits (updated 05.05.2021)

@uveso said in Benchmarking time spent in beat functions, 'avatar update' is very expensive:

@crispweed

i am hooking the beatfunction destructive because i test the function for a gamepatch.
I plan to remove the beat throttling completely from the game. ( i can't see any speedimprovements here on my PC)

OK.

Got to say I did wonder how useful this throttling actually is.

I mean, with the way this is setup, it seems like, as more units get created, and the game slows down, the 'throttled' functions are actually going to be run in more game ticks..

You could do a destructive hook. Or you could your changes on a factional level. If you want to look, the SCTA, has its own version of Engi Mod.

If you have the newest nvidia driver then it should be fixed and you do not need the mod anymore.

@Eternal- cool stuff ❤

@arma473 yes, the tournament will have 1 commander and a common army for two players

I wonder if Jagged uploaded it. I can see the "author" in the vault but not the up loader.

In any case I found out the fixes from the error messages.
Whoever renamed the module "Jaggeds_Infrastructure_Pack 3.0"
did NOT modify the source lines in various LUA files with import and iconpath statements referring to the original Mod's path.
So multi-file edit - search for "Jaggeds_Infrastructure_Pack" replace with "Jaggeds_Infrastructure_Pack 3.0"

With this fix in place and testing - T2 storage now works as expected.

@Gladry Seems a bit of Miss Communication. what i would do is the following

UnitBlueprint { BlueprintId = "tbu0029", Merge = true, Weapon = { { Damage = 30, }, {}, }, } UnitBlueprint { BlueprintId = "gmrb402", Merge = true, Intel = { VisionRadius = 20, }, Weapon = { { Damage = 30, }, {}, }, }

Btw I have a cli tool that is able to parse the .scfareplay format. It can at least tell you the in game time for those replays, I don't know if they have the real time though (I kindof doubt it). I can send a windows binary if you want it.

$ fafreplay info 9001733.scfareplay processing replay: 9001733.scfareplay Supreme Commander v1.50.3701 Replay v1.9 The Pyramid 5v5 (00:01:38) The Pyramid is now available for 5v5 gameplay. Map edit by Artifax Team 1 civilian (AI) 5 Team 2 NeoTek (0) Aeon

The source code:
https://gitlab.com/Askaholic/faf-replay-parser

DELETED

thanks i wil ask there 🙂

I would call preventing Square Enix from taking down FAF for copyright infringement a pretty sane reason.

Is there a way to change Selection Deprioritizer with regards to bomber selection? I often run into the issue of wanting to select all bombers, but when I have some T1 bombers in the mix, none of the T3 bombers get selected. It would be great if it didn't interfere with the bomber selection. I really like this mod by the way, thanks for making it.

Thanks!!

@Jip said in Scouting overlay mod.:

@techmind_ the textures currently don't have a resolution to the power of 2 - I'd recommend doing that. E.g., make them 256x256 instead of 200x200. If I have a texture that is 4097 the load time is increased by 10 seconds, but if it is 4096 (a power of 2) then it costs almost no time .

I don't think these small sizes will affect it, but it can't hurt either.

Edit:
Removing all the prints / logs will make it significantly faster too.

predictTimes = math.floor(ScanTimes - 1) destination = currentCommand.position xDiff = destination[1] - ux zDiff = destination[3] - uz xDiff2 = xDiff * xDiff zDiff2 = zDiff * zDiff squareDiff = xDiff * xDiff + zDiff * zDiff xSpeed = math.sqrt(uBp.Physics.MaxSpeed * uBp.Physics.MaxSpeed / squareDiff * xDiff2) zSpeed = math.sqrt(uBp.Physics.MaxSpeed * uBp.Physics.MaxSpeed / squareDiff * zDiff2)

I understand you are trying to predict where the scouts are going but square roots are expensive and should be prevented if possible. You can compute the vector towards the target point - normalize it (that is 1 square root) and then multiply that with the time you expect it to move in that direction. That would be your predictedX/Y and reduce the number of square roots / unit by 1. Personally I'd even go for a version without a square root, but that is for another conversation 🙂 .

I'm not entirely sure but it appears you keep creating / removing labels. Did you test to see whether it is faster to keep them around and hide them / move them out of vision? Allocation is generally expensive and I think you're doing it a lot by creating / removing them.

if (r.path) then -- CREATING? -- if (not r.label) then -- last parameter in monitor pixels, need to change with zoom somehow =( r.label = reclaim.CreateScoutLabel(view.ReclaimGroup, r.path, squareSize) r.position = position r.labelIndex = labelIndex LabelPool[labelIndex] = r.label labelIndex = labelIndex + 1 end r.onScreen = reclaim.OnScreen(view, position) if r.onScreen then onScreenSquared[onScreenSquareIndex] = r onScreenSquareIndex = onScreenSquareIndex + 1 --tprint(r.position) else r.label:Hide() end labelsData[sX][sZ] = r else -- REMOVING? -- if (LabelPool[r.labelIndex]) then LabelPool[r.labelIndex]:Destroy() LabelPool[r.labelIndex] = nil end labelsData[sX][sZ].label = nil end

It only removes label if square was scouted, otherwise they stay created (well that was intention, but there might be some bugs). Remove shoudl trigger then where is no 'path' variable (meaning empty texture - so it forces label deletion)..