So I threw this mod together for personal use on my own server and decided to share it with the community. It started out as just a way to try to determine magazine compatibility based on caliber, but it just kept growing as I decided to add more and more. Now it serves as a wider framework for automatically determining and implementing compatibility between modded weapons and parts.

WTT Armory Wages of Sin AR with Moxopixel attachments from MagTape and Tactical Gear Component as well as optics and components from EpicRangeTime’s All In One and SamSwat Optic Port.

The script performs a web of comparisons between modded and vanilla items using their metadata, the _props of the items those modded items were cloned from, other modded weapons in your database, and pretty much cross references everything in the web. It was the best way I could think of to help the game logic answer the questions that would be simple for a human being (like: “Is this a 5.56 AR magazine? And if so, which of these other modded guns are 5.56 AR’s and therefore should be compatible?”) The actual workings of it are less complicated than you might think, but largely because I used LLM’s to help me distill down my own initially overly complicated approach and come up with the least common denominators.

The mod SHOULD only add attachments that SHOULD be compatible. As we see here, the mod has by-and-large only added modded 5.56 AR magazines to saintdeer’s MCX Virtus.

The Advantage with this approach is firstly that there is a huge reduction in bloat over broad strokes ‘every item compatible’ type mods, especially in modlists with many custom weapons and attachments. Secondly, the other advantage over other more specific compatibility patches/mods is that this mod should not need to be updated every time an equipment mod is updated and new items are added or removed, or their id’s are changed; This is because the mod calculates and applies compatibilities every time the server boots. The drawback is that, as such with any automation, it wont be as perfect as painstakingly curating and creating compatibility “by hand”. And there will absolutely still be some mistaken and “cursed” compatibilities applied. To that end, I’ve implemented a config file that has some options for adjusting the scripts behavior a bit when it comes to specific items; although it will take some know-how on the part of the user.

Selecting optics on the WTT Armory ACR with new compats.

Same way you install every mod, pinky… Actually though, the one caveat is that this mod ABSOLUTELY needs to load after all your weapon and gear mods. I’ve included an ASCII Greek character at the front of the folder name so it SHOULD load after every other mod, even the ones where authors have prepended their folders with “zzzzzzzz”. The greek character worked well for me, but may cause issues on non-windows machines or in languages other than english, idk; lmk if it does. If all else fails just use Load Order Editor to make sure the mod loads after all your other gear mods.

There is a configuration file in the mod folder - config/config.json where you’ll find the following:

“enabled”: bool — enables and disables the mods functionality
“verboseLogging”: bool — enables or disables logging every change implemented by the mod to the terminal/log. This will overwhelm your logs very quickly if you have a lot of modded items.

“secondPass”:bool — Have the mod run a second pass after the first pass to check again for compatibilities. I implemented this functionality to see if new compats were found after our initial compats were applied, but it rarely ever resulted in any new findings. I kept it in in case anyone wants to use it. Disabled by default and may increase server boot time on slower machines.
“inheritBaseConflicts”: bool — Enables or disables propagated items inheritance of their base item’s slot conflict filters (when items show up red and say there is a conflict in game and you can’t equip both). This is a medium weight curse reduction technique, mainly for bots. Disable if you notice many items not allowing you to equip them together.

“inheritClonedConflicts”: bool — Enables or disables propagated items inheritance of cloned item’s slot conflict filters (when items show up red and say there is a conflict in game and you can’t equip both). This is standard curse reduction technique. Test this setting on and off if you notice many items not allowing you to equip them together.

“VoidConflicts”:[] –– Id’s of items in this field will not inherit any new conflicts from items used to calculate compatibility. Can be used to eliminate unexpected or unintended new conflicts on a single item. Echoes of Tarkov’s canted aim item is included in this field by default.

“ManualAdd”:[] — If you identify an attachment or ammo that should be compatible with something else and you know the item id’s you can manually add them here and they will be pushed. The manual add is based on slots and the attachment item type must match up with the target item types available slots. So a foregrip can only be added to the filters of an item with the “mod_forgrip” slot. Format example is “ManualAdd”: [{“attachmentId”: “58948c8e86f77409493f7266”, “targetItemId”: “5fbcc1d9016cce60e8341ab3”}] I haven’t actually tested this function yet myself, but it SHOULD work

“whitelist”:[] –– Previously “excludeFromProprietary”. Function is the same. Basically the mod identifies slots and items that it deems “proprietary”, meaning it appears to only fit in one place. An example would be a mod that adds a new gun and only one magazine type for that gun. If that mag is the only mag that gun accepts and isn’t present anywhere else, the mag slot and the mag are flagged as proprietary, and the slot will not accept new items during compatibility calculations, and the magazine will not be propagated to other magazine slots. You can exclude entries from these flags here, thereby allowing them to propagate to the next most likely places. More than likely you won’t need this and can just use “manual add”.

“blacklist”:[] — Items to be excluded from compatibility calculations. For “blacklist”, “whitelist”, and “VoidConflicts” use the item’s mongodb id in quotes, with multiple entries separated by a comma. Ex: “blacklist”: [“5fbcc1d9016cce60e8341ab3”, “58948c8e86f77409493f7266”]

• PSA: I realized I currently have my “is this proprietary?”
  logic only flagging slots and not items, so a lot of stuff is getting propagated that shouldn’t. Fixed in 1.1.0
• Mainly just that the mod isn’t perfect and will add things that shouldn’t be added or miss things that should. Its not infallible and is at its core somewhat rudimentary.
• For now you can blacklist items from compatibility calculations if they end up in the wrong places, but this nukes all their added compatibilities, so its not the best solution. I haven’t added a granular way to do a “manual remove” in the same way I implemented “manual add”.
• Some items don’t quite sit right. Sometimes its just a wash and there’s nothing you can do, but for some instances you can use Tyfon’s Weapon Customizer to fix alignment issues.
• In my testing I noticed that certain mods, like MassiveSoft Weapons, add some layers of compatibility to their own items in a later hook from my mod, so you may get some warnings about items already being listed in filters or something like that. All this is telling you is basically that ACF already added the item to the slot filters. This shouldn’t pose an issue.

• I tested this mod in my current server setup which is running 100 server mods and didn’t notice any incompatibilities or conflicts, other than the small one listed above. At its core this is a item database edit mod, so its compatibility should be relatively extensive.
• The mod should also only make additions, not subtractions to filters, and only on modded items, not vanilla ones. So it should be relatively low impact on mods adjusting vanilla items.
• The mod relies heavily on caliber for computing magazine and ammo compatibilities, so if a mod adjusts calibers or adds completely new calibers it may not work the best in tandem with ACF, just be aware.
• I’m not sure how this will interact with bot generation mods when they have custom item imports on, because in my testing I always loaded this last. Theoretically if you put it in the load order before a mod like APBS or ALP and enable custom weapons and attachments in those mods, the new compats from this mod may propagate to the bot generation. But it depends on how those mods handle bot loadout generation and when.

• Support on this mod is going to be limited because, again, I made it for myself, for my personal server build, and for my friends. I’m sharing it with the community just because I thought it was neat and I wanted it for myself so I figured some other folks might want something like this too. So I’m providing it “as is” and if it gets updated it will probably be because I added functionality to it for myself first.
• That said, if there’s something truly broken or something like that, I’ll try to address it. I’m deep into trying to configure a new custom configured server build for SPT and my satisfaction with it really determines if I’m going to jump back in to the deep end of SPT.
• Also if you’re here to ask about my trader mod and if I’m going to update it to SPT 3.11… I might. I’m not sure. I have really big plans for it that I currently don’t have time to execute on, and I knew I wouldn’t be satisfied with just updating to 3.11 with no new content. If an update is coming for it I’ll post something on the mod page. (also if its your first time looking at that mod page, I need to apologize for how bat shit insane it is SPT was kind of a madhouse when I dropped that mod, fresh off the chaos and mass exodus resulting from the unheard edition controversy, so I came at it with an energy that seems wildly unnecessary for the current (much chiller by comparison) SPT community. lolz)

Answer is Yes and No; You can have your weapon mods load first in your load order then have the attachment mods load after, and as long as the attachment mod is compatible with the vanilla weapon from which the new modded weapon was cloned, the attachments should appear (I’ve had two people so far tell me its the other way around, but don’t take my word for it, just try it yourself**). This is actually why some of my example images are bad examples, because yes, you could get the WTT WOS AR with those moxopixel attachments and EpicRangeTime attachments by just having the attachment mods load after WTT Armory.

First issue with this though, is that a lot of people don’t know about the way load order works when it comes to this topic - And WTT Armory starting with a “W” means if people aren’t actively editing their load order, they often never see other attachments added to WTT weapons, because it loads near the end of their server mods. I’ve also seen SPT staff actively discourage people (with good reason) from mucking around with their load order too much unless they know what they’re doing. So that’s point one of this mod, it seeks to be plug and play without needing to mess with your load order.

Now if you DO alter your load order to add compatibility, this works fine if you are only using a couple mods that handle mostly just weapons or mostly just attachments. The problem with this though is that the compatibility through load order is linear. So when you have a lot of mods, like I do, some adding weapons AND attachments in a single mod, only the weapon mod that loads first will receive the attachments from the mod that loads after and not the other way around; So on and so forth down the chain. For example: Take WTT Armory and Echoes of Tarkov, both add weapons AND attachments. If you load WTT first, its weapons may inherit attachments from EoT, but EoT’s weapons will not inherit attachments from WTT, and vice versa if you flip the load order. This mod seeks to be omnidirectional in this regard, at the cost of accuracy and a (hopefully only) slight increase in the potential for cursed guns.

Oh and I’m not even going to get deep into the fact that even in your “strictly weapon” mods, most of those components are technically attachments. Like the lower receiver of an AR is “the gun” but even the upper receiver is technically an attachment, so even two “strictly gun” mods may have the potential for cross compatibility that would be limited by load order.

Case and point: If you want simple compatibility between a few mods and don’t mind missing out on a few things, use load order to create that compatibility by loading weapons first, then the attachments you want propagated to those weapons after. If you’re a goblin and want it ALL (at the cost of maybe a couple misses and some slightly spooky guns) with omnidirectional compatibility and no need to mess with load order, use this mod. Pros and cons to each. As always:

**Technical details on this one point in case you are a dev (nerd) and are wondering why: So as I understand it, when you create a cloned item via custom item service it inherits everything from the item you clone it from, then you alter props and locales to meet the desired values of your new item. If you explicitly define, for example, new filters for “mod_scope” it overwrites the base items filters and now you’ve only whitelisted those attachments for “mod_scope”. If you load your weapon first, you define that list, but things like the “name” (not the one from locales, that’s the one you usually change) actually remain the same as the item you cloned from (I actually didn’t realize this until I began developing this mod and output every detail of all my modded items to a log). So when you load attachments after your new weapons and parts they still show enough info from the original item to have those attachments added to their filters. BUT, if you load your new weapon AFTER the new attachments, and you explicitly defined the filters for those mod slots, it will overwrite whatever has been added and once again explicitly white list only the attachment id’s that you’ve added. I hope this makes sense, I had to do a lot of digging and really figure out SPT’s “order of operations” for this stuff to make this mod work the way it does.

Already addressed this at bullet point 4 under known issues. Its harmless. Another mod is trying to retroactively add compatibilities to its items at a later hook than mine, but ACF already added them.

• AcidPhantasm — Looking at their code really helped me figure out the best way to isolate modded items from vanilla ones in the script; Without that this mod probably wouldn’t exist.
• MoxoPixel — Again, some of the main reasons I wanted to make this was to use their mags with any weapon; But also because in development I looked at and reverse engineered some of their methods to use in propagating compatibilities.
• All the amazing modders making custom weapons and equipment for SPT. They drove me to do this. This is their fault.
• The heralds of the apocalypse. I mean, Chat GPT and Grok ; For helping me boil down my insanely over complicated approach to this mod into much more organized and condensed steps. I feel like I lost a bit in the process, but hey…

Finally,

If you like my mods and wanna show me a little support, you can:

Also in lieu of donations to me, I also fully endorse donating to the Lupus Foundation of America and the National MS Society. I personally have Systemic Lupus, and my mother had MS for most of her life before she passed - so these causes mean a lot to me. Giving is appreciated.