Active Group Limiter Issues

  1. ‹ Older
  2. 9 years ago

    Friznit

    7 Aug 2015 Administrator
    Edited 9 years ago by Friznit

    Could simply be each individual player being counted as a profile and so you're hitting the group limiter. The group limiter is a very inelegant way of restricting the number of spawns, as you are discovering. If you want to keep the numbers manageable, it's better to spawn fewer in one place or spread them out more. Use TAOR sizes to manage the density of your Placements and give the AI Commander plenty of Logistics so he can keep the numbers up. The Group Limiter is like a 'hard deck' to prevent accidentally spawning in the whole world when a helicopter flies over and killing FPS. CQB units and Civs are not counted, so you can still get a lot of AI in one place if you're running those as well (though you can and should put CQB on Headless Client).

  3. Edited 9 years ago by SovietOnion

    @Savage, I'll look into those easy fixes. But yes, the main issue is that, when testing with say, 14 players, the mission runs as intended. But with our average server load of 50+, no ALiVE units spawn. Thing to note, is that the spawn limiter for that mission WAS at 50. And I think we had at least 48 players.

    @Friznit: Yeah, I've started understanding that and 'hand sculpting' AOs and unit counts. The problem was that that mission only had a handful of active AI units as wild cards, while most of the AI were CQB OR DAC patrols to make sure the combat was centralized.

    It has to be an issue with how groups are perceived (On our end, most likely) because raising the group limiter works. It would certainly explain away our issues, if each player is being considered a group. We do have it set so we can spawn into empty slots during a mission and "JIP" could that be it?

    I realize I'm being a big pain in the rear, but I can provide a copy of our framework if that would help.

  4. Hey guys. Just did some tests, and Friznit, you are on the money bud. I made a mission with a group limit of 3, and tested with one member. Only one enemy unit would spawn, regardless of if we were in the same group or not. But the CQB/Civilians spawned normally. So it's something to do with players getting counted as groups. I have a larger 45+ man test set for Sunday. Thank you very much for that suggestion.

  5. Friznit

    7 Aug 2015 Administrator

    Many player frameworks use individual, ungrouped playable units. Could this be your issue?

    Typically my gang only ever has 4 groups (3 sections plus HQ), so we only count as 4 groups as far as ALiVE is concerned with 35+ players online.

  6. No, we use 14 man squads split into lead/medic and 2 six man fire teams. Weapons teams, vehicle crews and platoon/company leadership are all generally 3 man teams as well. For my last ALIVE mission we had 14 player groups, but 49 players and our ALIVE group cap was 50. We might have run into an infantry patrol, but all the vehicle units that I had placed did not spawn.

    In the tests I mentioned above, a tester and I got the same results while slotting in different fire teams and slotting together. Still counted us as two groups, we think. So my current way around this is to take our average 55 player count, and just add 50 to it. Does that sound reasonable? I'd still be crafting missions more carefully to avoid large AI numbers in one spot.

  7. Just did the same test mission with 6 people all in the same group, limiter still at 3. No groups spawned. I think we have reasonable evidence that somehow it's counting each individual as a group. Simple solution for now is just to take our average count and add the crude group limiter number on top of that, while also sculpting missions more heavily.

  8. Thanks for figuring this out - I had no idea it counted player groups in the limiter. Most of our testing is done at low player counts so these kinds of things are hard to pick up.

  9. It seems to be counting each player individually as a group. Played a mission last night with 55 players and limiter set to 75 and had a good time with reasonable amounts of AI spawning. I appreciate all the help you guys have given here, and if you need anything just ask.

  10. 8 years ago

    Does ALiVE 1.0 still count player groups in the limiter?

  11. @looter Does ALiVE 1.0 still count player groups in the limiter?

    Good question and thanks for digging up this discussion (would not have known otherwise :) )

    If it still does what is the idea behind in doing so? AI does not need to control human player groups (nor individual players) at any point so why have include them in the limiter.

  12. Yeah without diving into the code, It sounds like a bug.

  13. I can't recall if this was fixed in a previous version but I've opened a ticket for it anyway.

  14. Edited 8 years ago by SpyderBlack723

    The limiter probably uses ALIVE_fnc_getNearProfiles which does not exclude players (at least I don't think so). If so, should be an easy fix by modifying that function to accept a no Player parameter

  15. This would definitely explain why my missions forces seem to get much weaker the more players there are. Glad I found this thread.

  16. Edited 8 years ago by HeroesandvillainsOS

    @looter This would definitely explain why my missions forces seem to get much weaker the more players there are. Glad I found this thread.

    How much weaker could it really be though? Virtual Force Pool's spawned by the game cluster in units, generally configured in 4-10 man squads depending on the unit pack you use (and obviously vehicles and aircraft and what not , depending on your settings).

    So let's say your side has 200 units. Let's estimate that at 500 men/tank/vehicle/etc. Even if you were playing with 50 people (equivalent to maybe 10 units), the left over Force Pool wouldn't be that much different, would it?

    I'm not discounting that I may be way off base on this though! Interesting discussion!

  17. So, the reason it counts players is because the limiter just does a quick count of all active profiles. Will need a bit of testing to make sure it doesn't cause any performance impact (looping through sometimes 1000's of profiles very frequently..) but otherwise easily dealt with.

 

or Sign Up to reply!