soldia

As this part of muting is completely handled by the TS Plugin, it can't be changed without a huge effort.

You already gave part of the answer. The second part is: We provide a tool for converting *.wav files to *.b64 files. This is in every ACRE2 Build as an *.exe. Take an empty wav, convert and replace the corresponding sound. Then repack the sys_sounds.pbo to provide it to your community. This would be the best solution for an entire community IMHO.

While it is true that the specific function needs to be optimized on our side: I can assure that even 80+ players do not represent an actual threat on that. In conclusion, it is not perfect but working

As snippers said, the best way to track this down is to put an issue on our issue-tracker. And to have a basis for analysis, we need .rpts plus a video or anything like that Common pitfalls for the plugin-errors are: - Missing rights on arma/teamspeak -> start both as NON-Admin - Your virus scanner has deleted .dll files of acre in the @acre2 folder (there must be both acre.dll and ACRE2Arma.dll)

Agree, that would be a huge improvement of eden in terms of modding it. Current situation isn't ideal, especially for communities with a high player count, as the total amount of overhead, like snippers said, will increase drastically.

Are you aware that the snow version of the titan is not working as intended with ace's javelin module? It isn't able to lock on any target. Reason lies in this issue on ACE Github: https://github.com/acemod/ACE3/issues/2854 Hope it helps.

They are in the acre_sys_sounds pbo

Pitch&Bank would be a great addition :) Looking forward to that. So far, X-Cam is a superb tool for building all kinds of stuff (from a missionmaker POV: Bases, Compounds, etc.)

It seems that certain CfgMagazines are affected. M200 and M855A1 are definitely not working. And of course mod versions are all the same, other Magazines and all Vanilla Weapons are working fine. Distance doesn't matter, you can't hear (and see) any gunshot while standing 1 meter away from the shooter.

No. Same here. With only Vanilla and RHS -> No sounds from other ppls weapons

To correct my statement from earlier. It is much easier with the "acre_api_fnc_setPresetChannelField" and "acre_api_fnc_getPresetChannelField" functions. And they are both 1-N based (so channel 1 is channel 1).

Assuming you want a new backpack-class which is also a radio: No, it is not. And why would you do that in the first place? As we're breaking with the old backpack == radio design, there is no need for tons of different backpacks just for a new camo texture. As long as the radio fits in, every backpack can be used. Vanilla, 3rd Party, doesn't matter. What you can do, of course, is: Create a model with an antenna. But you still need to put radio in it. Antenna's are coming, don't worry :) ---------- Post added at 07:53 ---------- Previous post was at 07:30 ---------- As we strictly commited ourselfes to a component based design, it is most likely there will be single components as different objects (no magic-backpacks) which need to be assembled. The command you're looking for is: acre_api_fnc_setPresetChannelData In order to use that you need to alter the PresetData Hash, which is requested by: acre_api_fnc_getPresetChannelData The work-flow is as follows: Get the PresetData Hash Alter the frequencies in that hash (first two parameters) Reassign the Data But be extra careful. All Clients+Server need to receive the new data. Otherwise ACRE might be broken on ALL clients after that. Thx for information. I'll have a look into it.

Under which circumstances does this occure? Mission setup, etc.? For better tracking, please file an issue in our feedback tracker. Do you want to create a complete new preset? Or do you want to alter frequencies of specific channels? Not at the moment, but it is definitely planned.

@Tester Communities: It isn't a Release Candidate and therefore not in the OP, but please use the latest version of ACRE2 for your tests, which would be .811: Download We've hunted several bugs between RC6 and .811, some of them are: Obsolete functions have been replaced correctly Changing Volume on 152/117F doesn't produce errors on remote clients anymore Detaching/Re-Attaching the PTT Handle on the 343 doesn't mute the player Improved Volume-Settings (with the goal to annihilate clipping) Correct handling of Spectator Function Basic Mission Setup Module should initialize Babel correctly now Ability to toggle Spectators in Spectator-mode (same key as toggle headset, look at your key bindings) As always: If you find any bug, please follow this link and file an issue: ACRE2 Feedback

Let me guess, your admin PW is longer than 5 letters? -> http://feedback.arma3.com/view.php?id=23594

You are correct, nou needs to update the OP. Meanwhile, simply use the link in my signature. (http://acre.idi-systems.com/api/api_general.html)

Do you have more information on that (How did you call it)? Checked the function myself and it is fine for me.

Simple solution: Different presets are automatically assigned by using the Mission Setup Module. Use that and you won't be able to hear each other. Advanced stuff: The 343 uses fixed channel frequencies. There are a total amount of 256 channels. 16 blocks, each containing 16 channels. To totally prevent sides from hearing each other is to use the preset API command. (http://acre.idi-systems.com/api/api_general.html#acre_api_fnc_setPreset) In fact, due to its limited range, the 343 is a very safe radio device to use in combat. If your enemy got the time to check 256 channels while you are within range, there is something going wrong ;)

Related tickets: http://feedback.arma3.com/view.php?id=19829 http://feedback.arma3.com/view.php?id=22741

As VKing said, simply assign two radios. In fact there are only few radios with dual channel (listening on two different channels) capability on the todays battlefield. If we ever implement one of those radios, dual channel will be available as well.

@Bullhorn: Regarding your PTT complaints, let me try to make it clear why we can't bind a single PTT Key to one radio like TFAR did. To resume, TFAR binds CAPSLOCK to the "Shortrange" Radio and CTRL+CAPSLOCK to the "Longrange" Radio, which is always a Backpack-Radio. I skip the buttons for additional channels because we currently don't have any radio capable of dual-channel operation in our arsenal. So, using TFAR you can be sure if pressing CAPSLOCK, you'll communicate over the "Shortrange" Radio. The skin might be different for each faction, but basically there is only one radio in TFAR. Fair enough. Now let's switch to ACRE2. You'll see, there are no such categories as "shortrange" or "longrange". We currently got five different radios (PRC-343, PRC-77, PRC-148, PRC-152 and PRC-117F). And it is totally up to the community or mission builder to define which radios they want to use. And due to this flexibility there is no way for us to bind a key combination for every radio (e.g. key-combo 1 -> 343, key-combo 2 -> 148,...). Even if this would work in theory, it will hit its limits if you own more than one of any type. Therefore we provide TWO different possiblities to handle your radios as I described earlier. And who is stopping you to unbind the normal PTT and radio cycle keys and simply go with the MultiPTT Keys? E.g. you can bind your "ALT Radio 1 Key" to capslock and the other two to whatever you want. You got your predefined radio loadouts in your community? E.g. everybody gets a 343, commanding elements an additional 148 and radio operators a 117? And you want them always to be on the same PTT Key? No problem, use the acre_api_fnc_setMultiPushToTalkAssignment function from our API and you get what you want. But perhaps some community don't want to use the 343 at all and instead everybody gets two 148? As I said before, the combinations are almost countless. And that is one of the major concept differences between ACRE and TFAR and the reason why we can't assign a key combo for talking over a 343,148,... and opening a 343,148,... . --------------------------- Regarding the bugs and problems in your video. The feedback tracker is linked in my signature, please file issues there and we can work on them.

Basically we got two systems of radio cycling and PTT here: First: Pressing the PTT Key (default: CapsLock) will always transmit the current Radio. This is the same radio you will open by pressing CTRL-ALT-CAPSLOCK (default). If you cycle the radio -> PTT binding changes to that radio. Second: The MultiPTT Keys actually change the current radio, yes. But they allow that in a much quicker way than cycling them manually. Via the API you can define the MultiPTT assignment as well, so you got consistency all over your community (and missions). There is no need to combine both the MultiPTT and PTT/cycle variant but you can, of course. Regarding TFAR: Sure, with only two types of radio (SR/LR) it is easy to do everything twice. But remember? There are two key combinations for opening those radios. In case you have more than one radio of any type, you need to remember two further key combinations to cycle. If we would go that way, we probably need the whole keyboard in the end (5 radios by now, count rising). Anyways, due to the higher flexibility of our radio system (nearly unlimited combinations of radios, not every soldier may have a 343), the PTT system needs flexibility as well. But sure, we can discuss that internally if we can separate those two methods more clearly. -------------------- And there won't be anything like "additional" channel in ACRE until we implement a radio that is actually capable of that. Or perhaps something like the AN/VRC-111, which will need two radios of course.

I don't use them, put the CfgFunctions are almost certainly called, so waitUntil is breaking that function. And you're calling it pre- and postinit? With CBAs XEH you could of course use spawn or exec...but as you don't want that you need to re-write your function

Yes, but how is that related to your other post where you were talking about uniforms? That sounds like equipment/gear config changes. Which is not part of CBA. Anyway... CBA provides a platform for all mod makers. What you're listing are extended eventhandlers. The alternative would be self-build init scripts for every mod and you certainly don't want that. Or every addon to copy parts of the CBA code which will result in a massive doubling of features if loading a few addons. Ok, you don't like it, but then you should stick with vanilla.

Ehh..what are you talking about?