flyingsaucerinvasion

[_unit, "HandGrenadeMuzzle"] call BIS_fnc_fire; The function BIS_fnc_fire, no longer works with CUP hand grenades. Still works with Arma 3's RGO hand grenade though. EDIT: Apparently each hand grenade has its own muzzle and I didn't know it. However, HandGrenadeMuzzle used to fire Cup grenades.

Self treatment must be abortable. It's extremely annoying to be shot while you can see an enemy taking aim at you, but you can't do anything about it just because of a stupid decision by the developers. Everyone who says that decision is realistic is wrong. By the way, you can't wait until an area is clear to treat yourself because the game doesn't let you move or aim when you're wounded.

Can anybody tell me why (specifically) Bradley fighting vehicles swerve wildly when being driven by an AI? They can take a REALLY long time to get anywhere, because they're driving in really tight wave patterns. This is how they're driving (not exaggerated): EDIT: It's happening in one of my complex custom missions. Does anybody know any AI group or individual state, or sqf commands that are known to or could cause this behavior?

I want to draw attention to several related, and serious bugs and problems concerning AI units firing hand held weapons with automatic fire: When the distance between the shooter and the player is less than 100 meters, then the ai is unable to compensate for recoil, and all but the first one or two shots in a burst always misses the target. One of the consequences of this is that AI machine gunners in the player's squad are almost never accurate. However, when the distance between the shooter and the player is greater than 100 meters, then the ai is able to compensate for recoil, and most shots in the whole burst are fairly accurate. Additionally, if the shooter is more than 100 meters from the player, or the shooter is more than 237 meters from its target, then the shooter's rate of fire drops dramatically. Additionally, the cadence of shots is faulty. The spacing between the first two shots, is usually much smaller than between subsequent ones. Sometimes the spacing between the first two shots is zero. Here's a Video Demonstrating the problems: https://youtu.be/g8V4T9oxMMQ If you're interested in adding your feedback to this issue, I've started a feedback bug report here: https://feedback.bistudio.com/T172180 Mission set up to demonstrate the problems: https://feedback.bistudio.com/file/download/oxrch6qcdn7inphwwalb/PHID-FILE-7daohk4cdsawnwzfib6x/AI_AUTO_FIRE_BUG_DEMO.VR.zip

AI should be the #1 priority for BI. There are so many problems, that have been longstanding for such a long time (decades). The new one I'm trying to find any kind of fix for regards ai Machine Gunners. They cannot control recoil when they are near the player, no matter what their skill is set to. And then when they are farther away, their rate of fire is really slow and stuttered.

When AI machine gunners are near the player, they are incapable of compensating for recoil. It doesn't matter what their skill level is. Also, "setUnitRecoilCoefficient" has no effect on them. But if the AI is more than like 50 meters away, suddenly the rate of fire for the AI machine gunners drops dramatically. Which a) sounds terrible, but also means more distant AI Machine gunners will have dramatically better control over their recoil than nearby AI machine gunners. So nearby AI machine gunners (aka guys in your squad) will have total shit accuracy no matter what, even if they have maximum skill settings. They just shoot up into the sky, and never hit anything. Something has got to be done about this!

I've noticed that often AI led groups have trouble deciding whether passengers should be inside or outside of vehicles. I run across an ai group in a vehicle, and 1 one or more passengers are repeatedly ejecting from the vehicle, and getting back in, doing that over and over again. It happens when the group is not near any enemies. If I'm standing nearby I can hear the ai leader ordering guys in and out continuously. I don't have any AI mods installed. Who else has noticed this problem?

Is there an event handler that fires when spent disposable launchers are dropped? I need to clean them up after a while.

Is there an event handler that catches the dropping of CUP disposable launchers? I need to clean them up after a while.

I didn't even know reforger was a thing intul about 20 minutes ago. The videos I've seen so far all gloss over what in my opinion is the most important factor. How is the new AI? Have they fixed any of the myriad of AI problems from previous arma games?

Get almost immediately a script error message saying "_previoustacomstate" is not defined. Don't know if this is related to the fact that very little seems to happen in the battlefield. One or two patrols seem to engage, an A10 takes off now and again, gets immediately shot down, and then pretty much nothing else happens.

Unless I'm mistaken, BIS_fnc_findSafePos doesn't check for moving objects, such as men, or vehicles. It's very important that vehicles don't spawn on top of men or other vehicles. Sometimes it seems to also miss structures that have been spawned in during the mission, example: a warfare bunker or the hbarriers surrounding it. It also seems to be my experience that BIS_fnc_findSafePos can return a position at the apex of a hill or mountain, because the apex is technically a low gradient, even though the area immediately around it is not. This is not suitable in cases where you are looking to find a place to put a structure, because the structure's perimeter foundation may end up hovering above the ground. Please correct me if I'm wrong about this.

Need help coming up with a solution to this problem. The requirements are: 1) Returned Position must be relatively flat. (i.e., not at a great slope, and not at the apex of a ridge or mountain). 2) Returned Position should be as close to the target Position as possible. (No returning positions hundreds of meters away when ones much closer would also meet the criteria). Most importantly: 3) Returned Position must be totally and completely devoid of anything that could possibly cause a collision issue. This includes, map objects, editor objects, moving objects (men and vehicles), as well as structures (buildings, ammo boxes, etc....) spawned in during the mission. 4) Position must be large enough to fit vehicles of any specific type. ---------------------------- I've got partial solutions to this problem that work most of, but not all of the time. And they fail all of the above requirements some of the time.

I couldn't find a good solution to this anywhere on google, so I'm gonna share what I came up with. To cancel a fire mission waypoint, such as this one: _wp = _arty_group addwaypoint [_target_pos,0]; _wp setWaypointType "SCRIPTED"; _wp setWaypointScript "A3\functions_f\waypoints\fn_wpArtillery.sqf"; _arty_group setCurrentWaypoint _wp; What I found that worked was to first move the waypoint somewhere where they can't shoot at it, pause for a few seconds, then delete the waypoint. NOTE: I have not yet tested this on mobile artillery. _wp setWaypointPosition [[1000000,0,0], 0]; //move wayoint somewhere where they can't shoot at it. sleep 5; //pause to let above waypoint movement to take effect, before deleting waypoints. _wp_count = (count (waypoints _arty_group)) - 1; for "_i" from _wp_count to 0 step -1 do { deleteWaypoint [_arty_group, _i]; }; ------- Here's a bonus piece of info: You can add dispersion to the fire mission by moving the waypoint a little bit periodically while the guns are shooting: _expire = time + 15; while {time < _expire} do { _wp setWaypointPosition [_target_pos, 75]; sleep 2; }; The artillery crew seems to adapt almost instantly to changes in the waypoint position. -------- Another piece of info: The artillery group used in conjunction with the fire mission waypoint doesn't have to be comprised of artillery of the same type, at least if you don't specify what kind of mag for them to fire. See here for more info on specifying the mag type.

I can now answer two of my questions. 1) To force a unit to fire a weapon muzzle using a specific mag: _unit reload [_muzzle,_mag]; _unit selectWeapon _muzzle; _unit fire _muzzle; It will take time for them to reload the mag (but only if it isn't already loaded. However, the delay caused by reloading the mag does not appear to stop them from firing the weapon. I don't really know if the "selectWeapon" function is needed, but it doesn't seem to cause any harm that I can see. 2) This script (see spoiler) gets the muzzle capable of firing a magazine. But only from the primary weapon. All it does is check each muzzle in the weapon until it finds one that contains the searched for "_mag" in that muzzle's possible magazines. "none" is returned if no muzzle can fire the magazine. ----------------------- I've not seen any way of firing on a position that doesn't involve using an invisible target. However, what I'm actually doing is just making them fire (in whatever direction they happen to be facing), and then I adjust the velocity of the fired projectile to set it on a parabolic course toward its intended firing position. Somehow, this seems easier to me than mucking around with invisible targets (in this context anyway).