You might want to look at using the func_rotate_train class as a controller, instead of the func_rotate_door. It's more complex but has the flexibility to do what you want. I'll see if I can put together an example map. 

@spy- thanks for the link, I'm registerd at quake.one but this has slipped off my attention.

@Qmaster- It was just my curiosity while playing Qtest1. I wondered why there were these monsters while they were not used. As I made a remake for the serpent, and a shield Ogre from the prequel screens, I thought it would be nice to make some Sp maps for it with the original monsters.

For what I seen in the q1test of Mega lol, he added the original quake monstes into the dm maps. My concern was to keep the authenticity of the original qtest, eventually added with a shield ogre. 

http://www.quaketastic.com/files/single_player/maps/pendulum.zip

Start by running pendtest.bsp in Quoth, observe the pendulum slicing. Notice how you can collide with the flat of the blade without taking damage, but it slices into you when you stand in the path of the rotation.

There's a lot going on to make this one object work, so follow this guide while looking through the map files in an editor to get an idea of how it works.

   External Models
The new idea (and the one that requires Quoth rather than plan Hipnotic) is to create the rotating entity as an external model, and then reference that model from the main map. This avoids the need to use an info_rotate entity (which historically made the rotating entity hard to texture and light correctly).

Take a look at the pendulum.map file first. You can see this just contains the brushes to make the physical, visible pendulum. Two things are important to note here
1) The brushes in this map are assigned to worldspawn, not part of an entity
2) The metal pivot at the top of the pendulum has been aligned exactly with the point '0 0 0' in the map. This point will be the centre of rotation for the object

Although I've been lazy in this test map and skipped lighting, another benefit of this file is that you can add lights to it. This lets you create lighting that looks reasonable at every angle the pendulum swings to.

The last thing to find out is how the external model is included after it's compiled. Open up pendtest.map in the editor. Normally, the brushes for a rotating object would be made into a "rotate_object" entity. In the case of an external model, we add a point entity to the main map with classname "rotate_object_point"; if you look at the example in pendtest, the key "model" "maps/pendulum.bsp" shows the format to specify the external model.

The Controller
Each rotating object in hipnotic requires a collaboration between a visible "rotate_object" entity, and a second entity which controls that visible entity. In this case, we are using a using a "func_rotate_train" to control. The targetname field on the visible entity links to the target field on the controller. The other keys we set on the controler are the noise it makes, the obituary text, and the damage it inflicts - 10hp is probably a bit low for such a huge chopper, but it is a test map.

The Paths
A rotating train needs a series of path entities which describe the sequence of rotations. For the back and forth rotation we want, only two "path_rotate" entities are needed. It's important to note that lots of different behaviours are possible at each step on the path, depending on the spawnflags used. In the example map the following are set: Angles & Stop rotate & Speed sets movetime

The first flag is the key to how our rotation works - we are stating that the waypoint specifies an angle for the object to face at the end of the movement (as opposed to setting a rate of rotation). "Speed sets movetime" is a bit of a convenience, it lets us say that the rotation must take 1 second directly, rather than having to calculate a speed of travel that makes the rotation look sensible. Stop rotate is cosmetic, it just adds a very short pause between each swing.

There's some subtlty to the angles chosen here: '410 0 0' and '-50 0 0'. The important thing to know is that after each step of the path completes, the angles of the object get normalised to the range 0-360. For example: after travelling to '-50 0 0', the angle is transformed to into '310 0 0', meaning that the object rotates forward to get to '410 0 0'. If we specified '50 0 0' instead of '410 0 0' the object would rotate the long way round, which is NOT what we want.

Finally, note that the path_rotate entities target each other to form a loop, while the "path" key of the func_rotate_train links it to the start of the path.

The Movewalls
The movewalls are needed to give the blade collision. All of them are given the same targetname as the original rotate_object, so they are moved by the controller in the same way. For demonstration purposes I've applied the "visible" spawnflag and an alpha value of 0.5 so that you can see what they're doing in the demonstration map. This spawnflag is very helpful for debugging, but in a final release can be turned off again.

There's also an argument to be had over the "damage on touch" spawnflag. On the one hand, I like the fact that you can touch the flat of the pendulum without taking damage, but on the other hand, you only get pushed if you get hit by the edge of the blade but aren't trapped by the walls on the other side. Perhaps just setting this flag on the end movewalls would be a good compromise. 

thank you very much for such a detailed answer. I am a little depressed that I will have to use an external bsp for my pendulum. I wanted to use only one file. I tried to replace the rotate_object_point with the rotate_object. But when I move the pendulum to a point other than zero, my pendulum starts to shake. But for rotate_object_point all works well. Probably have to use this method.

Thanks again 

The method doesn't RELY on the external model, it's just the simpler way of doing it. If you're set on having one file, you can refer back to the CZG tutorial, in particular the first paragraph. You need to make sure that you've included an info_rotate to mark the centre of rotation (instead of positioning it at '0 0 0'), and ensure that you've set the targets/targetnames up as CZG writes.

I have often though it would be useful if there was a way to take an external BSP model, and embed it into a BSP map, as if it had been a brush entity. Either compiler support for merging BSP models in when compiling the main map, or some kind of extra tool to run afterwards. If there was a BSP library for Python I'd have a go... 

I added info_rotate to the object and now it works well with rotate_object. Thank you! 

I need help, I'm very new to mapping and was wondering, how to add sounds to my sky. You know that familiar sound of quake's sky. I use trenchbroom and tried to search on the internet, but couldn't find any info or tutorial on how to do it. Thank you guys in advance. 

I think you just need to run vis to get that? (make sure the map is sealed too) 

yeah run vis to get the automatic ambients for sky,water,slime,lava 

also more info on texture names & sounds here: http://www.celephais.net/stuff/texturefaq.htm 

stuff comes up when i am working on the exact tutorial that covers this info! 

Yeah I asked this on your latest video @dumptruck_ds, it's because of your videos I came to this site to begin with. Looking forward to more of your tutorials. And to everybody else, thanks for the info. 

Great news. Well this is the place to come for any Quake questions. I guess I need to do a more in-depth compiling tutorial soon. That would have helped. Welcome! 

hello everyone

In terms of performance, is it better to have several sky brushes or a single big bush? Let's say I have a wall with 3 windows; should I make three individual brushes with the sky texture or a single big brush with the sky texture behind the wall?

Thanks 

It makes absolutely no difference, type r_showtris 2 in the console in game to see how your brushes are turned into triangles. 

Alright, that's good to know. Thanks! 

Just started mapping for Quake 2 and I wanted to know if you guys recommend any command line tools for:

1) bsp, vis, rad. Right now I'm using qbism/q2tools-220
2) creating wad's from PCX?
3) creating font textures?
4) creating skies?

Also, is there any documentation for special Q2 textures like there is for Q1?

https://quakewiki.org/wiki/Textures 

Welcome. There aren't as many q2 mappers around these parts. A few. But don't take the silence personally.

Have you visited tastyspleen? http://forum.tastyspleen.net/quake/index.php?board=40.0 

http://quake.wikia.com/wiki/Cut_content_(Q1)

Those images that look like they are from Deluxe Paint, the ones with the grid, where are they from?

I tried google image search and did not find anything. I reckon at some point Romero released some stuff like this, similar how he did with Doom.

Does anyone have a link to this?

Would be much appreciated. :) 

Here's a conundrum for anyone familiar with ericw's tools' extra options:

_mirrorinside (part of the extra options added by qbsp) causes any default brush entity to act as a sort of clip brush, which allows players and enemies to both see and shoot each other through it regardless of what faces are visible or textured with what, but can't be walked through. This applies to both stationary func_walls as well as func_doors (and I assume any other brush entity that acts similarly) and obviously illusionaries as well, which act normally (can be passed through). Any entity that requires being shot (i.e. buttons with health set) become inoperable due to all gunfire passing right through.

It's not listed in the readme anywhere that _mirrorinside should only be used on illusionaries and similar entities, and it does properly mirror the exterior to the interior of any brush entity, so I assumed all was good, but now I realize something's kind of fucky. Interestingly func_details are not affected by this- i.e. a func_detail_wall remains a solid wall that can be neither shot through nor walked through- which makes sense as so far as I can tell one of the main purposes of _mirrorinside is making truly flat fences and similar using a detail brush and making every side but the one you want skip, thus mirroring the one that's left. Just not sure if this is a bug or undocumented behavior, given _mirrorinside seems pretty experimental to begin with- can provide an example .bsp and .map if needed. 

Hi everyone, I'm trying my hand at Quake 2 modding and I was hoping someone here could help me out.

So far I'm trying to use Blender, I installed scripts for importing .md2 files but I'm struggling because the .pcx skins aren't supported by Blender... I converted them to .tga but I can't change the .md2 file's header to use the converted skin instead... :\

Any recommendations would be welcome. 

if you can't rename the pcx, rename the tga instead and hope the reader goes by contents instead of some random part of the filename. 

It didn't work, but meanwhile I did a lot more tests and I think I understand what's going on a bit better.

I still can't get the skins to show up in Blender, but I guess that's just because they have poor support for old model formats. I could get it to work in Misfit Model 3D, but I'd still like to have a way to explicitly edit the md2's headers, which I couldn't do with anything so far.

BTW I love your work! You did a great job with FTE, it's already my favourite port for Quake 2. The only reason I don't use it more is because it's still a bit unstable on my system. 

Should I run VIS each time I compile? I noticed that it still looks "vised" without running it and even new geometry doesn't stick.

P.S. there was a place on a map, that got a hole after VIS. But after I compiled it without VIS the hole was gone.