That was indeed the problem! I have no idea how that setting was enabled, especially because it definitely falls under the category of "[none] that I have observed" -- I wasn't even aware of it!
I wonder if that was slipped into a recent devbranch for the HMD head tracking stuff.
Can be closed as "no bug". Tried doing that myself but apparently issue reporters can't close their own bugs. =)
Confirmed no longer an issue as of devbranch build 1.25.125852. Can be closed as fixed.
The word you want is "integrate", not "inter-grade". ;-)
In any case, this is very unlikely to happen for two reasons:
In short, while it would definitely be nice (and as far as I'm concerned, the farther anyone keeps anything from Steam, the better -- I was *furious* when I found out that Arma III would be Steam exclusive), it's something that our technical realities just won't allow for. And that is a major shame, for everything that you stated above about the Steam Workshop is correct.
Let me get this straight. 1) Instead of it seeming like an arbitrary switch we now have a perfectly reasonable explanation on why they made the change, and 2) a viable workaround exists (scripting using the "unit join group" function, such as the provided example above -- you could even do it just using the Init boxes in the editor).
Where does the scope end? My mission utterly depends on having a rogue NATO pilot flying an AAF jet for the CSAT. I guess we'd better add all of the forces to all of the sides: AAF as BLUFOR, OPFOR, and Independent; NATO as BLUFOR, OPFOR, and Independent; FIA as BLUFOR, OPFOR, and Independent; and CSAT as BLUFOR, OPFOR, and Independent. Nothing else will suffice to cover all our usage scenarios.
Also, 3) "avoiding spoilers" so another person goes ahead and posts spoilers anyway, and 4) you catch more flies with honey than with vinegar. Let's call the campaign buggy and insult BIS for failing to make this switch, it'll get results for sure! ;-)
I get that people are annoyed that they can't use BIS assets for a purpose other than their original intention as easily as they used to, but if I were a BIS developer I would have already pushed this to the very bottom of my list based on reaction alone. I'm sure BIS is nicer and better to its community than I am, however, but bear in mind that were you to use this language in an indie dev community or a modding forum you could more or less forget about it ever seeing the light of day. =)
Now that the Survive campaign is out, I'm pretty sure people understand why the FIA faction is BLUFOR instead of independent. It's next to impossible to mention anything further without doing spoilers.
If you want these units as insurgents, you will have to use the join-group method, or will have to hand-edit your .sqm file.
On the other hand, "unlocking" the independent FIA units shouldn't be too difficult for BIS, so I'm not sure why that configuration edit isn't being done, other than pondering that maybe the configuration editors under Joris are all tapped to the extreme working on the campaign at the moment.
With regards to those people who think this is not an issue with ARMA 3: this isn't an issue with the ARMA 3 tanks (which obviously don't exist), but the ARMA 2 tanks ported over, and therefore is a valid consideration and something the dev team needs to take to heart. While I'm sure the developers will make every effort to properly physicalise the (new) tanks in ARMA 3 (which I believe are already nearly feature-complete if the E3 demo was any indication), the lack of support for physicalising the (existing) tanks from ARMA 2 is disheartening, and unless the developers include the ability to patch a model with additional physics configuration, most ARMA 2 content is deprecated -- which is very unfortunate.
BI policy is to disallow verbatim copies of existing content to ARMA 3 (for good reason, as mentioned below). Therefore, we cannot simply rewrite the entire models from ARMA 2 to include LODs without infringing on BIS copyright, unless of course they grant explicit and written authorisation (normally to a specific party) to do so -- and since ARMA 2 is still selling like hotcakes while ARMA 3 is still a tech demo rather than mainstream, it would be a very tough sell to get BIS to authorise a "no-ARMA-2-required" port of ARMA 2/OA content to ARMA 3. They granted explicit and exceptional permission for CWR² to use the OFP content, true, and also granted permission for CAA1 -- but that latter one ended badly...
Let's just say that things are in the air without having a good and ready way of porting existing content if the BIS official models are restricted from redistribution. While that doesn't stop the community from creating scratch-built models of ARMA 2 equipment in ARMA 3 with proper physics, that is an exceptional undertaking, and the personal licences of all of those independent contributors would become a legal maze for anyone hoping to release a total conversion (the individual would have no such trouble if they create a personal compilation for their own use, but aside from the sheer difficulty in collating all of that content it also means negligible compatibility for multiplayer).
In summary, this feature should be weighed on the merits of back-compatibility, not on the merits of whether it supports tanks in an alpha build that does not yet (publicly) include tanks.
I don't think this would be all that hard to implement, at least as initially proposed -- it just controls the whitelist of things that can be attached, and the rest is already handled through something called model proxies. Instead of the whitelist being based on classnames it should just be based on whether the attachment has a text string that matches one of the weapon's accepted text strings.
I fully support the original proposal.
Going full tilt and supporting an unlimited number of proxies/attachments would however be *very* difficult, since it would have to move model parts at run time to accommodate attachment points where they have room. For instance, mounting a reflex sight in front of a scope would be possible in reality, but in the game universe it would require knowing exactly what range of coordinates on the model could accept attachments, the dimensions of the attachment, and whether those dimensions would collide with other attachments. That's a lot of development work for a game that's not actually a gun construction simulator. ;-)
I would of course fully support this hardcore simulation, but I'd rather have the rest of the game first. =)
Hm, I keep coming back to this and being more and more disappointed by the responses. =P
For the "I don't want to hurt women" arguments, the response is very, very simple: it's not okay to shoot either men *or* women. When a person can claim that it's okay to shoot men, but not okay to shoot women, that is an insidious and poisonous form of sexism (and sociopathy) that is far more dangerous than "yayz I gets to shoot womens lolz". At least the person who willingly causes violence to men or women indiscriminately has come to terms with the fact that it's causing violence. A person who thinks that it's somehow okay against men but not against women is violent, misogynist, and misandrist, rather than just violent.
That said, if someone were to scroll back, I made what I consider to be a pretty good suggestion earlier on how to handle those "I can't stand the idea of shooting women" types. Specifically, "what you don't know won't hurt you" -- a client-side setting, seen only by you, that converts female soldiers into male soldiers so that you can play without ever feeling sorry for shooting a woman but not a man. The fact that such a feature would be necessary however is in itself quite sad, and provides acknowledgement of a moral viewpoint that should not need to be acknowledged, or even recognised.
Absolutely up-voted. The social issues are social issues, the political issues are political issues, the equality issues are equality issues... and none of them are issues with the feature itself. Is the implementation unfeasible in some way? Would it cause the game to crash? Is there any pressing reason, solely in terms of gameplay mechanics, that it shouldn't be there?
This request is solely about whether the feature needs to be there, and given that 20% of the BLUFOR combat force is being unrepresented, I would say that is proof positive that female soldiers need to be there regardless of whether they're front-line or not.
Even just a *head* model would be sufficient, since in general soldiers are wearing LBVs, armour, and full kit, at which point the only thing that distinguishes women from men is the face and the voice. The articles mentioned towards the top of the comments thread here describe the turret gunner women, who are passed off by observers as "just another soldier" until they actually speak. While this doesn't answer the 'underwear' problem, I'd like to think (although am mostly being proven wrong) that as a species we've matured enough to accept that as a non-issue.
Besides, as a huge fan of Gunny Sgt Babcock in the Honor Harrington series, I couldn't possibly disagree with women in combat roles. ;-)
One thing that would completely temper this debate and render it into a non-issue: allowing clients to enable a "Male soldiers only" checkbox in the options, so that whenever a female soldier appears on *their* end, it looks male, but anyone who wants to see female soldiers can leave the box unchecked and they see everyone as they are. The only people who lose here are those who need to assert themselves as female to others instead of simply identifying with themselves as female.
But this thread's about the aiming deadzone bug and its interaction with Track IR. As in ARMA 3 deadzone. ;-)
Note that the ARMA "aiming deadzone" is actually a big misnomer as it is. It should really be called "torso deadzone", "body deadzone", or "turning deadzone", since it controls the deadzone where you will continue to aim your weapon but not move your body. But that would be even more confusing than it already is. ;-)
Note that you inadvertently linked the same picture twice, but do I get the gist of what you're getting at. However, I don't think using a Track IR deadzone is an effective fix for this problem, since the problem doesn't exist in ARMA 2 and it is entirely possible to play with a "looser" weapon in ARMA 2.
I personally actually prefer the TrackIR twitches to be translated into the game -- albeit using a less sensitive zone in the centre so that I can still get a good feel for the zero point -- because it's so much more immersive. If the TrackIR becomes just another control input, I might as well just be using an analog hat -- with the minor and ordinarily imperceptible motions actually translated, it makes me conscious that I have the freedom to look around at almost all times (except in vehicle ironsights for some reason -- optics I get, but mounted weapon iron sights would be more interesting with a bit of free look =)).
If that's in reference to my "faster and looser" comment about Alt-looking, I'm referring to when looking through iron sights, not when your weapon is merely shouldered.
Behaviour when the weapon is shouldered and you are relying on Quick Kill technique is as Track IR -- Alt controls your head without altering your firing solution or your body position.
Behaviour when the weapon is under iron sights, however, is to adjust your firing solution without otherwise moving your body or your head. It also does make a difference in how fast the weapon can be brought to bear -- a very noticeable one at that.
I get this bug all the time too. It's sort of a sucky scenario when you can't play with the aiming deadzone enabled, since the game simulates the difficulty in bringing your torso to bear versus bringing your weapon to bear (note how much faster and looser your weapon is when you hold Alt while in a firing position).