Err
#15249 posted by DaZ on 2015/08/20 02:27:57
What entity makes the "large Switch" sound then? Like the sound in e1m1 as the lights turn on as you go down the slime room with the 3 buttons.
Daz
#15250 posted by ericw on 2015/08/20 02:30:38
Quark tells me "sounds" "3" on a trigger_once/multiple makes the "large switch" sound :)
There's also 2="beep beep" 1="secret" 0=none
#15251 posted by - on 2015/08/20 02:33:13
the trigger volumes do.
WHAT ERICW SAID
#15252 posted by - on 2015/08/20 02:33:42
Poor Daz
#15253 posted by necros on 2015/08/20 02:34:25
the jam has really taken a toll on him. :P
#15254 posted by Spirit on 2015/08/20 15:37:26
What's going on with the multiple maps in jam6 trying to load CD track 1? It does not exist, first track is 2. Some editor definition file using 1 as default? Noticed it with ericw/tronyn's and warren's.
#15255 posted by ptoing on 2015/08/20 16:04:34
Maybe they are hankering for some good old bit screeching.
#15256 posted by JneeraZ on 2015/08/20 16:08:56
Must be a default, I never set it.
Z-fighting
What causes z-fighting and how does one avoid it in creating a map?
#15258 posted by ptoing on 2015/08/20 17:12:23
Z-fighting is cause when faces of brushes overlap. In general this will only happen with things like func_door, func_plat etc.
So if you make a door or a platform make sure that none of the visible faces are level with other visible faces. This means that you should model in recesses for your platforms and doors to go into in most cases.
Thanks For The Fast Response, Ptoing
So what about having two world brushes with overlapping faces that the player can see? Will this ever result in z-fighting? And if not, is there any rule to which of the two faces (i.e. which texture) is seen in-game?
#15260 posted by ptoing on 2015/08/20 17:28:20
with world brushes you should not have them overlapping in such a way that parts of faces which will be seen are flush. You don't know and then engine does not know, hence the z-fighting. I think the gl_zfix thing only sets worldspawn to a higher prio than entities.
Ok, thanks for clarifying. I'm working on structure where it's kind of tricky not to have any visible surfaces overlap, especially without splitting the brushes into tiny components -- but I guess I'll have to figure it out somehow, then.
Thanks again!
#15262 posted by ptoing on 2015/08/20 18:14:44
Feel free to upload a work in progress of your .map and I can have a look at it and let you know what might be problematic.
Thank You!
That's very kind of you, but at the moment I'm still too embarrassed to show anything I've made.
I might take you up on the offer when things look less messy ... but that's going to take a while at my pace.
World Brushes Z-figiting
#15264 posted by ericw on 2015/08/20 19:10:22
shouldn't happen. Here's a test:
http://imgur.com/a/McOtQ#Ce5LmYE
qbsp has a step where it CSG-subtracts each brush against each other brush. I think they're done in map file order, so the first brush I added there clips away the corner of the second brush.
The gl_zfix cvar in quakespasm was pushing each face of bmodels (so func_wall/func_door, etc.) out by a small amount, but it's disabled now becuase it caused arifacts making some secrets visible, and caused mappers to put z-fighting in their maps inadvertently.
#15265 posted by ptoing on 2015/08/20 19:14:46
No problem :)
Eric
#15266 posted by ptoing on 2015/08/20 19:17:10
That is still kinda bad practise though, right? Plopping worldspawn brushes together like that. Esp. since you do not want to keep track of which brushes were placed earlier.
So in most cases like that you should still cut one of the brushes up into smaller parts, right?
#15267 posted by ericw on 2015/08/20 19:36:56
yeah, it's best to avoid - messy map file. But if it's hard to avoid overlapping world brushes, the compiler will deal with it.
Thanks for the extensive responses, ericw and ptoing.
#15269 posted by ptoing on 2015/08/20 20:22:48
That's what this place is here for :D
Warped Textures On Irregular Faces
I've noticed that on some angled brush-faces, the brick texture I'm using is warped -- as in, the vertical lines on the texture (the short part of the bricks) are diagonal instead of vertical. No amount of changing the texture angle/size/X/Y-offset seems to help...
Is there any way of fixing/avoiding this? I'm using TrenchBroom 2 on Linux.
#15271 posted by ptoing on 2015/08/21 02:46:03
I dunno about TB2, but Jackhammer has very good texture alignment tools and there is a Linux build, so maybe worth looking into that.
#15272 posted by Rick on 2015/08/21 02:54:30
I *think* that's something the "Valve 220" texture alignment fixes. And I *think* TrenchBroom supports it.
At the moment I use Netradiant, but I seem to remember somebody here sending me a map a year or so ago when I was trying TB1 that showed how it looked, and I remember being surprised how much better it was at aligning textures on angled and rotated surfaces.
Make a backup copy of your map if you try something like that, it may not be reversible.
Viewpos
#15273 posted by Rick on 2015/08/21 09:30:14
I can't believe I've been mapping all this time and just discovered this. Makes positioning info_intermission easy.
Turn on noclip and find a good view. Open the console and enter the "viewpos" command (no quotes). Write down the numbers:
(origin) mangle
Enter these in your map for an info_intermission - Done.
|