KC Grimes 79 Posted April 3, 2018 In a mission I treat certain things differently, for sake of performance, depending on whether it is a true Player vs Player scenario. If it is PvP, I run things locally as it varies by side. If it is not true PvP (for instance, same mission but Player vs AI), I may run a few things on the server just because I can. The point is, when it is not true PvP, there is nothing to hide from anyone. But I would like to also support a JIP PvP mission, that starts with Player vs AI and at some point a player joins the other team and it becomes true PvP. I don't want to detect that JIP and flip my locality around because that seems messy to me, and would take quite some work. Currently, if I anticipate a mission becoming true PvP at any point, I just set a global variable of, say, "isPvP" to true and use that as a condition to determine my locality of certain scripts from the start. This works as intended and is fine, but... eh. What I would like is, on mission init, a statement runs to "detect PvP possibility" (read: playable units on two opposing factions), despite whether or not there are units on both sides in the game at mission start, without naming each unit in the editor. playableUnits only returns an array of playable units in-game, who exist as either a player or AI. It does not count "unused", playable units that are available in the unit selection screen. I want a way to detect that there are units available to be played on multiple factions, whether or not those units are actually in use. Any ideas? Thanks! My only thought right now is somehow detecting that in mission.sqm there are two different classes where values of variable "side" are not equal. But I do not know how to do that. Share this post Link to post Share on other sites
KC Grimes 79 Posted April 3, 2018 Lol. Is it as simple as using playableSlotsNumber? Share this post Link to post Share on other sites
gossamersolid 153 Posted April 3, 2018 https://community.bistudio.com/wiki/allPlayers _bluNums = west countSide allPlayers; That'd give you what you want, from what I can see. Share this post Link to post Share on other sites
KC Grimes 79 Posted April 3, 2018 1 hour ago, gossamersolid said: https://community.bistudio.com/wiki/allPlayers _bluNums = west countSide allPlayers; That'd give you what you want, from what I can see. Unfortunately it does not, because the unused playable slots are not returned as part of allPlayers. It turns out playableSlotsNumber is the command I was looking for. Here is a quick example of how it would accomplish what I am talking about. _playableSideArray = []; { if ((playableSlotsNumber _x) > 0) then { _playableSideArray pushBack _x; }; } forEach [WEST, EAST, RESISTANCE, CIVILIAN]; if ((count _playableSideArray) > 1) then { isPvP = true; } else { isPvP = false; }; Share this post Link to post Share on other sites
gossamersolid 153 Posted April 4, 2018 Maybe I'm misunderstanding your original post, but you said you merely want to check if it's a true PvP scenario. Using the exact command I provided, if more than one side returns > 1, it's PvP, is it not? Share this post Link to post Share on other sites
KC Grimes 79 Posted April 4, 2018 37 minutes ago, gossamersolid said: Maybe I'm misunderstanding your original post, but you said you merely want to check if it's a true PvP scenario. Using the exact command I provided, if more than one side returns > 1, it's PvP, is it not? I wanted to know if it could be a PvP scenario. If a mission with playable units on two sides is started with only 1 player in the game at the time, allPlayers will only return the one player on the one side, defining the mission as non-PvP and disregarding the fact that someone may JIP to the other side and make it true PvP (which would go undetected). The code I proposed detects that possibility of PvP. Share this post Link to post Share on other sites
Dedmen 2394 Posted April 4, 2018 all playable units https://community.bistudio.com/wiki/playableUnits occupied units are a player. meaning unoccupied are not a player https://community.bistudio.com/wiki/isPlayer Thus playableUnits select {!isPlayer _x} returns array of playable units that are unoccupied. Then you can use count on that array to get the number. 1 Share this post Link to post Share on other sites
KC Grimes 79 Posted April 4, 2018 2 minutes ago, Dedmen said: all playable units https://community.bistudio.com/wiki/playableUnits occupied units are a player. meaning unoccupied are not a player https://community.bistudio.com/wiki/isPlayer Thus playableUnits select {!isPlayer _x} returns array of playable units that are unoccupied. Then you can use count on that array to get the number. That is correct, but my intent was not to determine the number of AI, nor does this address the circumstance I mentioned in the OP where the AI may or may not be disabled (unused). playableSlotsNumber provides a number, but in my particular case I am using it qualitatively: the side is or is not playable. If at mission start I detect 2 "playable sides", the mission is defined as PvP. 1 Share this post Link to post Share on other sites
Dedmen 2394 Posted April 5, 2018 Yup. Completly overread that. You could force enable AI for empty slots. So that for each slot there is always a AI spawned. Or... On 3.4.2018 at 5:53 PM, KC Grimes said: My only thought right now is somehow detecting that in mission.sqm there are two different classes where values of variable "side" are not equal. But I do not know how to do that. Keep your mission.sqm binraized. Then in Description.ext do class mission { #include "mission.sqm" } Now you can read your mission.sqm from scripts using `missionConfigFile >> "mission" >> ...` Only need to find out what determines if a slot is blufor/opfor. I don't have the mission.sqm layout in my head and don't have one available right now. 1 Share this post Link to post Share on other sites
KC Grimes 79 Posted April 5, 2018 1 hour ago, Dedmen said: Yup. Completly overread that. You could force enable AI for empty slots. So that for each slot there is always a AI spawned. Or... Keep your mission.sqm binraized. Then in Description.ext do class mission { #include "mission.sqm" } Now you can read your mission.sqm from scripts using `missionConfigFile >> "mission" >> ...` Only to find out what determines if a slot is blufor/opfor. I don't have the mission.sqm layout in my head and don't have one available right now. That is awesome. Will have to give it a shot. Hoping it works without binarization, at least for testing. Share this post Link to post Share on other sites