Jackal326

How many more threads are you going to start about this issue?

Try asking here:

Fair enough, but doesn't that seem a little "janky" (for lack of a better term) when it comes to firing around corners or over low cover as an example? For the VR player (and for the game-engine and server) their gun is firing around/over the cover yet for the non-VR user who's animations are "tied to the normal game" it would appear they're getting shot by nothing, or worse a floating gun. In a purely PvE/Co-op scenario this would be advantageous but in a PvP scenario I could see that causing issues.

Yes I do play VR. I've owned a Valve Index for several years now. Thank you for your interest. As I'm sure your vast game-development history can help BI in their inclusion of such features I can't wait for them to hire you. Then you can begin your work on the inclusion of the myriad of features immediately given that you say the inclusion will be easy and "not much of an issue". I look forward to VR's inclusion and you will have the community's thanks... Whilst your cash-in comment may be true, and the cross-compatibility of (some) mods is certainly true, you must acknowledge that given the distinctly different versions of the games in question that if multiplayer were to be factored in (I appreciated Fallout 4 and Skyrim are not multiplayer - but Arma certainly is), there is certainly the potential that the community could be divided if VR and non-VR players were unable to play together? That was the point I was trying to make that clearly a few people here have misunderstood. A few of you seem to think I'm against the inclusion of VR in the Arma franchise, that is simply not the case. However none of you seem to realise that VR's inclusion would not be an easy task - you all just seem to think that BI can conjure up some sort of magic-wand, wave it and have VR functionality included just because we (I use the term broadly to include the whole community as many of you don't seem to understand the 'us vs them' debate) want VR to be included. The fact is I would love for Arma to have VR included as an optional feature, that doesn't divide the community with a separate game version or site behind a DLC pay-wall. However, I'm slightly more pragmatic that I realise that arguing with people on a forum, posting my opinions as facts and throwing my toys out of the pram when people disagree with me wont get me very far.

I'm not sure 'rhs_uniform_acu_ocp' is the correct cfgVehicles class to inherit from, sounds more like a cfgWeapons entry...Your code would seem to link a uniform to a uniform rather than to a unit...

True, to an extent, but you'd have to seriously limit the view-distance as I am unsure whether you would get away with a 20km view distance in VR given the double-rendering required...Who knows, I'm not a game engine developer... Was it though? Was it really?

You could try the sticky thread in this very forum section maybe...

Both of which have maps/levels that are tiny in comparison to a game such as Arma...Even Skyrim's "main" map is small when compared to Altis, but even if you were to seamlessly add all of the dungeons and interiors (which of course are separate "levels") it still would not come close. Are you seriously saying "it was possible in OFP, so it will be possible in Reforger"? You're forgetting one big difference between Operation Flashpoint and more modern titles - Graphical fidelity. OFP's graphics were shit compared to Reforger which is a much more demanding and system-taxing engine due to higher detail terrain, object rendering and texture resolution. I don't think you'll find doing the same thing to be "no problem" nowadays...

Mod suggestions are what THIS THREAD is for.

C:\Users\[USERNAME]\Documents\Arma 3 - Other Profiles\IngameProfileName

Out of curiosity does the issue occur when not using a headset (assuming you have speakers)? If its affecting all audio, even apps outside of Arma itself my guess (emphasis on guess) would be either an audio driver issue or perhaps a loose connection. Check the jack isn't loose or covered in dust etc. Might also be the cable arcing out due to the wire being broken/split/frayed.

The thing is, those "hundreds of thousands of people" aren't posting in this thread in an entitled and cringe-inducing manner - YOU are. I imagine that is why the retort was levelled at YOU. If you bothered to do any form of research you'd have discovered that whilst RHS content has only been available on Steam Workshop since ~ January 2017, as you correctly stated, you would know that much of the same content has been available for much longer (via the RHS website and other, now defunct sources such as Armaholic) since before October 2014. That is almost 10 YEARS ago, and that was version 0.3.0 - you'd have to go back even further for previous versions (but I couldn't find dates on the RHS website for those). Either way, that is still over 10 YEARS of support...for content provided free of charge. "AAA" games you pay real money for don't get that length of support, and you're complaining that RHS has moved on and "abandoned" the mods with issues unresolved and bugs still present? I suppose you'll be complaining that Far Cry 3 still needs a patch next... And while I'm here, what the hell is a... ...anyway?

Well, don't take the following as gospel, but at a guess in the main directory you'd have a config with the base cfgPatches, that adds each of the sub-cfgPatches entries as required addons that each of the sub-cfgPatches entries references as a requirement. For example: Main PBO - config with MAIN CFGPATCHES ENTRY -/sub-folder one -- config with faction 1 cfgPatches entry (referencing MAIN as requirement) -/ sub-folder two -- config with faction 2 cfgPatches entry (referencing MAIN as requirement) etc.

I've just been looking at how BI do it in the main game's files and I noticed something you may or may not have already done - the main pbo root directory has a config.cpp as well. Though I can't see anything referencing the "sub configs" it does seem to be a running theme that any PBO that has configs within sub-folders also has a main config, even if its just a basic cfgPatches entry. Is this something you've tried or are you just putting the separate configs in the sub-folders and leaving it at that? I'm pondering if the "main" config acts as some sort of anchor or some such...I might also be chatting nonsense...

No worries. I've been modding OFP/Arma on and off since the early days of OFP modding and I still forget some of the most simple and basic stuff after a break - it'll come back to you.

Is there a Model.cfg entry for the new addition? Are the named selections correctly defined in the new model?

I have neither the time, nor the inclination to explain [a modder's workflow] to a man who rises and sleeps under the very [mods/addons RHS produces] and then questions the manner in which [they] provide it. I would rather that you just said "thank you" and went on your way. Otherwise, I suggest you pick up [the modding tools] and [do it yourself].

Looks more like a LOD/view-distance issue than a texture quality change.

Why would you move some of the game files and not all the game files? What files did you move (and which did you leave)? I'm surprised it works at all if you've moved half of your installation folder...

https://forums.bohemia.net/forums/topic/232367-arma-3-addon-request-thread/

I don't think there is such a command...

No. Well I suppose you technically could then script it to switch between a version with UGL and a version without when you "add" and "remove" the "attachment", but really its more trouble than its worth and from a work-flow perspective you'd still need to code and model both versions as well as code all the scripted swapping bullshit...

You simply need to create those named selections in Object Builder. Select faces and vertices that use the texture you want to assign to "camo1", then right click in the named-selection window and create new selection then call it 'camo1'. Repeat the process for 'camo2', 'camo3,' 'camo4' etc as many times as needed. Then you need to add those selections to your model.cfg in both the 'cfgSkeletons > skeletonBones' list, and the 'cfgModels > sections' list. As to the rest of your query, sadly I am unable to help as my experience working with vehicles is rather limited.

Calling to a model for the uniform only sets what the uniform object looks like when its placed on the floor (i.e. the folded up bundle of clothes you see when you drop a uniform on the ground - hence the "suitpack" path). The part you need to focus on to fix your issue is: uniformClass="092nd_BDU_Base"; This entry (for each uniform) MUST correspond to a cfgUnits class - i.e. an infantryman, and THIS is where you define the actual uniform model (i.e. what it looks like when worn) as well as define hiddenselections etc. My guess is you don't have a unit defined with the '092nd_BDU_Base' class... Try having a read of Arma 3: Characters And Gear Encoding Guide for further info, it'll help you understand what you're trying to accomplish and hopefully eliminate a bit of the trial-and-error for you...

You're referencing another external class again (UniformItem) which you haven't defined. This one is a little different so you'll need to reference its sub-classes too, as seen below: class InventoryItem_Base_F; class ItemCore; class UniformItem: InventoryItem_Base_F { type = 801; }; class Uniform_Base: ItemCore { scope = 0; allowedSlots[] = {901}; class ItemInfo: UniformItem { uniformModel = "-"; uniformClass = "B_Soldier_F"; containerClass = "Supply0"; mass = 0; }; }; // REST OF CFGWEAPONS STUFF HERE class U_B_CombatUniform_mcam; class 092nd_Standard_BDU: U_B_CombatUniform_mcam { scope=2; scopeArsenal=2; author="Winter"; displayName="[092nd] Standard BDU"; model="\A3\Characters_F\Common\Suitpacks\suitpack_blufor_diver"; picture="\092ndNPCs\data\Icons\H3_ODST_Uniform.paa"; class ItemInfo: UniformItem { uniformModel="-"; uniformClass="092nd_BDU_Base"; containerClass="Supply150"; mass=10; uniformType="Neopren"; modelSides[]={6}; }; };