@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)..

can't wait for the AI to realize that the game is perfectly balanced when every unit has 0 dps

OK thanks.

In the lobby, it would show their names. And the client shows the names of people in a lobby even if you are out of the lobby. To achieve this for a tournament, the admins would probably need to create new accounts to be used by tournament players. E.g. they could tell Tagada he needs to log out of his main account and log in to an account called "TournamentPlayerOne", and give him the password to that, and do that for 16 different players who all would need to log in that way. Also the admins would have to find a way to hide the country flags in the client for those accounts. (Probably the easiest way would be to just shut down national flags for everyone for the day of the tournament--this is the way I think, lazy AF. That's easier than re-writing the code to specifically not show flags for just the 16 tournament accounts, although that also would be a good option, especially because the accounts could be re-used for later tournaments.) The challonge would have to be set up according to their fake names, not the real ones, or we could figure out who they are just by looking at the brackets. Probably the admins would have to assign each player a color so we wouldn't guess them by their color. We wouldn't be able to tell them by their chat messages because they could intentionally do chat messages in the style of another Playerino. Then it would be up to the TD to decide when each player's identity is revealed. (When they are eliminated? Or wait until the end of the tournament?) Players would probably have to be locked out of their main accounts for the day of the tournament to prevent a defeated player from logging back in under their real account during the tournament, which would give it away. Even if you created a parallel "game mode" like Galactic War, Aeolus would still show who was present in chat, so it would provide clues about people's identities. I think "tournament accounts" are the only way to make this work.

Yes I uploaded it to fix that very bug, sorry should have mentioned it

For anybody who might read this in the future: When enabling ecomanager and the new version of the SSB simultaneously, the SSB score board takes precedence and hence the broken score board of ecomanager get's overwritten. Regarding the "selection sound" issue of the ecomanger that I described above, the solution is to explicitly enable the "common mod tools" mod as a UI mod. Just having it installed is enough to have the mod's functionality work, but to fix the sound issue, you need to enable it as well.