News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
No Detail Brushes In Q1... 
Change brush groups into func_walls or func_illusionaries to avoid breaking up surfaces, or float them 1 pixel off the floor/wall. 
And... 
Overlapping brushes are ok, especially for weird off-angle arches and such. 
Natural Looking Terrain 
Anyone got any tips/tutorials/techniques for creating the best rocky/uneven terrain in Quake 1 bsp? :E 
Multiple Buttons To Trigger A Door 
Can anyone tell me what kind of triggers connections i have to do in order to make 4 buttons to trigger a door ? like if all are ON then the door should open .. if 1 is OFF the door shouldnt open (logical "AND" condition) i use the Quake 3 engine (GTK Radiant). Thanks in advance :) 
 
Create a Trigger_Counter (with a name of course :) )that activates at 4, and make it's target the door. Make each button target the counter, and make each button's reset time -1 so a single button can only be used once. 
@ Generic 
OK thanks that explains why setting detail doesn't work in BSP or Radiant. I guess the option is in the editors for Quake2 and higher.

So when I got a cemetery full of fancy gravestones, I make the gravestones funk_walls or func_illusionaries. The downside of this seems that the func_walls/illusionaries don't cast shadows... I've read you can built a simple solid brush in them to cast shadows.. but I wonder if I can just copy the complex/detailed architecture, duplicate it and turn it into invisible brushes that will speed things up and DO cast shadows... For instance, here's a tutorial once from a guy who used a sky brush to cast a Quake logo shadow on the ground...but I can't duplicate it:
http://bspquakeeditor.com/q1tutor/q_lights.html 
ZealousQuakeFan 
IMO the best way to do terrain in Quake1 bsp is to use triangular prisms. I use ones with a depth of 64 units. You just lay the triangles out as a mesh, then move the corners up or down to make a nice uneven surface.

Also - ALWAYS overlap brushes in Quake1 maps. I used to think it was bad, but it turns out that its actually one way of making sure an area is sealed, for starters.

And you dont get in-game z-fighting. But if you get z-fighting in your editor, the newest brush will win. After you have compiled the map, any parts of a newer brush which were visible in your editor will be visible in the bsp. But they wont flicker. 
Zfighting 
Does z-fighting actually happen (in advanced engines) into brushes that intersect each-other, without any coplanar face? Such as overlapping perpendicular walls as generated by some hollowing commands in some editors... 
"Multiple Buttons To Trigger A Door" 
Man I shouldn't post at 3 in the morning, didn't see you were referring to quake 3, so ignore me :E 
 
hmm, okay. Off to give it a go :)

As I understand it then the main limitation with quake 1 BSP is that if a square face is twisted across where the polygon seam would be it just breaks? Like 3D modelling if you couldn't flip edges...? 
Door Opened By Multi Buttons 
I quote a recent post :

Can anyone tell me what kind of triggers connections i have to do in order to make 4 buttons to trigger a door ? like if all are ON then the door should open .. if 1 is OFF the door shouldnt open (logical "AND" condition) i use the Quake 3 engine (GTK Radiant). Thanks in advance :)

I want to do the same thing in Quake 1, but a little different. The door should open at a combination of opened and closed buttons - some sort of cippher :)

Can that be done ?

Let's say you have 4 buttons - all closed. You push one - it remains open until you push it again - same for all. The door should open only if button 1 is opened, button 2 is closed, 3 closed, 4 opened (an example). 
It Can 
But without new code it's a bit fiddly to set up.

Basically, you have a hidden tunnel somewhere outside the map which has four doors in it, a shootable button and a nail shooter.

The player never goes into the tunnel - you're just using it to set up a logic gate.

The four doors are controlled by your four buttons, and they're all 'toggle' so that the buttons can turn them to on or off states.

The button inside the tunnel is shootable (health 1) and is behind all the doors.

The spike shooter is at the opposite end, and just shoots forever.

The idea is that if the doors are in the right places then they'll allow a nail to go from the spike shooter into the shootable button, which triggers your event.

Problem is, there's no real way to show when a button is on/off - which is a must for the game play not to be confusing and frustrating. 
Err 
Also - ALWAYS overlap brushes in Quake1 maps.

ignore this 
 
Problem is, there's no real way to show when a button is on/off - which is a must for the game play not to be confusing and frustrating.

How about creating a little "indicator light" above the button; a func_door with a fullbright texture, that appears/disappears from inside another brush to indicate state. You can build a nice frame/socket around it so it looks like some kind of light fixture or computer terminal. 
Re: Multiple Buttons To Trigger A Door 
Ok seems silly but i just found the solution for my problem :D seems silly but it works :

for only 2 buttons to trigger the Door i did this:
2 func_button each of them triggers a shooter_plasma which shots to a door(1). that door(1) opens and behind it there is another door(2) that opens my Door(3) .. that way i can have my Door(2) opened when both doors (1 AND 2) are opened
(some images for better understanding http://img411.imageshack.us/img411/7038/multipletriggersand1.jpg http://img688.imageshack.us/img688/9168/multipletriggersand2.jpg )
is there an easier way ? 
Hmm 
Could you not just make the buttons only trigger once (wait value of -1 iirc) and a trigger_counter with a count value of 2? 
Func_door Indicactors 
That'll do nicely. 
Re: Hmmm 
in gtk radiant 1.5 for quake 3 engine i tried trigger_counter but it doesn't work aand if i put wait the value -1 it will do exactly what the manaul sais : "wait : number of seconds button stays pressed (default 1, -1 = return immediately)." 
Rotating Entities... 
So I'm dabbling with the dark arts and trying to make some rotating stuff, and I've got a nice door opening and closing but it's insanely jittery, as though the axis of rotation is bouncing up and down... Any idea what I've done wrong? :E 
 
sounds like one of two things:

you did not target an info_rotate with your rotate_object

or

your compiler does not support rotating entities (very unlikely at it would have to be a compiler made before the hipnotic mission pack came out).

so make sure you add in an info_rotate that should be placed somewhere in the center of your rotating brushes.
next, add a 'targetname' to it.
now, for all the rotate_objects applicable, add a 'target' that points to that info_rotate. 
 
hrrmph. At the moment I have a func_rotate_door targeting a rotate_object. The object is rotating around the rotate_door. I can't find an info_rotate in my entities list :/ 
 
Duh, I think I've worked it out. The rotate_object has to target back at the rotate door. Duuuh... 
 
you will need to create an entry for info_rotate if you don't have it.

rotate_objects don't rotate around info_rotates.
info_rotates are used explicitly in the bsp process to define the origin of the rotater, otherwise the rotater's origin is simply '0 0 0'.

try this: make a rotating door right on the '0 0 0' origin of the world and it will work perfectly without an info_rotate.

it has to do with quake's angle accuracy (or lack, thereof). as you know, the farther from the center of a rotation you are, the bigger the gap between one degree to the next.
quake has a pretty low resolution when it comes to angles, so once a bmodel is far away from the origin, rotating it makes it 'snap' to the next angle.
targetting object_rotate to an info_rotate tells qbsp to move the bmodel onto the origin with the info_rotate as the center. 
 
doh, cross-posted.

i guess that can work too. you're just replacing info_rotate with the func_rotate_door. the only hard coded thing in qbsp is object_rotate -> target. i don't think it cares what entity you target. 
 
Well...it seems to work okay anyhow :E

Another question however, train rotates. I've got it set up so an object moves between two points like a normal train, but -1 stops don't seem to work and it never rotates, it just moves. Any ideas...?

If you want an idea for what I'm trying to do, I want to make a draw bridge that drops down in stages (ie has multiple triggers, each one moving it x degrees down), rather than just going from 90 degrees to flat in one motion. ta for help btw this stuff is pretty confusing :p 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.