Really? Lol, that's insane.
Yeah, that freaked me out too =)
This is all about code structure. See, all modern games use Object-oriented programming approach, where all code is made of different classes. Classes are essentially the blueprints for making different game objects. Say, in OpenXcom we have `RuleItem` class, and it creates an item from rulesets every time yaml parser see `- type:` under `items:` (well, not exactly like that, but it's just for simplicity). So all in-game items are essentially the same, they just have different properties, but they are all printed with the same logic, coded in `RuleItem` class.
Now, in XCOM 2 any item has to have own class, and in-game will be blueprinted from that specific class. So one class for assault rifle, one for sniper rifle, one for grenade and so on. That can (and AFAIK all items do) have some config settings, so you can specify damage output of your rifle without compiling your own code, but you can't make a brand-new item without making a new class for game logic.
On one hand, that puts modding of XCOM 2 to another level, and most XCOM 2 modders would be treated as engine coders in our OpenXcom community, as XCOM 2 mods (well, most of them) essentially alters the game code. On another, it makes XCOM 2 modders one head above, as they can actually change game logic in a way they want, without making own version of the game (not to mention, that you can't distribute whole commercial games as altered versions). So yes, you have to make a new unreal engine code to make a new item, but you can make it in a way you want it to work without any limitsSo yes, you have to make a new unreal engine code to make a new item, but you can make it in a way you want it to work without any strict limits (for example, in OpenXcom you can't make a psi amp that will also shoot, but it's easy in XCOM 2). With such approach, we can have global overhaul mods like Long War.