LSValmont

Thank you johnny, that compliment is a real honor specially coming from the father of all Arma 3 Dogs. 😄 Technically you filled the need for a Dog companion in Arma 3 first... and we all know BI didn't make it easy for you... To be honest I was about to give up on it until you came up with amazing ideas to make it work. I make all my missions MP since all my family plays on a LAN so I really needed these scripts too. 😊 Believe it or not but Arma 2 had much better animal behavior than Arma 3. If Arma 2 was 64 bit I would be playing that...

That is correct Vandeanson, the vDog Patrol script only runs under 2 conditions: The Ai handler is alive and the handler unit has its simulations enabled. If players are far away and the handler has its simulations disabled then the dog script is put on hold. If the handler is dead then the script tells the dog to play an idle animation and then exits. The dog now is like any regular ambient dog and will consume next to no resources. Here are the code snipes that deal with that: waitUntil {Sleep (2 + (random 2)); simulationEnabled _dogOwner && alive _dogOwner}; while {alive _dog} do { if (simulationEnabled _dogOwner) then { if (alive _dog && !alive _dogOwner) exitWith {_dog playMove "Dog_Idle_Stop";}; if (!alive _dog) exitWith { _dogGrpSideLogic = createGroup sideLogic; _deadDogLogic = _dogGrpSideLogic createUnit ["logic", getPos _dog, [], 0, "none"]; [_deadDogLogic, "dogCry"] remoteExec ["say3D"]; sleep 5; deleteVehicle _deadDogLogic; }; if (alive _dogOwner && !(simulationEnabled _dogOwner)) then {[_dog, false] remoteExec ["enableSimulationGlobal",2]; sleep (10 + (random 10));} else {[_dog, true] remoteExec ["enableSimulationGlobal",2];}; Another thing to consider is that because this is a MULTIPLAYER focused script I had to put several and often random sleeps so the vDogs will never be as responsive as the JBOY Dogs. That only means that in order to maximize optimization I had to make some concessions. The vDogs therefore do not react instantly to their ai/player handler's actions nor to their targets actions but it is still (or even more) realistic than dogs instantly picking up targets or reacting to their owners actions in a second. They do what they are intended to do (alert its owner of enemy presence) quite well even if their attacks and speed are not as deadly as JBoys.

I've just released a Hotfix: Let me know when it is implemented so I can try it! 😉

1.3B (HotFix) RELEASED: - Updated the Dogs attack distance so they don't reach enemies who are high above the ground. - Updated and Improved the Demo Mission with both Patrol Dogs and Feral Dogs present and examples with Patrol Dogs on Player, on Ai enemy and Feral Dogs Guarding a tower as their territory by using a trigger. - Updated Readme Files to show the latest changes. 1.3B Demo Mission DOWNLOAD LINK (Google Drive): https://drive.google.com/open?id=1AJ0NYIAVklLT1jBwq4x4d47EoKiiFaUs 1.3B Demo Mission DOWNLOAD LINK (Armaholic): http://www.armaholic.com/page.php?id=35026

So I've just realized that my mission has many unwanted DLC dependencies. 1) Anyone knows a quickly way to remove those DLC items from my mission so I don't have to go Item by Item? 2) If a mission has no DLC dependency but during gameplay a Script adds a DLC item (lets say a weapon) will players without the DLC still be able to play it without interference?

That is good to know Argmax, I was going to recommend vDog Feral if it was multiplayer but the script works just fine in SP too. Looking forward to your mission!

Dear Vandeanson, anyone who has contributed so much to the Ravage community such as yourself can be considered OWNERS of my scripts... I would be honored to contribute even if it is with this little script to your amazing work. Another benefit is that you will be scratching one item from you list while reducing the file size, increasing performance and simplifying installation while also adding the MP compatibility. If you have any particular need for the script I would be happy to adapt it for your particular needs.

Is your mission Multiplayer or Singleplayer?

Hey guys, I've just updated my MULTIPLAYER compatible lightweight Dog Scripts with working territorial FERAL DOGS and due to popular request now fully compatible with ACE 3! Anyways, more details below:

vDog Patrol and vDog Feral Scripts version 1.3 "FERAL DOGS" RELEASED! Release highlights/Changelog: - Now includes a brand new script that adds Multiplayer Compatible FERAL DOGS! to your missions by using just a trigger! (MORE DETAILS BELOW). These wild dogs roam their territory (trigger Area) in packs and viciously attack anyone who invades their space but will not pursue targets outside of this area. - Both the vDog Patrol and vDog Feral have a new damage model. Now the damage adds up the more the dogs bite a particular target. (Previously the damage was flat meaning that the dogs could never kill their target). - Added ACE 3 support! (The script will now defect if you are using ACE 3 and apply the correct damage commands that work with ACE MEDICAL). - Final tweaks to sounds volume/distance ratios. (Now dogs can be heard over longer distances). DOWNLOAD: Demo Mission version 1.3 DOWNLOAD Link (Google drive): https://drive.google.com/open?id=1T75uuzKGmTn29dWxYvtIEaNPxItY6Rb2 Demo Mission version 1.3 DOWNLOAD Link (Armaholic) http://www.armaholic.com/page.php?id=35026 vDog Feral Details:

I understand that AFAR currently limits itself to modifying the behaviour of the Group Channel but I don't understand completely disabling all of the other channels under all circumstances just because the script currently does not include the whole scope of communications. You see I've always imagined that each default Arma 3 Channel represented a different frequency and equipment used. So for example: 1) Player on foot without radio: Limited to Local (AKA mouth to mouth conversations) channel. 2) Player on foot with radio: Limited to Local and Group channels. 3) Player on vehicle (Supposing vehicle contains long range equipment and that the vehicular radio uses a frequency that is repeated using FOB antennas etc): Gains access to Side Channel. 4) Player on a radio specific installation or asset (Like a long range radio placed near a radio Antenna): Gains access to Global Channel. Sadly Arma 3 completely forgot to add those limitations and requirements for accessing each channel's benefits. Perhaps it would be in AFAR's interest and scope to do so... so instead of disabled channels we get: "You can communicate to your whole side but you need to be inside a vehicle with a much better equipment or inside a radio installation etc. I hope you get my point. Also disabling default Arma channels might lead to scripts and mods not communicating things correctly. Like: [unit1,"Kicked for cheating!"] remoteExec ["globalChat",0];

Sorry @oldbear! Its fixed now!

Greenfist... would it be possible for your amazing Yet Another Arma Benchmark to have a special tab or section that measures all the mission's running scripts individually and list them based on different parameters like memory usage, cpu impact and network bandwidth usage? So perhaps we can figure out what script/mod is causing the most performance drop in terms of memory, cpu and also network bandwidth. That would be just a dream come true for mission and even mod makers. Thanks for all your hard work on this must have tool of yours!

I want to congratulate IvosH_cz and any other War Machine dev... the mission is amazing and runs like a dream. No other mission this complex involving so many autonomous Ai runs this well. So this mission is a testament to the amazing things good coders and mission makers can do!

Hey Alert23, congrats on the release! Looking forward to playing it soon!

I found this script for Arma 2 and I was wondering if it would still work correctly for Arma 3. I have tried it on several helicopters and they all seemed to go down just as fast as without it. Script: if (!isServer) exitWith {}; _unit = _this select 0; _unit setVariable ["selections", []]; _unit setVariable ["gethit", []]; _unit addEventHandler [ "HandleDamage", { _unit = _this select 0; _selections = _unit getVariable ["selections", []]; _gethit = _unit getVariable ["gethit", []]; _selection = _this select 1; if !(_selection in _selections) then { _selections set [count _selections, _selection]; _gethit set [count _gethit, 0]; }; _i = _selections find _selection; _olddamage = _gethit select _i; _damage = _olddamage + ((_this select 2) - _olddamage) * 0.2; _gethit set [_i, _damage]; _damage; } ]; Run from Helicopter's Init: null = [this] execVM "heliHP.sqf"; PS: The 0.2 is supposed to be the damage multiplier. So 0.2 means the Heli Part that is being damaged should be only be getting 20% of the total damage.

I have to say that I am also getting micro stutters with the latest Ravage version. (And I have a super PC). It happens mostly while going fast on vehicles. I had to disable the Ai Module to reduce the stutters but they still happen occasionally. I am also getting this issue where after using the loot HoldAction an empty inventory screen pops up. (Before If it was empty Ravage would just show "its empty" and not opening the inventory screen.

Ok final attempt: Replace these lines (Original Script): _rdmBiteDamage = selectRandom [0.5,0.6]; _closestHuman setHitPointDamage ["hitLegs", _rdmBiteDamage]; Or these new lines: _humanDmgCheck = damage _closestHuman; _biteDamage = _humanDmgCheck + 0.3; _closestHuman setDamage _biteDamage; With This: [_closestHuman, 0.6, "leg_r", "bullet"] call ace_medical_fnc_addDamageToUnit;

Try this then: Replace these lines: _rdmBiteDamage = selectRandom [0.5,0.6]; _closestHuman setHitPointDamage ["hitLegs", _rdmBiteDamage]; With these: _humanDmgCheck = damage _closestHuman; _biteDamage = _humanDmgCheck + 0.3; _closestHuman setDamage _biteDamage; Please let me know if it works now.

I don't know how ACE3 damage works but the dogs currently only do LEG damage by using the following commands: _rdmBiteDamage = selectRandom [0.5,0.6]; _closestHuman setHitPointDamage ["hitLegs", _rdmBiteDamage]; That way the dog always cripples the target but never kills it. If that does not work with ACE3 you could try the most basic command so: Replace these lines: _rdmBiteDamage = selectRandom [0.5,0.6]; _closestHuman setHitPointDamage ["hitLegs", _rdmBiteDamage]; With these: _humanDmgCheck = damage _closestHuman; _biteDamage = _humanDmgCheck + 0.3; _closestHuman setDamage _biteDamage; Let me know if that works for you (and ACE3).

Somehow the error stopped popping suddenly... I changed nothing it just stopped out of nowhere... so I guess Arma? Still a fix for it not happening in the future is super welcome! So thanks for all your work and fixes!

Hello Phronk! About that feedback... here is mine: 1) The radio pop-up looks cool in mi opinion... and it is one of the most immersive features the script has for my players. If it is not too resource/bandwidth consuming then I vote on keeping it. In the worst case make it optional (as it already is I believe). But I am also not against a 2D radio that appears in its place if that means having better performance. (Something like the cellphones some Arma 3 Life servers have but in radio form could be cool!). 2) Not unless it is hurting performance in some way. 3) Having a 2D interface could be awesome in terms of immersion too, and I vote on its implementation but perhaps as a config/status tool that allows you to check you radio's current channel, change channels etc. About 3D interfaces vs SQF solutions: In my personal experience having integrated my own .HPP solution to my most recent mission... it is perhaps not the best alternative. My players are having the issue that the longer the mission server is on the longer it takes for the .HPP interface to load. It is like interfaces are delayed while the SQF scripts run incredibly fast. So I might be reverting my solution for something else. Unless you manage to avoid that interface slowing bug I would then recommend going for a SQF solution even if it doesn't look as good. (Players just wanna push a button and use the radio anyway, most don't care about complex interfaces but they do care about performance). About radio noise: Some radio noise is great for immersion but having it based on many factors could affect the script's performance in my opinion, so I vote on having a standard radio noise when using the radio keeping any kind of increasing radio noise to minimal etc. Just the regular noise you would have in police radios etc like what we hear in the movies but nothing too invasive... Communication is key in Arma and having it impaired makes players want to go to other (not impairing) solutions. Example: PS: Is see that you left the increasing radio noise based on overcast and that seem good enough as long as the noise increase is not too invasive. What would be better in my opinion is that the radio noise amount is based on the mission's dynamic simulation ranges, so if a player is outside the mission's dynamic simulation range the noise is the strongest and so you know that whoever is talking via the radio is very far away. That way the radio noise serves a purpose other than telling you that overcast is high etc... Doing something like that makes the noise have a purpose just like when you intended it represent range between players. Having a blast reading your changelog! Radio noise no longer uses attachTo! (This is very very good! It is a known fact that the attachTo command destroys multiplayer performance so delete that when possible as much as possible and keep it away from your scripts.) Removed: Radio range requirement (Until BI adds a local mute command): Great, whatever doesn't work as intended should be just removed. I know it is hard to undo your hard work but it is for the better, relying on BIS is not such a good idea these days. I also suggest that the script only modifies the radio Arma 3 channels behavior (like group comms etc) while leaving direct communication channel completely alone. By the way the amount of commands you've updated to their most recent and better counterparts is amazing! Anyway, that is my feedback so far, hope it helps 😃

That sounds orgasmic Phonk! Clean new code is always the best way to go... It happens to me that when I want to update old code, since I have learned so much since then, it is far better just to start over using the newer commands and just having everything as optimized as possible. I was going to tell PortalGunner to just wait for this new version to come out as probably most of his issues won't exist there thus not requiring any fixing at all.

@haleks I also have a question. If I wanted to add this MP Hit Eventhandler to the zombies via the zombies module: _zombie addMPEventHandler ["MPHit", { params ["_zombie"]; _rand = random 100; if (damage _zombie > 0 && (_rand > 60) && !(lifeState _zombie == "INCAPACITATED")) then { [_zombie] spawn { params ["_zombie"]; _zombie setUnconscious true; sleep (5 + (random 10)); _zombie setUnconscious false;}; }; }]; I tried using the Zombies Module's HIT EH field but it did not work. Any idea how I could do that via module? (I don't want to run a script to constantly check if zombies have the EH).

Great to hear about your progress Vandeanson! You are doing something unique here! By the way, are you still using GRAD for server storage or you came up with another solution?