Calling an artillery through glass
The current behaviour is like that even you see through the glass, you can’t call an artillery because it is like you would calling inside because the glass is like an obstacle.
See the attached demo to see the current behaviour.
#2 Updated by Aranud over 2 years ago
This seem to be difficult to implement and I try to resume what were told on Gitter.
First, regular shader (i.e windows) doesn’t use the surfaceparm glass. Currently the surface of a glass (i.e fueldump) is detected as nodraw and nomarks and many invisible entity ( i.e construction set, clip ...), use theses surface. (like thunder mentionned)
Second and copy/past litteraly from kemon said :
surfaceparm glass is the only thing related to glass and it gives the glass sound when being shot at. Usually mappers made their glass destructible though, so it’s a func_explosive that will break when being shot at without glass sound
Transparency with shaders is a complete mess.
For now, we have nothing to properly determine if a surface is really a glass.
Otherwise, to fix it, every surface setted as nodraw and nomarks surface should not be detected as an obstacle ... not the best solution but work.
#4 Updated by keMoN over 2 years ago
- File transparency_test.pk3 added
[quote]Otherwise, to fix it, every surface setted as nodraw and nomarks surface should not be detected as an obstacle ... not the best solution but work.[/quote]
To my knowledge this is the current behaviour. However, "surface" is the incorrect term. Better use "brush" here. (One brush has 6 surfaces/sides).
I made a test map for you and attached it, so please let me go ahead and screw up your day
I have been working with maps in ET literally for years now and to this day I could not write a shader from scratch if my life depended on it. There is no such thing as a standard "alpha" shader and I absolutely can not explain what exactly makes the game consider something as "transparent", but let me try and lay out my experience for you. Also keep in mind that "transparent" is again a rather incorrect term.
In the test map there are two brushes with battery’s bunker texture so you absolutely know that thing is solid as it gets. The yellow one has that texture on all surfaces/sides, while the black one only has the bunker texture assigned to the front. The other sides are common/nodraw. Now all of a sudden the game considers this brush as non existent for entities. While you can not see through, you can walk, shoot, throw nades and for this thread most importantly call artillery through it!
The second set of brushes in the test map is with miltary_wall/window_m03. Again the yellow is solid, however this time with common/clipweap on all sides/surfaces except the front. The black one replaces common/clipweap again with common/nodraw.
//Fun-Fact: The secret room in "Streets of Italy" uses that system. It has a seemingly solid concrete texture on the outside and on all other sides it has common/nodraw. The fact that you also see a seemingly solid texture from the inside is because that is another brush with common/nodraw everywhere except the wallpaper on the front.
Theoratically, you can already call artillery through glass, however the brush has to use the window texture on the front and common/nodraw on the other surfaces. Mappers don’t usually do this, because that means that you could also move, shoot, throw nades through. Also when you can shoot through it you can’t actually shoot it, or in other words break it. So what mappers do is, they use common/clipweap instead of common/nodraw. That way the entire brush is clipped for weapons, meaning it acts as an obstacle. Now you can shoot the brush, but you also can’t call artillery through it, since it is considered solid by the game. To make the brush destructible, you transform it into a func_explosive. Now it is solid, but breakable.
So, I guess what I’m saying is is that this isn’t related to a surface, but to the whole brush. I’d love to see this feature implemented, but I think it would need substantial rework of the shader madness.
#5 Updated by thunder over 2 years ago
Agree with you @ keMoN,
But a solution would be if we added a keyword in shader as EX: surface seethrough that would only fix this one, but yes it would mean a lot of code work. We would need to implement this not only in ordinary code but also in shader parser