haleks

Hello Ravagers! Time for another update guys! This release introduces a small immersion-enhancement script to improve AI reactions to nearby gunshots, plus the usual tweaks and fixes : SP players may see a slight improvement performance-wise, although a lot of work remains to be done in that area... Have fun fellas, and thank you for your support! 😉

All global variables handled by the gearpool module : "lootVital_list", "lootWeapon_list", "lootMagazine_list", "lootItem_list", "lootBackpack_list", "lootworldObject_list", "rvg_weapons", "rvg_LMG", "rvg_launchers", "rvg_uniforms_lv0", "rvg_uniforms_lv1", "rvg_vests", "rvg_headGears", "rvg_goggles", "rvg_backpacks", "rvg_nvgs"

Interesting topic! ^^ Obviously, everyone has its own process and there's more than one way to "make a monster", but I'm happy to share ideas if it can help modders out there! Although keep in mind : my own approach is rather empirical, and there're probably better ways to achieve what we're talking about (for instance using FSM files for complex behaviours). Usually, zombies spawned by the Ravage modules are Agents, for two good reasons : - Agents do not use the standard FSM routines, and are less demanding as a result. That's exactly what you need for "zombies scenarios", where we need numerous but dumb entities. The downside is that a lot of scripted commands do not work on Agents, but... - Agents are easier to work with when you need better control of their pathfinding (which is odd, considering that agents are usually used for super dumb animals in a typical Arma scenario). To be more specific, the setDestination command is a powerful tool for Agents, with more flexibility than what we have for "classic" units : it can clear the planned path on the fly and force an immediate update. In Ravage, this is used to help zombies anticipating their target's trajectory : instead of moving to the target's position every x seconds, they re-calculate the best path to the expected "destination" of the target, based on its velocity. Not necessarily the best method, but I just plug my own .sqf scripts to zombie entities. It will do the job for dumb monsters, but if you need more complex/dynamic behaviours, it's probably best to have a go at FSM files, but I can't help you there. ^^' But yeah, basically that's it : targets are selected based on their visibility and proximity, zombies switch to a "chase state" (faster movements, different SFX) and an attack sequence is triggered once in range. For Ravage, a fake bullet with tweaked properties is used, rather than 100% scripted damage : the idea is to be in line with "how Arma is supposed to work", and improve compatibility with in-depth modifications like ACE. I also added a bunch of scripts to handle their audio perception - in that area, you pretty much have to script everything yourself when working with Agents... Yep. Since zombies have their own logic for target selection, it doesn't conflict with vanilla behaviour. The "fake bullet" trick also helps the AI knowing when they're being attacked/hit by a zombie, which is something you would have to script yourself with less conventional methods. class CfgVehicles { class B_Survivor_F; class zombie : B_Survivor_F { nameSound = "Walker"; }; }; https://community.bistudio.com/wiki/Arma_3_NameSound_Setup "Walker" just happens to be an existing NameSound in Arma 3, lucky for me. ^^ That deserves its own thread, but IMO : - make sure you know everything you need about locality : you want to know when to execute a script server-side or client-side, what needs to be sync'd across the network or not etc (for instance, the VFX script when a player is hit by a zombie only needs to be executed on his machine)... - always test the performance of each iteration of your scripts. - try to stay within the "engine rules" : the less custom scripts you need, the easier it will be for everyone, including mission makers. That's all I can think of right now... By the way, @R0adki11, I think this thread best suits the Editing section of the forum? 😉

Greenfist' script is designed to monitor "regular" units - zombies in Ravage are usually spawned as agents, and those are a bit different. Most commands related to AI behaviour/knowledge/movement don't work on them. 😉 Zombies in Ravage behave according to in-house logics and variables, so most monitoring tools won't have any relevant data for them.

Yeah, I think the AI lacks an "uncertain state" : the "who are you?! Oh you're friendly" kinda situation. Typically it's the sort of thing that is scripted in mainstream games - and various scenarios in Arma3 campaigns do have those scripted encounters - but that's not part of the "vanilla package". It's a shame IMO, that's what mission makers need to have as a ready-to-use tool in such a sandbox. The situation in your video perfectly depicts that (assuming the lad was indeed hostile ^^). Regarding the next update and improving AI reactions to audible gunshots, I'm pretty happy with the first results so far! It's still WIP, but right now the logic behind the script is pretty simple : units within close range of any gunshot will immediately switch to "danger" behaviour (unless they're in stealth mode) if they have no prior knowledge about the shooter and if he belongs to a different group. They will also look at an estimated position of the shooter - the precision depends on how loud the weapon is, and how close the shooter is. The script doesn't actually reveal the shooter to nearby AIs, it just forces them to "act surprised" and look at somewhere near the gunshot while the engine does its stuff. It may indirectly help the AI to spot far away shooters, but other than that it's a rather light approach with mostly cosmetic (yet very much needed) consequences.

Fear not, the effects should be minimal and mostly for immersion. My previous statement was a bit inaccurate : the problem is more a matter of how they react, actually. I'm under the impression that it takes several seconds for the AI to react, or to pinpoint the gunshot origin - during that time lap they just stand still, and they only switch to "danger" once they see the shooter. It looks underwhelming... The goal is just to have them show some kinda surprise right away, and make them switch to danger before they see/pinpoint the shooter. 😉

Hi guys! Some quick news about the next update & recent suggestions : I realised this week-end that I added a function to handle that in a previous version - but the script failed to identify emptied weaponHolders... That is fixed on my current build - no more opening empty weaponHolders, and the overall "looting experience" is a tad more fluid. I still have to test the fix on CUP structures with proxies, but I'm confident it will solve all related problems. Regarding a more detailed repair system for vehicles, it is very much needed indeed. It probably won't be part of the next update, but I reckon a lot of props from recent DLCs can be put to good use. 😉 Here's the planned changelog : Right now I have a ready-to-release build, but I want to have a go at something that has been bothering me lately, which is the vanilla AI being pretty much completely deaf... They simply don't hear gunshots beyond a very small range, unless they're directly being shot at. Since I have a pretty solid "enhanced audio perception" for zombies already, I figure it shouldn't be too much troubles to work something out for the vanilla AI. The update should happen sometime this week, maybe followed by another one before November.

New module parameter(s) incoming! ^^

Is there a list of structures used as replacements?

"thisList" is an array : a list containing several objects : [obj1, obj2, obj3] In this case, the array contains all units/objects that fulfil the trigger's condition statement. Use this code in the "on activation" field to see what is included in thisList : hint str thisList The "thisList select 0" code simply selects the first element in that array (indexing starts at 0 when going through arrays).

Always happy to help destroying stuff! Here's a ready-to-use function : //example : [getpos somelogic, 1000, 1] call myFunction to level everything, or : //[getpos somelogic, 1000, 0.75] call myFunction to damage everything myFunction = { params ["_pos", "_radius", "_dam"]; _arr = [ "BUILDING", "HOUSE", "CHURCH", "CHAPEL", "BUNKER", "FORTRESS", "VIEW-TOWER", "LIGHTHOUSE", "FUELSTATION", "HOSPITAL", "WALL", "HIDE", "BUSSTOP", "STACK", "TOURISM", "WATERTOWER", "POWER LINES", "POWERSOLAR" ]; { _x setDamage [_dam, false] } forEach (nearestTerrainObjects [_pos, _arr, _radius,false]); true }; I'm pretty sure nothing will survive that - although keep in mind that some buildings may not have a proper "damaged" model (mostly structures from Tanoa).

Looking at it, you're probably going to need to set "allowedTargets=0" for all Ravage functions except rvg_fnc_init_loot : most of them will run client-side (assuming it works like remoteExec where 0 means all machines and 2 means server only).

I think the following covers it : rvg_fnc_init_loot fnc_checkLoot fnc_loadFrnt fnc_findNearestBldCat fnc_lootSearchAction Note that most of these functions aren't properly configured (wich is something I really need to do some day...), but generated on the fly after module inits - it may be a problem, I have no idea to be honest. The loot system also involves a few vanilla functions, but I don't think BIS scripts are blacklisted? Definitely a good idea mate! I'm mostly working on MyST these days, but I plan on pushing a Ravage update before November (before Death Stranding hits the shelves, actually!). 😉

Well, on the other hand, BIS moved so much stuff to the free platform that there isn't much left at this point to be kept as an exclusive for DLC owners, except for the aliens... Judging by the quasi complete absence of user-made missions involving said aliens, I think they went the wrong way as to what should be made available to everyone though.

It's supposed to be true call BIN_fnc_showHorizontalCompass, iirc.