killick

Hi @jandrews This is fairly random snipped of code I use - _this select 0 is the string name of the area marker. Marker can be map placed or created using Zen_SpawnMarker while {!(_ok)} do { switch (tolower(_this select 1)) do { case "boat" : { _randomPos = [_this select 0,0,[],2] call Zen_FindGroundPosition; // must be water _return = _randomPos findEmptyPosition [0,10,"O_Boat_Armed_01_hmg_F"]; if ((count _return) > 0) then { _nObject = nearestObject [_return, "AllVehicles"]; if !(isNull _nObject) then {_nObjectDist = _nObject distance2d _return} else {_nObjectDist = 50;}; // if !(isNull _nObject) then {systemchat format ["Type of %1 at %2",typeof _nObject,_nObjectDist]}; // DEBUG if (_nObjectDist > 15) then {_ok = _return call DSC_isOutdoorsWet}; }; }; case "inf" : { _randomPos = [_this select 0] call Zen_FindGroundPosition; // any land position _return = _randomPos findEmptyPosition [0,8,"Box_East_AmmoVeh_F"]; if ((count _return) > 0) then { _ok = _return call DSC_isOutdoorsDry}; }; case "static" : { _randomPos = [_this select 0,0,[],1,[3,15]] call Zen_FindGroundPosition; // off roads by 3m min (15-12) _return = _randomPos findEmptyPosition [0,12,"B_Truck_01_Repair_F"];

I was looking at JEBUS today, and saw that it comes with a full copy of the GAIA scripts. So if you are using that and MCC you might have an issue with two versions of GAIA running? Just guessing. Sorry - there are so many variables to test for I'd need to set up a mission and run it a few times to offer more assistance. And 'real-life demands' are keeping me from ARMA just now.

Hi @avibird 1 - Short answer - nowhere near that long. Long answer - first the differences: I use GAIA as scripts and not as a mod, and so without MCC as well. I don't start my missions with editor placed groups under the control of GAIA, I dynamically spawn all GAIA groups into their zones and give them an attack, defend, fortify order according to the mission set up. I don't use VcomAI. Outcome - when a group is spawned and 'given to GAIA' they tend to respond within 30 to 60 seconds and start moving, patrolling, fortifying etc. Have you tried without Vcom, as I think you might have two mods fighting each other to decide which is going to boss the units around the map?

Not that I have ever encountered @avibird 1 I have used it with high group counts. But when you say "issues with groups getting way points" - in what circumstances? I've never seen issues with groups getting patrol waypoint or fortify when they are just 'doing their thing'. I have often seen Gaia not giving orders to groups that I had expected would react to an enemy presence, but Gaia didn't issue them any order to attack or move. However, I have put that down to the Gaia decision making about how to respond to a detected threat, and not down to a bug. Some groups do respond, others not.

@doc. caliban I've just done quick a quick tally of a mission I made a little while back and that had the potential for 170+ groups under Gaia control placed on the map in the editor (a Malden-wide mission) so delete-spawn caching would have been important before the bump of the limit from 144 to 288 groups per mission. That ran fine. In another mission I developed since then I was more sanguine about group numbers, given the bump, and cached fewer units (as I wanted the opfor to drive a long way across the Angola map before being handed over to Gaia). In that the server slowed and then crawled and then juddered and the mission had to be abandoned. Lesson learned. I'm going to stay silent on caching loadouts as I agree with @Strider that it's useful and I also know from my own coding that it's a bit of a chore to implement with the getUnitLoadout and setUnitLoadout arrays. I have got round it simply by not letting Gaia cache units and vehicles where I have built a special loadout, but have still had to do some loadout caching to allow some of those vehicles / units to be respawned when destroyed. I too also use Gaia as scripts, as it is plugged into a larger set of scripts that I used as a framework for making these big missions that I like. The core bits of that are the @Zenophon framework, Gaia, the Hermes Airlift Services Script by @Gunter Severloh. But an Eden editor module for setting options sounds good.

The changes that you are proposing look very good, and the change over to the Zen Occupy Houses will be a massive improvement. The benefit that Gaia caching has over dynamic simulation is that at Stage 2 it actively deletes the group. That used to make a big difference to the maximum group count in a mission, less so after the maximum group limit was upped some time back. With a really massive mission the need to do real 'delete - respawn' caching might remain, so the GAIA code version or a modified version of it could still have a role. I find the stage 1 / stage 2 caching is noticeable with vehicles patrols more so that foot patrols. At stage 2 the vehicle will keep moving, so vehicle patrols and attacks keep going over longer ranges. Like Vigil Vindex I have looked at trying to add future predictions of position but never felt it added anything as, as you say, it is no better than a random position. The main reason I had gone off Gaia caching was the way it messed up "fortify" units. If you have fixed that then I think caching might still have a place, especially in big missions (which I sometimes make). So I'm looking forward to trying out the changes you have made.

doc. caliban - you asked a question of me a few posts back and I have been AFK for a week so have missed all the developments in this thread, and unable to reply. I have a bit of catching up reading to do today then I will reply to the question properly.

The Gaia Fortify code is just lifted from a CBA function - Fortify is CBA_fnc_taskDefend. There is a scripter who posts here called Zenophon who has an excellent occupy houses script that I use in missions sometimes, but I haven't tried to replace the Gaia / CBA code with his work. But Gaia caching would still break the unit positions, so I wanted to get past that one first. Zenophon's code actually places units by the windows in buildings so they don't just fortify it, they can see and shoot out of it, and they pop up/down in combat using a script from JBOY.

I am following this thread keenly, and impressed by the changes you have made doc.caliban. Being the 'friend' referred to by Strider I'll add my observations on what I believe to be the issue with the caching system, and what I think it is doing wrong. All this could be a misunderstanding on my part and if I have this wrong it will be very helpful to know.... Stage 1 caching - everyone by the Team Leader becomes un-simulated and is sunk underground to get them off the map Stage 2 caching - everything is deleted Stage2 uncaching - the Team Leader is recreated and become active again Stage 1 uncaching - the other units are created and spawned at their relative formation position to the TL (because GAIA has no idea where they should be since the TL could have moved since they were stage 1 cached) So if the unit was garrisoning a building only the TL goes back where he was, the rest elsewhere. On the Takistan map I have had cached units respawned under buildings, and I think this is the cause of it. I'dd add that I have not looked at this for a good while as I have started to look at tweaking Gaia to use Dynamic Simulation instead of Gaia caching, and I don't know what version of Gaia I have (I dug the code out of an update of the MCC mod)

@avibird 1 I believe that if you just put a unit down in the editor, with no init code, and leave it alone in MCC, then I don't think GAIA is allowed to take control of it. So I guess there is something in the mission setup that is letting GAIA order the unit about. The init code I suggested won't work as whatever else it is that is giving GAIA control will just over ride it. I don't know JEBUS - never used it - but from the thread on it here it seems to need a call to the JEBUS function in the unit's or group's INIT code. What are you using in the APC squad's INIT? (I don't know if jebus works on the vehicle, the group for the crew, or the leader of the crew group - sorry). But does that INIT 'give' the unit to GAIA (any of the Follow / no_follow options)? And then MCC sandox on top of that. Again, I've not used it for a long time (I use the GAIA script version rather than MCC), I recall that in MCC you have to "give units to GAIA"? Are you doing that in any way?

@avibird 1 can you maybe describe the units a bit more? Is it one group of infantry in the APC, with the driver / commander who are part of that squad? Or does the APC have the driver (the crew) in a separate group from the infantry squad that is in the cargo space?

Try setting this at the 'group' level for the ACP units - so in the INIT field in the group in Eden this setVariable ["GAIA_ZONE_INTEND",nil] I think that should stop Gaia having any control over them.

Happy Anniversary! That is an impressive record. I am sure you know this already but version 3 works flawlessly. I tried four different test situations: AI Enabled / AI Disabled - RYD_HAS_UseSupportsMenu True / False. Worked like a dream every time. Bravo Zulu. And, just to add, I was well impressed with how it handled the JIP player joining the mission, calling for support, then disconnecting. Brilliant stuff. I'm really just guessing here but maybe it's to do with the 'ownership' of the unit object being transferred from the server to the client. If AI is disabled the object will be 'owned' by the client PC right from instantiation. But when AI is enabled the object will start life on the server and then need to be transferred to the client PC when a player JIP's into that object. Maybe some stuff survives that transfer and some stuff doesn't? As I say, just a guess, and whatever it is you have overcome it. Nice one. PS It's a holiday weekend in the UK this weekend so I'm AFK. No responses for a while is not from a loss of interest, but the loss of access to the PC.

With more debug code I got this right at the start of the mission loading for the server player 19:34:07 "After RYD_HAS_FC_submenu - Adding RYD_HAS_Access true for unit2" 19:34:07 "After RYD_HAS_FC_submenu - Adding RYD_HAS_Access true for unit3" 19:34:07 "After RYD_HAS_FC_submenu - Adding RYD_HAS_Access true for unit4" 19:34:07 "After RYD_HAS_FC_submenu - Adding RYD_HAS_Access true for unit5" 19:34:07 "After RYD_HAS_FC_submenu - Adding RYD_HAS_Access true for unit6" 19:34:07 "After RYD_HAS_FC_submenu - Adding RYD_HAS_Access true for unit1" So all the playable units are having RYD_HAS_Access set to true at lines 170 to 174 as part of RYD_HAS_Init. So when one of them is taken over as a JIP player it is already True. To quote Henry Kissinger this time "Each success only buys an admission ticket to a more difficult problem." I went back to my version of version 1 - and implemented your suggestion to " I could just not using RYD_HAS_Access check" to give if (_jip) then { [4,_owner] spawn { params ["_delay","_theOwner"]; sleep _delay; { if ((owner _x) isEqualTo _theOwner) exitWith { [_x] call RYD_HAS_NewUnits; } } foreach (allPlayers - (entities "HeadlessClient_F")) }; }; and that worked, but it didn't. It called RYD_HAS_NewUnits as it should. The code in that function would not call RYD_HAS_GiveActions for the JIP unit, so they did not get the menu options showing. I can see that RYD_HAS_UseSupportsMenu is set to True in the UserConfig file. if not (RYD_HAS_UseSupportsMenu) then { _this call RYD_HAS_GiveActions; }; BUT! When I ran the mission with AI disabled everything worked perfectly!. So the fact that the JIP unit is not getting the support menu options added is in some way related to it being in the mission as an AI unit before it is taken over by a player. When it is not in the mission until it is a player unit then the code is working perfectly. And that is true of Version 1 with the the sleep and the RYD_HAS_Access check restored. When AI is disabled the original version 1 [with this tweak] works as you had intended. if (RYD_HAS_addJIPs) then { RYD_HAS_JIPEH = addMissionEventHandler ["PlayerConnected", { params ["_id", "_uid", "_name", "_jip", "_owner", "_idstr"]; if (_jip) then { [4,_owner] spawn { params ["_delay","_theOwner"]; sleep _delay; { if (((owner _x) isEqualTo _theOwner) and {not ((_x getVariable ["RYD_HAS_Access",false]))}) exitWith { [_x] call RYD_HAS_NewUnits; } } foreach (allPlayers - (entities "HeadlessClient_F")) }; }; }]; }; And that is where I will leave off this evening's investigations, I'm afraid. I have not looked to see where the difference arises in the code between enabled and disabled AI units. But that seems to be the new problem where admission has been bought.

Rydygier Sorry but i think I am making things worse not better! I'll start with Version 2, and return to Version 1 lower down - but they have one issue in common Version 2 - your code with my debug lines RYD_HAS_JIPLoop = [] spawn { sleep 5;//just in case while {true} do { _allPlayers = (allPlayers - (entities "HeadlessClient_F")); sleep 1; if not ((allPlayers - (entities "HeadlessClient_F")) isEqualTo _allPlayers) then { systemchat "allPlayers not same as _allplayers"; diag_log "allPlayers not same as _allplayers"; { systemchat format ["Unit %1 - GetVariable %1 is %2",_x,_x getVariable ["RYD_HAS_Access",false]]; diag_log format ["Unit %1 - GetVariable %1 is %2",_x,_x getVariable ["RYD_HAS_Access",false]]; if not (_x getVariable ["RYD_HAS_Access",false]) then { systemchat "GetVariable false - calling RYD_HAS_NewUnits"; diag_log "GetVariable false - calling RYD_HAS_NewUnits"; [_x] call RYD_HAS_NewUnits; } } foreach _allPlayers } } } resulted in the code not testing the JIP unit - "unit2" 20:36:17 "allPlayers not same as _allplayers" 20:36:17 "Unit unit1 - GetVariable unit1 is true" So changed "foreach _allPlayers" to "foreach allPlayers" and got 20:37:43 "allPlayers not same as _allplayers" 20:37:43 "Unit unit2 - GetVariable unit2 is true" 20:37:43 "Unit unit1 - GetVariable unit1 is true" The JIP unit - "unit2" - seems to have "RYD_HAS_Access" as True on connecting. Therefore the "if not (_x getVariable ["RYD_HAS_Access",false]) then" never called RYD_HAS_NewUnits. I cannot work out why this is or where else might be setting RYD_HAS_Access. Sorry. Version 1 code has the same issue. I changed the code to include a sleep. Adding a 'spawn' to the eventHandler that would then sleep for a bit before running the foreach loop if (_jip) then { [4,_owner] spawn { params ["_delay","_theOwner"]; sleep _delay; { if (((owner _x) isEqualTo _theOwner) and {not ((_x getVariable ["RYD_HAS_Access",false]))}) exitWith That worked and the JIP player was included in allPlayers, but it ran into the same issue with the getVariable being true :-( 20:46:09 "PlayerConnected missionEventHandler with JIP = false, Name = Dev01, Owner = 2" 20:46:09 Mission id: d6658cdcbd067c2cf4620cbf8fe3110f500e7f21 20:46:33 "PlayerConnected missionEventHandler with JIP = true, Name = Dev02, Owner = 7" 20:46:37 "Comparing owner 7 to 7, and getVariable [""RYD_HAS_Access""] = true" 20:46:37 "Comparing owner 2 to 7, and getVariable [""RYD_HAS_Access""] = true" Thomas Edison would say that finding more and more things that don't work is a form of progress, so I hope all this is helpful to you in some way.

Hi Blitzen88 I don't happen by this thread very often, so sorry if this is old news. The function you want to look at is (I believe) fn_isPlayerNear in the functions\cache folder. It uses a foreach playableUnits loop to test only playable units, and then filters those using isPlayer to actually only test those that are real human players. You might be able to achieve what you want without too many changes to that function, depending on... The function tests the distance between players and a geographical position, so it does not know anything of the unit that the player is being tested against, such as its side. So it can't detect if it is friendly or enemy. If you want any unit of side Blue (player or AI) to be able to cache / uncache units then the function could be tweaked to do that (use allUnits instead of playableUnits and filter by side rather than isPlayer - frame rate hit allowing!). If you want any unit of any side to cache / uncache 'enemy' units then the function has to know something about the actual units - to know if they are on the opposite side. It needs more than just the position they are in. That would need a deeper rewrite of the code to pass the fn_isPlayerNear more than just a position and a distance.

Hi Rydygier I'll do more testing for you. At work today, in the less busy moments, I was wondering how to get past the AllPlayers issue. Maybe the eventHandler would work with a 'sleep' of a few seconds so as to give the engine time to create the actual player object, and put it into allPlayers? Then when the loop runs all will be well. The chances of the JIP player wanting to call for a chopper in the first few seconds of joining a mission have got to be slim. So the eventhandler feels like the right solution to me. I share your views on watching for the index count of allPlayers changing, that feels like it will be inefficient. Likewise a 1 second perpetual loop running all the time. I'll try to report back later this evening (UK time).

Hi Rydygier Tested this for you - not good news alas. First, maybe the code ought to be if (RYD_HAS_addJIPs) then { RYD_HAS_JIPEH = addMissionEventHandler ["PlayerConnected", { params ["_id", "_uid", "_name", "_jip", "_owner", "_idstr"]; if (_jip) then { { if (((owner _x) isEqualTo _owner) and {not ((_x getVariable ["RYD_HAS_Access",false]))}) exitWith { [_x] call RYD_HAS_NewUnits; // *** Replaced _unit with _x - _unit not a param in the Event Handler ? } } foreach (allPlayers - (entities "HeadlessClient_F")) }; }]; }; But even with that change it still didn't work. Having dropped lots of diag_log lines into the code to see what is going on it seemed that the problem is with the content of the AllPlayers array. The EventHandler seems to be firing before the JIP player has been added into the array. The RPT output shows the Eventhandler firing twice, once for each player. When JIP is true for the second player it then dumps the content of AllPlayers and then monitors the tests in the foreach loop, but that only runs once. 19:28:28 "PlayerConnected missionEventHandler with JIP = false, Name = Dev01, Owner = 2" // Mission starting - host player starts the mission 19:28:28 Mission id: 634c322b881a6ee0e95c8ba4ba2b4763072e0507 19:29:07 "PlayerConnected missionEventHandler with JIP = true, Name = Dev02, Owner = 11" // Player 2 - JIP 19:29:07 "JIP = true, allplayers = [unit1]" // Player 2 still not in the AllPlayers array 19:29:07 "Comparing owner 2 to 11, and getVariable [""RYD_HAS_Access""] = true" // The loop does not test Player 2

Just to add that I use Hermes and Gaia at the same time and there is no inherent conflict between them. But in the way I use them both the HAS aircraft are not under Gaia control. I don't think the HAS scripts can work if the aircraft pilot group is also being ordered around by Gaia. The two systems will be issuing contradictory 'orders' (domove commands) to the group.

Just another update from me. Tested in single, multiplayer hosted server and dedicated server. The airlift system is all working beautifully. Integrating into the mission system revealed all the problems with my own code, so I have been fixing that before declaring 'mission accomplished. Thanks again for the effort you have put into this, and for sharing it. It's a fine piece of work.

Thanks for the update. Destroyed helis are indeed removed from the lists. Multiplayer testing is all working fine for calling missions, adding new helis, adding new (JIP) players. It's all very sweet. I still want to test the mission on a dedicated server and two clients, but that's not for tonight. I spent time tonight trying to fix my own 'bug', to work out how I had seemingly managed to break the CAS system. I was suddenly unable to call CAS missions. I would set a CAS target location only to have it vanish again almost immediately. I was checking and rechecking my code to see what I was done wrong. In the end it was simply that the Blackfoot didn't have a gunner - just a pilot! Your code is smarter than I am 🙂

Thanks for this [newUnit1,newUnit2,newUnit3] call RYD_HAS_NewUnits; Multiplayer testing continues, so a bit more feedback if I may, I hope this isn't pestering you! I am testing the system with a three player set up: player 1 is hosting the game, 2 is joining at the very start, 3 is JIP. At certain point in a mission, when the only transport chopper has been shot down but before it has re-spawned, if player 1 tries to call a Transport mission the Available transport menu is empty. Player 2 and 3 both see the downed Transport heli in their support menu as an Available transport, but if it is selected the "There's no heli able to perform the task - exiting call." hint pops up. So the code that populates the menu thinks there is a chopper, and the code that calls the mission knows there isn't. But only on both the clients, not on the server.

Hi Rydygier Testing goes very well and the system is doing everything without problems. I'm in the middle of doing more multiplayer testing, which leads to yet another question. Please can I just check for JIP players joining / rejoining a mission after the RYD_HAS_Init has run, do I just need to call _newPlayerObject call RYD_HAS_GiveActions; to get that player to have the call support options become available to them ? I am also appending the new player object to the RYD_HAS_STT array.

Works like a dream. I hadn't spotted the NewChopper function when I looked at the code, but it works well in every respect. Thanks. I've been AFK for a few days so I'm just getting to try out the 1.7wip2 code for the first time proper. There is a one issue I am having with with after-effects respawning the helicopter objects. For example - at mission there is a single Ghost Hawk object assigned as a HAS resource: airlift1. When a 'transport' mission is called the 'Available transport' menu is: As the mission runs the Ghost Hawk is destroyed and respawned a number of times, all without any problems. But after a few cycles of that, when a 'transport' mission is called the 'Available transport' menu is then There is still just one single Ghost Hawk in the mission. However, it all still works, I can pick any of those menu options and the chopper is on its way. (just to explain the pictures. The top icons are from four of the Arma vanilla virtual support modules. The HAS icons are the lower three in each case)

Another couple of questions please (1) Is the RYD_HAS_CASChoppers array cleaned up in a similar way to the RYD_HAS_ClearHelis function removes destroyed objects from the RYD_HAS_allChoppers array? I have the respawn code adding the new objects into RYD_HAS_allChoppers, and I am content that RYD_HAS_ClearHelis will get rid of the deleted objects at some stage. But I'm not sure what I need to do about destroyed CAS helicopters. (2) Do I need to worry about this I have seen in the code? I've not examined the code well enough yet to see if this is in "run once at init" code, or if its in a loop that will be checking for new helis spawned. I think this might be something to do with the respawned helicopters not displaying all the systemchat messages for the end of the airlift. I get the audio cue for a message - but no text. I don't get the 'daytime signal' and 'signal seen' messages. I do get the 'on the way' message when the airlift is called. { if not ((driver _x) kbHasTopic "BIS_SUPP_protocol") then//these 4 lines need to be applied also to every new heli spawned during the mission { (driver _x) kbAddtopic ["BIS_SUPP_protocol", "A3\Modules_F\supports\kb\protocol.bikb", "A3\Modules_F\supports\kb\protocol.fsm", {call compile preprocessFileLineNumbers "A3\Modules_F\supports\kb\protocol.sqf"}]; }; } foreach RYD_HAS_allChoppers Just an update - on the whole the integration is going well and the HAS is working superbly. In the framework mission making is driven by placing markers of various sorts. So to make the Hermes Airlift fit in with the way the rest of the framework operates, in mission making I need to place a point marker called HermesAirliftBase where I want the gamelogic to be, and the code creates the gamelogic at that spot (and hides the marker). Then any helis to be controlled are placed in the editor (with a pilot) and named Airlift1 through to Airlift99. All the Airliftx objects that are an aircraft with a pilot are synced to the gamelogic, and an invisible helipad is created underneath each of them. Once all that is done I call RYD_HAS_Init Then, if any object called Airliftx is destroyed then it is respawned at its original location with a pilot and added back into RYD_HAS_allChoppers and RYD_HAS_CASChoppers as appropriate. What I have still to test are the interactions between using playableUnits to populate RYD_HAS_STT, and what that will mean for JIP and respawned players. I think that will be for another day. Thanks for this great system.