Yes, that is what those two menu items do.

Save selected saves the selected brushes to a map file and save region saves the current region. 

'region' 

Region selection is in the "View" menu. It's basically a way to hide large chunks of the map at once. You can select only a specific area to be visible while editing, this can de-clutter your view of the map a lot.

I've only used the "set xy" option, so I don't really know how the others work. The "set xy" will hide everything that's not in the current xy 2D view

I've never tried saving a region, can't think of any good reason why I'd want to. I guess it just saves the currently viewable stuff in a new map. 

Thanks for those articles, looking forward to the follow-ups :)

If it turns out that the experimental switches like "-forcegoodtree" are indeed not having yet unknown side-effects, like causing one's offspring to be born with a tail, maybe it could be implemented in other tools as well - the code change needed is very minimal. 

 

.. has also this feature: it is possible to hide some part of the design in the editor (3 options are actually possible: visible, hide, or greyed).
Also, vis-grouping allows to be indeed more flexible. It is possible to build only a selected part of the design to check that it looks correct.
Well, I guess more or less all editors have this kind of features :) 

I've always liked quarks tree view that makes map components look like a file system. 

i still like quarks texture applying. 

I tried messing around to figure out how to do it but can't figure this one out. How do I get brushes to move around like you see in many of the areas in the game? (Quake). I am talking about things like platforms that move back and forth and also things like those those cubes at the end of E1M2 that move around. How do I create those? 

thats a lot of questions..
head over to:

quakewiki.org/wiki/mapping

in entities you'll find what you looking for

googling the unofficial quake specs should be helpful too. 

func_train and Path_corner to be more unprecise 

For platforms that only move in one direction like back and forth, or up and down, you can just use a door. For more complex motion you'll need to use a func_train with multiple path_corner entities. 

Moving platforms are func_train entities. They move along an interlinked set of path_corner entities. The plaform starts at the path_corner it targets (if it has a targetname itself, it will only start moving after being triggered); each path_corner targets the next one, and the last one the first. If the platform is supposed to stop at the last path_corner, set "wait" "-1" there. 

Slow typer... 

OK, my next foray into the realm of messing with BSP compilers, and the first real success (sort of).

http://tomeofpreach.wordpress.com/2013/06/07/random-algorithms-and-bsp/

Now with graphs! Yes graphs! 

Very interesting research into the BSP process, Preach.
It's weird how the results we so different from a box map and a full size one.

Have you tried this test with maybe some small maps like DM maps? 

Afraid I didn't try any map in-between. I'd go and give it a shot now, although I expect that the result would be more like the latter than the former. Unfortunately I can't do that easily right now, because I've been revising the code for a future post, and don't have the original compiled at the moment... 

I was mainly interested in pinpointing where it started to become 'bad' and to try to pinpoint what it is about full maps that don't show up in box maps. 

I may have some insight into that from the new tests. It seems like there's a very fine balance to strike with random input - it seems to work best for trying out different ways of resolving "ties". I guess that in the simplest of test maps there really isn't any difference between just tie-breaking and randomising everything - but I think as soon as you add any real detail then the difference matters. 

I'm following this as well, thanks for the work.

Nothing solid to add though. 

is it possible to make rmq using some modern free engine?

i remember i've seen e1m1 on crytek eng 

 

http://tomeofpreach.wordpress.com/2013/06/09/quasi-randomised-algorithms-and-bsp/

So here's the way I was talking about, it gets you some improvement, even in the average case, over the deterministic compile run. I'm pretty sure that because the randomness is so low level, it's almost always a case of multiple tying brushes, and the randomisation changing how the tie is broken.

It's not mentioned in the post, but I did check and this version also performs well on the simple test map file. We achieve the same minimum of 160 (over 100 tests), and I'm beginning to suspect that can't be bettered. The graph shows an improvement in the average case, similar to the one that's in the article. So that's reassuring. 

is it possible to make rmq using some modern free engine?

that would end up being a free quake replacement, and zenimax would probably sue you for theft of IP. 

It's on a free engine... if you mean porting it to something like Unity or sauerbrauten then yes it'd be possible, but in that case it'd be better to make a standalone brand new FPS game using the same ideals as Quake.

Making a classic FPS game isn't too taxing in terms of asset and feature creation, as long as you make a feasible plan and still to it.

An idealistic FPS is almost impossible to make :)

And a AAA FPS would be a great big waste of time.

It also depends how much of a hobby or job the project is in terms of both your own time and if you can pay others for theirs.