Protegimus

.bisign's are ok. Delete the contents of the beta directory (or rename it to beta.83657 or whatever) and re-install the beta; maybe the files are mixed up. Protegimus

Yes, I can confirm this. After healing another player you are stuck in the medic animation (reported in previous beta) for some time 30-60s after he is once again mobile. With beta 83657 you now also get randomly teleported 2-300m away from currently location at end of heal animation. While you're looking at the first aid stuff, could you make a healed players aim stay much worse for a period after they are healed; maybe one or two minutes so that there is more of a penalty for getting shot? It also would be great if the first aid module didn't kick in immediately on 1% injured, let us experience the damage in arm/legged injuries first, before bleeding or being injured further and going into the full writhing in agony anim. Thanks Suma, for all the fixes and improvements over the last couple of weeks, massive progress ...and of course to all those posting tickets and creating detailed repro's. Protegimus

Yes, please test carefully, as further runs with build 79384 aren't providing consistent results... DCDeadBody is frequently 2x Body Count, but appears to vary. Will test further. Protegimus

Hi fabrizio, I looked at this with great interest and have found a few things that profoundly affect the outcome of the test mission: 1. Place (not spawn) a West (BlueFor) soldier on the map away from the combat zone 2. Amend your init.sqf from _opforGrp = createGroup East; to _opforGrp = createGroup West; Now re-run the test, first with version 1.59 build 79384. Version 1.59 build 79384 now behaves as expected with all danger.fsm _dangerCause values observed & DCDeadBody in sync with Body Count. With beta 83281, the danger.fsm _dangerCause values do not increment as expected. No DCFire (fire visible) cause, only DCEnemyDetected and CAN FIRE appear to increment as expected. I triggered DCEnemyNear and DCExplosion by manually (as the civie) picking a weapon and frag and attacking the Russian rifleman. DCDeadBody is twice Body Count. With beta 83181 and 83281 AI aim is very poor in single fire mode - appears (from observation) to be fine in burst. Now a couple of questions of my own: fabrizio, you were spawning USMC soldiers in an East group - was this purely for the purpose of testing? The pre-requisite for spawning West units: _sideWestAIHQ = createCenter West; did not correctly initialise the AI behaviour (danger.fsm causes not being detected) in my testing - is there something else that needs to be done when you intend to start a mission with no OpFor present, but spawn them all in during the course of a mission? @Suma: please could you explain how the DCFire event is incremented - it appears to jump in orders of magnitude when enemy fire is observed. Also, is there a significance to the priority values in the Reacting on Danger init? _priors = [3, 4, 5, 1, 4, 1, 1, 2, 2]; Protegimus

I'm surprised you're talking this down? If you were playing against another player and he could walk through walls, the base of a house or fences then shoot you in the back you'd be pretty annoyed - so what can be more immersion breaking than the AI doing this? I'd rather they hold position and either cover, or pour fire into the gap for a few seconds. This is obviously a different perspective, though equally valid - I was referring to opposing AI doing it rather than leading a bunch of AI and them getting held up somewhere. Perhaps a tiny bit of logic can give us the best of both - any enemy around and they either wait or traverse the obstacle the same way the player does (simply play a funky animation) ...or no enemy around - they stare at goats and pass through walls/houses/fences and keep up with their human leader? Protegimus

Visual state improvements welcome, though the 'jerkiness' is still there and the AI appear to rapidly warp from one position to another. It makes leading a target moving across your arc incredibly difficult - perhaps more intermediate stages of interpolation are needed so that the AI don't warp so much? Currently this is experienced in online multiplayer: o o o o | --------> | ::::::::> | --------> | normal fast normal warp o | player The slowdown when looking through optics is also reduced in this version, which re-appeared a few betas ago. Performance feels great with -malloc=0, slightly more 'sluggish' over time with -malloc=3 and this is re-inforced on Zargabad which now runs incredibly well. One thing that appears significantly worse though is the AI walking through buildings and the concrete fences - please can you look at this as it significantly affects the gameplay. Protegimus

Small update to my CSM2 sound mod for the BAF addon, taking it to version: 0.1c. New sounds are added for the NLAW, additional L85A2 firing sound and improved 40mm munition impact sounds and mounted L7A2 firing sounds. Download link in first post, thanks for Foxhound @ Armaholic for hosting it. Protegimus

Good, we'll count that one as closed then. I wouldn't bother, line 23 of the readme: - Changes the speed at which an AI can get a bead on a target No one that enjoys doing infantry stuff likes playing against aimbot AI. metalcraze, the speculation is getting a little out of hand. From the description you gave in Death From Above, do you think the two AA units you were detected by and which fired missiles on your LB may have had an influence? AA units can realistically operate at night. If you want to play carefully scripted campaign missions designed for ArmA 2, remove Zeus AI; or accept that it changes stuff. What I'm interested in with regard to AI observation at the minute is whether it is possible to improve the AI vision at night (without NV and before contact is initiated). This has always been very closely linked to AI hearing ability and the recent patches do appear to have changed this ability again (AI seems less sensitive). Solus also mentioned that during his testing he obtained different values than I for spotTime[]= which affected this, so I will revisit that. spotDistance[] = values, no I've always been satisfied that the low skill level was essential to improving the AI spotting...tested in broad daylight on a flat runway. By all means test spotting related stuff and report data from your observations, different values for cfgAISkill and such. The source information is deliberately included in the .pbo, for you or anyone else that's interested in contributing - there's nothing to say it can't be improved upon and just as with AI "Hold fire", I'm not too proud to revisit it and sort it out if I can. Protegimus

ok, thanks for testing. Version: zeu_AI_v0.02d1.7z passes your test mission (at least for me) and mine, irrespective of who calls the enemy. For aircraft recognition, please test without: zeu_OA_c_ai_recognition.pbo btw, you can simply ask questions in a reasonable manner and I'll try to point you in the right direction. Protegimus

The amount of effort that must have gone in to this must be immense...like the results: <object width="480" height="385"><param name="movie" value="http://www.youtube.com/watch?v=SdjvYGLkPv4&hl=en_GB&feature=player_embedded&version=3"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=SdjvYGLkPv4&hl=en_GB&feature=player_embedded&version=3" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object> Hope you don't mind a bit of constructive feedback: Fire is especially improved on burning vehicles, though fuel fires should be much more orange/red than yellow and smoke is light grey very close to the vehicle quickly turning grey/dark grey to black and 'dirty' then grey again as you reach the edges - pity we can't post pictures on this forum as I have a couple of perfect examples. Muzzle flash for small arms is a bit overcooked - even pre-dating the vortex flash hiders they are way too obvious especially in daylight. You only rarely see a orange red blast about 15cm from the muzzle, it is particularly bad on the M249/Minimi. Smoke from Hellfire, Tow has already been picked up. Finally AT4 - is the light the tracer as it has no rocket motor? If tracer can you tone it down to just like that on a .50 tracer round. I realise many want the effects turned right up, but you're so close on so many aspects a few tweaks will really make it excellent. PM me if you want a look at the photo's, they might be helpful. NM, have a look at David Leeson's images, there's also a video of MLRS launches. Protegimus

Well, well, AI engaging under "Hold Fire" order i.e. ROE violation when enemy near... The biki states units ordered to hold fire are set to combatMode "GREEN" (Hold fire - defend only) - as of build 1.57.76934 this is not the case, they are in combatMode "YELLOW" (Fire at will). ref.: http://community.bistudio.com/wiki/ArmA:_AI_Combat_Modes#Engagement_rules Can someone test and confirm AI hold fire finally matches default ArmA 2 performance. The file you want is: zeu_AI_v0.02d.7z NoBrainer: the only reason the files weren't versioned as well was because if you followed the thread this was meant to be a casual test release. I've tested with a specific scenario and my AI both hold fire and cease fire on order. Protegimus

If we put re-inforcement range it in a config, it will be one size fits all - which is no different to where we are now really. If it's taken from the mission, be that by .sqf or a game logic it will be mission specific; albeit useless to missions created without it, when it will default to what I set. As it stands, if AI have an active waypoint sequence they are not eligible to be called as re-inforcement. I will code some sort of "stay static" option, as I appreciate mission makers want some units to stay exactly where they expect - I'm considering the best way to implement it. zeu_AIBypass wasn't working the way it was intended so it was removed. metalcraze: wrt to the AI spotting armoured vehicles, etc. it's not a bug, it was a conscious design decision to make the AI recognise armour/air and vehicle contacts more readily - is that ok, because they were really shit at it before? I (once again) tested your suggestion regarding AI breaking "hold fire" order, but I can't see a difference in my test scenario and as "doFire" was borked until the latest patch I think that if there is any influence from Zeus it lies with the caller, not the zeu_fireAtEnemy function. I'll do some more testing in the next few days. Before you play the 'realism' card, do the tanks you are referring to have thermal/NV? Please keep the feedback succint guys...I only need to read something once and while it may be frustrating for some of you that the mod takes an unwelcome path in its development, it will be refined over time. Protegimus

Configuration files are available for download from the TS3 server as zeu_BAF_wep_cfg.7z at: teamspeak.zeus-community.net:9987 Channel: Support & File Repository for graphical instructions, go here thanks Rabbit! Protegimus

Version 0.02c is available for download from the TS3 server: teamspeak.zeus-community.net:9987 Channel: Support & File Repository for graphical instructions, go here thanks Rabbit! Version numbers and fixes are in the readme Changelog section (also reproduced below), together with instructions, including instructions on what to do for ACE. Fixes/improvements: - version 0.02c (27.12.2010): Changed: re-inforcement ranges for each faction are reduced to prevent all enemy forces being sucked in to the first contact: East: 2000m West: 2500m Resistance: 1400m others: 1000m Improved: AI will now only use small boats for transport, not ships Improved: Rating for helicopters is now more granular, attack helicopters are treated differently to transport choppers Improved: information sharing is less efficient between AI groups, variation added for how long it can take and how likely it is to succeed Fixed: helicopters that are transporting troops will no longer attack enemy Fixed: zeu_OA_c_ai_rof.pbo - attack helicopters not engaging targets Fixed: zeu_OA_c_RocketBallistics.pbo - AH-64D not firing FFAR (FFAR initSpeed must be 0.05 or greater) From that we also kill one from the known issues list: 10.12.2010 UGLY58: Helicopter crews engage ground targets irrespective of what type of helicopter they are in, ref. BIS help us again with patch 1.57: [76747] Fixed: doFire did not work on most targets CQB should see an improvement due to this and it should be obvious on the Utes airport test (maturin). metalcraze: very timely information regarding the FFAR's, you must have realised I was looking at the helicopter stuff, so thanks for that. While it was testing this one thing seems clear - <object width="480" height="385"><param name="movie" value="http://www.youtube.com/watch?v=LAWVK4ofPQo&hl=en_GB&feature=player_embedded&version=3"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=LAWVK4ofPQo&hl=en_GB&feature=player_embedded&version=3" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="385"></embed></object> default AI don't select ordnance according to the type of target they are attacking...one more for the wish list. Protegimus

If your server has ACE installed, you are incorrectly using: zeu_OA_c_wep_dispersion.pbo From the readme... Important: You must use the ACE specific version for: zeu_ACE_c_wep_dispersion.pbo instead of the OA version (zeu_OA_c_wep_dispersion.pbo) or a dependency error message will be generated on mission load: .rpt: "Addon zeu_ace_c_wep_dispersion (entry PKT_veh) not found in the list of active addons." Warning Message: You cannot play/edit this mission; it is dependent on downloadable content that has been deleted. zeu_OA_c_wep_dispersion" Protegimus