galzohar

I'll need to see if I can get some players on the Dev branch for a test. It's hard enough to get enough in for a test on the release branch :( As for the group logic, it doesn't break when group A merges with group B as long as group A keeps its group and leader. I don't have a problem with groups being deleted, I have a problem with groups being disbanded and re-created without the user requesting it. If the user disbanded his group then he is responsible for configuring his new group: Selecting new spawn location, signaling when his group is ready to start the mission, choosing group radio channel. Those things don't make sense to be saved anywhere else. On the group I only save group-specific things that can be safely deleted once the group is deleted. However, groups shouldn't be deleted and re-created unless the player disbanded a group. Promoting should simply use the selectLeader scripting commands, which, in turn, should be fixed to work in multiplayer (if it hand't been fixed already). In my opinion, new groups should only be created when players leave/join/disband groups, and not when selecting a new leader or modifying anything else in the group that doesn't involve creating a new group (from the player's perspective).

Thanks for taking my feedback into consideration :) Why can't the selectLeader command be adjusted to work globally and be synchronized across the network? That way no need to create new groups. When I was using my own system I used selectLeader locally on each machine based on a global variable setting the leader's unit variable name, which made it possible to synchronize across the network, but required a repeated checks for the variable value to keep the group leader selection up to date locally. If selectLeader was global and correctly synchronized across the network, it would save all that trouble on top of saving the need to create new groups to select a new leader. I have to use groups to store game-relevant data because I have a lot of per-group scripting, such as squad leader picking insertion position and squad radio channel, as well as signaling to the server his group is ready to start the game. Creating a new group resets all the above to default values. While the scripts can handle it, it would be more user-friendly if they could be saved without extensive workaround scripts. As for reproducing the promotion, in DTAS mission I get this all the time. However it seems to require multiple players in the group (could not reproduce it with just 2 players, and it seems to sometimes depend on which players join the group). Maybe give it a try with a larger number of players (4-5). Using an improved variation of selectLeader might eliminate this issue, anyway.

As you can see I added the sleep .1; between the calls to TFAR_fnc_setSwChannel and TFAR_fnc_setAdditionalSwChannel, or should I add more? I don't want to add too much delay, because this delays the whole player initialization process at the start of a round. Note that that setSwChannel is always working as expected. Only the additional channel fails.

Hi, I still have a problem with the additional channel setting via script. Setting the normal channel works without issues. Code used: private ["_i", "_count", "_TFRChannel", "_radio"]; if (canHaveRadio) then { _count = count (assignedItems player); if (isTFR && canHaveRadio) then { _radio = "tf_anprc152"; //if (sidePlayer != attackerSide) then if (sidePlayer == east) then { _radio = "tf_fadak"; }; player linkItem _radio; // Wait for the new radio with ID to be added. waitUntil {[] call TFAR_fnc_haveSWRadio}; // Wait for server to assign squad channel if it isn't assigned. _TFRChannel = -1; waitUntil { _TFRChannel = (group player) getVariable ["TFRChannel", -1]; _TFRChannel != -1 }; // Set the short range channel to the squad channel. [[] call TFAR_fnc_activeSwRadio, _TFRChannel - 1] call TFAR_fnc_setSwChannel; sleep .1; // Set the additional channel to command channel (8). if (commandChannelEnabled) then { [[] call TFAR_fnc_activeSwRadio, 7] call TFAR_fnc_setAdditionalSwChannel; }; } else { player linkItem "ItemRadio"; }; }; This sets the channel but sometimes does not set the additional channel. commandChannelEnabled is initialized to true and only changed via an action script - An action I never used, so it should always be true, especially considering that sometimes the additional channel does get set. For complete mission, look up DTAS. Any idea why this isn't working? Am I doing something wrong or is this a problem with TFR? If it is TFR, will it be fixed? Currently, it is rather confusing when you sometimes have the additional channel set and sometimes not, and even when it is set, only the players who also have it set can hear you, while those who had the bug cannot hear.

Hi, I tried using the new group system but found some game breaking bugs: - Promoting will often show the promoted person as the leader on the left-hand side of the menu, but in practice the group leader is someone else as will be shown on the right-hand side of the menu. After that, nobody can promote anyone until the bugged players leave and re-join the group. This doesn't always reproduce but reproduces very often. - Promoting creates a new group rather than changing the leader, which means any variables set on the old group are deleted, breaking mission-related scripts that use the group to track mission data (such as group insertion position, rally point, etc). - Empty groups are not deleted. After leaving and joining enough times, you will reach the group limit, and no new groups can be created.

DTAS uses this mod (optionally, if server runs the mod). http://forums.bistudio.com/showthread.php?153398-Dynamic-Take-And-Secure-Randomized-Round-Based-No-Respawn-A-amp-D Soon it will be updated to use stuff from the latest version (mostly Hamas faction for defenders).

While I cannot reproduce it in a small test case, it seems like every time the player you spectate dies, Arma crashes. If anyone knows any workaround, please let me know, so that I can restore the spectator functionality. Version 1.12 - Worked around mission parameters bug introduced in Arma 3 version 1.44, which means time of day can no longer be changed. See 0024007. - Disabled spectator script due to Arma 3 crash bug introduced in Arma 3 version 1.44. - Removed workaround for fixed Task Force Radio bug. - Defenders can no longer prevent attackers from capturing by staying in the objective area. The only way to defend it is to kill any attackers attempting to enter. Attackers no longer have to clear the zone from defenders, they only need to enter it. - Default zone size reduced to 10 meters. - Attackers can now see the objective capture progress (in %). - IDF faction will now use equipment from latest IDF mod version. First post updated, including mission description.

Drogno, could you please at least grant permissions for someone else to pick up work on the mod?

IDF soldiers don't wear the flag anywhere on any piece of equipment. White and light blue colors don't fit on things that are supposed to be used in combat. Vest is just a re-skinned variant of default A3 vest that is most similar to a standard IDF vest. A new model of proper IDF vest is still WIP.

Version 1.05 - Remove workaround for no-longer-existing Task Force Radio bug which broken the mission with new Task Force Radio mission. - Change Zafir magazine class name for latest Arma 3 1.42 patch. First post updated.

We will be playing the new fixed version tonight at 18:00 GMT (20:00 Israel time) on the Arma-IL IDF PvP server. No mods required. Allowed mods: Task Force Radio (requires teamspeak), JSRS3, CBA_A3, STHUD_A3 and st_stamina_bar. Teamspeak and server IP are ts.arma-il.info (server port 2302). Events posted as usual on the Steam group: http://steamcommunity.com/groups/arma3pvpcommunity If all works, new version will be released shortly after the event.

Voice would first require someone who knows how to change soldier voices with custom ones...

All you need is respawn points (markers) and 2 teams with base respawn settings (in description.ext). No modules needed. Of course, for it to actually be good, you'll have to do some scripting.

https://community.bistudio.com/wiki/setGroupId To save myself some nasty multiplayer testing, does anyone know if setting this is synchronized on all machines (in which case I still need to know which machine to run it on), or if I need to run this on every machine for the command to take effect? Thanks.

Seems like new Arma version broke some stuff. I will investigate and fix it once I get home on April 25th (may take a few days to fix all issues). As I cannot access the game at the moment, so if anyone with scripting knowledge has any idea about which patch changes caused new DTAS issues, please list them to save me some time investigating.

Why not just let the player set his own view distance in graphics settings? Simply include absolutely no view distance script in your mission, and problem is solved :) Forcing the player to a fixed view distance makes the game ugly for those who have high-end machine and unplayable for those who have a low-end machine.

Hmm, maybe at least be able to do it when not in a game? As in, when TFAR is not connected is it possible to make it not constantly un-mute people?

In any case, the representation of those options in the mission.sqm should be in such a way that is easy to copy-paste from mission to mission, so that we can have the advantage of easy-to-use UI without the disadvantage of difficulty copy-pasting content.

That is a great answer, but to the wrong question :) I just want to mute someone specific regardless of what TFR is doing so that I never ever hear him at all whatsoever. Some people have hot mics and it's incredibly annoying, since they make nothing but noise. However, when locally muting them (as in, not being an admin), TFR just unmutes them a few seconds later, even when we aren't actually playing (so TFR is not connected for either of us).

Is it impossible to mute annoying players on teamspeak while Task Force Radio plugin is running?

Relying on the "group must be local *somewhere*" sounds like a bad idea, because while it might be local to the client when the server tries to execute the local command, the group might no longer be local to said client when he actually gets the BIS_fnc_mp broadcast. Remember that BIS_fnc_mp does not get executed simultaneously on all machines (due to network latency and processing required, which may take different time for different machines), and thus you might "fall through the cracks", so to speak, and the command will not be executed anywhere. We really need a more reliable system, as in make all commands global or at least server-global (as in, have global effect when executed by server). Something like selectLeader shouldn't require broadcasting SQF variables across the network - IMO it should have native support by the engine with a single scripting command executed on the server. Also, something like locking a group (making it private) or other general "join group" handling shouldn't have to be handled by the server - A client script can see the group is private and block the option to join it. Join requests shouldn't have to be sent to the server using SQF variable broadcasting, when joinSilent already synchronizes its results across the network anyway. To be honest, I already have a rather nicely working system for joining groups, but it has absolutely no user interface which makes it pretty ugly pure action menu stuff to call the functions and display the groups, and there are ugly scripted workarounds for engine quirks as well as the more rare engine quirks simply not handled. It would be really nice if the new group system can help bring those needed improvements (less ugly scripting to work around engine limitations and overall less stuff that need to be worked around, and of course the pretty UI), without adding any unnecessary SQF overhead. One more thing about dynamic groups in Arma, is that when a player joins to a slot of a unit that was already in a group, the game will place him back in the old group, which is bad for missions that use dynamic groups as that player probably never wanted to be in that group, plus the group may be private. I had to work around that by leaving the current player's group for all units upon mission init, however cleaner solutions can be implemented with engine support (like rejoining your old group if you are the same player, and not if you are using the same "slot", toggle-able with a description.ext option).

Would all groups created on the server be local to the server? Because I found it rather difficult to predict where a group would be local, and locality seems to change in a way difficult to predict. For example, empty group that was previously local to the last player who left it, will become local to the server only several seconds (or more) after it becomes empty. I guess everything would become easier if all groups are always local to the server. Is joinSilent reliable being executed on the machine where the joining player is local? I can see how things would work better if all is done on server-side, but for now I'm not sure if you can really keep everything local to the server and let the server execute all commands in a way that will work. Even commands that say on the wiki that they are global seem to not always work when the target is non-local, such as setDamage - #11873. Also, it might be a bit network-intensive to broadcast SQF variables instead of using engine synchronization to broadcast data (since it doesn't have the SQF overhead). But then again letting clients do anything with a global effect seems to cause a lot of trouble in Arma... In the end it would be really nice if all scripting commands would be possible to execute on the server rather than when the unit is local, even for commands that currently require locality.

Increasing brightness/gamma in-game will not increase the brightness/gamma of your recorded video. It'll just increase the brightness/gamma of the displayed image. If your monitor is excessively dark in a way that makes you need to increase brightness/gamma, you will need to do the same when viewing videos you or others have recorded (in your video player). After all, those settings are meant to help you make up for excessively dark/bright monitors, recording that would make your videos too bright/dark for anyone else who would view them on an average-brightness monitor. So, to make a long story short, it's not the game video being dark, it's your monitor being dark :) (or you really liking things to be extra-bright) In any case, this is just the way you see your own videos. If you upload them (without tinkering with brightness in editing software), others would see them just fine. Go ahead and give it a try.

Semi-transparent optics simply won't simulate the realistic effect properly. It'll just look bad and weird. The only way to get this right is a 3d view. Until we can have that at every home computer, we'll have to live with monocular view. Trying to simulate binocular view with a single monitor that is observed by both eyes simply won't work right.

I've had quite a few issues with group management scripts that use the simple existing joinSilent and selectLeader commands. Nothing fancy, just actions that execute said commands with the appropriate parameters. So far the main issues I've had with group management which required dirty work around tricks were: - Deleting of empty groups is difficult, but is necessary due to the maximum group count limit and overall trash cleaning. This is rather tricky since locality of groups is rather unpredictable, and non-local group seem to be impossible to delete. Deleting an empty group on a client seems to also cause issues (some players end up not seeing some of the groups correctly). - Synchronization of group leader across the network - Sometimes change of group leader is not synchronized, some will see one leader while others see another. Some more issues I haven't resolved: - On rare occasions, player will join a group but some will still see him as if he's not in the group, while others and himself will see him as being in the group. - Locking groups on server-side while handling scripts that rely on groups to not change. For example, iterating over all groups will usually cause unexpected behavior if a player switches groups during the script's execution. For example, a loop that assigns each player in each group to a seat in the group's vehicle - It will break if between assigning group 1 to assigning group 2, a player just happened to switch from group 2 to group 1 - He will not be assigned any vehicle seat! I'll post again if I come up with any additional issues I've encountered that are impossible/difficult to work around with scripting.