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
Trying To Make A Button Opening Two Rotating Doors 
It's guessing work when it comes to Scourge's rotating doors, but I think there needs to be a func_rotating_doors as the center of rotation for a given brush, and then have a rotate_object brush being targeted by said func_rotating_doors, but I digress.

I want a button to open two doors (which is actually one, just like in Scourge's E2M1) but since we can only target one thing I'm completely lost on making it work. I tried a trigger_relay but no, I really need a way for a single func to target two things at once. How can I do it? 
 
The func_button targets one door and a trigger_relay, which targets the other door.

The way func_rotate_doors are set up prevents them having the same targetname i guess.

Check the ad_test3.map for details. 
Checking Ad_test3 
And I found that big circular door in 2 parts. One part is a func_door while the other in a rotate_object.

What's the difference between the twos if they're both assigned to a rotating entity? And what's the difference between info_rotate and func_rotate_door? Do their placement matters, as in the targeted brush's center of rotation, or no? And I'm getting a bit confused with the button targetting and all, can't we target more than two entities at once if they have the same target name? 
 
This sounds odd. Why shouldn't multiple rotating doors be able to have the same targetname...

Apart from that, one door can target the other, so there's no need for a trigger_relay. 
Another Thing Regarding Clip Brushes 
I wanted to create fences like in Doom, where no one can pass through but only attacks. My method would be to have a func_illusionary brush with a clip brush on it, but when testing the clip brush isn't there, I'm passing through the fence. Is there a workaround? 
 
the clip brush should be part of the world, not the illusionary.
if the clip brushes are part of the illusionary then it'll be non-solid, just like the rest of the func_illusionary geometry.
(they could also be part of a separate func_wall if you want to killtarget it to make it passable later, but you will may need to fiddle about with it in order to get the qbsp to accept it, depending on the qbsp) 
 
Clip textures on func_illusionary tends to crash my compilers 
Fixed It 
It was simple actually, have the func_illusionary brush be surrounded from both sides by 1 unit-thick clip brushes.

For that whole rotating brushes thing, can I get to know more about it? 
Daya 
Ok 
ad_test3s first rotating door (the "vault" door) is a bit trickier to explain, it is actually a func_rotate_train.

But first the normal door we all see everyday, with a vertical and fixed hinge. Build one of those out of as many brushes you want, these all go into an entity called "rotate_object".

Note there is no func_ prefix on this entity, idk who was so crazy to name it w/o this.. :) But the quoth fgd/def has it.

Give it a targetname, lets say rotate_door1 , and a target, lets say rotate_hinge1.

"targetname" "rotate_door1"
"target" "rotate_hinge1"

You must also set the light parameters like "_dirt" and "_minlight" on this one (if you want to).

Now create a "info_rotate", this is a point entity, important is you place it right on the vertical axis i.e when viewed from above or below in the middle of the hingebrush for best looking results.
This one is targeted by the rotate_object.

"targetname" "rotate_hinge1"

Now create a "func_rotate_door", again a point entity placed on the axis.
This one targets the rotate_object

"target" "rotate_door1"

This entity has all the keys for controlling the rotation of your door.

"speed" - the amount of time to open/close the door

"angles x y z" - the total angle the door rotates i.e.0 360 0 is one full turn vertical.

sounds/noise keys depending on the used progs.

"targetname" - last but not least this one must be targeted itself by a button/event of your choice.

Important note, these "doors" have no collision. You'd have to fake this with skip-textured func_doors/func_movewalls.

Try this guide first, vault-doors later (those are easier to fake collision for :))
Hey.. 
ERIC 
 
What's In A Name 
Build one of those out of as many brushes you want, these all go into an entity called "rotate_object".

Note there is no func_ prefix on this entity, idk who was so crazy to name it w/o this.. :) But the quoth fgd/def has it.


Blame hipnotic! In Quoth we tried to name things with consistency in terms of func_ being solid brush entities, trigger_ being invisible brush entities, info_ being invisible point entities, etc. Most of the exceptions to the rule are things that would be too confusing to rename now, like trigger_counter. Unfortunately rotate_object is a name hard-coded into the compile process and there's no way to change it. 
Looking At Preach's Tutorial 
I don't get the part with the func_move_walls. I know they're part on making a collision mask, but for two side-to-side rotating doors how does it work?
Do I just make tiny cube brushes that form a quarter-circle from the closed position of the door to the theorized opened one? Or do I just make a single brush that I cut in an arc that's suposed to draw out the shape of the movement? 
Movewalls 
Correction: CZG's tutorial

The movewalls should be shaped to approximate the size and shape of the visible entity while stationary. The ideas is that because you can't actually rotate solids in Quake, you have these small chunks which slide along a circular path.

It might be better to describe a couple of basic things you might create, and how to movewall them.


A door: cuboids which stretch from the top to the bottom of the door, are square on top, and exactly match the width of the door. In ascii, from above

========= (door)

[ ][ ][ ][ ][ ] (movewalls)


A propeller: cubes along the length of each blade, flattened to the thickness of each propeller. 
Awww Yeaaah 
After some bits of trial and error regarding rotation angles I came through
http://image.noelshack.com/fichiers/2016/06/1454888677-schlossherr20160208004219-00.jpg

(And here you can see fullbright pixels will be a huge problem) 
 
TexMex can remove fullbrights. 
 
Load the wad into TexMex. Double-click a texture. It will open in a "Detailed View" window. Right click on the texture and select "Adjust Brightness", then click "Remove Brites" in the "Brightness Adjust" window. 
Thanks! 
 
 
I hope it works. I'm not sure I ever actually tried it.

I edit textures in an old version of PSP and have a custom quake.pal file where all the fullbrights are replaced with black. I just apply that (using match nearest color) to any texture where I want to get rid of stray fullbrights. 
It Worked Half The Time 
Some of the reworked pixels where fullbrights, so I had to edit them with Photoshop.
Nevertheless, they're gone now. 
 
Is there a hack to make explosions made of info_notnull deal zero damage? I need just a visual effect of explosion. 
PuLSaR 
Oh Yes 
Ogre grenade suits perfectly for this, thanks 
 
Is it possible to place an animated texture without animation frames playing (last frame I need) without making it a separate non-animated texture in wad? Like the button that have already been pressed? 
Figured That Out 
ignore the previous post 
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.