The func_door_secret is limited in that it only goes in two directions when opening. One could use the func_train to make an elaborate secret door, but it can only open once when you set the last path corner wait to -1. 

Could you use the angles key to allow for more directions? I seem to recall a Preach blog:

https://tomeofpreach.wordpress.com/2014/06/26/unusual-func_door_secret-angles/ 

Hi again,

Is there a link to acquire the most recent Quoth2.fgd file? The option I used was from Preach's Blog and while that is up to date, I don't see any mdl paths defined which causes just bounding boxes to display in the editor.

If I am expected to add the mdl paths myself I can do that but was just wondering if someone just had a quick link to the file.

Sorry if I am missing something! 

Which editor? 

TrenchBroom includes a Quoth2 FGD that displays models in the editor 

You have to make sure you point to the mod folder in preferences 

Sorry should have stated more details.

Using latest release of Trenchbroom. It comes with a slightly outdated Quoth2 fgd file than the one hosted on Preach's blog.

The problem I found is that the Preach Quoth2 fgd seens to not have mdl paths defined as they are in the Trenchbroom one. Hopefully that makes more sense.

Everything works...I just can't see the models within the editor. This is only a problem if I opt to use the newest Quoth2 fgd and not the one that is packaged with Trenchbroom.

Thanks for the replies! 

Okay, so I believe I have everything sorted. I just opened the trenchbroom Quoth2 file and the Quoth2.2 file and manually copied the missing entries across. Everything seems to be working with models showing.

For reference here was the problem I was seeing:

Ex: Envirosuit--

TB file =

@PointClass base(Item, Appearflags) model(":progs/suit.mdl") =
item_artifact_envirosuit : "Environmental protection suit" []

2.2 Quoth file =

@PointClass base(Item, Appearflags) =
item_artifact_envirosuit : "Envirosuit" []

The "updated" file is missing the model path and this is the case for all entity models in the editor.

That was my initial issue but there were only a handful of missing definitions so I just inserted them into the file with models already defined!

Cheers everyone, until next time! >;) 

it would be great if you could create an issue report on github and attach your file so that I can include it in future releases. 

I really have been meaning to get around to that too! So if you've done it already, with your permission I'd love to grab a copy and post an updated version on the official site.

Do the model paths cause issues in other editors? Or are they safely ignored? I don't know if I need to keep a 2nd copy online for users of other editors... 

It is great to hear I wasn't just missing something obvious!

I will be happy to assist with the updated file.

Here is the updated Quoth2 fgd:

https://copy.com/Q2AbvQX9DjQugqCj

There were only a few things missing (waterfall, effect pulse, etc). And this retains all of the model paths.

I do not know about other editors but I imagine if the path to the mdl files are completely absent from the definition file that it would have the same issue.

SleepWalkR, I will report the issue! 

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. 

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. 

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 

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? 

czg's rotation tutorial:
https://tomeofpreach.wordpress.com/quoth/tutorial/rotation-overview/ 

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.. 

 

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. 

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? 

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.