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.

Just try tu build a turrets on walls, in original version everything works fine, but in FAF those turrets builds in walls instead on walls.

Factory drains 4 mass/sec, most of construction like factories, pgens drain 4 mass/s per 5 BP (1 engie). In regards of energy, building factories and pgens is expesive, Air factory drains a lot of e, Land factories drains only 20. In more Detail: You need 2 mexes + 1 pgen to run t1 factory. You need 1 mex + 4 pgens to run Air fac. You need 2 mex + 2 pgens to build factory per 5 BP (1 engie), 1.5 mex and 1.5 pgen to build a pgen per 5 BP ( 1 engie) Everything else is too complex for human brain to calculate in real time during the game and so is done by experience by playing hundreds of games.

solved. It was an issue with too many vertex groups assigned to too many bones. On paper, SupCom can handle 200 of them. In reality, the limit is around 70-ish, so anything over that number will cause the issue I am having.

Brutus was looking in to the total mayhem upload the other day

The blender plug inside are version specific hence the reason their is a 2.7 and 2 8 version of tge exporter you will have to wait until someone update it to 2.9 or live with 2.8