Chewz

At the moment, if you monetise a server and then break the monetisation rules, Bohemia disable BattlEye on your server until you remove the violation - This essentially makes servers completely unusable, as not only is BattlEye disabled but your in-game chat is spammed stating the server is breaking Monetisation rules. In my personal opinion, a similar system should be implemented for reporting IP violations- You provide Bohemia with proof a community (or mod) has broken IP (in the form of screenshots, PBO.s containing the IP etc etc), and Bohemia can then make a judgement on what to do next. Whether thats by blocking the communities servers BattlEye, or removing the violating mod from the workshop. I must admit IP breaches has really pushed me away from wanting to release anything made on my end as there's literally nothing you can do to prevent some unnamed communities 'ripping' the content and reusing it for their own profitable means, which some communities still make even if the mod has not allowed any kind of monetisation.

But you shouldn't work DayZSA Assets under ArmA 3 in the first place?

No worries!

Hi man, you had any luck with this?

Your code doesn't make any sense. In order to get a position you simply need to do getPos <OBJECT>, not the array you did. When assigning the _unit variable, you've defined the unit as an array, which won't work for both the setPos and setDamage commands. This code below will work provided both t1 and t4 are assigned objects. _Pos = getPosATL t1; // Gets the position of object 't1' at the terrain level. t4 setPos _Pos; // Sets object 't4' to the position of 't1'; t4 setDamage 1; // Kills object 't4' (for some reason you want to do this) // Ideally you then should delete t1 // deleteVehicle t1;

That's strange. It sounds like the script is hanging on the waitUntil. Can you please change the onPause script to this: diag_log format ["ONPAUSE: ALIVE = %1", alive player]; diag_log "ONPAUSE: STARTED"; waitUntil {!isNull _pauseMenuDisplay}; diag_log "ONPAUSE: WAIT UNTIL PASSED"; _AbortButton = (_pauseMenuDisplay displayCtrl 1010); _AbortButton ctrlEnable false; sleep 10; _AbortButton ctrlEnable true; Once you have retested this, can you please send me your rpt (put it as a spoiler when you paste it in here) Thanks Chewz

Hi Yes, replace the myGroup variable with the variable name of your group, and provided your trigger only activates when you land, then yes you would put it in the 'on activation' section. Thanks Chewz

This should still work on single player, as you would be 'acting' as the server. Have you had any luck with this command? I'm worried the AI may still engage as they are already targeted on the desired enemy. I would have a look at @pierremgi's post in this forum post, as it seems to be a recurring issue! https://forums.bohemia.net/forums/topic/207330-how-to-make-a-run-ai-units-under-enemy-fire/?do=findComment&comment=3243056 Hopefully this helps, let me know if you don't have any luck 🙂 Chewz

Hi, Change ((findDisplay 49) displayCtrl 1010); to ((findDisplay 49) displayCtrl 104); Apologies, I got the idc numbers mixed up! Chewz

It'll be interesting to see. The script you linked looks very cool by the way! I've never seen a concept like that before I guess one downside of my method of not using checkVisibility is the impact of weather, as checkVisibility can be impacted by fog etc which TankBuster mentioned in your post, which is very cool! This could be included however; you simply include it in the waitUntil to ensure that you have line of sight and it is visible even after taking into account weather impacts. I'll be intrigued to see if you'll be able to get it to work though, and if there's a noticeable performance difference. Thanks Chewz

You could try to do the following: YOURSIDE setFriend [ENEMYSIDE, 1]; e.g, your team is blufor and the enemy team is opfor so you would do the following: BLUFOR setFriend [OPFOR, 1]; This command must however be ran on the server / host user, is this a single player or multiplayer mission you're making? Chewz

Good suggestion @atmo I imagine worldToScreen would be definitely better for checking one specific location (such as a specific building in the base, or the entrances), in a similar way to checkVisibility, but I think it would be extremely hard to do an efficient in area check for like a designated area defined by a trigger (such as an area with a 100m radius). It depends on the requirements! It would be certainly quicker if you only needed to check lets say for 1 house or a checkpoint, but would be very hard for checking an area (unless you have an idea as to how this may work?) ScreenToWorld allows you to check an entire area but with the compromise that you have to physically look at the base area rather than it just being within your field of view / peripheral vision I'm not sure, what do you think? Chewz

i'm puzzled honestly

Hi Try this for fn_queryRequest: https://pastebin.com/MBTUbiZD The fn_updatePartial looks good though! Chewz

Hi Apologies, I named the function wrong! I did HC_ instead of DB_ try this instead [_uid, _side, str(_side), 8] call DB_fnc_updatePartial;