Pocket test

[SittingDucken]

Summary

Bugfixes "Testing a continue for items that register incorrectly as magazines."

Purpose of change

Fix a build error.

Describe the solution

Implement a check to see if item is a tool or an armor and has a magazine. If it does, skip it.

Describe alternatives you've considered

No alternatives considered.

Testing

This run against the build.

Additional context

[Maleclypse]

(continued from above) ERROR : src/item.cpp:1854 [ret_val item::put_in(const item &, pocket_type, const bool, Character *)] tried to put an item (smart_watch) count (1) in a container (outfit_storage) that cannot contain it: pocket with type (MAGAZINE_WELL) not found

Error still happening

[SittingDucken]

Attempting to narrow it down. The call is odd. I can isolate it to generate a single message followed by the error. And then it gets called again and follows the expected function latb.

[Maleclypse]

Basic build passed. Good job. I’ll retrigger the failed tests and see how it goes

[SittingDucken]

Yeah, its a fair fix for now vs editing the loot table. I'm working through the logic of steps to determine if its truly an issue or not. The general gist I've got at the moment is any item that has pocket data magazine should not then insist on being loaded into a magazine well.

I think the route to start then would be the is_magazine() would need to be more robust in its typing determination logic. But that then goes counter to the typing model of other types which are essentially assigned labels. So I'm unsure if there's a direction to take without a proper determination of either
(Implement robust magazine type labeling)
or
(Implement robust is_magazine() logic)

[Maleclypse]

I'm a little concerned about the LTO build failure that keeps occuring. Can someone confirm merging this won't break a different build?

cc1plus: note: ‘-gsplit-dwarf’ is not supported with LTO, disabling
CCACHE_SLOPPINESS=pch_defines,time_macros,include_file_ctime,include_file_mtime ccache g++-9 -Isrc -isystem src/third-party -DRELEASE -DGIT_VERSION -DBACKTRACE -DLIBBACKTRACE -DLOCALIZE -DIMTUI -gsplit-dwarf -Os -flto=jobserver -flto-odr-type-merging -Wodr -Werror -Wall -Wextra -Wformat-signedness -Wlogical-op -Wmissing-declarations -Wmissing-noreturn -Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -Wpedantic -Wsuggest-override -Wunused-macros -Wzero-as-null-pointer-constant -Wno-unknown-warning-option -Wno-dangling-reference -Wno-c++20-compat -Wredundant-decls -g -fsigned-char -std=c++17 -m64 -fuse-ld=gold -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -MMD -MP -Winvalid-pch -include pch/main-pch.hpp -c src/filesystem.cpp -o obj/filesystem.o
cc1plus: note: ‘-gsplit-dwarf’ is not supported with LTO, disabling

[mqrause]

What is the purpose of the c++ change? It doesn't seem to me that does anything helpful, since find_pocket_for isn't even on the path that causes the error. That would be guess_pocket_for instead. The json change by itself should already fix the issue at hand. It doesn't prevent the same error popping up again in the future, of course, which should be fine for a quick fix.

Also unrelated changes should go into their own PR, or at the very least be described in the PR.

[SittingDucken]

Was seeing the error occur twice and tried to narrow down the first. Then noted that the outfit could just be changed to be like other basic containers that dont have tool flag. And yeah all for separating the changes out. Since the bugfix is blocking changes will leave that decision to others tho.

[SittingDucken]

Closing and recreating for basic build fixes.