Thank you for reporting this.

The bug is scheduled for a fix don't worry :)

"Resolution: no bug" but still "Status: assigned", does that mean that it is in development?

Possibly related to #22140.

Update:

as I said in previous comments there were still some mods files in:

C:\Program Files (x86)\Steam\steamapps\workshop\content\107410

I tried to unsubscribe and resubscribe those mods again and they appeared again in launcher without downloading from start. but other mods which are completely gone from that directory, are starting to download again and it's the negative aspect.

so I can describe again that what happened:

1- I just subscribed 5 mods and they downloaded and appeared in launcher as they must, and I even played them.
2- Then I subscribed another mod (@FIR AWS ).
3- After that I saw all previous 5 mods are disappeared from launcher and game directory where they have a folder with starting name by "@mod name".
4- But 2 of those mod still had their pbo files here:
C:\Program Files (x86)\Steam\steamapps\workshop\content\107410
when I resubscribed them through steam they just appeared again in launcher without downloading and they are now in game directory too, although rest of them which weren't in that directory, are starting to download again after resubscribing.

problem is why they just disappeared from launcher and game directory and worse of it why some of them completely deleted with out user permission.

OK, then could you upload this file instead of logs: "C:\Program Files (x86)\Steam\steamapps\workshop\appworkshop_107410.acf".

If you start the Launcher again, does the mods appear in the list?

uploaded.
I start it again but still those subscribed campaigns aren't showing.
maybe unsubscribing and resubscribing them will fix this but you know! it will start to downloading them again, and this issue may happen again too.

sorry I used ccleaner recently and those logs are gone now.
yes I first use of my steam mod workshop was in 2015-05-06 and I downloaded 5 mods (campaigns) then today when I subscribed and downloaded @FIR AWS mod, I saw all my previous 5 campaign mods are gone from launcher list although they are still checked as subscribed in steam workshop. also I found some of those 5 mod files are still in this directory:

C:\Program Files (x86)\Steam\steamapps\workshop\content\107410

although some other are not.

Hello,
can you upload also logs from the Steam client? (from C:\Program Files (x86)\Steam\logs).

From the logs I can see that yesterday (2015-05-06 11:01:10,536) the Launcher received subscription list from Steam with 5 mods and next time it started (2015-05-07 13:49:37,744) the list of subscribed items contained only one mod (FIR AWS).

If you didn't unsubscribed the item downloaded content should be present in Steam cache and therefore there they will not be re-downloaded, but simply restored from Steam cache. If you exit the Launcher and restart Steam client (Exit and start again), do the mods re-appear in the Launcher and are they being downloaded again?

UPDATE:
I found missed downloaded mods here:
C:\Program Files (x86)\Steam\steamapps\workshop

but as they aren't in arma 3 main folder, launcher won't show them.

hoho ...

Is BiS using the number of people reporting an issue on the feedback tracker to judge if an issue is worthwhile fixing? It'd be interesting to know what that magic number is.

If they are, and them being the intelligent people they mostly seem to be, it shouldn't be unknown to them that the absolute majority of players NEVER EVER contact BiS about issues.

If it annoys players enough, they just stop playing the game.

Please upvote this ticket - it's still not fixed - 9 months after logging. BIS need to filter inputs from joystick controllers for certain classes - like infantry movement. No one uses a joystick to move around and as stated above most joysticks don't have a clearly marked center or neutral zone. It should be a simple issue to fix - just look back a year ago - when this issue wasn't an issue!

My previous suggestion allowing users to uncheck inputs from certain devices on each binding class is a good solution.

Still an issue in the 1.56 RC Patch... -_-

I've the same issue since the last update.

Makeshift solution while BiS get their proverbial thumbs out of their proverbial asses (well, you can always hope they do)

While in-game ...

1. configure -> controls -> controller

2. Disable everything listed

3. back -> keyboard

4. Do your keybindings

5. back -> controller

6. Enable everything listed

7. Enjoy

Currently the following of my devices let Arma believe that this devices axis is a modifier key:
MFG Crosswind Pedals
Thrustmaster Warthog Throttle
Komodo Simulation Pro-Collective

Why can I map an Axis as an modifier key, when I cannot use a DX-Joystick Button as a modifier? Doesnt make sense.

Please just fix it.

WTH BiS! It wasn't like this before last patch. Can't you just acknowledge theres a problem and then fix it.

Are we supposed to UNPLUG stuff before we can map keyboard buttons?

Seem kinda lo-tek.

A week later and no news? Adam? Please :)

Two months later? Anything we can help you guys figure it out?

It's now 5 months since this issue was logged and it seems Adam is quite happy with the current state of double binding key mappings - if a joystick is plugged in. Adam just for fun - reset your keys with a joystick plugged in and then remap 10 random keys. Make sure your joystick throttle is in the up or down position first. Note my comment above about most throttles not having a center 0 position.

This issue only cropped up in the last 6 months.

I have a number of friends who just started playing Arma3 (I've played nearly 5000 hrs) - without exception they all complain about the key mapping process when a joystick is plugged in - "why hasn't someone fixed this?" is the standard question.

Surely it can be reverted? Or better still see my suggestion above. If there is a new key binding system coming that will replace the current process - then please at least let us know so we don't waste any more of our time!

I too have the exact same problem. Ch Pro Throttle USB and CH Fighterstick USB

1.48 was released and no fix.
Interesting find: A friend of mine never had the issue with his Thrustmaster HOTAS + Saitek Combat Pedals. Now on Saturday he received the new MFG Crosswinds and now he has the same issue.

Could somebody at bis take a look at it? Would be greatly appreciated...

I always try to keep a copy of the Arma3Profile file, so when things get messed up then I can just copy it back. However if you switch USB ports for a controller you should make a new copy. You could also set it to read-only, but unfortunately the same file is used to track missions that you play. In any event, I had no troubles with this update, no dupes, controls are still working as expected.

Since MFG Crosswind Pedals causing issues also, I attached my DxDiag for the Dev's to have the USB Controller Manufacturer Codes. Maybe it will help them to debug.

Thank you.

I really do have to say BiS representatives here on the bugtraqer often comes across as rather defensive and one eyed on the issues people are reporting in.

Using a Saitek X55 setup and same totally worthless issue here since last patch.

Is it possible to manually edit your profile cfg key bind section with like say notepad? I looked in there but it was all strange long numbers. \o/

How do these issues not get picked up in testing before the new version goes public? It's these highly annoying and frustrating issues that put a lot pf people off Arma3. Luckily I'm not one of them. But I know a lot of my friends have given up on Arma3 after playing for a few hours simply because they find the game too frustrating. Issues like this are unacceptable in a game like Arma3.

Please BIS, fix it fo the next stable patch (1.48). Its anoying to disable three controllers every time you want to assign a keybind.

The point is that no one in their right mind is going to use a double bind keyboard + joystick combination for infantry movement - surely BIS should switch off joystick binding for this input category - alternatively add a checkbox option to bind inputs from controllers on each section - common, infantry movement, etc? This would allow us to filter only specific control inputs i.e. keyboard, mouse, joystick, TrackIR, game controller etc. for each section.

And while we are at it - when mapping a joystick preset the inputs for aircraft using a Logitech Extreme 3D are mostly missing and only some are applied for helicopters. So the apply preset or map option needs some work as well.

I have the same issues. My MFG Crosswind-Toebreaks will allways assign also, when I try to bind a key. Since toebreaks are springloaded, it's nearly impossible to find and hold the position.

My workarround for the time beeing: Disable the controller when you are assigning all the other keys. The bindings won't be delited, just greyed out.

This wasnt happening in older builds. I do not really see the point in using an AXIS as a modifier key...

Would it be possible to revert this?

Something's going on. Since the update, all of my controllers had duplicate entries (Thrustmaster Warthog, Xbox controller, Saitek pedals). One entry appeared to be "dead" but I ended up remapping everything. Today I load the game, a few of the bindings are doubled again, such as the x-axis for Xbox controller which effectively made steering turn about 1 deg (seriously). Remapped those, restarted game to test, suddenly the Saitek is mapped to steering in one direction (it should never be mapped to ground vehicles in my setup). Keep in mind this has *never* occurred before. I thought it might be related to this ticket, or I could create another if you wish.

Since most joysticks don't have a throttle mid point marker or notch - it's very difficult to center the slider. If you can find the slider mid point - it does remove the double binding - but why has this issue cropped up in the new release - we never had this issue before? Is there now a reverse function for planes? This would be useful when moving a plane from a hangar.

@Adam: Joystick has been centered - if it was a simple matter of recalibration I would not have reported the issue. This happens on all machine's using Logitech Extreme 3D Pro and most likely all others joysticks.

This issue was not present in previous A3 releases. Clearly the input detection in Arma3 is now too sensitive and picking up dead zone inputs or it's a USB sensing issue.

Please get this issue fixed urgently.

I have no issues using Logitech Extreme 3D pro. Have you tried putting the Stick slider into the middle?

Hello, please make sure your joystic is centered before attempting to rebind the keys. Thank you

Hello, try resetting your control presets you can do this by going to: Configure -> Controls -> Presets -> Select Arma 3 and press OK.

Have you any MODs running ? i had the same problem while using MCC MOD.

i try it i fail resetting changes nothing.i can still not change the type of grenade, i push the change button and he throw it.
the keybord setting is default arma 3 standart i also have reinstall the game but i got still the same... :(

Update: Finaly setPosATL [x,x,x] (FIXED COORDINATES) on each client will fix this problem. If you use: setPosATL getPosATL _unit the position of the given unit seems not to be 100% the same on each client so the model get stretched.

i think the problem is, that the dead body is not local to the host because the issue only apears on the clients not on the Host Player. If i have time i will reproduce it.

if you have time, create a unit per script on the client side, so the unit is local to the client and not to the host/server player. then call the setPosATL command from the host/server side. Now check if the model still ok in the client/ second player.

Same here!
Needs hotfix...

Hello, i'm unable to reproduce the stretching issue on direct and dedicated server. Could you please provide more info? Thank you.

CALL SetPosATL on each client seems to fix the bug.

i think, giving an dead unit the same ID on each Client will fix the problem. Currently dead units get random ids on each client. ID# NR MODEL.P3D REMOTE

This issue may be fixed for you, but I still have it in dev build 1.53.132523.

I have reset all key bindings to Arma 3 preset, but the issue remains.

I have also tested on my laptop, which still has this issue using stable 1.50.131969, with both my custom keybinds listed above and the Arma 3 preset bindings.

It's strange that you say this - because this issue has been fixed since 1.48. You must be referring something else.

Related to http://feedback.arma3.com/view.php?id=23959

New information discovered:
The bug happens because the default Optics Mode key is Ctrl+RMB (Switching from CQB to magnifying sights).

It wasn't a problem in the past though...

Agree, since alpha release (well Arma 2 really) I have been used similar key bindings (RMB = temp zoom, CTRL+RMB = swap optics, CTRL = hold breath) and could hold RMB to zoom temporary and hold CTRL to hold breath without any issues, but suddenly this issue has been introduced.

You did not read my ticket correctly or do not understand it.

when compiling with the Debug CRT, it *does not zero the memory*, it sets it to different debug values depending on the type/method of allocation (see the link I provided (http://stackoverflow.com/questions/370195/when-and-why-will-an-os-initialise-memory-to-0xcd-0xdd-etc-on-malloc-free-new). Additionally, it will fill buffers for different string and memory copy/allocation functions for debug purposes.

This means you *cannot run extensions compiled against the Debug CRT*, only built against the release CRT. It's not world ending, but its annoying when working on complex extensions. That means, if you do something to the affect of:

ACE_VD_EXPORT void __stdcall RVExtension(char *output, int outputSize, const char *function) {

sprintf_s(output, outputSize, "My Balls");

}

The debug CRT writes:
output = My Balls 0x00 0xFE 0xFE 0xFE 0xFE

Thus triggering this warning. Which has nothing to do with a buffer overflow, its just that the 2nd to last byte they provided me is not null.

This can be worked around in the extension by setting the 2nd-to-last output byte to 0x00 no matter what.

Ideally though, this should be appropriately handled with a correct guard byte after the buffer - not a guard byte inside the buffer sent to the function.

This does not occur in release builds because ArmA3 zero'es the buffer prior to passing it to you; its specifically your extensions debug flag which is re-writing the buffer.

Arma is already setting the last byte in the outputBuffer to 0 before calling the Extension like:

output[outputSize - 1] = 0;
RVExtension(output, outputSize, function);
if (output[outputSize - 1])
{
  error("Buffer overrun detected");
}

Yes, you're right, I didn't understand your ticket. You have attributed this issue to Debug CRT itself, which is actually wrong. That got me confused.

Debug CRT only sets the memory to the provided values *if the buffer is allocated within it*. When the buffer is passed into extension by ArmA, that is obviously not the case - the buffer has been already generated by Release CRT that is used by ArmA and stays there. The runtime which your extension was linked against has no effect on ArmA's runtime - meaning ArmA will always give you a zero-filled buffer, regardless of whether you start with debug

Judging from your description (unless there are some more details missing), what you're actually looking at is an issue with sprintf_s function. It is not a C standard function, but rather a Microsoft extension; and Microsoft did their best there in not following the "least surprise principle". Debug version of sprintf_s just fills the rest of the buffer with bogus data - that is why your buffer ends up filled up with 0xWHATEVER instead of 0x00 that were there previously.

Why am I saying it is not Debug CRT fault, if it's debug version of function?
Because with a slightly different code you can get it working regardless of runtime:

    memset(output,0,outputSize)
    std::string balls("My balls");
    memcpy(output,balls.c_str(),balls.size()); // Copying without the 0-byte, as the buffer is zero already

Neither your code nor my example above use any explicit allocations; hence, Debug CRT's stack overflow protection is irrelevant.

To workaround this issue, you can try to:

• use code similar to above
• use undocumented function _CrtSetDebugFillThreshold(0) which disables that bad behavior[1]
• just take a more standard-conformant function like snprintf().

[1] see more here: https://social.msdn.microsoft.com/Forums/vstudio/en-US/16ce9c2a-341e-4601-82cd-bb437ab8a6bf/sprintfs-slower-in-vs2010-than-in-vs2008

I agree with your suggestion regarding ArmA's behavior. What I'd like to note is just that your issue is not with Debug CRT per se, but with a specific gotcha in one Microsoft's function.

P.S. output[outputSize-1] is not "2nd-to-last" byte, it is the last.

What is the fix...?

If that's true - how on earth do extensions work now? If in debug mode the check hits an unallocated space, then in release it should have hit uninitialized area => only 1/256 chance of having zero there.

Something does not compute.

I have another issue like this and it was assigned this morning. Hopefully a fix soon.

http://feedback.arma3.com/view.php?id=24057

So is there a fix for it?

Ok, we were able to find what causes this strange behaviour.
The value of the "animationPhase" which is used to determine which siren and/or which light should be on is not properly send to all clients. In our example the animationPhase = 0.2 is set for the driver and everyone else receives values like 0.2000767 which causes the switch case(0.2) to fail.

But please Bohemia elaborate why this value is not propogated correctly.

So what you're telling me is you've done something to break my server of which gets usually around 80-100 players for it to now have major disruption due to an update BI have done?

I'm sorry but we cannot fix issues regarding mods. Please try contacting the development team of the mod and see if they can do something about it.

Thank you for your feedback.

I do not believe this should be considered "resolved". This was a issue that BI CREATED with the update. This issue should be fixed by BI or at least told how to correct. Regardless if it is a mod or not, they were working perfectly fine before you guys decided to update and break them. Now they only work client side for the person who turns them on and no one else.

This issue needs to be re-opened and some actual help needs to be delivered.

Maybe if you don't want to support mod issues, you should not cause such important things to BREAK with your updates.

Hello, no this is an issue concerning modded police and medic cars primarily used in mods like Altis Life or Arma 3 Life or City Life RPG.

Hello, is this issue reproducible without mods in a mission created in a editor?

Thank you!

Good! Thank you for your help!

LAst patch (2015.05.15) resolved my problem. I don't know what was it, but it works again.

It can help to find the problem if I link the previous same error ticket:
http://feedback.arma3.com/view.php?id=20250

This error also resolved from itself after some patch .

Ok, so what do you suggest? But is the current version wrong, or just uncomfortable?

redux: Are you sure that it should be named "ОФ"? What about Triada, do you agree?

falagor,

"Аламут тбг-42.jpg - wrong!!!
ОФ - is abbreviation from type: "Осколочно-фугасный" it's type, it's not the Redux ammo name "ТБГ-42В" - THIS WILL STAY ОФ (High-Explosive)"

??? ОФ!!! ???

as i say must "ПП" - it is abbreviation from type "Противопехотный"

1)<Key ID=???>
2)ОФ
3)ПП