AgentRev

Are those remote exec commands filtered by BattlEye's remoteExec.txt? If yes, then this whole thing is utterly useless for client-to-server stuff.

Dropping inventory items on the ground and shooting bullets are somewhat equivalent to createVehicle calls (as both are filtered by BE's createvehicle.txt), but otherwise a blank mission never uses createVehicle to spawn driveable vehicles client-side.

Mr. vital, the best place to post about such issues is over here: http://forums.a3wasteland.com/index.php?board=12.0

Telling which mag fits in which weapon is not the intended purpose of magazinesAmmoFull. If you want to find magazines that are compatible with the primary weapon, you have to cross-check the classnames with those defined in the weapon config: _magsAmmo = magazinesAmmoFull player; _magsAmmoPrimary = []; { _mag = _x; { if (_x select 0 == _mag) then { _magsAmmoPrimary pushBack _x; }; } forEach _magsAmmo; } forEach getArray (configFile >> "CfgWeapons" >> primaryWeapon player >> "magazines"); // Do stuff with _magsAmmoPrimary

The type value indicates in which kind of weapon the mag is loaded in, not the type of the magazine itself. Magazine configs don't really hold reliable info about which weapon type they "belong" to, as what kind of magazine a weapon can accept is defined in weapon configs. Take the 9mm 30Rnd Mag for example, it can be loaded in 9mm SMGs (primary) and pistols (handgun). The game can't say to which class it belongs to, it only knows in which weapons it can fit. Taken to the extreme, it could even be all of them at once (primary, secondary, handgun, vehicle). I don't understand what you're trying to do, but I'm sure there's another way to do it. ---------- Post added at 17:52 ---------- Previous post was at 17:41 ---------- What kind of half-decent coder would write case-sensitive code? If you don't run anim states in toLower or toUpper before using any of those commands, then you should be using ==. I say take it up a notch by having the engine randomize the case before returning the anim state.

I noticed that the RscCombo class from the main config has 3 parameters that I did not have in the combo class from my mission's description.ext: colorPicture[] = {1, 1, 1, 1}; colorPictureSelected[] = {1, 1, 1, 1}; colorPictureDisabled[] = {1, 1, 1, 1}; I added those to my combo class, and now pictures display fine without using lbSetPictureColor. I guess that these params were added not too long ago, and omitting them makes pictures invisible by default.

I have the same problem, kinda frustrating. Created a bug report: http://feedback.arma3.com/view.php?id=22201

Coincidentally, I was trying myself to add custom markers to A3W just an hour ago, and it turns out you can't do it without external addons (adding CfgMarkers in description.ext doesn't work). Even if you add them to a server-side PBO, anybody connecting to your server will need to have the same changes on their machine, otherwise they will get "config.bin/xxxxx not found" messages and won't see the custom markers.

Just wanted to bring everyone's attention to this issue: http://feedback.arma3.com/view.php?id=21613

Not sure this would have much effect, as GroundWeaponHolder's and mines are not PhysX objects.

Could a dev please elaborate on what "Added: Auto-INIT scenario server-side" from v1.36 means?

Hey Dwarden, is it possible for dedicated HCs to bypass all BE filters that apply to normal players? My filters are very restrictive due to the massive amount of scriptkiddies that attempt to ruin everyone's fun on a daily basis (ex.: no vehicles or civilian units can be created by players), and having the BE filters apply to the headless client greatly limits the kind of stuff that can be offloaded to it. I was expecting the new dedicated HC to bypass BE by default, but it seems that such a feature has not been considered or even discussed before.

Looks like BIS are not open to discuss this, so I guess the only logical solution is to manually triple the ammo of all the miniguns in my mission.

According to config, current direct damage of 6.5mm minigun ammo is equal to its rifle counterpart. It has a splash damage equivalent to 15% its direct damage, with a 1m area of effect. It's okay for firing at infantry from above, but the 67% reduction in fired bullets per mag makes them a lot less effective against vehicles.

There is no splash damage. Just plain ammo. The ammo counter matches the real fire rate but it's all smokes and mirrors, the minigun doesn't fire at that rate. EDIT: There seems to be a mix of splash and non-splash

Maybe you should reset the status of this ticket? http://feedback.arma3.com/view.php?id=18265

HandleScore EH does not persist after respawn. Since it's server only, it should definitely have been implemented via addMissionEventHandler, not addEventHandler.

I've been trying to get my mission working on a Linux server, but for some reason, I keep running into weird issues where calling scriptDone on some execVM threads always returns false, even if they are actually complete, which causes some waitUntil's to get stuck indefinitely. I don't have this problem on Windows. If I replace those execVM's by "spawn compile preprocessFileLineNumbers", then everything seems to work fine. I'm not quite sure what's wrong here. I don't know what exact circumstances cause this thing to happen, but it seems to change based on the presence of certain files and their size, regardless of if they are loaded at all during the mission. I do have one specific PBO for which the problem seems to happen 100% of the time, thought. Another strange observation is that it only seems to do it on Altis; swapping the mission.sqm to a Stratis one makes the problem disappear. As long as it's on Altis, regardless of the mission.sqm's contents, the problem happens if the circumstances are right. The weirdest observation I made so far is scriptDone always returning false for execVM'd files which only contain whitespaces and nothing else.

I experienced the same issues with v1.26 and v1.28, updates were simply not downloading anymore. Here's how I solved it without having to redownload the entire game: Exit Steam Open the SteamApps\common folder where Arma 3 is installed (usually C:\Program Files (x86)\Steam\SteamApps\common) Rename the Arma 3 folder to something else, let's say "Arma 3 backup" Open Steam Make sure a second time that the renamed folder is truly the one that contains the game Right-click Arma 3, select Delete Local Content, and press Delete Once the game shows as Not Installed, exit Steam Go back in SteamApps\common, and rename the previous folder back to "Arma 3" Open Steam Install Arma 3 under the same location containing your previous Arma 3 install (for the above example, that would be C:\Program Files (x86)\Steam) Notice that the installation should undergo a "Discovering existing files" step at some point Once the installation reaches "Steam is now downloading Arma 3", press Finish The download size will probably still be huge, like 7.7 GB for LostLeviathan above, since Steam has already deleted long ago the files it has judged as out-of-date Once Arma 3 is ready to play, normally you should be able to hop on servers with the latest version, and the game should now receive further updates as normal :) If it didn't work, then try restarting Steam again and do Verify Integrity of Game Cache If the previous step didn't work then try to do the whole thing again If the previous step didn't work again, then I'm afraid you might have to flush the Steam config as explained here, and do the whole thing again If none of the above has worked, then now you might have to consider reinstalling the whole game...

Hello everyone, Is there an addon, mod, or anything else that will make AI shoot at MRAPs (especially the tires) using small arms (7.62mm and lower)? Unless I give a rocket launcher or some other heavy weaponry to AI groups, they just start running around like headless chickens whenever an enemy MRAP comes close to them, even unarmed ones, and they just let themselves being run over. This is downright stupid, since we almighty humans can take out the front tire of an MRAP using a single 5.56 magazine, assuming correct aiming. I tried bCombat AI, ASR AI, and FFIS, but AI units continue to show absolutely 0 care and 0 intelligence whatsoever whenever they see an MRAP. They don't even run for cover unless I change their behaviour to "Stealth". Any suggestion? :confused: Thanks

Yep as Varanon said, they work via addWeapon, not addItem. They are considered weapons since you can hold the actual thing in your hand, unlike plain inventory items.

Fixing Arma 3 one community workaround at a time. Thanks MarkoCRO

Create a file named "initPlayerServer.sqf" at the root of your mission, and there you have it. _this select 0 = player object _this select 1 = JIP boolean

I'm not asking for it to be done, I am saying that it is the current behavior of "addMagazine" for vehicles. It allows you to add a magazine without specifying the turret, the command loads it automatically in the correct one, with minor exceptions as I mentioned. Try it, you'll see.

In the meanwhile, it is possible to use "vehicle addMagazine [class, ammo]" for vehicles. However, it doesn't work with all types of magazines, for instance smoke shells and flares. It also doesn't seem to work for commander HMGs on tanks. The only vanilla vehicle for which addMagazine shouldn't be used is the Ghost Hawk. Since the command tries to determine in which turret the magazine should be loaded based on the ammo it shoots, and it has 2 turrets shooting the same ammunition, they all end up in the left gun. ---------- Post added at 23:20 ---------- Previous post was at 23:07 ---------- Also in the meanwhile again, it is possible to "emulate" passing elements by reference, by passing them inside an array, accessing the value using "select 0", and changing the value by using "set [0, ...". It sure is a bit wacky, but it works. All arrays are always passed by reference, so as long as you change the values inside using "set", any other script accessing that array using "select" will see identical values. It is particularly useful when you need to spawn 2 threads that must share info, without using public variables.