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.