Doomguy

Hi rick1965, I'm fine with releasing it! Doomguy

Hi Rip31st, The sound problem was reported to ACE already and was fixed by Sickboy. It will be in the upcoming ACE patch. I already fixed the problem with respawning AI being stuck in WACO ACE v1.1.5f. It's a matter of calling enableAI a couple of time after respawn. Here is the code I added for ACE compatability. This is really a work-around until ACE will release a patch that allows us to add the Warfare OnPlayerConnected entry to ACE's instead of overriding it. That will fix a lot of compatability issues. Anyway, the code. I added the lines from the // ACE: comment. In Server/AI/Advanced/Advanced_UpdateSquadRespawn.sqf, from line 20 and onward: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> while {!IsPlayer Leader _team} do {   WaitUntil {!Alive Leader _team || IsPlayer Leader _team};   if (!IsPlayer Leader _team) then   {     _body = Leader _team;     WaitUntil {Alive Leader _team || IsPlayer Leader _team};     if (!IsPlayer Leader _team) then     {       _leader = Leader _team;       _leader SetPos GetMarkerPos _respawnMarker;       Sleep 14;       // ACE: prevent unconscious leader after respawn       _leader setVariable ["ACE_unconscious", false];       _leader setCaptive false;       _leader enableAI "TARGET";       _leader enableAI "AUTOTARGET";       _leader enableAI "MOVE"; Doomguy

Agreed! It's easy to change: Comment out or remove line 11 in Client/PVFunctions/AwardBounty.sqf, i.e., the line where it says <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Format[Localize "STRWFAWARDBOUNTY",_bounty,_name] Call GroupChatMessage; Doomguy

Here is ACE version v1.1.5f! The first version that really works well enough. AI teams are no longer stuck after respawn, and most ACE stuff seems to work fine. Thanks everyone for your feedback! Download from FileFront Here are the changes: - (ACE) AI squads should no longer become stuck after respawn. This has been fixed by a work around, which will be replaced by a proper fix once the ACE patch is out. - (ACE) Due to a compatability problem between Warfare UI and Mando Missile HUD, players could no longer buy stuff from factories once they entered a helo or plane. This has been fixed. - (ACE) Soldiers in AI teams that are unconscious are killed during their regular update cycle (between 15 - 30 seconds). This is to prevent AI teams being held up by unconscious men, and also descreases the amount of ammo wasted on injured soldiers. - (ACE) Replaced ACE resistance units by standard BIS because ACE units have config problems. - (ACE) AV8B GBU and AV8B AA were incorrectly swapped in factory menu. Doomguy

You're right Wolfrug! I just ran some tests and indeed, both event handlers run. Cool! Also, removeAllEventHandlers seems to remove the ACE event handlers, indeed. Doomguy

Hi! I have some XEH questions for the event handler experts here. Some missions, for instance Warfare, use event handlers to implement functionality like scoring and clean up. The event handlers are added by scripts that call addEventHandler. I'm concerned that this might conflict with the XEH system of keeping track of event handlers. Now, the question. Does the use of addEventHandler in scripts conflict with event handlers added by addons using XEH (let's say, ACE). If, for instance, an addon would use XEH to add a "killed" event handler to all objects of type Man, and my mission script would do addEventHandler ["killed", command] to an object of type Man, would both event handlers remain, or would one override the other? If event handlers override each other in the situation above I would like to know how to make sure both event handler run. Can you add event handlers to the XEH system in mission scripts? Thanks! Doomguy out.

I found the cause of the being unable to buy stuff at factories after dying (or just being inside) a helo or plane! It turns out that the Mando Missile HUD that's shown in helo's and planes causes a client side script to halt (forever). That script should update the actions the player can do, like buying at factories. There will be a fix in the next update. Also, I found that ACE needs some setup that is overwritten by Warfare. This probably causes the AI to remain stuck after respawn. ACE is releasing a patch soon that will allow me to fix this. Doomguy out.

I was mainly thinking of normal land vehicles that suffer from mountain ranges and chokepoints such as cities (Corazol). The AI path finding has a hard time navigating around/through those things. The independent air team is programmed to ignore commander commands. Its squad leader stays at the base, in particular at the aircraft factory if there is one. The aircraft it purchases are sent on missions independently, the commander has no control over where they go. It's certainly possible that vehicles get stuck. In fact, it happens quite a lot in ArmA, especially wheeled vehicles such as Strykers. This is why, if the commander is AI controlled, AI teams' movements are tracked. If an AI team doesn't move more than 50 meters in 5 minutes (numbers from the top of my mind), they are respawned. If the player is commander, this doesn't happen. Therefore you sometimes have to unstick teams yourself (respawn them). Me neither, actually. Also, in ACE the laser designator is put in the binocular slot, normally it is a launcher weapon. I haven't really tried to fix this yet, as I hardly ever use the laser designator myself. Doomguy

Never mind the arma.rpt, I reproduced the problem (and there is no error message). It happens only on the ACE version: die in a heli and the buying options cannot be changed anymore. I'll look into it. Doomguy

Any error messages that you saw before that happened? Could you send me arma.rpt of the session? Thanks for that, I'll fix it. Gunhawk: Could you please cut the enormous quote? I haven't made a full Sahrani version, but at some point somebody was working on one. I'm not sure if it was ever released, sorry. Personally I think the AI won't perform that well on full Sahrani as there are too many chokepoints and mountain ranges. Doomguy

Hi Mazza, I noticed this myself too. They seem to be stuck even if they have all units according to their templates. It must be something related to ACE, since it doesn't happen in the normal addon or stand alone versions. Can you recall if the men crewing the vehicles were wounded (shown as red or yellow in the commander's team status menu)? My current theory is that the ACE wounding behavior causes these problems when soldiers go unconscious. AI teams will always buy all the units their funds allow them to buy, given that there is a factory they can buy from. After buying, they will wait for some time (armor teams wait at least 3 minutes) before they will try to buy again, or move on to their objective. The buying behavior is not based on the build queue. Not for AI teams currently. Doomguy out.

Updated all versions to v1.1.5e. Changes: - Updated included SPON Core to 0.53. - Fixed problems with various scripts. Error messages should be a  thing of the past now. - Attack helicopters and planes are 50% more expensive. (Testing turned out that attack helicopters are extremely powerful and should be rare). All improvements previously made to the ACE version are now also merged into the normal and stand-alone versions. Doomguy out.

I'm releasing a version with an updated SPON Core soon, that will solve issues with not getting the debug log. Doomguy.

That's great! I'll have a look at it soon. Doomguy

I wrote a fixed version of FindStringIgnoringCase a couple of days ago. It will be released with some other fixes soon. But here it comes already: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">/*  int FindStringIgnoringCase (array _ar, string _s)  Returns the index of string _s inside array _ar.  Case is ignored during string comparison.  If _s was not found, -1 is returned. */ Private["_ar","_as","_s","_is","_l","_i"]; _ar = _this Select 0; _s  = _this Select 1; _is = -1; if ((TypeName _ar) != "ARRAY") then {  [Format["FindStringIgnoringCase called with bad argument: arg1 = %1, arg2 = %2", _ar, _s]] Call TRACE; } else {  _l  = Count _ar;  for [{_i = 0},{_is == -1 && _i < _l},{_i = _i + 1}] do {   _as = (_ar Select _i);   if ((TypeName _as) == "STRING") then {    if (_as == _s) then {_is = _i}   }  }; }; _is; Note that there is still a call to TRACE in there, which is a proxy for a SPON debug command. So you'll either need SPON Core integrated in the mission or comment out that line. Doomguy

Did you notice any scripting error messages? Could you post your arma.rpt and arma_server.rpt somewhere? Doomguy

Hi klamacz, Thanks for the report, but I can't replicate the problem. I tried dying in a vehicle with radio several times, but each time I was still able to use factories without radio. The buying buttons are refreshed every 3 seconds as well, so I can't really see how this can go wrong... Doomguy

That sounds great! It turns out I was not properly awake this morning when I answered your question. There is a far easier way to change back the camp behavior. In Client\Client_UpdateAvailableActions.sqf at lines 50 to 52 where it says <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> if (Call Compile Format["%1SupplyValue", Str _camp] >= 20) then { suppliedCampInRange = _camp; }; change the 20 into 10. Camps get supply level 10 when they are captured, so essentially you'll have the old behavior back where you can order gear and construct stuff at the camps you just captured. Sorry if you already waded through all the other files... Doomguy

Thanks for the report! What would really help is to have the arma.rpt and arma_server.rpt (if you used a dedicated server) logs of the games were you noticed that behavior. Doomguy

You can change the purchase range for player in Common\Init\Init_CommonConstants.sqs. The variable is called PURCHASERANGE. If you want to change back the behavior for camps you need to do a little bit more. In the following files: GUI_UpdateCommanderVoteMenu.sqs GUI_UpdateGearMenu.sqs GUI_UpdateHelpMenu.sqs GUI_UpdateMissionMap.sqs GUI_UpdateTeamMenu.sqs Change 'suppliedCampInRange' to 'campInRange' throughout the files. Also, in Client_UpdateAvailableActions.sqf change 'suppliedCampInRange' to 'campInRange' in the conditions at lines 166 and 174. I'll make this more easlity configurable in the future. Doomguy out.

That behavior is normal. The AI squad leaders wait for up to 3 minutes so that all purchased units can join their squads before they head out. A mod that I can recommend to boost AI behavior in general is SLX_GL3. ACE AI is better than standard ArmA but not as good as ECS + SIX Pack 3 + SLX_GL3 can be. I use slx_gl3.pbo, slx_netcode.pbo and slx_nosuppress.pbo with my ACE games. Doomguy

Well, there tend to be fewer AI units in standard Warfare games because the standard config has fewer units in it. I just played a game on a dedicated server and everything seemed to work OK. How many FPS do you get during play (as admin, do #monitor 1)? If it the FPS is far below 15, the server may be overloaded. Doomguy

Hi klamacz, What AI do you mean? BLUFOR, OPFOR, or resistance? I'll do a few runs myself on a dedicated server to see if I get the same thing. Doomguy

Hi AlDente, I guess not... But don't worry, Sickboy of ACE already fixed the problem and so it won't be in the next version of ACE. Roger, I'm seeing these errors occurring occasionally as well. Looking into it... Doomguy.

There I was, hoping that the AI performance of WACO set it apart But don't worry, I won't remove it! The implementation of respawn-as-team-member is a little bit scattered. In Client\Client_Killed.sqs look at lines 81 to 85. There is a call to PlayerRespawnAsMember if there are members left. That function is defined in Client\Functions\Client_PlayerRespawnAsMember.sqf. Cheers, Doomguy