A linedef flag that prevents every line behind it to be mapped on the Automap.
Reasoning is simple: If you have a double-sided line that the player cannot visually see through, everything behind it will still be mapped into the Automap, making it easier to find a secret behind such walls. This flag could "hide" that from the Automap, making it harder to find.
I tried "Shown as 1-sided on Automap" just doesn't help there, even though it could be used in conjunction with that.
If this can be added at all and only for UDMF, it's fine with me.
Unless there is already a way to achieve this?
New Line Flag: Block Automapping
Moderator: GZDoom Developers
-
- Posts: 219
- Joined: Wed Jan 08, 2014 8:40 am
- Graphics Processor: nVidia with Vulkan support
- Location: Germany
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: New Line Flag: Block Automapping
Technically not possible. In order to achieve this some very, very costly checks would have to be added to the core render loop and that's out of the question.
Re: New Line Flag: Block Automapping
Would sector be enough? Because at least you can hide sectors from map in vanilla, I'm not sure if sector or sidedefflag, but one of the both it must be then xD
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: New Line Flag: Block Automapping
No. As I said, it doesn't work that way. The code that processes the level has no concept of 'behind', aside from the needed visibility clipping to skip parts of the map that are blocked from view.
This code just sets a flag once it encounters a line or subsector, it doesn't do any checks whatsoever on them, so it is fast. Once you have to do a second visibility pass on far more arbitrary data you'll inevitably end up with something that's less than half as fast than what's there.
This code just sets a flag once it encounters a line or subsector, it doesn't do any checks whatsoever on them, so it is fast. Once you have to do a second visibility pass on far more arbitrary data you'll inevitably end up with something that's less than half as fast than what's there.