I was going through the changelog for Construct and noticed 'Is visible' is now false if the object's layer is invisible.
To be honest, this disappointed me, because it's so obviously a bad choice, just like when it was decided that Construct (now classic) should be 1-based.
When I was designing a minimap in MMF2 which turned out to have the same issue, I worked a lot with visibility. Then when the minimap was complete, I added a feature to hide the layer because I didn't want the minimap to be visible all the time. Suddenly, when I display it, everything is messed up. My minimap system didn't work because I couldn't rely on the "is visible" condition. The fix was of course to store the "actual" visibility setting in a value.
According to this flawed logic (the type that makes MMF2 a pain often and makes me want to switch to e.g. Construct), it could as well return Off when the object is outside the window (hey, you can't see it, right?) or when it's simply covered by an other object on top of it.
Thing is, if "is visible" returns False just because the object is in an invisible layer, the whole feature is essentially rendered useless for invisible layers. Things will not work normally when you hide layers and then show them again. Why would you NOT want to have the ability to check an object's own visibility setting unless the layer can be seen? If I'd be interested in knowing if the layer is invisible, I'd check the layer setting itself.
Develop games in your browser. Powerful, performant & highly capable.
Well, it used to work how you wanted, then another user requested that it take in to account the layer visibility and IIRC made a convincing argument. However I agree that this is one of those cases where having it work both ways is useful.
Since you can test if an object's layer is visible with 'Is layer object.LayerName visible', and there's also a separate 'Is on-screen' condition, between these you could make any test you wanted, providing 'is visible' is changed to only test the object's visibility flag again. This sounds like a good idea so I think I'll change it back in the next build.