I'm having this same issue with an I44 mission I am making.
The allied (Independent) force just completely stop receiving reinforcements within the first hour, Despite HQ's being placed along the beachheads where they spawn
I'm having this same issue with an I44 mission I am making.
The allied (Independent) force just completely stop receiving reinforcements within the first hour, Despite HQ's being placed along the beachheads where they spawn
So this is without server saving and exiting and loading the mission back up?
Yeah, though adding some extra cust. HQ objects seems to of helped.
Scratch that - The Virtual AI appears to be spawning in the units but then quickly deleting them after a certain amount of time, leaving there to eventually be only a handful of groups (atleast for my independent faction - don't notice the same for West).
The transportation units will be removed, they are not apart of the BCR's.. merely a way of getting them to battle.
@AUTigerGrad
*Side note* I'm still REALLY wishing there will be an enhancement to set up the ability to call reinforcements from multiple factions without having to have ALL factions available. (i.e. Player is RHS Socom but can call in troop reinforcements from RHS Socom AND Project Opfor Afghan Army for example).
Any chance of doing this via a "whitelist/blacklist factions" line in the Player Combat Logisitics?
I don't want players to be able to call in reinforcements from EVERY Blufor faction available but I also don't want to limit them when, for example, we are playing as US Special Forces working with the Afghan Army and, as such, are not going to call more Special Forces troops in, but instead will call in Afghan units for reinforcements.
This would be highly useful IMO.
I'd personally love to see it tap into the factions used in the obj modules/controlled by that side's OPCOM. So if I have ANA at civ objs and special forces at mil objs, no matter who I play as, I can call in ANA and special forces groups on the field.
Set up a ticket for it on GitHub. I'm sure it's a good enough idea to implement. :)
I think this is one already on the Git: https://github.com/ALiVEOS/ALiVE.OS/issues/127
Ah you're right :)
Whoever implements this gets the honor of being my best friend for life. So..you know... that's the level of awesomeness you get as a reward. Nuff said.
@SpyderBlack723 The transportation units will be removed, they are not apart of the BCR's.. merely a way of getting them to battle.
This is happening for a faction I set up as strictly infantry
This is happening for a faction I set up as strictly infantry
BCR's will always be transported by a vehicle to their objective of insertion.
So to piggyback on my original post....
My current campaign is on Lythium. I started out with over 70 Blufor Groups on the map.
I do a server save once a day to keep the server fresh and running top notch.
The mission has been on the server for almost 4 weeks now.
I currently have 9 Blufor Groups on the map. They aren't replenishing units lost, and the sessions are staying up for at least 24 hours so there is plenty of time for BCRs to come in. I have Logistics set to Constant as well so they should be coming along pretty constantly.
Because of this....The Opfor numbers are now riiiiiiiiiidiculous lol. They are spawning like bacteria.
Highhead is away right now, and is the dev assigned to fix this issue. It may be a bit.
Question, do you think there may be two issues here? Marceldev89 said persistence doesn't track initial starting profile numbers so we know that needs to be fixed. But are you feeling like something else is going on with reinforcements too?
I know on your Lythium mission you use a static logistics BCR module. So you would think you would always have a suitable place to BCR at assuming it hasn't been taken by the enemy. At least this is my guess.
I still think this could be explained by the ticket issue, depending on how many groups were "saved" during your very first server save and exit. If you were between resupplies it could have been low. And then it just dwindles down from there because this becomes your "new BCR cap" but I can't really say because I haven't looked at this myself.
Well, the cap shouldn't be an issue and here's why in my view.
If I start with 70 Blufor groups for example and let's say I start receiving casualties and losing groups...if I have it set to constant..I should be receiving reinforcements as soon as I lose 10% of my original force. When I first start the mission...this occurs. However..after at least one server save then restart.....no more reinforcements. For an assymetric campaign..the Occupying Blufor force will sustain casualties but they should be replenishing them pretty quickly. That's not occuring persistently. I think there is an issue with the BCRs working at all after at least one server save and exit.....as in they stop working completely. Which is why I'm seeing my occupying force go from 70 groups to 7 and why the Opfor insurgents are now numbering in the 600s of profiles now on the map.
Even if I do suffer casualties...the server is staying up for at least 24 hours..plenty of time for Blufor to replenish its ranks at a constant state before doing a server save. So at worst..I should be looking at 60-65 profiles now..instead of 7.
Now the reason I have noticed this now is because on previous campaigns, Players had the ability to call in reinforcements manually so, because of this, the lack of BCRs persistently wasn't as noticeable since players were bringing in profiles manually. But this mission...I only allowed ammo to be brought in and make the players play as themselves only. So..with no manual reinforcements/profiles being brought in..the issue is MUCH more noticeable.
I see. I'm not doubting you, just thinking out loud here.
Let's say you start with 70. My impressions with looking at this is even though you technically should be resupplying at 10% of 70 with a "Constant" setting (which I think is 63), I don't feel this is a hard set rule. My best guess is due to OPCOM cycles or something but I really have no clue. But for the sake of argument, let's just concede this isn't a hard rule of 10% and say it can get down as low as 50 which I think for this example is fair. Then let's say you're between BCR replacements and then save.
That means, when you load, according to Marceldev89, you will now only have 50 profiles. And can never again get higher. Now if you were to save again, when it was at like 30, you can see how just a few saves would completely deplete your side. It wouldn't take long.
All in all, it's very possible something else is up. I think the best thing to do would be to let an ALiVE CBA mission run on the server a bit, then save and load and see what happens. I think if you debug the obj modules, the rpt will have an exact count of profiles for each module.
So I can safely say that this is completely broken after a persistent save, at least in my testing.
All of my campaigns, after doing at least one server save then restart with the saved data,with military logistics set to persistent, do not work after at least one server save.
If someone else would like to test, please do.
I set Reinforcements to 10000000, saved my mission, restarted, attempted to call in reinforcements-said my current force pool was 0.
I tested on 3 separate occasions. Everytime they went to 0 after one server save.
WORKAROUND: If you set Military Logistics to NO on persistent, then it will allow for reinforcements upon restart as it does reset the reinforcement level. Not ideal..but it keeps your friendly forces from dwindling down to 0.
Sounds like 2 separate issues.
1. Original start state of mil placement groups is not persisted, therefore AI Comd calculates BCR requirements based on current session start state only, so BCR requests will eventually dwindle to zero. This is an oversight in the persistence code which we will fix.
2. New issue reported above: force pool not being persisted or resetting to 0 between sessions. This needs a repro on local and cloud saving and a separate ticket on github
Thanks @Friznit. I'll post a separate ticket for the force pool.