Jump to content

killick

Member
  • Content Count

    28
  • Joined

  • Last visited

  • Medals

Community Reputation

18 Good

About killick

  • Rank
    Private First Class

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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)
  3. @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?
  4. @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?
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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).
  11. 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
  12. 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.
  13. 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.
  14. 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 🙂
  15. 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.
×