Here's alpha 5:
tabq1dm5_alpha5.zip

Bots should be lured to the waterroom alcove a lot more. Still not really often on the nonpure version, but this is all I can do without pretty much breaking bot behaviour anyway.
I did swap the MH & RA - keeping the weaker item right next to the weapon (RG) spawn, and making a dive/jump towards the alcove better worth the trouble and danger.

Fire away!

I only did a quick run through, but it seemed well enough. I will agree with Pho about the extra teleport however.. and the steeper stairs confuses me, but that's easy to get used to.

The bricks at the bottom of that pit are a nice touch. That was the one area of the original map that bugged me the most because it was pretty much a dead end.

Hmm, I disagree there. The only reason the stairs are as they are now, is because it looks better to me. I upscaled the entire map, but didn't think about the way that would affect some things. Doorways look fine a tad larger, but the steps look better smaller. I really don't notice any change in gameplay, so I pretty much ignored sock's opinion regarding the matter.


Aye, they voice their opinions pretty extensively. On the plus side, they are also very willing to share their expertise. I'm currently priv-msg'ing back and forth with AEon, who's helping out with the bot issues and vis-blocking to lower r_speeds. These guys have been in the 'business' since Quake 3 was actually still popular, and when in doubt, I tend to trust their view on non-aesthetic matters.

There's also another side to this, that makes me pay more attention to Q3W than I would for tabd2map01. I feel that the map's layout is tight and has good potential to actually work for the kind of gameplay that the people there like. I'm not willing to do things that would go against my own idea of a fun map, but I'm willing to make some jumps easier, or shortcuts available, if an big and active crowd of players prefers this.

Add to that that I care most about the aesthetic side of mapping -- I like creating moody, convincing and hopefully eye-popping levels that catch a particular look that matches the original game. How it plays is secondary to me, so I have no strong opinions on the matter. (That, by the way, is the main reason why I would never have added a jumppad --or even a lift-- to the map, no matter how strongly it was recommended).

The result is that I'm willing to learn about either, but tend to follow experts in gameplay design more easily than I would people voicing their opinions about the looks of the thing. I feel that I can justify that in this case, because there's a pure version to keep the gameflow of Quake. I'd decided very early on that I didn't want to keep that for the non-pure version -- additional changes seem to come naturally.

Finally, the suggestions aren't as extreme as it may seem at first. For example, the request for a change to the RA-alcove didn't include making it easier to get to the item. The RA is at a higher position and it looks like you can make it back to the walkway without swimming -- but you can't, by a hair. That means that circle-jumping back only drops you awkwardly into the water in such a way that it can't but be annoying. If they'd asked to keep the RG/MH-door open and remove the button, I'd not have considered it. That would be too much, and remove the needed danger to get to the items. But in other points, such as shortcuts and added interconnection, I really am willing to listen to these rather opinionated mappers. If it looks good, fits the map and doesn't play any worse for me, I'm willing to consider it.

Summary: a lot of words to simply say that I will make this lean slightly towards the common type of Q3 map, while certainly not doing everything Q3W-people are suggesting.

I thought I was nearly done, but now it seems I've been doing some bad things when clipping and botclipping the map. I'm currently trying to fix that, and every room I change seems to cut the bot-information (in the .aas file) down by many tens of kilobytes. Should in the end fix a lot of the bot stutter, I hope!

It may solve the tabd2map01 problem, but probably more because it involves entirely redoing all the botclipping, rather than any inherent quality. Not looking forward to that, but bugs must be fixed..

The "proper" botclipping process is indeed simple to explain, so here goes:

The logic of it is that apparently, using less brushes is better. Complex solid brushes (and especially patches) that are entirely enclosed in a botclip (or even a playerclip) brush, will be ignored by the botcompiler. The simpler the remaining set of structural brushes, the simpler the .aas can be (and the quicker it compiles).

So if you have a hypothetical level that has all its ceilings at the same height, you'd best begin botclipping by drawing one huge brush over every ceiling, right up to (or even enclosing) your caulk hull (if you were using one). It doesn't matter that it intersects stuff or even if it ends up largely in the void around your level. It also helps to make it as low as it can go without getting noticeable. Bots don't really rocketjump and if they can't even get halfway up to the ceilings, you can really clip a huge chunk of empty space below the roof.
I did this for most of my level, even though not all ceilings are at the same height, and it made quite a difference.

Playerclipping comes first, though, and should be done relatively simple aswell. Most of the guidelines for botclipping work for playerclip aswell. Ofcourse, you wouldn't clip stuff the player actually expects to get to, even if it means rocketjumping, etc.
Basic approach would be: 1) playerclip complicated brushes so the player doesn't get annoyed or trapped by them, 2) enclose the playerclip brushes in an even simpler botclip shell (that completely encloses them), if it simpler it can be.

Guidelines to keep in mind:
- If you can use one botclip brush to do the job of two, use the method with only one.
- Angled or complex botclip brushes complicate the .aas. If you can use big, simple cubes, that's the way to go. This means that you do not miter botclip (or playerclip, for that matter).
- Extend brushes to the botclip-ceiling or floor if they can be without interfering with play. (example: my torches are botclipped with rectangular botclip brushes that extend way up to the big ceiling-botclip brush.)

Other things to consider:
- Clipping stairs as ramps can help, if the ramp stays simple enough.

That's basically it. If you're not sure if something actually helps, just compile the map once with, once without and compare bspc results.

I don't think the bots can do those fancy tricks... the stairs are ramps for the bots, though. With botclip you make real bot-geometry, as well as the logical space for them to work in.

Aye, that's the idea. It's like the bots are running around in a different map from you. They can walk on botclip brushes, crash into them, etc. I don't actually know what happens if a func_bobbing or _rotate or the like pushes a bot into a clipbrush, but my guess is that it'll go *splat* as if there'd been a normal wall..