nkey

You can try next beta preview version - https://github.com/michail-nikolaev/task-force-arma-3-radio/raw/master/releases/0.8.2.zip It is not carefully tested yet (not released), so use on your own risk :) UPDATE: (some issues with spectator mode currently)

Yes, I know ;) But you should run addItemCargoGlobal only for server...

Hi, I have tested this additemcargo ["tf_fadak_999", 1] with vehicles and ammo boxes and everything work correctly... Regarding 152\148 - I think it is know issues with BTC Revive compatibility. Regarding long range radio - looks like mission changes groups on the fly, so after start everyone in the same group. So, it is may be solved by putting a few LR radios in the same box.

Actually it is possible to change frequencies in ACRE too, but anyway thanks for feedback :)

Next release more maintenance-specific, not a lot of new functionality. You can check closed tickets here and open here. Basically: a lot of bugfixes, new DSP effect for LR and personal, same frequencies for groups (optional - team), some API, ability to setup stereo channels on radio, time-critical code moved to non-scheduled environment, etc.

As far as I remember initialization line code is run on server, so on dedicated server you will not get any effect. In case of your server - each commands will be run on you PC. If you can wait for a little (update almost ready) - in next version every unit in the same group have same frequencies by default.

Thanks, already fixed in dev version. ---------- Post added at 12:04 ---------- Previous post was at 12:02 ---------- If you are not planning to play for the very long time per mission you may add them in inverse direction: tf_anrprc152_999,tf_anrprc152_998,tf_anrprc152_997...

They are named tf_anrprc152_x, tf_anrprc148jem_x, tf_fadak_x where "x" - is unique number of the radio. So, you should not give radios by youself because server needs to be sure what all radio radio items are uniqueness.

Could you please provide some images?

3) Try to increase "Options > Payback > Sound Pack Volume" in TeamSpeak. +1) Will think about, but currently you may use long range radio for communications also (20km). +2) Have some ideas to allow switch radio to loud mode, but not easy technically +3) Planned for future +4) Not sure it is really required. Also, may be done using some scripts. +5) You mean radar to detect radio communications? Planned for future.

Please check previous posts, there is someone with explanation how to change values by adding some code to init.sqf. UPDATE: Nevermind, found it. Add to init.sqf: tf_west_radio_code = "_alliance"; tf_east_radio_code = "_opfor"; tf_guer_radio_code = "_alliance"; ---------- Post added at 09:04 ---------- Previous post was at 08:59 ---------- Already fixed in dev version (not released yet). Also, you may try to update BTC-revive for your map (if it is used).

Thanks for feedback. 1) Known issue, already fixed in dev version. Currently reaload TS plugin in such cases as workaround. 2) Are you sure? Maybe you somehow have radio item cloned? (same radio item for several players) 3) Not sure I get you... Could you please explain in details? Clicks=Beeps? Yes, stereo settings will be implemented soon (new maintenance build almost ready).

I wrote post to VAS thread, so lets wait for some results.

Hello. Could you please add minor change to script - if item is inherited from ItemRadio then skip it, or replace with ItemRadio. It will help to be more compatible with modes like FTAR or ACRE. You can get some details here - http://forums.bistudio.com/showthread.php?169029-Task-Force-Arrowhead-Radio&p=2574390&viewfull=1#post2574390 To check if item inherited from "ItemRadio" you may use this code: (configname inheritsFrom (configFile >> "CfgWeapons" >> _item)) == "ItemRadio"

Currently I need to check problem myself - but looks like one only way to fix it in clear way is to add some changes into Virtual Ammo Box (to replace all items inherited from ItemRadio to ItemRadio).

Wow, cool. Could you please create MD file, like this one - https://raw.github.com/michail-nikolaev/task-force-arma-3-radio/master/README_EN.md ---------- Post added at 11:55 ---------- Previous post was at 11:52 ---------- It is possible to disable automatic backpacks - check in documentation. Also, you always able to get old backpack from the ground. Regarding multiband - yes, I have some plans. I want to add subchannels support for personal radios, and multiband support for long range radios. ---------- Post added at 12:00 ---------- Previous post was at 11:55 ---------- Could you please provide some ways to reproduce issue? Also, it is not a good idea to save radio item into ammobox.. Because they should be given by the server. Will try to concat Vitual Ammo Box System authors...

Thanks for tutorial :)

Check for "tf_no_auto_long_range_radio " at http://radio.task-force.ru/en/

In one of next version I'll add way to specify overall level of volume (for both radios and direct speech). So, you will be able to call it from the script. Is such feature time-critical for you?

Open SteamApps\common\Arma 3\userconfig\task_force_radio\radio_keys.hpp for records sw_channel_[1-8] and lr_channel_[1-9] set key value to 0. Restart game, try. This should work.

This mod http://www.armaholic.com/page.php?id=23375 ? Possible it is because TFA changes default marker to small dot, maybe some kind of conflict here..

No, it will cause 16ms (0.12*140) freeze in case of naive approach. 285ms - is time to get fresh data for all playes. Of course we should do processing every frame for 1/10 of players to avoid freezes. Yes, I was thinking about it too. But also I need some info to prepare mute status for players, in future check them for some anti-radio devices, etc. Looks like after optimisation it will easy to send data about each players (few players per sample, update nearest peoples more frequently, update heavy-load attributes less frequently). Will think about.

Thanks, I have tested your ideas quickly. Currently (without any specific optimisations) procesing of one player takes about 0.12ms. So, in case of 140 players and 35 FPS we will get about 32.9 FPS (in case of updating every 10th frame). Every person will be updated in 285ms (almost equal 0.2 sleep) - fine for 140 players game. In case of 60 player - 34 FPS. Also, there is a lot of things may be optimized here. Regarding radio IDs - they are processed by a server in single loop (fast enough) - so problem occurs only if some script cloning items for some reason.

No, sleep for 0.2 second are called after ALL units processed. So, 5 updates per second for everyone player. UPDATE: Oops, looks like you said same thing...My fault.

Hm. I almost sure both PRC148JEM and PRC152 and even FADAK have 3km range :) I hope I'll able to finish bug-fix 0.8.2 update soon. Currently you may change radio codes using API to set the same values for BLUEFOR and INDEPENDENT. In such case 148 will be able to transmit for the 152. ---------- Post added at 13:31 ---------- Previous post was at 12:43 ---------- Just small note - we conducted successful 136 players game with mod( http://arma3.swec.se/game/data/881268 )