An "Unlimited Unit Cap" Option
-
Well I just don't think 1500 unit cap is much of a barrier, especially if you have it shared with allies on death. I don't think I've ever hit unit cap in those situations; only where unit cap is not shared, or it is only 1k cap.
But one slight problem is if someone has to go afk and walks their acu to a safe spot and just transfers all their units, thinking they might be able to return in 5-10 minutes, but give everything over to avoid inconveniencing everyone. In that case, a solution would be to have 1500 unit cap per player, available to the whole team.But besides that tiny change which impacts maybe 1% or less of my games, I don't think I'd want a higher unit cap. The game just isn't optimized well enough, so pathfinding issues really crop up well before we would be hitting 6k units for one team in a 4v4. It frequently happens that if you give new orders to units they just lose their previous orders and stop moving, necessitating a shift-g to try to get them to move. I have seen it many times before on setons. I'd rather play games that have at least some incentive to avoid that cancerous, unenjoyable -4 sim speed pain for everyone involved.
One thing I'm not sure about is how buildings affect lag. Maybe we could have buildings not impact the unit cap? If that would be the case maybe just a 1k UNIT cap would be plenty.
-
ALL units impact performance - buildings, units, wrecks.
-
@sprouto Ok thank you for that. Is there any difference between units and buildings though? It would make sense to me that 500 zthuees floating along are a bigger issue than 500 pgens or mass fabs or whatever. E.g. the 500v500 asf fight that drops sim speeds to -9 clearly is more demanding than units that just sit there, so I'd guess buildings that never move are similarly less demanding to process. If that's the case we could consider adjusting it somewhat, but if not then leave things as is.
-
There is some difference - mostly related to the number of weapons, or the amount and type of intel generated, throw in the additional loads of any animations or blinking lights (which of themselves aren't a problem - but the SIM is responsible for tracking and initiating all those things) and movement, you get a picture of why this is not just a simple subject. From a simple memory standpoint - the overhead of a structure and a mobile unit are fairly similar. The impact on performance lies primarily there. Adjusting the unit cap impact of them won't alter the performance curve in any way - it will simply move the unit cap goalpost around a bit.
Wrecks are a little bit less of an issue, by definition they are very simple - but even so - the number of wrecks, and to a lesser degree, props - can add significantly to the processing overhead.
-
@corvathranoob said in An "Unlimited Unit Cap" Option:
@sprouto Ok thank you for that. Is there any difference between units and buildings though? It would make sense to me that 500 zthuees floating along are a bigger issue than 500 pgens or mass fabs or whatever. E.g. the 500v500 asf fight that drops sim speeds to -9 clearly is more demanding than units that just sit there, so I'd guess buildings that never move are similarly less demanding to process. If that's the case we could consider adjusting it somewhat, but if not then leave things as is.
To give you another perspective: collision detection between projectiles / units (including buildings). Algorithms can 'cut out' units that are far away quite easily, but if they're all stacked on one another it quickly turns into O(n^2), which is expensive for real time applications. That is why ASF fights can be so demanding, but having various fights in general across the map is fine.
-
While the above discussion about performance is an important one, I think it would be beneficial to stay on topic, namely that the unit cap does nothing to improve performance!
I have never once thought "Oh man, I'm close to the unit cap, better stop building units". If I hit the unit cap in team games I just give my ASFs, SAMS, Frigats, Zuthees, or whatever to my teammate, so the total number of units did not even decrease. The only thing the unit cap managed to do was make my game worse!
As do agree with CorvathraNoob that the unit cap impacts about 1% of games, but whenever it does, it is purely negatively.
Why do we accept 1% of our games to be notably worse, if adding a single line of code could change them for the better?
-
The only time I've hit unit cap in real games was when I had at least 100 obsolete engis or 500 asf which is also kind of never useful (just make 400 and 20flak instead)
-
@cheeseberry said in An "Unlimited Unit Cap" Option:
Why do we accept 1% of our games to be notably worse, if adding a single line of code could change them for the better?
Who told you it's just a single line ???
If you want to change the unitcap you need to modify:\lua\ScenarioFramework.lua
function GiveUnitToArmy()
(army brains ignoring armycap on transfering units and re-enable it after doing it.)\lua\SimUtils.lua
function UpdateUnitCap()
(logic for ShareUnitCap option)\lua\AI\aiarchetype-managerloader.lua
function UnitCapWatchThread()
(This thread is watching the unitcap for GPG AI and need to be rewritten for unlimited units)
function UnitCapWatchThreadSorian()
(This thread is watching the unitcap for Sorian AI and need to be rewritten for unlimited units)
function GetAIUnderUnitCap()
(AI helper function for UnitCapWatchThread & UnitCapWatchThreadSorian)\lua\editor\UnitCountBuildConditions.lua
function UnitCapCheckGreater()
(Need a new function that does not need a UnitCap to calculate % of possible units)
function UnitCapCheckLess()
(Need a new function that does not need a UnitCap to calculate % of possible units)\lua\sim\ScenarioUtilities.lua
function CreateArmyUnit()
function CreateArmySubGroup()
function SpawnPlatoon()
function SpawnTableOfPlatoons()
function CreateArmyGroup()
function CreateArmyTree()
function CreateArmyGroupAsPlatoon()
(AI Scenarios need to know the unitcap and/or switching it on and off.)\lua\sim\Unit.lua
function OnCaptured
(function need a patch for CampaignMode and captorBrain.IgnoreArmyCaps)\units\XEB2402\XEB2402_Script.lua (Experimental Satellite System)
function OnCaptured
(function need a patch for CampaignMode and captorBrain.IgnoreArmyCaps) -
@uveso Well, it certainly looks like it would be much more complicated to change all of those things...but then the intelligent way to create an ESSENTIALLY unlimited unit cap would be changing the 1500 option to 15000...
-
@uveso It seems to me that you are assuming that I want to set the unit cap to literally infinity.
As mentioned in my first post, I don't think a literally infinite unit cap is even possible. Finite hardware and all that.Are you saying that there is not just some global variable or equivalent that one can change from 1500 to e.g. 15000 as Corva suggested?
-
Yes that's exactly the point. (thats why i also pointed to all related functions)
If you took a look at those functions you will see that an unitcap of 'infinite ' or 15000 will break some AI functions.There are tactical decisions based on unit count that can't work with extreme numbers like 15000+.
Nothing that can't be fixed, but its not a single line of change.
Its more like 1-2 hour work of coding and 1-2 Days of testing and rebalancing the AI. -
I don't think he's concerned about AI at all, he's just talking about pvp games.
-
I have no opinion on this.
I am only providing information about what is needed to change unitcap in SupCom.And in case someone decides to implement this, then all should have in mind this change can take a while.
Its not only the GPG and Sorian AI that need to be patched. Also my and all other AI mods need a fix then.As i said before, its not just a single line to change.
(This shouldn't discourage anyone from asking, it's just a fact.) -
Just saw a game with a mod with raised unit cap x4
-
One good thing about the unit cap is that you can't spam t1 only you need to upgrade to t2, t3, experimentals and other structures etc.
-
the mod you mentioned is not changing the game functions.
The mod is patching all units in blueprint.lua like:
Blueprint.General.CapCost = Blueprint.General.CapCost * 0.25Its changing the need of cap for a unit.
This is the worst way to do it.
Absolutely incompatible with AI functions and every unit count function in the game.
(the cap is only visible for the c-engine not for LUA code) -
@uveso
Thanks a lot for explaining the possible technical hurdles, I was in fact not aware of their existence!FemtoZetta is of course right that I myself only care about PVP games, but, should a significantly larger unit cap be introduced and fully integrated into the client, it should work with all of FAFs features. This does of course include AI.
Do you think the technical hurdles are managable/reasonable? How would you recommend testing the change?
Regardless, I would gladly volunteer to help with the implementation and it's tests wherever I can
-
Yes its technical possible. And we have also developer who are able to do it. (i guess this was the question)
I can't say if its reasonable. Only you can.
Do you want this so badly that it is okay with you that I have to work 2 days for it?
Not to mention the other 7 AI developer who also need to check their AIs.
Also Nomads and SCTA (Total Annihilation) are based on the FAF codebase and need some tests.
(Nomads should be ok, but SCTA is using custom AI functions)
I know this sounds a bit exaggerate, but i already checked some functions and it is indeed needed.
(I say it again, this is not meant to discourage you, just a fact)Testing itself is the easy part. My AI has an option for endless test games.
So you only need to start a AI vs AI game and watch the log window.The tricky part is patching some functions.
One function is watching the unitcap.
When unit cap is rached the AI knows it has reached the maximum amount of units.
This means we have equal or more units that the enemy.
Time to attack.
But wihtout a unitcap how can we decide that we have maximum units reached,
and more important that we have more or equal units than the enemy ?
(we can't just get the data from LUA without using cheat methods and our AIs don't use those methods)This does not mean we can't do it, but we need some time to test new functions and conditions.
-
Personally, I'd totally spend a weekend working on this.
It might not improve FAF by a huge amount, but compared to the ridiculous number of man hours already put into this project, it also doesn't take a huge amount of time.Sadly though, I can't implement and test everything on my own. While I am a semi-competent programmer, I have no clue about the inner workings of FAF, or any of the AIs.
Therefore the question is: Who's help do I need and how do I get their buy-in? (Seems like talking to you is a good start)
-
Well, you could join us on our AI-Development Discord:
https://discord.gg/ChRfhB3There you can talk to all AI devs.
