Jump to content

Recommended Posts

1. The problem with the script, aside from the description.ext script error apparently, is that the script doesn't work as intended with more than two players on a server. The maximum distance for the radio works fine, but like I said, the way it works is it simply checks if a player is in radius of another friendly player. The way I want it to work is that I want all players who aren't within radio range of you to be locally muted, to simulate being outside of range to communicate. Right now, it works fine if there's just you and another player. If there's more than 2 players on the same side, then the comms can be easily exploited. I already explained this in a previous post.

 

2. I don't want to resort to extreme noise to drown out the comms because that isn't immersive and is intrusive.

 

3. The say3D command does not effect player voice volume and does not allow the muting/unmuting of a player.

  • Like 1
  • Thanks 1
  • Sad 1

Share this post


Link to post
Share on other sites
12 hours ago, phronk said:

1. The problem with the script, aside from the description.ext script error apparently, is that the script doesn't work as intended with more than two players on a server. The maximum distance for the radio works fine, but like I said, the way it works is it simply checks if a player is in radius of another friendly player. The way I want it to work is that I want all players who aren't within radio range of you to be locally muted, to simulate being outside of range to communicate. Right now, it works fine if there's just you and another player. If there's more than 2 players on the same side, then the comms can be easily exploited. I already explained this in a previous post.

 

2. I don't want to resort to extreme noise to drown out the comms because that isn't immersive and is intrusive.

 

3. The say3D command does not effect player voice volume and does not allow the muting/unmuting of a player.

 

Its great to hear from you Phronk...

 

I just want to give you my opinion on what I think this script or perhaps a new one could address. 

 

You see, there is tremendous need in the community, specially those playing small COOP missions and such, for a simpler, script based task force radio (TFAR) replacement.

 

I think that was exactly what you intended with AFAR.

 

The only problem is that replicating all the task force features just by using scripts is rather difficult and perhaps... even unnecessary.

 

You see, most mission makers want the Addon-Free ArmA Radio perhaps not as much because of its advanced features but rather the Immersion creating ones... features like:

 

- The need to have a radio equipped to use communications other than the Direct Channel.

- The Radio noises and effects.

- The Radio that appears while talking.

- Having like 5 or 6 channels so that groups can communicate "safely" without having other groups of players hearing their communications so easily. (But having frequencies is too complex, channels is enough).

 

My point is... that perhaps the complex features you are mostly struggling with like:

 

- Players having interference over distances or blocking the hearing of certain players over certain conditions etc.

 

Are the least demanded and us mission makers could easily do without them for the sake of having a more immersive, fully working and lightweight radio script.

 

In a perfect world I would have your Addon-Free ArmA Radio but a lite version of its current form.

A version that is simplified to the core and giving us just the immersion features rather than the more technical/advanced ones. After all it is a game and not a radio operator simulator but in vanilla arma the radio item is like useless and there are no immersion creating features.

 

Anyway, that is my honest opinion. And I am super looking forward to having a lite version of AFAR that I can use in all my missions to give my players the extra immersion without the complexities or encumbrance of super complex scripts or third party external software etc.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Knowing myself I've probably done a stupid and that's why this hasn't worked, but I've put:

this addEventHandler["Respawn",{(_this select 0) setUnitTrait ["RTO", true, true]}];

In the inits of two units, and neither of them get the support channel when they load in to the game. They're ungrouped and within 100m of each other, with radios. 
I hope it's something simple I've missed. Tested with players and AI in the slots.

Edit: Aside from that I think LSValmont makes a good point. The interference/distance feature is not the only unique feature AFAR gives us, and it's certainly a worthy mod even without it. 

Edited by PortalGunner
  • Like 1

Share this post


Link to post
Share on other sites

That's a fair point and I understand what you mean now. I can see why that'd be interesting to use on a vanilla server.

 

I may do a separate version rewrite to be cleaner/more optimized and function without the range/distortion effects. Also from my tests, setUnitTrait persists automatically through respawns, so the respawn eventHandler may not be necessary. Not sure why it isn't working for you, but I also haven't looked at the code in months or a maybe even a year. I'll look into tonight maybe and start working on the separate version with distance/distortion.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
1 hour ago, phronk said:

That's a fair point and I understand what you mean now. I can see why that'd be interesting to use on a vanilla server.

 

I may do a separate version rewrite to be cleaner/more optimized and function without the range/distortion effects. Also from my tests, setUnitTrait persists automatically through respawns, so the respawn eventHandler may not be necessary. Not sure why it isn't working for you, but I also haven't looked at the code in months or a maybe even a year. I'll look into tonight maybe and start working on the separate version with distance/distortion.

That sounds good to me 👍
I believe I tried it without an eventHandler and it still wouldn't work. Works fine on your pre-made mission though 😕
I'll keep looking for a solution.

Share this post


Link to post
Share on other sites
9 hours ago, phronk said:

That's a fair point and I understand what you mean now. I can see why that'd be interesting to use on a vanilla server.

 

I may do a separate version rewrite to be cleaner/more optimized and function without the range/distortion effects. Also from my tests, setUnitTrait persists automatically through respawns, so the respawn eventHandler may not be necessary. Not sure why it isn't working for you, but I also haven't looked at the code in months or a maybe even a year. I'll look into tonight maybe and start working on the separate version with distance/distortion.

 

Thank you so much phonk! You are a godsend!

Share this post


Link to post
Share on other sites

How do you reckon I should go about adding RTO to all Pilots (and possibly Artillery too)? I noticed auto-adding was removed with v0.8, but don't know how to replace that functionality (atleast elegantly) for just the two roles I mentioned. Sorry if I'm asking so many questions btw ^^; If I might suggest something, could the auto-adding be added as a toggle in CFG.sqf? Or was there another reason it was removed.
I hope you continue development phronk!

Edit: Going to try this

Edit2: Got it working:

Spoiler

description.ext


class CfgFunctions
{
	#include "functions\functions.hpp"
};

functions/functions.hpp


class TAG
{
	tag = "TAG";
	class functions
	{
		file = "functions";
		class capableRTO {};
		class vehicleRTO {};
	};
};

initPlayerLocal.sqf


if (player != player) then {waitUntil {player == player};};
[] call TAG_fnc_vehicleRTO;

functions/fn_capableRTO.sqf


_veh = vehicle player;
_typeVeh = typeOf _veh;
_isAir = _veh isKindOf "Air";

if (!alive player) exitWith {false};

if !(driver _veh == player) exitWith {false};

if (isNumber (configFile >> "CfgVehicles" >> _typeVeh >> "artilleryScanner")) then {
	_isArty = getNumber (configFile >> "CfgVehicles" >> _typeVeh >> "artilleryScanner");
};

if ((_isArty != 1) && !(_isAir)) exitWith {false};

true

functions/fn_vehicleRTO.sqf


_isArty = 0;
_isRTO = player getUnitTrait "RTO";
if (_isRTO) exitwith {};
while {true} do {
	sleep 1;
	_veh = vehicle player;
	_typeVeh = typeOf _veh;
	if (isNumber (configFile >> "CfgVehicles" >> _typeVeh >> "artilleryScanner")) then {
		_isArty = getNumber (configFile >> "CfgVehicles" >> _typeVeh >> "artilleryScanner");
	};
	if (call TAG_fnc_capableRTO) then {
		player setUnitTrait["RTO",true,true]; 
	} else {
		player setUnitTrait["RTO",false,true]; 
	};
};

 

 

Share this post


Link to post
Share on other sites

So the script I posted in my previous comment successfully manages who has the RTO traits, but it seems with some initial testing there's some problems with AFAR recognising the changed trait when its applied. Is there something I can call that will refresh it? Thanks.

Share this post


Link to post
Share on other sites

The AFAR code might be broken, but I'll try to get it fixed in the next update. I'm rewriting a lot of it to be more efficient. A lot has changed, so I can't really attest to what'll fix it. I think my way of troubleshooting was by cycling through radio channels to get correct permissions on the radio via the radio interface. If that doesn't work, just wait for the next update.

  • Like 2
  • Thanks 2

Share this post


Link to post
Share on other sites
17 hours ago, phronk said:

The AFAR code might be broken, but I'll try to get it fixed in the next update. I'm rewriting a lot of it to be more efficient. A lot has changed, so I can't really attest to what'll fix it. I think my way of troubleshooting was by cycling through radio channels to get correct permissions on the radio via the radio interface. If that doesn't work, just wait for the next update.

 

That sounds orgasmic Phonk! Clean new code is always the best way to go... It happens to me that when I want to update old code, since I have learned so much since then, it is far better just to start over using the newer commands and just having everything as optimized as possible.

 

I was going to tell PortalGunner to just wait for this new version to come out as probably most of his issues won't exist there thus not requiring any fixing at all.

Share this post


Link to post
Share on other sites

For those interested, I actively update this change-log as I continue to make progress on the script.

 

Feedback is needed on the pop-up radio: is it really necessary? I'd like to work towards completely removing the radio to help improve performance/efficiency. There's a few routes I can go. You guys let me know which you prefer:

  1. Keep the pop-up radio as it is
  2. Completely remove the radio
  3. Convert 3D radio to 2D as an interface (Using cutRsc / titleRsc)

I'm also torn between rewriting the 3D radio interface into a 2D radio interface via .SQF instead of .HPP (Makes script easier to install to your mission, but radio interface will look like shit). Finally, I'm reworking the radio noise: I'm either completely removing it or make the noise intensity vary based on rain, overcast, time of day, and possibly line of sight. Maaaybe powerlines and stuff like that too can effect it, but I don't wanna get crazy just yet.

 

Again, your feedback is appreciated!

  • Thanks 3

Share this post


Link to post
Share on other sites
14 hours ago, phronk said:

For those interested, I actively update this change-log as I continue to make progress on the script.

 

Feedback is needed on the pop-up radio: is it really necessary? I'd like to work towards completely removing the radio to help improve performance/efficiency. There's a few routes I can go. You guys let me know which you prefer:

  1. Keep the pop-up radio as it is
  2. Completely remove the radio
  3. Convert 3D radio to 2D as an interface (Using cutRsc / titleRsc)

I'm also torn between rewriting the 3D radio interface into a 2D radio interface via .SQF instead of .HPP (Makes script easier to install to your mission, but radio interface will look like shit). Finally, I'm reworking the radio noise: I'm either completely removing it or make the noise intensity vary based on rain, overcast, time of day, and possibly line of sight. Maaaybe powerlines and stuff like that too can effect it, but I don't wanna get crazy just yet.

 

Again, your feedback is appreciated!

 

Hello Phronk! About that feedback... here is mine:

 

1) The radio pop-up looks cool in mi opinion... and it is one of the most immersive features the script has for my players. If it is not too resource/bandwidth consuming then I vote on keeping it. In the worst case make it optional (as it already is I believe). But I am also not against a 2D radio that appears in its place if that means having better performance. (Something like the cellphones some Arma 3 Life servers have but in radio form could be cool!).

2) Not unless it is hurting performance in some way.

3) Having a 2D interface could be awesome in terms of immersion too, and I vote on its implementation but perhaps as a config/status tool that allows you to check you radio's current channel, change channels etc.

 

About 3D interfaces vs SQF solutions: In my personal experience having integrated my own .HPP solution to my most recent mission... it is perhaps not the best alternative. My players are having the issue that the longer the mission server is on the longer it takes for the .HPP interface to load. It is like interfaces are delayed while the SQF scripts run incredibly fast. So I might be reverting my solution for something else. Unless you manage to avoid that interface slowing bug I would then recommend going for a SQF solution even if it doesn't look as good. (Players just wanna push a button and use the radio anyway, most don't care about complex interfaces but they do care about performance).

 

About radio noise: Some radio noise is great for immersion but having it based on many factors could affect the script's performance in my opinion, so I vote on having a standard radio noise when using the radio keeping any kind of increasing radio noise to minimal etc. Just the regular noise you would have in police radios etc like what we hear in the movies but nothing too invasive... Communication is key in Arma and having it impaired makes players want to go to other (not impairing) solutions. 

Example: 

 

PS: Is see that you left the increasing radio noise based on overcast and that seem good enough as long as the noise increase is not too invasive.

What would be better in my opinion is that the radio noise amount is based on the mission's dynamic simulation ranges, so if a player is outside the mission's dynamic simulation range the noise is the strongest and so you know that whoever is talking via the radio is very far away. That way the radio noise serves a purpose other than telling you that overcast is high etc... Doing something like that makes the noise have a purpose just like when you intended it represent range between players.

 

Having a blast reading your changelog!

 

Radio noise no longer uses attachTo! (This is very very good! It is a known fact that the attachTo command destroys multiplayer performance so delete that when possible as much as possible and keep it away from your scripts.)

Removed: Radio range requirement (Until BI adds a local mute command): Great, whatever doesn't work as intended should be just removed. I know it is hard to undo your hard work but it is for the better, relying on BIS is not such a good idea these days.

 

I also suggest that the script only modifies the radio Arma 3 channels behavior (like group comms etc) while leaving direct communication channel completely alone.

 

By the way the amount of commands you've updated to their most recent and better counterparts is amazing!

 

Anyway, that is my feedback so far, hope it helps 😃

 

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for the detailed feedback. I won't be releasing the script this weekend, but likely this week or next weekend if things go well. Currently fixing bugs and adding the ability to configure the settings in-game for your own personal liking (client-side settings, of course). I'd go over the full list of changes I've done in the past couple days, but the change-log speaks for itself. Quite a bit more to come. Already have some cool experimental ideas for the version to come after, too.

 

Since I won't be doing a release this weekend, here's the new pop-up radio when holding a PushToTalk key down:

Spoiler

Short Range Radio (Group Channel)
K5rHj3X.jpg

Long Range Radio (Command & Support Channel)

utxFkPp.jpg

 

  • Thanks 3

Share this post


Link to post
Share on other sites

I think that interface is pretty out of the way, so 👍
I honestly thought it would take longer so if it's coming out in the next week or two then.. awesome!
Also, just want to get some confirmation on your plans for Global chat - it was available in the same way Direct was in the last release, which didn't seem right. 
At the same time if Allied channels are completed that would be cool! But either way I'm glad you decided to rewrite this addon. 

  • Like 1

Share this post


Link to post
Share on other sites

Global and Side chat are strictly unsupported by the script -- AFAR is not designed to be run with those channels enabled. Enabling them will cause problems. With that said, Arma 3 forces Global channel enabled for the logged-in admin -- there's nothing I can do about it. Everyone else it should be disabled for, though. Probably won't add the "Allied" channel because yet another voice channel might be too clunky and I don't play PVP or TVT type missions anyway.

 

The script is basically ready for release, but waiting to add the new client-side settings interface and test the script thoroughly with 2+ other players to ensure there are no script errors. So far in tests with 1 other player, almost everything is working as intended.

  • Like 2

Share this post


Link to post
Share on other sites

I'm free most of the time if you need another tester. (Though when I post this it is 9:30pm here)
I actually didn't know Global was forced for admin - so I guess that's why I had it. And although I would request you eventually add the Allied channel, I understand if that's out of the scope of the addon. 
At the same time I hope the support channel is more compatible with mid-mission application of the RTO trait (or was that replaced completely by the list?) ^^; 

Share this post


Link to post
Share on other sites

The new RTO setting in the CFG.sqf just adds the RTO trait to any units in that array. You can easily add and take away the RTO trait from players mid-mission. Additionally, you can also change the channel permissions on the fly also. For example:
 

r_vCH = [ FALSE, FALSE ];

Will completely disable Vehicle chat from being accessible, even in the radio interface, until at least one element in that array is true. (Only in new verison, not possible in old version)

  • Like 1

Share this post


Link to post
Share on other sites
14 hours ago, phronk said:

Global and Side chat are strictly unsupported by the script -- AFAR is not designed to be run with those channels enabled. Enabling them will cause problems. With that said, Arma 3 forces Global channel enabled for the logged-in admin -- there's nothing I can do about it. Everyone else it should be disabled for, though. Probably won't add the "Allied" channel because yet another voice channel might be too clunky and I don't play PVP or TVT type missions anyway.

 

The script is basically ready for release, but waiting to add the new client-side settings interface and test the script thoroughly with 2+ other players to ensure there are no script errors. So far in tests with 1 other player, almost everything is working as intended.

 

I understand that AFAR currently limits itself to modifying the behaviour of the Group Channel but I don't understand completely disabling all of the other channels under all circumstances just because the script currently does not include the whole scope of communications.

 

You see I've always imagined that each default Arma 3 Channel represented a different frequency and equipment used.

 

So for example:

 

1) Player on foot without radio: Limited to Local (AKA mouth to mouth conversations) channel.

2) Player on foot with radio: Limited to Local and Group channels.

3) Player on vehicle (Supposing vehicle contains long range equipment and that the vehicular radio uses a frequency that is repeated using FOB antennas etc): Gains access to Side Channel.

4) Player on a radio specific installation or asset (Like a long range radio placed near a radio Antenna): Gains access to Global Channel.

 

Sadly Arma 3 completely forgot to add those limitations and requirements for accessing each channel's benefits.

 

Perhaps it would be in AFAR's interest and scope to do so... so instead of disabled channels we get: "You can communicate to your whole side but you need to be inside a vehicle with a much better equipment or inside a radio installation etc. I hope you get my point.

 

Also disabling default Arma channels might lead to scripts and mods not communicating things correctly. Like: [unit1,"Kicked for cheating!"] remoteExec ["globalChat",0];

Share this post


Link to post
Share on other sites

I'm pretty sure scripted chat commands will still go through, despite the channel they're being sent through is disabled. As far as I understand, it just disables your player unit from being able to type or use pushToTalk / VoiceOverNet. If I'm wrong, I'll look into it.

 

One of the reasons why I made AFAR was because every public server I have ever played on has a bunch of morons flooding comms on either Global or Side chat. This will help filter the banter or at least that's the goal, while "enhancing" immersion. Enabling Side or Global on any server always inevitably results in everyone creating their own solo Rambo group and then talking on Side. I'm not interested in appeasing that crowd. As far as being able to communicate with your side members outside of your group, that's what Command and Support channels are for. And to clarify about my above post, Vehicle channel is enabled by default, I was just showing how you could dynamically change the variable/setting (must be done globally via debug window or remoteExec).

 

To recap the channels:
Direct Channel: The only channel, aside from Spectator, which doesn't require a radio to talk in. Projects voice in 3D proximity of your character, unless you are dead, isObjectHidden, or isNull (Hasn't spawned yet), or if you're underwater without a rebreather.

Command Channel: If you're the leader of your group, you get access to Command channel to speak with other leaders. May make it so that at least 1 other player has to be in your group to get access to Command net, since you can technically just form your own group and magically get access to Command channel.

Group Channel: Allows you to communicate with everyone in your group.

Vehicle Channel: Allows you speak with everyone in your vehicle.
Support Channel: Allows any player with Bob setUnitTrait ["RTO" , TRUE , TRUE ]; to communicate with others who have access to the Support channel, including pilots, copilots, gunners, commanders, and sometimes drivers, as long as they are in the right seat of the vehicle and vehicle type.

Spectator Channel: If the Arma 3 Spectator revive respawn template is set in the mission, dead players can only talk in the Spectator channel until they respawn.

 

[EDIT]

Someone brought it to my attention that they feel the "Transmitting...", "----------------", and "^v^v^v^v^v^v^v^" hints when transmitting could interfere with certain missions which display critical objective info via hints, such as side missions. Should this become an optional feature or removed entirely?

  • Like 2

Share this post


Link to post
Share on other sites
4 hours ago, phronk said:

Support Channel: Allows any player with Bob setUnitTrait ["RTO" , TRUE , TRUE ]; to communicate with others who have access to the Support channel, including pilots, copilots, gunners, commanders, and sometimes drivers, as long as they are in the right seat of the vehicle and vehicle type.

Spectator Channel: If the Arma 3 Spectator revive respawn template is set in the mission, dead players can only talk in the Spectator channel until they respawn.

 

[EDIT]

Someone brought it to my attention that they feel the "Transmitting...", "----------------", and "^v^v^v^v^v^v^v^" hints when transmitting could interfere with certain missions which display critical objective info via hints, such as side missions. Should this become an optional feature or removed entirely?

 

In my opinion hints should be a last resort as so many scripts use them. Is it a viable option to have a fake LED on the radio interface that acts as the "Transmitting" light (long-range radio could have something on the LCD screen)? Or possibly a fake switch/button that gets pushed in whenever you're transmitting? Possibly not viable but I'm just trying to think of options. 

Also, does this mean you plan to readd the Support Channel becoming available for gunners, commanders etc.? If I may, could I request this feature be optional? Kind of removes the point of my 'Artillery & Pilots only' script. The way our missions play out I'd rather not have every tank able to have access to the Support channel. 

I think the only use our group has for the Global Channel is communicating with Zeus when he's changed sides. We usually do it over Discord, but sometimes its nicer to do it in-game (I know AFAR doesn't support Zeus yet). As such I'm content with losing access to that.

I think the only other thing I can think of to mention is that it would be useful if we had a classname array we could add radios from mods to (like Radio Backpacks = long-range radio access; ACE radio; etc.). Probably not important at this point but something to think about.

Anyway, don't rush the release!

Share this post


Link to post
Share on other sites

What I can do is rename the "Support" channel to "Air" and make it accessible only to players with the RTO trait or a player who is a pilot, copilot, and gunner (Not including door gunners).

 

Will also most likely replace the short range "walkie talkie" radio model, used only for Group channel, with the big radio with the screen since that's what all other channels use. It'll make it easier to move the transmitting text to the screen of the radio across all channels too.

  • Like 1

Share this post


Link to post
Share on other sites

I think a toggle for the entire auto-access would be better, as it allows people to make their own custom solution for it. But that is just my opinion. 
Replacing the short range model would also make it identical to the radio icon.. which is a good thing, I guess!

Share this post


Link to post
Share on other sites
On 4/21/2019 at 8:12 PM, phronk said:

One of the reasons why I made AFAR was because every public server I have ever played on has a bunch of morons flooding comms on either Global or Side chat. This will help filter the banter or at least that's the goal, while "enhancing" immersion. Enabling Side or Global on any server always inevitably results in everyone creating their own solo Rambo group and then talking on Side

 

I completely agree, that is why adding those requirements (being on vehicles or radio installations or having to use heavy radios that are unpractical to have on your inventory) in order to be able to access those Global and/or Side chat etc channels would fix the "flooding issue" without disabling the channel completely.

 

I just don't know if adding those kind of limitations for specific channels is doable in the scope of a script but perhaps it is. (Checking if player is inside vehicle and if vehicle has long range frequency radio on its inventory or checking if player is near a specific building or object is easy script wise).

 

Anyway, I hope the new version is coming along nicely, can't wait to add it to my mission.

Share this post


Link to post
Share on other sites

[Development News]
Although my plan was to release version 0.9 tonight, there are some annoying bugs that need to be fixed first. Primarily related to a persistent radio noise bug that is caused by holding down the PTT key and getting incapacitate or killed. It's mostly fixed, but still working on it. That's the main thing I'm working on. Additionally, I might add an option to disable the channel switching keybinds to enforce having to use the radio interface. Otherwise, there's a big difference between v0.8 and v0.9: better optimization, smaller filesize, less bugs, more functionality, more options to play around with, etc. It's difficult for me to get a lot of players to test a multi-faction mission to see if the radios work as intended. My main concern is that I started using playerSide which supposedly has issues with teamSwitching and JIP compatibility, but has worked fine for me so far. Expect a release sometime this week or next weekend for sure.

PS: Decided to hold off on adding text to the radio -- it wasn't visually appealing enough, but I will revisit the idea in v1.0 probably. For now, I've removed the transmitting hints.

  • Thanks 3

Share this post


Link to post
Share on other sites
11 hours ago, phronk said:

[Development News]
Although my plan was to release version 0.9 tonight, there are some annoying bugs that need to be fixed first. Primarily related to a persistent radio noise bug that is caused by holding down the PTT key and getting incapacitate or killed. It's mostly fixed, but still working on it. That's the main thing I'm working on. Additionally, I might add an option to disable the channel switching keybinds to enforce having to use the radio interface. Otherwise, there's a big difference between v0.8 and v0.9: better optimization, smaller filesize, less bugs, more functionality, more options to play around with, etc. It's difficult for me to get a lot of players to test a multi-faction mission to see if the radios work as intended. My main concern is that I started using playerSide which supposedly has issues with teamSwitching and JIP compatibility, but has worked fine for me so far. Expect a release sometime this week or next weekend for sure.

PS: Decided to hold off on adding text to the radio -- it wasn't visually appealing enough, but I will revisit the idea in v1.0 probably. For now, I've removed the transmitting hints.

 

Amazing news Phronk!

I vote no on:  disabling the channel switching keybinds. (It is better to have two ways of doing things just in case the interface glitches or has delays (happens when the client FPSs is low).

I vote yes on: Not adding transmitting hints... the radio sounds are feedback enough. Perhaps the interface could have a blinking light that turn green while talking and red while not or something.

 

PS: I have a LAN with 10 pcs and we play every weekend so I will do a multi faction test!

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×