I have a question about water.
How does ns handle a brush textured as water? I know can swim in it without turning the brush to func_water, but is it an entity server side?
I have some water which is larger than 320 in 2 dimensions but is not an entity. Will it be rendered all over? Or just normally as it is not tied to an entity?
I don’t know!! Currently I’m assuming that it won’t be as I didn’t make it into an entity and thus it shouldn’t be one. But, weirder things have happened.
whee..
Full Version: Brushes Textured As Water Vs Func_water
its because when you make a wad file, you have to add variables to it.
{ Transparent
! water
+ animated
+A toggle animate
- Random tiling
Sky sky
you can do this with wally. just rename your texture and apply the setting in the beginning
e.g. water_blue renamed to !water_blue to make it a water texture.
{ Transparent
! water
+ animated
+A toggle animate
- Random tiling
Sky sky
you can do this with wally. just rename your texture and apply the setting in the beginning
e.g. water_blue renamed to !water_blue to make it a water texture.
Uhm BlackPlague I don't think confused! was asking how to change the texture variables to changes its behavior 
He wants to know if a brush textured in !anywatertexture but not tied to an entity would be serverside. (don't know the answer to this one confused! sorry, Cagey would probably know it)
But about the size and if it's rendered troughout the entire level when larger then 320 units... I'm not sure, since it's not an entity I think it would not do that. You can always try gl_wireframe
He wants to know if a brush textured in !anywatertexture but not tied to an entity would be serverside. (don't know the answer to this one confused! sorry, Cagey would probably know it
)But about the size and if it's rendered troughout the entire level when larger then 320 units... I'm not sure, since it's not an entity I think it would not do that. You can always try gl_wireframe
Confused! : I don't think water is a server side entity to begin with...I could be wrong..regardless that's a huge bit of water anyways.. I'd be thinking along the lines of "If people have to be able to swim in it?" - if the answer is yes then make it an entity (and figure out a way to make it smaller cause 320 is huge -unless you mean 32x10 or something). If people don't have to swim in it and you can handle it having 100% opacity, then leave it be - but I'm not sure whether it will still animate the same way - I believe it does...hrmmm... what an interesting thing to look into..
liquid brushes should automatically create visblocking water, which is all fine and dandy and useful, but unfortunately I think the compile tools now have a feature to automatically make any liquid brush a func_water entity. I could be wrong, but I recall this being in a changelog somewhere. Oops.
| QUOTE (KungFuSquirrel @ Mar 23 2004, 07:42 PM) |
| liquid brushes should automatically create visblocking water, which is all fine and dandy and useful, but unfortunately I think the compile tools now have a feature to automatically make any liquid brush a func_water entity. I could be wrong, but I recall this being in a changelog somewhere. Oops. |
That may have been a feature at one point, but it's not in the current development branch -- I double checked with a search for the string 'func_'; there were 0 hits in the source for func_water, so there isn't anything creating func_water entities (although I stumbled onto somebody's apparently undocumented and half-finished project using 'func_vis' entities in HLVIS, something I'll need to look into).
If you make a water brush and don't turn it into an entity, it remains part of the worldspawn and doesn't require any network communication. It also will be obscured by VIS like other sections of the worldspawn instead of being drawn everywhere (and block VIS from one side to the other). Unfortunately, it also blocks all light at the moment, which means that models standing in shallow brush-based water may appear black since the floor under them isn't being lit.
Underwater lights can fix the problem, and I'm considering a long term (read: don't wait for it) modification to HLRAD to allow light to pass though water using the new translucency code that Hullu has written. Doing that would mean writing an exception to current HLRAD vis checking code handling since brush-based water blocks vis (like KFS mentioned).
EDIT: shuffled sentences for clarity.
excellent... * chuckles evilly *
the only problem being, of course, that it is lit full bright, but hey i can't ask for everything:)
the only problem being, of course, that it is lit full bright, but hey i can't ask for everything:)
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.