I can launch client with BattlEye just fine. The point is that installing/launching BattlEye on the client is unnecessary if not joining a BattlEye-enabled server.

No, this can still happen in vanilla. :)

Alright, I'll re-open if I notice it again!

@Groove_C may I ask when this was resolved? I have seen it happen again at least 2 patches ago.

This can be reproduced with Eden Editor, which apparently saves layout like when going through layout editor.

@oukej Thanks to research of @Alwarren we found out CUP's Harrier and F-35 are not "airplanex", but only "airplane" (due to some old issues that "airplanex" had with LHD, however that was not yet retested post Jets DLC). After changing it to "airplanex" vectoring with "vtol=4" works perfectly.

I just tried again and realized I forgot about that. "vtol = 4" has the same issue as "vtol = 3", when you are on the ground nozzles are forced into vertical flight orientation. So it's the opposite of 1 or 2, it's like 3 in that manner, except it doesn't even allow for the minor changes that 3 allows (90-60° change or something like that), it's completely locked (at 90°) below certain height (~7m it seems).

Hi @oukej thanks for the fast reply!

I will look into it further, it's a pain to debug as it appears it only happens on dedicated, and so far only on players.

Further debugging of this showed that it happens because of BIS_fnc_setUnitInsignia. Possibly BIS_fnc_setUnitInsignia gets executed to early?

Added information of getObjectTextures from an instance of the bug. Note, bug does not happen globally for all clients, only for some, inconsistently.

Also happens with TV objects as reported in https://feedback.bistudio.com/T84431.

Any update on this?

Will provide a test mission and all configuration as well as RPT in the coming days.

Using exactly same keys in the folder just created with today's update? In changelog nothing says about any changes with anything related to DSSignFile or DSCreateKey or whatever they are called exactly.

I just created a key with dev-branch Arma 3 Tools and it fixed the issue by naming it differently than the old bikey was, which was created with previous stable Arma 3 Tools.

More time showed another interesting thing. With a bunch of mods and keys all worked, removing "randomslap.bikey" broke it again. Yes, *removing* it, this is not making any sense anymore...

Removing ANY other key next to that one made it work again.

@LondonLand

It's not the same, but it's related. Since my old bikey "jns_skycranes" bugged out with just one other key (that I could find), but the key was created by previous Arma 3 Tools (stable), the new one with dev-branch and new one "jnsSkycranes" works.

From what I can see it's random or at least there is are visible reproduction steps, here is what I was doing past 2 days trying to figure things out.

First, key "CCIP_v0.3a" was conflicting with key "jns_skycranes", removing either of them fixed the issue. Renaming second to "jnsSkycranes" for example fixed the issue, but renaming first to dash or underscore instead of a dot did NOT fix it while renaming it to exclude the dot (03 together) fixed it.

(Arma 3 Tools also doesn't support a dot in the key's name, I've already reported that to the mod's author.)

Second, after I resolved above, I made another random key "missing_units_usec" which conflicted with "jns_skycranes" as well, removing either fixed it yet again. Then renaming first one to "missingUnits_usec" or "missing_units-units" fixed it as well, while renaming it to "missing_units" or "missing_units-usec" or "missing-units_usec" or "missing-units-usec" did NOT fix it.
Renaming second to "jnsSkycranes" or even "jns_sycranes" (without 'k') fixed the issue as well.

'renaming' in all above context means creating a new key, as renaming it plainly doesn't change anything at all. That leads me to a conclusion that the key's name somehow gets corrupted in the actual encryption of the key or whatever it does, so it's not referencing itself correctly or something along the lines.

Duplicate of #0022002

Same is true for any custom texture, on Bench variant of the Taru it's impossible to change object texture (using config or setObjectTexture).

Did more testing, AGM breaks it, tested with AGM 0.93 and 0.94.1.
GitHub issue: https://github.com/KoffeinFlummi/AGM/issues/1533

Workaround: Remove AGM_Aircraft.pbo

Can the poster check if this was the problem on his end as well?

It works fine without mods.

Well the main reason they are not implementing is because of AI, at least that's how I see it. And also because they want something more than what can be achieved with scripting only (attachTo).

But I believe simple design, land on top of it and attachTo to it, perfect for Coop without AI. Or if you want to be more complicated you can replace the vehicle with the one with correct pod, that would be suitable for AI as well, but involves many other things to worry about.
You could also make it so, start sling loading and then without detaching pull slings up and when the pod gets close enough use attachTo then, again perfect for Coop without AI.

Nope... http://forums.bistudio.com/showthread.php?152866-General-Discussion-%28dev-branch%29&p=2806089&viewfull=1#post2806089

This seems to have been fixed, no more issues since last comment.

Happened again, resolved by ending process of Tortoise SVN client, there were 2 of them, once I closed them both Arma 3 Tools responded to Steam that they are closed.

It started happening again recently so I went mad and went from process to process of those that I didn't know what they were for (or wasn't totally sure), something made it close but I was too fast to see what. When it starts happening again I'll make sure to go slowly and find out.

I guess, I just made direct shortcuts to all the Tools (except Addon Builder, that wants to be run through Steam for whatever reason).

Possibly, right now I am just not starting Object Builder through Arma 3 Tools dialog anymore.

Edit: I am running Steam as admin.

Now it's happening by running anything, Addon Builder, Terrain Builder, Object Builder, Arma 3 Tools. Nothing makes Steam think it's closed.

Also, running Addon Builder directly from it's directory throws a message that Steam is not running, but there is a fresh launch of it open.

Possibly, but your issue is when you try running both, might be because of same appid? While my issue is happening with only the Tools.

Another issue is that when you pick up Mine Detector (or any item inheriting from that, in mods for example) via Pick up action (in mouse wheel), the item will simply disappear and leave an empty GroundWeaponHolder"

Via Inventory Dialog it works fine though (both by pressing hotkey or action menu->Inventory), bug here is "Pick up action".

This majorly happens when using setGroupOwner command.

Looks like fixed in dev-branch EXE rev. 130903 (26-05-2015): http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2941973&viewfull=1#post2941973

This happens to me as well, since Alpha but I haven't bothered finding a fix since even the enlarged is not big enough anyways.

As of "need more info", I found a temporary fix (next restart it falls back again), if you open your *name*.Arma3Profile in Documents\Arma 3 - Other Profiles and delete the following lines:

class MainMap
{
class Compass
{

		inBack=0;
		position[]={0.043552287,-0.029674841,0.2};
		positionBack[]={0.044657435,-0.031056296,0.2};

};
};

Next start it will function properly as long as you don't move it, then it won't change size on double-click yet again. And sometimes after second restart it will get totally stuck at small compass even if you closed the game with enlarged compass.

Now on dev-branch: http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2836093&viewfull=1#post2836093

I was missing this command just yesterday, good to see it!