Pennyworth

Here is the All in One Config for Apex, as of June 11th stable branch update (1.62.137494). I will be updating these periodically and will include dumps with some of the larger and more popular mods. All of these will be view able from this directory, dependent on what game version the dump was on. The mods used will be listed in the file name, and I'll provide links to the most updated versions of those mods in this post. If you find any issues feel free to leave a comment on this thread, message me here on the forums, or message me on the main Arma discord. All in One Configs for the following addons can now be found in the 1.63 folder, included are different combinations of addons frequently used together. ACE ALiVE CBA CUP IFA3 RHS The code used to generate these can be found below in the spoiler. I've only made minor edits to the script from it's original state, and that's mainly because there have been new commands introduced since it first written (2010). The script will require you to use an extension I wrote for writing to a file. Credits: Denis Usenko - wrote the original script defunkt - the initial idea and code utilizing Map Builder's File IO Extension (used in previous version of this script) NeoArmageddon - Map Builder Addon (used in previous version of this script) Script F. A. Q. Known Issues

I thought I would verify some information I read on the wiki regarding section counts. More specifically, For this test I created two objects, one with 16 proxies of a shelf model in the 1st LOD, ShadowVolume, and Geometry, and the other object had all of the shelves in the "base" object, instead of proxies. Images of the models and the video settings I used can be seen here. I then created numerous duplicates of the object and observed the FPS and draw call count from an Intel debugging tool. Here's a small spreadsheet with some of the data I found while testing. Though the model with proxies did have higher draw calls, the total number is so low in this testing that there was no adverse effect on FPS. With the object without proxies we only see the draw calls go up between the 500-550 range, but we see it go up for the object with proxies first between the 30-40 range. I was initially confused by this, but after some testing I determined that the draw calls went up for the object without proxies exactly on the 513th object, meaning that the first set of 512 objects shared draw calls. Now what about the object with proxies? Well if the draw calls are shared between 512 "instances" of an object, and there are 16 proxies in the object, then that should mean the first 32 objects of that type will share the same draw call (512 / 16 = 32), and the 33rd copy of this object will get a new draw call. I then tested this and did in fact see the draw call count go up every 33 objects. So my findings are that the information on the wiki regarding this is wrong, but I wanted to get opinions on my method of testing and any thoughts before I made any edits. I'll do some more testing with this later for things like weapon accessories and equipment, and post an update if I see anything interesting.

Preface I want to start by saying that my intention isn't to make a quick-and-dirty guide to getting clutter working in Buldozer. I think it's important to try and understand how the technology works, so I will explain in probably too much detail how I figured this out. While trying to determine if it was possible to update Buldozer lighting to look similar to the lighting in game, I stumbled upon something rather interesting. I noticed that Buldozer was reading "Arma 3 Steam Installation\dta\bin.pbo", or "P:\bin\config.cpp", if "Arma 3 Steam Installation\dta\bin.pbo" wasn't present. I had known that Buldozer loaded a config from somewhere, but never really looked into it in detail. It came as no surprise that there was an entry for "CfgWorlds >> DefaultWorld" in there, but I couldn't figure out if "DefaultWorld" was the terrain being used by Buldozer, so I ignored that for the time being. What was more interesting was that there were entries for CfgSurfaces and CfgSurfaceCharacters. Well, why is that useful? How CfgSurfaces, CfgSurfaceCharacters and Clutter work If you understand how surfaces and clutter work, then you can skip to the next section. To the best of my knowledge, the full process of how clutter appears on your terrain goes something like this: You define a material for a surface in your layers.cfg (e.g. material = "yourTag_yourMap\data\yourTag_someGrassSurface.rvmat";) Your RVMAT contains two "stages", //yourTag_yourMap\data\yourTag_someGrassSurface.rvmat /* ... stuff ... */ class Stage1 { texture = "yourTag_yourMap\data\yourTag_someGrassSurface_nopx.paa"; /* ... stuff ... */ }; class Stage2 { texture = "yourTag_yourMap\data\yourTag_someGrassSurface_co.paa"; /* .. .stuff ... */ }; When you generate layers in TB (Terrain Builder), it takes your original satellite, mask, and normal (if you are using normal map) images and splits them into "tiles". At this point it reads the RVMATs from your layers.cfg (e.g. yourTag_someGrassSurface.rvmat) and creates one, or more RVMATs for that specific tile (e.g. p_000-000_l00.rvmat). The generated tiles (e.g. p_000-000_l00.rvmat) use your yourTag_someGrassSurface_nopx and yourTag_someGrassSurface_co textures, instead of the original yourTag_someGrassSurface.rvmat. You define properties for that surface in "CfgSurfaces", for example: class CfgSurfaces { class Default; class yourTag_someGrassSurface: Default { files = "yourtag_somegrasssurface_*"; character = "yourTag_someGrassSurface_character"; soundEnviron = "grass"; soundHit = "soft_ground"; impact = "hitGroundSoft"; }; //more surfaces }; The important things to note here are "files" and "character". a) The "files" corresponds to the name of the texture used in your surfaces RVMAT (yourTag_someGrassSurface.rvmat), in this case yourTag_someGrassSurface_co, or yourTag_someGrassSurface_nopx. I couldn't tell you definitively which is used. This is why it's important you tag the name of your textures, if you don't you could easily mess with the vanilla or third party terrains if you are using the same texture or surface names. b) The "character" corresponds to an entry in your CfgSurfaceCharacters. You define properties for that surface in "CfgSurfaceCharacters" class CfgSurfaceCharacters { class yourTag_someGrassSurface_character { probability[] = {0.4, 0.4}; names[] = {"yourTag_GrassGreen", "yourTag_ThistleThornGreen"}; }; //more surface characters }; So now your character is defined, but now the game needs to know which models to actually place on your terrain. The entries from "names[]" point to things defined in "CfgWorlds >> yourTag_yourMap >> clutter". You define the actual clutter models that will be used in "CfgWorlds >> yourTag_yourMap >> clutter". class CfgWorlds { class someBaseTerrain; class yourTag_yourMap: someBaseTerrain { //lots of stuff before this class DefaultClutter; class clutter { class yourTag_GrassGreen: DefaultClutter {/* config entries here for your clutter */}; class yourTag_ThistleThornGreen: DefaultClutter {/* config entries here for your clutter */}; }; }; }; When your terrain is loaded in game, and you go to a specific location, it looks at which of the generated tiles RVMATs (e.g. p_000-000_l00.rvmat) corresponds to the location you're at. Using that, it applies the nopx and co textures for all the surfaces on that tile, and possibly surrounding tiles. Now you might ask, where does the clutter come into this? For each of those surface textures it loads, it looks at the "files" config property for ALL of "CfgSurfaces" for something that matches the pattern of the texture it's searching for. In the case of yourTag_someGrassSurface_co, it matches the surface with the "files" entry of "files = yourtag_somegrasssurface_*", which has a "CfgSurfaces" entry of "yourTag_someGrassSurface". Again, this is why it's important to tag your surfaces or surface texture names. At any given moment, every single terrain you have loaded has all of its CfgSurfaces loaded at the same time, so it's completely plausible surfaces and textures that aren't tagged can conflict. Now that the game knows what surface is being used, it can assign all of that surface's properties to it. For example, if you were to walk on that surface (yourTag_someGrassSurface), you'd get the "grass" sound, if you were to shoot that surface, you'd here the "soft_ground" hit sound and you'd see the "hitGroundSoft" particle effect, and most important for us, the "character", which is "yourTag_someGrassSurface_character". If you get the position of that command with scripting and pass it to the surfaceType command, it should return "#yourTag_someGrassSurface". If it returns "#Default", that likely means it didn't match the texture for that surface with any "files" from the various "CfgSurfaces" entries. Sweet, it found a match for the surface (yourTag_someGrassSurface), and now it knows the character (yourTag_someGrassSurface_character). As you might guess, it then looks at "CfgSurfaceCharacters >> yourTag_someGrassSurface_character" to see what character needs to be used. The "names[]" of the clutter used by "yourTag_someGrassSurface_character" are "yourTag_GrassGreen" and "yourTag_ThistleThornGreen". Similar to "CfgSurfaces", the "CfgSurfaceCharacters" for all terrains are loaded at the same time, so tagging is important. Finally, now that it knows the names of the clutter it's looking for (yourTag_GrassGreen and yourTag_ThistleThornGreen), it looks in "CfgWorlds >> yourTag_yourMap >> clutter" for matches. Now it can display the corresponding clutter models on that surface. From what I can tell, it only looks for the "clutter" entry on the terrain you're currently loaded on, but I'm not 100% sure on that. There you have it, from start to finish how clutter is added to a terrain (I think ). Testing and Experimentation From previous tests, I concluded that the surfaceType command returns "#Default" at a certain position if it didn't match the texture for a given surface with any "files" from the various "CfgSurfaces" entries. With some scripting, I was able to show what surface was at the middle of the screen at that time in Buldozer by adding the following to the initBuldozer.sqf [] spawn { while {true} do { sleep 1; private _pos = screenToWorld [0.5,0.5]; _surface = surfaceType _pos; systemChat format ["Surface: %1, at :%2", _surface, _pos]; }; }; As expected, it returned "#Default" for everywhere I went. Well, that makes sense, it's not finding any "CfgSurfaces" with a matching "files". So I wondered, what if I added my surfaces to the "CfgSurfaces" in "bin\config.cpp"? We already know that it's reading "bin\config.cpp", and "CfgSurfaces" is accessible across all terrains, so that means even if I don't know what "CfgWorlds" Buldozer is loading, I should still see what surfaces are being used. Lo and behold, it worked! With a test terrain, I was able to get it showing the corresponding "CfgSurfaces" entry for the surface that was below the cursor. As shown in the gif below, you can see it prints the name of the surface below the cursor as it moves. Alright, well that's fine and dandy, but we're still missing clutter. We know "CfgSurfaceCharacters" is also accessible no matter what terrain you're using, but that's useless without the clutter from "CfgWorlds" for that terrain. Here is where I got a bit lucky, I just guessed that it's loading "DefaultWorld", and I'll be damned, it is. So after adding some basic clutter to "CfgWorlds >> DefaultWorld >> clutter", I saw this. To confirm that it wasn't just a flook, I tried the same thing with Takistan and this was the result. Success! How-to As a warning, in its current state, this is something I'd only recommend for advanced users. To get it working initially I'd recommend experimenting on a smaller terrain so that you can quickly open and close Buldozer to test. For those not aware a "//" comments out everything on that line, and a "/*...*/" comments out everything between the asterisks, so those were used to provide more context. For the sake of length, I also snipped out parts of configs to allow things to be more readable. Open "P:\bin\config. cpp " Find "class CfgSurfaces", and add the "class CfgSurfaces" for your terrain. In my case, I split the "class CfgSurfaces" from my terrain's original config. So after modifying it, this how it looked: //P:\bin\config.cpp CfgSurfaces { class Default {/* default surface that I didn't touch */}; class Water {/* default surface that I didn't touch */}; #include "\path\to\your\CfgSurfaces.hpp" //could be a different file extension than hpp }; For example, my "CfgSurfaces.hpp" looked like this: //P:\path\to\your\CfgSurfaces.hpp class myTagSurface1: Default {/* various surface properties */}; class myTagSurface2: Default {/* various surface properties */}; //more surfaces, etc Find "class CfgSurfaceCharacters", and add the "CfgSurfaceCharacters" for your terrain. In my case I split the "class CfgSurfacesCharacters" from my terrain's original config. So after modifying it, this how it looked: class CfgSurfaceCharacters { class Empty {/* default empty character that I didn't touch */}; #include "\path\to\your\CfgSurfaceCharacters.hpp" }; For example, my "CfgSurfaceCharacters. hpp " looked like this: //P:\path\to\your\CfgSurfaceCharacters.hpp class myTagCharacter1 { names[] = {"myTag_someClutterName1", "myTag_someClutterName2", "myTag_someClutterName3"}; probability[] = {0.2, 0.2, 0.2}; }; //more surface characters, etc Find "DefaultWorld >> Clutter", and add the clutter from your terrain. In my case I split the "clutter" from my terrain's original config. So after modifying it, this how it looked: class CfgWorlds { /* didn't touch the config entries before this */ class DefaultWorld { /* didn't touch the config entries before this */ class clutter { #include "\path\to\your\clutter.hpp" }; /* didn't touch the config entries after this */ }; }; For example, my "clutter.hpp" looked like this: //P:\path\to\your\clutter.hpp class myTag_someClutterName1: DefaultClutter {/* various surface properties */}; class myTag_someClutterName2: DefaultClutter {/* various surface properties */}; //more clutter definitions, etc Check your Buldozer RPT to determine if "Arma 3 Steam Installation\dta\bin.pbo" is being loaded. You would only see it in the RPT if you removed "-noLogs" from your Buldozer parameters in TB. You'll see it about 40 lines down in the RPT in the "==== Loaded addons ====" section. If you don't see it loading "Arma 3 Steam Installation\dta\bin.pbo" 1) Launch Buldozer and see if your clutter is present. 2) If you do see clutter, celebrate! If you don't, then briefly mourn, check everything is done correctly, and try again. If you see it loading "Arma 3 Steam Installation\dta\bin.pbo", proceed to make a backup of that PBO. It's not the end of the world if you lose it, as you can always verify integrity of the game cache on Steam. Just don't forget to restore the original PBO if you actually want to play A3. Option 1, deleting the PBO: a) Delete "Arma 3 Steam Installation\dta\bin.pbo". If Buldozer doesn't see that PBO then it *should* default to using "P:\bin\config.cpp". b) Launch Buldozer and see if your clutter is present. c) If you do see clutter, cheer! If you don't, take a moment to shed a tear, verify you didn't make a mistake somewhere, and try again. Option 2, replacing the PBO (more tedious): a) Using a PBO packer of some kind (I'd recommend pboProject), pack "P:\bin\config.cpp". b) Copy your newly packed PBO and replace the existing one in "Arma 3 Steam Installation\dta\bin.pbo" c) Launch Buldozer and see if your clutter is present. d) If you do see clutter, scream with joy! If you don't, temporarily weep, make the necessary sacrifice, and try again. Conclusion Thanks for taking the time to read this. Hopefully it wasn't too dry or bloated, and people found it helpful. My goal with explaining some aspects in detail was in hopes that others might be inspired or have ideas on similar aspects. If you believe any of the information is incorrect, or have a better explanation for things, feel free to let me know. And thanks to Lappihuan for letting me bounce random things off him. I haven't had time to try and achieve my initial goal of changing the lighting in "DefaultWorld", but I think this was a good diversion. It seems like there is potential here for meeting that goal, and allowing for more as well.

Config and model.cfg look fine, so my guess would be that there is something wrong with your named selections. Does the unbroken window texture disappear if you animate the Glass_1_source in buldozer? If the answer to that question is no, then the problem is with your model.cfg or the P3D itself, as buldozer doesn't look at your config.cpp.

Good work! Always nice to see audio getting some love. Could this also be applied to things like destruction sound effects? An example:

Pretty frustrated with myself for not spotting this during testing, but there is an issue with the furthest distant LOD on 11 objects being a white box/plane. There could be more, but I've already fixed the ones mentioned in this ticket. Here is an example image of the issue: This will be hotfixed, but I'd like to give it another day first to see if there are any other hotfix worthy issues that pop up. Sorry for the inconvenience.

Building class names, paths to models, and positions should be the same. The only thing that should have changed is related to animations. The majority of JBAD buildings were for structures_e, which like Neo stated, are used on Takistan and Zargabad. However, all of the A2 terrains will have received upgraded buildings, in some cases it might only be one or two new buildings, but it's probably best to play it safe and reindex the maps. If needed I could put together a list of specific buildings that were updated, but I don't really have an easy method of telling you what maps use those specific buildings.

Now™

It's fixed in the next update, which you can expect soon™. If you're on your death bed and your last dying wish is to have dust effects on the CUP Terrains and Tanoa, then I can give you a small PBO that fixes it.

CUP Terrains has many faults, but causing Taunus to miss dust effects is not one of them. From the V2 Taunus config I have, even if you did correctly add "CUP_Worlds_DustEffects" to your requiredAddons, dust effects would not work. This is because the values you use in the "rightDustEffects" and "leftDustEffects" array are incorrect. These should be the names of entries in your CfgSurfaces. For example "xcam_grass_green_co", you have no CfgSurfaces entry to match that, and in addition it has an "_co" suffix. Secondly, the way you guys are defining your dust effects would actually cause dust effects to disappear on all terrains, even Stratis, Altis, and Tanoa. As I mentioned in the ticket linked above, this is only an issue because you can't inherit nested config arrays, so every map author is overwriting everyone else's dust effects when they define them, so it's just a game of whoever's config gets loaded last. Here is a PBO with a config fixing the missing dust effects, as well as including all of the A3 and CUP dust effects. I did this at 2 AM so I could easily missed some Taunus surfaces, but it worked in the quick testing I did. Hopefully this post didn't come across as hostile, I just don't want people to think CUP is breaking people's maps and ignoring the issue.

It's been awhile since we've had an update, so I thought I would let people know that we're still active and working hard towards a release in the upcoming weeks. The changelog is long, but some of the more notable things are improved lighting on European terrains, roads, railways, and more available in the editor, implementation of JBAD directly into CUP, and performance improvements (geometric occluders). If time permits, maybe even some extra sound effects.

Your error probably occurs because you're inheriting from House, House_F, and Ruins_F, but you have no entry for your requiredAddons. Likely leading to your config loading before the A3 vanilla configs, and unintentionally messing with base classes. You can fix this error by simply adding: requiredAddons[] = {"A3_Structures_F"}; The fact that it doesn't happen with CUP Terrains loaded is slightly concerning to me, as it could mean that CUP Terrains is altering base classes. Hopefully that's not the case, and it's instead something silly like loading CUP Terrains and your addon leads to a longer startup time during which it loads the vanilla structures config before it's able to load your config. Either way, I'll look into a little further.

Steam workshop should be updated. Previously, there were some requests for torrents as well, so links for those can be found below. CUP Units 1.8.0 CUP Vehicles 1.8.0 CUP Weapons 1.8.0 CUP Vehicles ACE Compat 1.8.0 CUP Weapons ACE Compat 1.8.0

I'm going to tell you how to metaphorically fish, and then give you a fish. First, I would suggest is using something like Notepad++'s "Find in Files" option, and searching for a related term. For example, I see you are inheriting "Vest_Camo_Base", so I'm going to search for that with Notepad++. Alright cool, it found that 12 times in "a3\characters_f\config.cpp", now if I click one of the highlighted lines it will open that file and take me to that line. So I'll first look at where "Vest_Camo_Base" is defined, I see that in the "ItemInfo" it's inheriting "VestItem", just like you are. However, it defines a hiddenSelection of "camo" here. So then in your config you'll want to define that same hiddenSelection again for, but that hiddenSelection also needs an accompanying texture to go with it, so you'll want to define hiddenSelectionTexture for that vest as well. After you made those changes your "ItemInfo" would look something like this, I've obviously cut it short for the sake of space on this post. class TF2031_OCP_PlateCarrier1_rgr: Vest_Camo_Base { ...some stuff... class ItemInfo: VestItem { uniformModel = "\A3\Characters_F_EPA\BLUFOR\equip_b_vest_kerry"; hiddenSelections[] = {"camo"}; hiddenSelectionsTextures[] = {"\Projects\TF_2031_Mod\addons\TF_2031_Units\data\textures\plate_carriers\TF2031_PC_MCAM_co.paa"}; containerClass = "Supply200"; mass = 1; ...your HitpointsProtectionInfo here... }; };

If you are using extractPBO try the following from batch file or command line, and you will need to include the letter to the drive: extractPBO "D:\path\to\@IFA" "P:\path\to\where\you\want\it\extracted"

Another image he didn't share here.

The config dump for the Apex update (1.62) has been added. In the next few days I will also add dumps for addons as they are updated by their various authors.

It doesn't matter what folder it goes in as long as it's loaded like a normal addon. You could place it in your Arma 3 directory as "@MonkeysLikeBananas\addons\" and it would function the same as if you dropped it directly into the CUP terrains folder. However, in general I would advise against putting extra PBOs into existing mod folders that you don't control, in this case it's a straightforward fix and wouldn't cause any issues. Just as an example if it was a more intricate fix, and say when the next update comes out you forgot it was placed in there, then it could cause issues for you that would be hard to track down.

The repair function on the launcher only works if steam has recognized that there is an issue, which in most cases it doesn't. One thing you can try doing is to verifying the game integrity on steam, which we recently learned also checks the integrity of workshop content. To access that option right click Arma 3 from the game library > Local Files > Verify Integrity of Game Cache. It can take several minutes depending on your hardware and will only check the workshop content integrity after you hit the "ok" box when it says it has finished verifying the integrity of Arma 3. Hope that resolves your issue. The roads have been out since the 1.60 update, but I've heard more comments about them in the past week than in that whole time. Nonetheless, they'll be back in the next update along with some other missing objects.

The CfgModels error was caused by one of the configs from the ported CWR2 content. It has been fixed for the next update. In the meanwhile, lolkij's linked PBO will fix the error.

I've noticed the D3D device removed error occasionally while playing recently, but that was just with vanilla content. It seems to happen randomly every few days and sometimes a computer restart fixes it. When the transition happens is completely up to the engine and its own algorithm. We can however improve the LODs so there isn't such a rough transition in some cases. If you could post a ticket on our bug tracker with the name of the object I'll take a look and try and improve them. Thank you for noticing the sound changes when firing weapons in A2 buildings, it was part of the 1.1.0 update, but I was still very proud of it because it required a lot of surfaces to be changed and fixed. With that being said, any buildings in particular you notice there being no reverb sound in? I haven't touched the sounds in the newly added OFP terrains so there are bound to be some sounds missing there. If you could make a ticket on our bug tracker with a list of buildings that don't have reverb sounds I'll make sure to get them all fixed for the next update. Also, what do you mean by starwars fight gun? The tracer color and effect is totally independent from the terrain so it should behave the same as on A3 Terrains. Finally, what do you mean by environement colorimetry? The lighting on the European terrains is next on kraze's list for next update. I will also look into reducing the brightness of the satellite map textures for those terrains, as BI had to tone down the brightness of the satellite maps for Stratis and Altis for the 1.60 update (visual upgrade). I'm not trying to pick apart your English, just looking for clarification. And excuse any of my formatting or grammatical mistakes, I'm away for the week and posting this from my phone.

I'm leaning towards a corrupt download or another addon causing the issue, as pboProject doesn't really forget to binarize things. If you want to upload the mission and send it to me along with a list of mods I'll try and help narrow down the issue.

Are you running any other addons? I've seen a lot of errors in my life, but never that one specifically.

Sorry to hear you won't be continuing work on these buildings, they really do look great. I'd like to help pick the project back up and allow terrain makers to utilize these buildings, as quality buildings are hard to come by. With that being said, are there any areas in particular you think work needs to be focused on? Or is it more scattered? Thanks.

The complete pack is just the maps and core together, placed in the same addon for convenience. The maps pack only contains maps from A1, A2, and DLCs (Chernarus, Takistan, Utes, etc...) and requires you to have the core pack to use it. However, the core pack by itself is standalone and contains the actual models of buildings, plants, etc..., and is sometimes used by other terrain makers to give them access to more content to place and use on their maps. So if you were to load up the game with only the core pack you would see no extra maps, but would have access to more structures and objects in the editor. So for your situation I would assume you would like to use a map like Chernarus. This would require the complete pack, or alternatively the maps and core, because complete = maps + core.