I also would like to thank You @highhead for sharing the script here!

When testing with your initial version I couldn't see any info on the side chat for some reason. Probably because of me :)
Thus I did test with @Reddog 's version and that was printing objective info on the systemchat so now I could somewhat understand what's going on there.

When I started this discussion I was looking a way to end (ALiVE) missions when a side has Occupied objectives that are needed to successfully complete one.

Apparently I got this far on my own: when I place the following code

if (_objectiveID == "OPCOM_7388496_objective_0") then {"end1" call BIS_fnc_endMissionServer;};

in highhead's script the mission successfully ends. But after that I haven't been able to come up with anything level-headed that would solve the following problems:

• What if one wanted a mission to end when multiple objectives are occupied? Would I need to create an array of objectives and if yes then how? (to this day I haven't digested how to "array" in Arma..)
• Naturally a mission should end when certain objectives have been occupied by a certain Side and not just any, so the code for this should include a side check. How should one approach this?

Additionally: I used the Reddog's version to display a single objective's objectiveID but how can one find objectiveID's of multiple objectives in a single mission? Is there a convenient way to dump them to clipboard or something the like with a code snippet?

@AUTigerGrad

I at least wouldn't mind if you could give a try if you could come up with an easy-to-use solution with what @SpyderBlack723 was kindly offering to me. Please see: Using objective capture status for triggering events
As far as I understand that by using the stuff Spyder was suggesting, there should be a possibility to "extract" the information when a zone has a certain state (Occupied, Captured, other) and then use that information to trigger other events.

@CaseyQ32 's solution shouldn't work, at least not for virtualized profiles. It does work when the AI profiles have been spawned in, but as we all know spawning in AI profiles needs a player (or some other magic trick) inside the AI profile's spawn radius.
Virtualized profiles won't be able to capture Sectors (that are provided by BIS via a module) until ALiVE team can come up with a solution. Here's a GitHub request just for that: https://github.com/ALiVEOS/ALiVE.OS/issues/251

Here's actually another discussion about making it possible for the ALiVE AI profiles to capture BIS Sector control modules: Let Virtual AI capture sector control

@eric963 Several of us have the same issue with larger missions.

Take a look at this

https://github.com/ALiVEOS/ALiVE.OS/issues/66

Hey, and thanks for the heads-up eric.

As per the GitHub report and that if I just understood the report correctly the issue could lie somewhere in the player persistence.

I did a few tests with the same mission I used to do the report here while concentrating on the aspects @incontinenetia had reported in that GitHub issue.

To test the reported aspects I disabled all the persistence options I could find in the five ALiVE modules I have placed in my mission. I especially made sure that every Player Persistence option in the module ALiVE Player Options (ALiVE_SYS_player_options) was set to NO.

Since there wasn't much else to do I copied the mission to my dedicated server and went on to test the mission start sequence.

From the test I conclude that out of the every fresh mission start (4 or 5) I made the issue I report here still persists even with all the possible persistence options disabled.

Here are the differences stored in server RPT when:

all the persistence options are left to their defaults

12:53:19  Mission id: b69b9fb663e8d32b8f8c9d2c0687e16f7b0eb38f
12:53:19 Game started.
12:53:19 ALiVE SYS_PLAYER - EXITING AS SERVER IS UNIT CONNECTING OR UID IS NIL
12:53:19 "Null playerUID sent to getPlayerByUIDOnConnect"
12:53:19 "Null playerUID sent to getPlayerByUIDOnConnect"
12:53:19 "Null playerUID sent to getPlayerByUIDOnConnect"
12:53:19 "Null playerUID sent to getPlayerByUIDOnConnect"
12:53:19 ALIVE AI Distributor exiting, no headless clients [] or not server false
12:53:19 Weather was forced to change
12:53:19 ALiVE [m_54|220] Module ALiVE_sys_weather INIT COMPLETE TIME:  12.703
12:53:19 Ragdoll - loading of ragdoll source "Soldier" started.
12:53:19 Ragdoll - loading of ragdoll source "Soldier" finished successfully.
12:53:21 "ALiVE - Starting Garbage Collector..."
12:53:25 ["SYS_PLAYER: PLAYER UNIT NOT FOUND IN PLAYABLEUNITS(Asmodeus)"]
12:53:29 ALiVE [m_47|190] Module ALiVE_mil_logistics INIT COMPLETE TIME:  24.339
12:53:29 ALiVE [m_48|190] Module ALiVE_mil_logistics INIT COMPLETE TIME:  24.256

in this case leaving the mission by going back to lobby and joining the mission again with the same or different soldier slot will produce these three additional lines

Unaccessible
12:54:08 ALiVE SYS_PLAYER - PLAYER UNIT FOUND IN PLAYABLEUNITS (lt_4)
12:54:08 DATA: Restoring player data for lt_4

all the persistence options are disabled

11:30:10  Mission id: a5b7fbf7e46715bb753d28d949a5031ea649343b
11:30:10 Game started.
11:30:10 ALiVE SYS_PLAYER - EXITING AS SERVER IS UNIT CONNECTING OR UID IS NIL
11:30:10 "Null playerUID sent to getPlayerByUIDOnConnect"
11:30:10 "Null playerUID sent to getPlayerByUIDOnConnect"
11:30:10 "Null playerUID sent to getPlayerByUIDOnConnect"
11:30:10 "Null playerUID sent to getPlayerByUIDOnConnect"
11:30:10 ALIVE AI Distributor exiting, no headless clients [] or not server false
11:30:10 Weather was forced to change
11:30:10 ALiVE [m_54|220] Module ALiVE_sys_weather INIT COMPLETE TIME:  11.163
11:30:10 Ragdoll - loading of ragdoll source "Soldier" started.
11:30:10 Ragdoll - loading of ragdoll source "Soldier" finished successfully.
11:30:12 "ALiVE - Starting Garbage Collector..."
11:30:20 ALiVE [m_47|190] Module ALiVE_mil_logistics INIT COMPLETE TIME:  22.962
11:30:20 ALiVE [m_48|190] Module ALiVE_mil_logistics INIT COMPLETE TIME:  21.81

in this case leaving the mission by going back to lobby and joining the mission again with the same or different soldier slot will produce these two additional lines

Unaccessible
11:31:53 ALIVE Profile Handler - Register Profile [player_0]

Don't ask me what Unaccessible appearing in both cases is supposed to be.

So concluding from the test I made I don't see how this is ALiVE's persistence problem.
To me it would seem more like ALIVE Profile Handler problem but to what module that is tied to or is that particular functionality somewhere "deeper" in the modifications framework?

The behavior seems to be consistent, always happens to the first player(s) that happen(s) to join the mission when it begins.

Yesterday we were two players testing the mission. We were both waiting in the screen where the map is displayed so we both joined the mission at the same time when I clicked continue. And both of our profiles got the ["SYS_PLAYER: PLAYER UNIT NOT FOUND IN PLAYABLEUNITS(playername)"] treatment.

These are the startup parameters for the server.

./arma3server -config=server.cfg -filePatching -mod=@CBA_A3\;@IFA3LITE\;@ALiVE\;@ASR_AI3\;@task_force_radio

I have to say I didn't even know what this autoinit was until I took a quick search just now :)

Here's a paste I went to grab for the sake of getting one: http://pastebin.com/hgpN7P0Y

@SpyderBlack723 As long as the black screen portion is the same size as the original tablet, it shouldn't be too hard to implement. Otherwise, all of the interface elements will have to be moved.

Create a ticket so it doesn't get lost.

I tried to make sure that the screen area would stay the same size. There might be needed some small adjustments but only small!

May I inquire now that the optional model displayed here was merged to master, is there any way to put the model to use already now or does it require additional framework or somesuch that comes hopefully someday soon? :)

Hey,

the first player that joins this one "huuuge" mission that is running on my dedicated server makes the server go ["SYS_PLAYER: PLAYER UNIT NOT FOUND IN PLAYABLEUNITS(playername)"] but then by going back to lobby and joining the mission using the same player slot makes the server go ALiVE SYS_PLAYER - PLAYER UNIT FOUND IN PLAYABLEUNITS (playername)

When a player is not found in PLAYABLEUNITS ALiVE doesn't recognize the player as one profile among other (ALiVE) profiles and this is a slight problem (at least for this particular mission).

I did a test with the latest @CBA and @ALiVE only just to confirm that when the server is running a "small" mission and thus not 'crumbling' under all the pressure of loading ALiVE assets the human player is found easily in the PLAYABLEUNITS

Would someone happen to have a suggestion how to circumvent the problem I'm describing here without having to resort to making smaller missions?

Copy that @HeroesandvillainsOS  thanks for the quick reply :)

Hey @highhead,

apparently @SpyderBlack723 already did, or how am I supposed to understand those GitHub tags?
See: https://github.com/ALiVEOS/ALiVE.OS/issues/250

I was about to come up with a topic about this very subject but managed to find this before creating a new one :)

So I too was hoping (and still am) that if the virtual profiles could somehow capture vanilla A3 sectors. Can this be achieved with ALiVE in any way, possibly in some future version perhaps?

It would seem an easy way to create missions that rely on capturing objectives for ending said missions with Arma 3's module Sector Control.. if just the virtual profiles would somehow signal those modules about their existence.
Or what is the hacky way to do this then? Is it possible to force a virtualized profile to spawn without human player being in the spawn radius? Though that's going to be a hit on server performance probably, at least in large-scale scenarios having to spawn profiles for such purpose.

Here's a nice and simple video from pickinthatbanjo about Arma 3's Sector Control module