Not a bug
BYOND Version:513.1495
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 79.0.3945.16
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

Objects with their vis_flags set to values such as "VIS_INHERIT_DIR" or "VIS_INHERIT_ICON_STATE" won't fallback to their icon_state when no matching dir/state is in the parent icon, it'll simply be blank.

Numbered Steps to Reproduce Problem:

1) Set vis_flags on an object to "VIS_INHERIT_DIR|VIS_INHERIT_ICON_STATE" (what I tried)
2) Add said object to a mob's vis_contents.
3) If the object matches the state/dir visually, it works.
4) If not, it's not visible.

Code Snippet (if applicable) to Reproduce Problem:
var/obj/visual = new()
src.vis_contents += visual

Expected Results:

The same behavior as an overlay where it'll fallback to its default state or current icon_state when it can't match with the parent icon.

Actual Results:

No visual at all.

Does the problem occur:
Every time? Or how often? Every time.
In other games? ?
In other user accounts? Yep
On other computers? Yep

When does the problem NOT occur?

New stuff, new bugs.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)


You could make your icon 100% match, but that gets ugly.
It seems some of the logic for this is embedded in a deeper routine than I'd like it to be, and I'm going to have to take some time to study out a better solution. But I'll figure it out. Likely this is going to work out to be similar to the movement flag fix.
Can you build me a test project for this? I need something to compare behavior and having a project ready to go would help a lot.
Lummox JR resolved issue (Not a bug)
Note for future reference: From the test case we determined there isn't a bug here. The object was acting as intended.

The reason the object wasn't falling back on an another icon state was that there was no default state in the icon to fall back on. This was the result of some confusion arising from a case in the larger game's code where an icon had two conflicting default states.