commy2

I think you are talking about 1.62? Sorry, but we don't (can't) support dev and release branches.

Just use the method described here: https://forums.bistudio.com/topic/168277-cba-community-base-addons-arma-3/?p=3041773 The game will tell you if and what a signature check fails. If you don't understand the log, feel free to post it here. Without RPT or anything else, we can't help you. Sorry.

See: https://forums.bistudio.com/topic/168277-cba-community-base-addons-arma-3/?p=3041773 Keys seem to work fine. No error can be reproduced when handling the keys correctly.

@DedFusion I answered you on the issue tracker. You have to update your battle eye filters. I never used battle eye, so I can't help you there. Nothing we can do. It's the server owners responsibility to do that.

Yes. It will be fixed in the next version.

You have been tricked. Arma 3 is only available on Steam. We don't support pirated versions.

I cannot reproduce this. What mission? Please upload a RPT

This is technically wrong. There are two syntaxes of "isNil": "isNil STRING" where you use a variable name and "isNil CODE" where you check the return value of an expression. If you actually use this: 0 spawn { isNil _undefined; }; You get the error: "undefined variable: _undefined".

While Author[] is indeed not supposed to be used in CfgPatches, this whole debacle could've been avoided if the 3DEN script used "isText" before reading the value with "getText". This whole thing would be fixed in two minutes. Ironically CBA does check with "isArray" before attempting to read the "author[]" entry, so at least the vanilla CfgPatches don't have the same error in reverse.

The NV attachment isn't supposed to work with that thing. Will be fixed in the next version.

>Actually, all I can see is that these lines, never used anywhere, cause issues and don't cause any issues when not used. You are wrong. They are used by the engine to determine what attachments can be used on a weapon. Making these for Katiba & Co. was specifically requested by some addon makes to make their optics work with these weapons. >They're never ever been any issues before these lines added, and I already explore the configuration files from BI, and I've never see this way to do, so, for me, it's not an issue that can be let to BI responsability. But it is! The arsenal is displaying optics that are not compatible! Only BI can fix that issue, because they wrote the Arsenal script! >If they don't use it, maybe there's a good reason ? So, why using it in CBA ? If CBA add theses lines that are not correctly supported, while BI don't use them, CBA cause the issue by adding these lines. It's logical. >BI don't use that way in their own configuration files and there's a good reason for that. And if you know that's not correctly supported by Arsenal, why using it ? Because they don't have to deal with third party optics being compatible with fourth party attachments. It's pretty easy to understand. >For example, the jumping over obstacles animation exist since the first release but the action of jumping over while runing still use the walking one instead of the jumping one in older versions. It's integrated now. Dude, you are kidding, right? You cannot jump in vanilla Arma. There is an animation, but it was KoffeinFlummi, who made that feature work back in AGM by replacing the vaulting animation while moving. I know this, because I am the maintainer of that component that is now in ACE3. Here: https://github.com/acemod/ACE3/blob/master/addons/movement/CfgMoves.hpp#L34-L38 Now please don't say that these line are never used. >So, no, I don't think I'm wrong. Yes, you are! And I explained this as good as I can. >You can continue to said that I'm wrong even with the proofs that leads to this observation and conclusion and don't do anything and continuing to use lines that cause issues for all those who using CBA. Your conclusions don't hold any water, because they are based on a lack of understanding of this subject. Sorry. ¯\_(ツ)_/¯ Well, regardless of all this, we are always searching for the best solutions to compatibilty problems like this. Having wrong attachments displayed in the Virtual Arsenal is a really minor thing and currently no good solution is found to circumvent it. If you have any idea, feel free to open a pull request. Additional optional files are a really poor solution for a problem like this, because the bug could one day be solved by other means, and then we have a completely useless optional file to maintain that had no reason to exist in the first place, except for some aesthetic reasons.

You are wrong. :-) There are two ways of defining an attachment as compatible. Vanilla Arma uses the "compatibleItems[]" <ARRAY>. You put all optics that should be compatible with the weapon into that array. This is not very mod-friendly, because different mods cannot add optics to weapons of third party addons. Therefore, BI introduced the alternative method of adding sub entries to a new CLASS that is also called "compatibleItems". By creating standard base classes other addons can add their optics in, ASDG Joint Rails and now CBA Joint Rails can create an easy way for third party mods to make their optics compatible with any other mod weapon. Example: https://github.com/CBATeam/CBA_A3/blob/master/addons/jr/cfgweapons.hpp#L296-L298 BI never uses this method, because they don't have to. The Virtual Arsenal does not understand this correctly since 1.58 (or 1.56 can't remember) and can show "ghost optics". There appear to be more optics in the Virtual Arsenal, but clicking those does nothing. This is a bug in the Arsenals scripting. Only BI can fix that. The VA does not display the actual engine behaviour.

No, but there is no way around that. It's what the new CfgPatches rework from BI does.

That is a bug with the Virtual Arsenal. Instead of searching for strange work-arounds, BI should fix that issue directly. It does not only affect your attachments.

I found the issue. We are inheriting the ammunition from the RPG32 from vanilla and BI increased the "thrust" of the rocket in v1.60. Will be fixed.

The "zeroing" for the CG is only for setting the range of the Smoke and Illum rounds. The Pz3 doesn't have a PgUp/Dn zeroing.

Dude, we know exactly what's up. Just be patient. Also expect for this bug to be around for quite some time as probably 60%+ of all big mods are affected.

We cannot help you if you don't provide a full RPT file. It might seem not important to you, but there are very important informations all over the file. The actual error message is the least interesting most of the time.

Post client and server RPT

Yes. We are aware of that. It's already fixed internally. However, there is another problem with all our sounds. We use 44.1khz sampling and that is no longer supported. We are currently converting all sounds ... and will release a hotfix as soon as possible.

Nothing. All players are muted by default. No module has to be placed.

Yes, ACE mutes players by default.

No, it should be: "feature request - add option to ask AI to always pull out the AT launcher". Btw. the BI wiki is a exactly that: a wiki. All you have to do is make an account and you can add a note about "selectWeapon" and AI yourself.

What are you talking about? The is whole system is event based, which means there aren't any scripts running. There is practically zero calculation time. You show a severe lack of understanding on this matter. You can fool yourself, but please don't spread obviously false rumors.

You have to create a totally silent radio protocoll. This requires you to create a mod that every client has (not just the server), so a mission only solution is out of question. The system is strongly integrated into the ACE event framework so it can work with all kinds of missions out of the box. Just think about how zeus, teamSwitch an respawn change the players controlled object - it all handles that. https://github.com/acemod/ACE3/blob/master/addons/common/CfgVoice.hpp basic functions to mute and unmute units: https://github.com/acemod/ACE3/blob/e1403d567c98a93382454e616bfd683a1209bb2c/addons/common/XEH_postInit.sqf#L157 https://github.com/acemod/ACE3/blob/03f3b1084d4e9d14617f159db14a7086b1af8682/addons/common/functions/fnc_muteUnit.sqf https://github.com/acemod/ACE3/blob/03f3b1084d4e9d14617f159db14a7086b1af8682/addons/common/functions/fnc_unmuteUnit.sqf function to handle JIP: https://github.com/acemod/ACE3/blob/03f3b1084d4e9d14617f159db14a7086b1af8682/addons/common/functions/fnc_muteUnitHandleInitPost.sqf function to handle respawn: https://github.com/acemod/ACE3/blob/03f3b1084d4e9d14617f159db14a7086b1af8682/addons/common/functions/fnc_muteUnitHandleRespawn.sqf function to handle disconnected players (missions with "AI enabled" - we want the AI left behind to talk again) https://github.com/acemod/ACE3/blob/master/addons/noradio/XEH_postInit.sqf#L4-L9 and the function to trigger this framework - modular so it can be disabled. https://github.com/acemod/ACE3/blob/master/addons/noradio/XEH_postInit.sqf#L13-L24