Jackal326

You could also just make a new headgear/glasses/whatever item with a small black sphere (black on the inside, like my soul) within the Pilot LOD that would enclose the head/eyes. Though you would still be able to see in 3rd person...

Whilst it would be nice, I highly doubt any major changes (or even minor ones for that matter) are going to be made to the game/engine given that most of the developing power is now working on Reforger/ArmA4 (maybe).

I know very little with regards to vehicle configs but your method of adding eventHandlers to your vehicle is breaking your config The "a" encountered instead of "=" is from the 'a' in addEventHandler this addEventHandler ["FiredNear", { You'll need to add proper eventhandler subclasses and maybe even custom functions to get your code to work. Hopefully someone here will be able to correct your code for you as I have no clue.

Its also a memory point within the model itself so not sure it can be changed via just the config...

SJB Assault Rifles v1.0 After a few years out of the modding scene I am proud to present a pack of assault rifles that I have had in the works for what feels like decades. In reality its more like about 9 years, so its close enough. CONTENTS: The pack contains 25 variants of 10 famous rifles with more planned to be added in the future. A full list of the pack's contents can be found below: - AKM/AKMS - C7A2 (Canadian version of the M16A2 with OD furniture and TRI-AD I rail adaptor) - C8A3 (Canadian version and upgrade of the M4A1 with similar additions as the C7A2) - HK416 (10" and 14.5" variants) - HK417 (16" and 20" DMR variants*) - L119A1 (In CQB and SFW variants with various furniture - 6 versions and 2 with UGL - 8 total) - L119A2 (Only one CQB model so far, more versions with various barrel lengths are planned as well as various furniture) - M4 - M4A1 (3 versions with diffrent furniture and one with a grip-pod foregrip) - M16A2 (An old classic with an M203 version) - M16A4 (A more modernised M16A2 with RIS foregrip and an M203 version). * I realise a DMR isn't technically an assault rifle, but I already had the model done as part of a weapon pack I helped develop for my old squad so I decided to include it. FUTURE PLANS: I do plan to include other rifles in future versions, as well as more variants of currently included rifles - most are in the "one day, when I have the time!" stage. Throughout development I have been in two-minds as to whether or not to use custom sound files for the weapons firing sounds. I already use a few custom sounds for the bolt opening/closing and selector switches being used when switching firing modes. However, inheriting default weapon sounds from the base game's weapons allows users to use their own preferred sound mod and have this pack integrate seemlessly with other addons that do the same. If demand is high enough I may well implement custom sounds, or perhaps an alternate config to allow for choice but as of right now the weapons use sounds from the base-game's weapons. CREDITS: Without the help, advice and permissions of the people listed below this pack would not have been possible, so a huge thank you needs to be extended to the following people: - Twinke Masta (Johan Santana) - (M4A1 base model/textures) - Krycek - (M16A2 model pieces) - Da12thMonkey/UKF - (FA556-212 Suppressor base-model/textures) - Frimenitnet - (AKM base model) - Stefan Engdahl - (M203 textures and base-model) - PuFu - (PuFu's sarcasm rivals my own and the forum post made by PuFu often kept me amused and motivated) - Eddie Price - (Massive amount of work on the textures of most rifles and attachments and a lot of suggestions for model tweaks) VERSION HISTORY: v1.0 - This release Q&A: - What does this mod require? Please see the "'REQUIREMENTS' section below - Do you plan to add <insert weapon name here>? Maybe, but don't ask/demand/request/pleased/offer bribes for......infact bribes might work... - When will the next update/addition be released? When its ready... - Can I make a mission/campaign/showcase for your addon? Go for it. Being used in missions is why I released the addon in the first place. THE ALL IMPORTANT DOWNLOAD LINKS: SJB ASSAULT RIFLES V1.00 - STEAM WORKSHOP - Mirrors to follow SJB WEAPONS CORE V1.00 - STEAM WORKSHOP - Mirrors to follow REQUIREMENTS: Arma3 with the latest update This addon makes use of CBA's ASDG-JR (Joint Rails) and as a result requires CBA for Arma3 to function properly (read: at all as its listed as a required addon in the config). This addon also requires 'SJB Weapons Core v1.0' which contains all of the ammunition, magazine defines and magazine proxies for use across all of my planned weapon packs.

Having read the link you provided I had noticed the author has posted about '#if __has_include()' and was about to suggest that is where you start looking into, but you're already on that track so there we go...

...is it? I'm no config expert but I'm not entirely sure it is. Either the mod is dependant upon another one or it isn't. If you reference an external class from a mod you don't have installed your game wont load - likewise if you set the dependency to a mod you don't have installed you'll get errors on startup saying the mod isn't there. I'm not sure how you could make it a "soft dependency". What mods have you seen that do this?

Its either a positioning issue of the model itself (i.e. its X,Y,Z coordinates in Object Builder) which can be tested if you turn your characters head and the model DOES MOVE, or a named selection issue which will be evident if you turn your characters head and the NVG DO NOT MOVE... Keep in mind named selections are CaSe sEnSiTiVe and as such should match your model.cfg exactly.

At this point I'm not sure if you're trolling or just very naive. Mods, whilst broad in their scope and being able to change many facets of the games content don't come close to changing the core engine of the game. The game is not like a car where you can just take the engine out and swap in a newer, more powerful one. If that were even remotely possible I'm pretty sure BI would have done it themselves years ago. Its taken 4 games and numerous expansions for them to decide to switch over for Reforger/Arma 4...

My guess would be something with either the geometry LOD or more likely the 'Paths'/'Roadway' LODs of the model itself. If any of these are indeed the case you wont be able to adjust the AI's behaviour with config changes as any alterations would need to be made to the model itself, and given that the model is a base game model its Binarized so is not editable. Hopefully I'm wrong though...

Very.

Try adjusting your inheritance structure: class cfgRecoils { class Default; class recoil_default; class your_recoil: recoil_default { blah

Cool, glad you got it working, and good work on posting your solution, it'll help anyone who has similar issues 👍

Try without spaces or non-alphanumeric characters in the PBO names (make the - into a _ for example)

Your best bet for correct inheritance is to check how each class inherits its config entries. For example, you can use the following for your first two classes: class hgun_ACPC2_F: Pistol_Base_F { class WeaponSlotsInfo; }; class hgun_Pistol_heavy_02_F: Pistol_Base_F { class WeaponSlotsInfo; }; Then just refer to each of the remaining classes inheritance trees for the remainder of your config base class setup.

Try changing the uniform classname to be different to the unit classname (and of course changing the uniformClass entry to match).

Using your example above, you would add the following to each unit's config entry: genericNames = "OSEF";

I've not done any work with vehicle re-textures but I just checked out the config for the relevant plane and saw this: hiddenSelections[] = {"Camo1","Camo2","CamoGlass","camo_cockpit_1","camo_cockpit_2","camo_cockpit_3","camo_cockpit_5","number_01","number_02","number_03"}; As such, it looks like your hiddenSleection reference is incorrect, try changing it to "Camo1" in your config... EDIT: Just re-read your post and saw that it wasn't even showing up in the editor, try this and see if it shows in the default category...

There is also a TransportMagazine part to it, but here is a sample from my weapons packs (the config work is the same for a crate as it is for a vehicle...as crates are basically vehicles that don't move...) The '_xx_' prefix seems the standard for default in-game crates/vehicle cargo setups - don't have them the same as the classname of the item(s) you're referencing as that breaks things...

Run the P drive setup that should automatically unpack all relevant ArmA3 pbos for you...it might be another one of Mikero's tools that does it rather than a BIS tool...

I may be wrong but it might be because when textures are loaded from main game PBOs, i.e. the default textures, they're pre-loaded/cached before you ever see them in-game. When they're loaded from a mission PBO as you are doing in your example, the textures are loaded on demand and as such are not pre-cached and are loaded at a lower mip-map/quality to load them faster. If you were to make your re-texture into an addon (complete with config etc) and load it that way I feel your issue would disappear...

I suppose it comes down to one of two things, or perhaps a combination of the two: RHS is a combined team effort with different parts being made by different people. As such, each has their own methods and requirements for what they are making. The overall needs of the mod itself - do they require retextures of this one vest/helmet/whatever? If not its quicker/easier to not bother adding the named selections and hiddenselection defines. Granted, adding them in from the start makes things future-proof and saves time later if they decide to add other variants, but to each their own...

This may seem like a weird response, but go with me on this... Have you tried opening the .paa outside of game and if so does it look "normal"? TexView uses filters when its converting textures from TGA/PNG/whatever based on suffixes of the texture name itself. More information on this can be found HERE. Due to this, your texture ('BCO_SHC_MC.paa') may mean that TexView is trying to convert it to a macro texture. Always try and get in the habit of using the texture naming conventions when creating your textures so TexView knows what filters to apply - in this case you'd want your names to end with _co.paa EDIT: On second look, why does the hiddenSelectionsTextures array have two different textures for the cover for the same item? (_mc.paa in the main define, and _od.paa in the ItemInfo sub-class). This might also be a cause but I could be wrong... EDIT 2: After trying out my original theory by renaming a _co.paa texture I know works fine to _mc.paa suffix and converting it with TexView, the resulting file appeared fine with no issues I could spot...

To be honest it is perfectly acceptable if mod creators DON'T want people making re-textures of their work (in my opinion). It should be considered a BONUS if mod creators add hiddenselections/materials etc. to their work, not an expectation...

It depends what kind of gameplay you want, Arma is very diverse in the game types available so you'd need to be more specific as to what you're looking for...