Comments - real_leaper

Here's a quick and dirty fix. Edit demonized_weapon_modifiers.script and change this:
local c_obj = obj:cast_Weapon()
for set, val in pairs(v) do
c_obj[set](c_obj, val)
end
to this:
local c_obj = obj:cast_Weapon()
if c_obj then
for set, val in pairs(v) do
c_obj[set](c_obj, val)
end
end

I also toyed with an idea to put the reward items into a stash and giving the player its coordinates, but there's no easy way to do this without involving all the stash mechanics (achievements for finding stashes; addons that change the loot you find in stashes, etc; in my tests the stash always contained more stuff beside the reward, because other addons put it there). Maybe piggybacking on RF Receiver Stash addon would have worked better. But either way, that was too much work for me to bother.

Another idea is to actually spawn a stalker courier that would bring you the reward. Kind of like the courier in Skyrim that finds you anywhere, as long as you're outside.

I think Moira's HD Icons addon also does something similar (at least, it has parts highlighted in color).

Also, I think you translated the name wrong. This addon should be called "What to fix the part with".

For those of you who are reading this later: TheMrDemonized's statement was a joke. No, you can't merge them.

As for the lite version, it lacks all minor adjustments to everything, not just attachments. PBA only conflicts with AAAO in items_attachments.ltx, so I see no reason to solve it by using the lite version. Deleting your instance of items_attachments.ltx (or just giving AAAO higher priority in ModOrganizer) is easy, and produces better results overall.

For Anomaly Armor Attachments Overhaul compatibility, all changes made by this addon to items_attachments.ltx can be omitted. That is to say, Artifex's major armor attachment changes should take precedence over minor weight and immunity adjustments that this addon makes. There's no way to merge them.

In that case, use this Pastebin.com DLTX version instead. Similar minor adjustments spread over multiple semi-related sections - that's a perfect use-case for DLTX.

This addon contains numerous minor changes to armor attachments (items_attachments.ltx). What was the idea behind these changes? For example, it changes wound_immunity and explosion_immunity for af_plates from 0.056 to 0.0509.

Which version of the addon are you using? Did you install it with ModOrganizer?

EDIT: Anyway, there was a typo, I've just fixed it in v1.1.2.

However, you seem to be using an older version (not even v1.1.1). You have to either use ModOrganizer (or any mod manager), or properly remove the old version before installing a new version. Otherwise you'll have old broken scripts littering your scripts directory.

I can't. You'll have to figure it out yourself. The simplest course is to disable half of the addons in your loadout, then try driking. If it quenches, re-enable one quarter of the addons. If it doesn't quench, disable one more quarter of the addons. Keep going until you either figure out which addon does this, or you run out of addons you can disable and re-enable (many addons can't be disabled without starting a new game).

Also, try grepping the installed addons for any changes to [mineral_water] and grepping the installed addons for any scripts that mention thirst.

Slo-mo might be from More Melee Features addon.

Feel free to integrate anything I did here into your addon, then notify me, and I'll archive this version.

Also, people are complaining (and I've noticed it myself as well) that yadulin is too powerful. Not only does it heal you very quickly, it also heals your arms and legs pretty well (if you're using Grok's Body Health System) - all the while being relatively cheap and with 5 uses per item.

And some of the recipes that I've changed are somewhat circular (Item A is used to make Item B, and then Item B is used to make Item A). I haven't realized it until I had a closer look at the recipes in-game, but by that point the addon was already released, and I wouldn't have any idea what the fix for the respective recipes would be anyway.

Easy.

[recipe_sections]
recipes_foo = -500
my_cool_recipes = 200
recipes_for_my_addon = 1000

Sort the tabs with these numbers. If some addons happen to add recipe sections with the same number, sort also by recipe section name.

Honestly, the new craft.ltx feels like a half-measure. It would have been better to do something like this:

[recipe_sections]
recipes_foo
my_cool_recipes
recipes_for_my_addon

[recipes_foo]
output1 = recipestring,...
output2 = recipestring...

[my_cool_recipes]
output3 = recipestring...
output4 = recipestring...

[recipes_for_my_addon]
...

That is to say, let addons use any section name (as long as it's unique), and find them by keeping a master-section ([recipe_sections]) with the names of these sections as its fields. Sure, DLTX would be required to add fields to [recipe_sections], but I don't see why anyone wouldn't want to use DLTX. This is the use-case where DLTX performs perfectly. And you'd need to change the recipe-loading script, but you're already doing that, so there's no disadvantage here.

I don't get the new DLTX version. For example, it does:

!![1]
!title
!x_detector_simple
!x_detector_geiger
...

This makes no sense. "!![1]" already deletes the whole [1] section, there's no need to remove recipes in that section.

I don't get why you're trying to use DLTX here at all. BCSI allows to split craft.ltx into multiple files via #include. Any BCSI-based addons can (and will) just provide their own files, you don't need DLTX to keep compatibility with them.

BCSI also replaces the semantics for sections. Meaning that changes to vanilla craft.ltx do not matter. If any addon changes something in vanilla craft.ltx, BCSI will just nuke these changes by removing vanilla recipe sections [1]-[6]. Even with DLTX you won't get compatibility with these addons.

And if some BCSI-based addon provides its own craft.ltx with changed BCSI basic recipes, DLTX won't help either - BCSI will just override any craft.ltx changes with its own DLTX file.

Finally, two DLTX addons that both change craft.ltx (BCSI and some other BCSI-based addon) will likely clash, with the addon with the highest filename winning. So this doesn't help either.

The best, most honest way is to just ship normal craft.ltx, i.e. use the non-DLTX version. This is compatible with BCSI-based addons that add new recipes, it's compatible with BCSI-based addons that change basic BCSI recipes via DLTX (BCSI-based addon wins, because it uses DLTX and BCSI doesn't), and it's incompatible with any addon that ships its own copy of craft.ltx, but at least that conflict is obvious (ModOrganizer will show it).

The only thing I can think of where DLTX might be useful is when an addon ships its own changed vanilla craft.ltx, and BCSI just adds its own sections via DLTX, keeping changes to vanilla sections intact. But for that you need to change the DLTX file to NOT delete these sections, and NOT delete the vanilla recipes (otherwise you'll erase any changes to vanilla recipes that other addons do)...which will result in duplicated recipes (no idea why you didn't use vanilla section numbers for vanilla recipes).

A more elegant fix is to store the list of mutants at that location when the task is given. Then track the damage that these mutants receive. Once the mutants are dead, check if at least one of them received at least some damage from actor or actor's companions. If that isn't so, fail the quest (which, I think, is thematically appropriate - you promised to clear a mutant lair, and you didn't; the fact that someone else did the job doesn't mean that you get a reward).

Can you monkey-patch the reward function to prevent reward items from being teleported to actor upon task completion? Just replace any items with their money equivalent.

Right. Forgot to post this here.
BRBN with Drugs That Make Sense compatibility - Moddb.com
Drugs That Make Sense with BRBN compatibility - Moddb.com

Yes, you need both.

Try v1.1

The reason why integration is advised is because BCSI + my addon have 3 copies of recipe-loading code in total. This has got to stop. There should be just one function for loading recipes, and it should be used in all three places (workshop, encyclopedia, reading recipe items).

No, I haven't thought of that. But this is a good point, I'll look into it.

Found the culprit. It's z_parts_inject.script by koreisha.
If you have that script in your mod loadout, do the following:
1) Open the script in any good text editor
2) Find this line:
if parts_custom[key] then
3) Change it to look this way:
if parts_custom[key] and parts_custom[key][val] then

This should fix the issue.

Other scripts that monkey-patch the parse_list() function might also break the component display in item details sheet.

1. This should be fixed in v1.1.2

2. v1.1.2 also allows you to use smaller font for part names or even hide them completely.

Try v1.0.1

Feature request: Also add disassembly info to the tooltip. Right now it's only visible in item details sheet.

By the way, a few months ago (see comments above) some people reported that disassembly components go missing from the item details sheet. I have seen that as well, but I have no idea why it happened. The issue disappeared after I restarted the game.

Disguise Addon Merge alters gameplay_disguise.script (in fact, this is the only thing it alters).
Milspec PDA does not alter gameplay_disguise.script.

What made you think that you NEED a compatibility patch?

BCSI also breaks recipes in encyclopedia (encyclopedia still uses old-style recipe reading code, with sections [1] to [6]) and recipe reading UI, when activating recipe item in your inventory (again, UI-filling code uses old recipe reading code).

Here's an addon to fix that - Moddb.com

Though this really should be just integrated into BCSI.

Part name display is for WPO. In WPO you need to always be looking for gun parts in good condition to strip off the trophy weapons. When you rightclick on a gun to field-strip it, the menu shows part NAMES only. Unless you have perfect memory, there's no way for you to match the part you see in the tooltip with the name in the menu. Part name display fixes that: if you can see on the icon that it's a trigger, and in the menu you also see something about "trigger" - then you strip _that_.

I am amendable to making the condition and the part name text use different fonts. This way you'd be able to make part name smaller, if it irks you so. Is that something you want?

As for the larger text not showing immediately after looking at a tooltip for a non-weapon/non-outfit item - I will try looking into that. I initially assumed that there's some kind of delay and that's why the larger text isn't shown. But your observation is, indeed true - if you look at PDA, then at a weapon or outfit, the larger text is never there on the first try.

Try the new version, it has MCM support, so you can change the font. It might work better for you. Still don't know about EFP.

Done. You need to install Moddb.com and update Banjaji's Crafting system improvements + artifex's addons compatibility to v1.1.0. Make sure the dummy workshop_autoinject.script from this addon overrides all other instances of workshop_autoinject.script.

The original version of what? Elaborate.