Magirot

It's still there, but you need to first put your weapon away first. For example by putting it on your back with the default key 0.

I've not had the chance to test this yet, but it looks fantastic! Since the map requires AiA TP anyway, shouldn't that have some suitable buildings?

Thank you for the new version! Are these the last refuge of giants on purpose? D: spoiler image

TF_give_personal_radio_to_regular_soldier = TRUE; in init.sqf (or TF_give_personal_radio_to_regular_soldier = 1; in server's userconfig file) means commander radios will be given instead of rifleman radios, or you can use TF_defaultWestRiflemanRadio, TF_defaultEastRiflemanRadio etc to define the exact radios that ItemRadio will be replaced with. https://github.com/michail-nikolaev/task-force-arma-3-radio/wiki/API:-Variables https://github.com/michail-nikolaev/task-force-arma-3-radio/wiki/API%3A-Classes (but if it works already then I guess there's no problem)

http://feedback.arma3.com/view.php?id=18967 One more into the threads list.

Stiching is still missing the text for me. Though it works, it's just an empty box in the advanced menu. Anyone else have this? One of our players also managed to load themselves into a vehicle (as in he was attachTo'd 100m above the vehicle with hideObject) with the action menu, but I'm not sure if that happened due to desync.

Is this a special case for this unit, or is there some reason you can't use these variables in init.sqf to define the radios? TF_defaultWestBackpack = "tf_anprc152g"; TF_defaultWestPersonalRadio = "tf_anprc152"; TF_defaultWestRiflemanRadio = "tf_anprc152"; + East/Guer variants (variables, classnames).

In OFP / Arma 1 / Arma 2 you could use setFlagSide and setFlagOwner to set a unit as a flag carrier, like in a CTF match, after which it'd appear on their back. For infantry it mainly worked in humorous scenarios, but for vehicles it was great in "serious" missions too (screenshot). However, this visual representation seems to have been removed in Arma 3, or is there some other way to access it? Has anyone else tried it?

You should add a short sleep to the beginning of the spawn too; I've experienced it not being completely reliable in bypassing the randomisation otherwise. However, you don't need to switch the texture with setObjectTexture if you want to use one of the default textures in the "random pool", just use this in the init field: this setVariable ["color", 1]; changing the number to the colour you want (it's texture name minus 1, so red is 0, black is 1, etc. See kylania's post). And if you want to disable randomised textures (to use your own texture, for example) you can use: this setVariable ["BIS_enableRandomization", FALSE]; These have been in the game since 1.18 (April 2014).

Yeah, I did similar tests and they didn't see people who were prone. But as far as I know, the AI handles grass in such a way that it's not an obstacle to its vision per se, it just decreases the change of spotting the target if the target is below "grass level". This means that while it won't detect prone targets, it can spot units that are standing up even if the AI itself is prone in the field, since it doesn't see any obstacles in the way. Quality paint presentation.

Thanks for the report. We have fixed this. :) In the same file, _force doesn't get a value when you throw a dead guy into a bodybag: 19:55:10 Error in expression <; if (!local _unit) exitwith { [[_unit, _force], "cse_fnc_setDead", _unit, false> 19:55:10 Error position: <_force], "cse_fnc_setDead", _unit, false> 19:55:10 Error Undefined variable in expression: _force 19:55:10 File cse\cse_main\misc\functions\fn_setDead.sqf, line 20 Edit: Happens with a carriable copy of a dead player, I guess because they're alive game mechanics wise?

Also a small one south of Aakirkeby.

The phantom AI gunner doesn't seem to react to any commandWatch and lookAt commands either, which is interesting. Are there any other commands that might be used to influence it? Edit: Though I'm not sure if those commands should affect vehicle gunners in the first place.

This has probably already been noticed, but since the issue tracker doesn't have it: 19:32:07 Error Undefined variable in expression: _unit 19:32:07 File cse\cse_main\misc\functions\fn_setDead.sqf, line 34 _unit spawn { _playerDead = isPlayer _unit; <- _unit not defined yet private ["_unit","_counter"]; _unit = _this;

I understood from nkey's reply that this is currently already in, but only works with custom spectator scripts, since BI's own spectator system doesn't give anything to reference the current camera position.

I thought AGM already has the "automatically replace vanilla items with addon items" thing, at least when I last tried it? Or am I misunderstanding something?

Thanks for the new version! This is a great addition that should've really been part of CMS from the beginning. Are there plans to expand it in some way, for example to give it a few sets of items to choose from? "A few more bandages" option could be useful gameplay-wise, for example, given how many wounds you usually get. On that note, what about introducing some kind of automatic replacing of vanilla medical items? I remember it was pretty frustrating early on to run out of bandages and then be unable to use all those first aid kits the enemy had. I made my own script, but things like this should really be part of the mod. My script if someone is interested:

I'm with the 3d editor crowd in this. Setting each object up manually works if there's just a few of them, but if we're talking about hundreds of objects, using either the 3d editor or Zeus with the DynO Mapper (apparently doesn't work in A3) is the only sane choice. enableSimulation will work in MP as well if it's in the init field, since all clients execute them, and the command allows using global arguments. enableSimulationGlobal can be used if you need something that's executed only on one machine apply to everyone.

From the old thread: You might be interested in this: Maybe switching to floor helps with the results?

Depends on the vehicle, for most helicopters I think it's "engine" (or "HitEngine"?). Edit: "HitEngine", "HitHRotor" (main rotor), "HitVRotor" (tail rotor)

zlt_fieldrepair.sqf already has a respawn eventhandler without a variable check at the bottom, so the issue is more that if a player gets the action once, they'll get them for all units they subsequently respawn as too. But you're right, that'd guarantee that respawned units have it, and simply removing the last seven lines of zlt_fieldrepair.sqf shouldn't be too hard.

As mentioned in the first post, if you add engineers and repair specialists into the mission, they'll be able to use the game's own repair action which repairs everything in a flash. But you can simulate them by adding an "allow repair" variable to some units, and use the editor's "Description" field to signify their role. For example, an Explosives Specialist with Description "Engineer" and this as it's init: this setVariable ["allowRepair", TRUE, TRUE]; and in init.sqf: if isServer then { [] execVM "zlt_fieldrepair.sqf"; } else { [] spawn { waitUntil {!isNull player}; if (player getVariable ["allowRepair", FALSE]) then { [] execVM "zlt_fieldrepair.sqf"; }; }; }; It's not compatible with respawn (works with JIP though), and on a non-dedicated server the hosting player always gets the repair action. If this is enough for your needs then this should be the simplest method, otherwise zlt_fieldrepair.sqf needs modifying.

I don't quite understand initdedi.sqf. It checks if the cycled unit is a player, and then attempts to use the player command, which refers to the object controlled by the current client, which on a dedicated server is null. You should switch player to _x (the object being cycled by forEach allUnits) in this case. However, since initplayer.sqf already has a waitUntil {!isNull player}; check, I'm not sure what's the point of initdedi.sqf in the first place. Could you post the contents of competitorLoadout.sqf or civLoadout.sqf? Maybe something in those is the issue.

Did you remember this part:

You can use playableUnits + switchableUnits so it'll be compatible in both SP and MP; also "units" probably slipped there, since it isn't needed with playableUnits being a list of units already. Otherwise it should work. So you can set the trigger settings to "<player side> present" or "anybody present" and put this into your trigger's "condition" field: {_x in thisList} count (playableUnits + switchableUnits) == {alive _x} count (playableUnits + switchableUnits) To maybe help understand what it does: