External BSP models work fine as long as you make sure the corresponding entity is also set SOLID_BSP. It takes more effort to light them correctly though...

ORLY?? shit... i think i may try that out then! 

The last map I made was struggling with these marksurface error.
When I really try to understand what was happening, I rejected the subject, because my small brains couldn't get where it's at.
Sometimes I could add entities at the 32767 limit, and sometimes changing b_models into sprites (which lowered the marksurfaces) added the marksurface_limit error.

So if you look for a maxlimit brush map, take venividifuzi. 

is there a built-in way to do weather effects (ie rain, snow, etc) in modern engines, that's cross-engine (ie if it works in one it'll work in another)? 

Nothing that looks remotely acceptable. Zerstorer had some ugly qc rain or was it nehahra?

Darkplaces has gorgeous effects which you can try eg with dpmod. Tomazquake and its derivates have good effects. 

at least i think it's from extras (someone else may have to provide the link). it's in the remakequake progs anyway.. all you need is a little raindrop or snowflake mdl and you can make it fall pretty much however you want and control the density too

one thing rmq added was an 'alpha' field to allow transparency, which makes for better rain. i'm not sure whether that's cross-engine though 

http://quake.chaoticbox.com/downloads/extras_r4.zip

check the docs for how it works :) 

RMQ has partice rain I think, just not used in maps yet. The emitter method for rain is probably not the best one. Most people don't get the raindrops right.

As for "every engine supports it", well that's always the problem. The emitters are qc, so that'd work. 

...do people have any strong opinions about having forced quicksaves like checkpoints?

My map is pretty much linear so it's not a problem regarding saving at a bad moment (also avoiding triggering when the player is balancing on a platform or in the middle of running and gunning), but on the other hand I'd like to keep options open for making something more open ended.

Thoughts? 

If you think it's necessary, do it. But only in key positions, not in every room. And make sure to use a unique name for the autosave, e.g. the map name. If you want to keep options open, you could make the autosaves button-operated. Though then it wouldn't be much different from regular quicksaving. 

I think it is nice to put a *couple* of savepoints in a map nowadays. As maps get bigger people are less liklely to find the willpower to start a level over from scratch if they died and forgot to save. 

hmm, I was planning on fairly regular, since the map's combat is fairly nicely broken up. There are plenty of Half-Life style moments of just moving to the next area... 

I tend to forget to quicksave and then I curse when the game has no checkpoints. Then I quit the game out of frustration.

Checkpoints are a good thing. Use them in a sane way and I doubt players will come to your house with torches. 

We've got them. A quicksave is also created on map load, which is very useful.

I'm placing them now in one level, and as a rule of thumb I'd suggest after every key door in a medium sized map to be a decent checkpoint.

For big maps maybe picking up a key or other pertinent moment when there aren't enemies or traps around.

Random idea - in a tech map you could add computers with a button on them throughout - whenever the player presses the button it quicksaves.

In terms of good idea or not, I don't think anyone is ever going to complain about making the game more accessible / less frustrating to play. 

Please find a way to make the player not notice them. It is breaking immersion or hinting at "death ahead" otherwise. 

That's why key doors are good. 

Also, before hard fights would be useful. 

Well it's hard to make the play avoid noticing them, since they will always cause a slight jerk when they fire.

I plan to release a beta soonish so if I've put in to many I'll find out then I guess :) 

use 'save autosave' and then have your trigger command bind f8 to 'load autosave'. that way it doesn't interfere with standard quake saves. 

The saving jerk might be minimize-able. 

umm, and about placement, basically make sure the player doesn't have to re-do difficult or time consuming tasks, like a puzzle, a trap gauntlet, a jumping / platforming thingy, or a larger fight.

The #1 reason for frustration is "Oh no, now I have to do all that crap again just to get back to where I was." So after the player did "all that crap", ie beat a challenge, give them a savepoint / checkpoint.

In complex, Half-Lifey maps the checkpoint density is going to be higher than in DOOMish maps, naturally. 

Did you guys see my autosave engine patch? It saves when you pick up health (with certain restrictions, like no more frequently than every 30 seconds).

http://www.celephais.net/board/view_thread.php?id=60172&start=320

I've been playing a lot of maps with it over the past few weeks and it works pretty well; the slight pause is only noticeable on really big maps. I couldn't go back to manual saving again! 

The #1 reason for frustration is "Oh no, now I have to do all that crap again just to get back to where I was." So after the player did "all that crap", ie beat a challenge, give them a savepoint / checkpoint.

The #1 reason for frustration is the crap itself. Make good maps, then there is no need for holding the player's hands. 

I love czg03, but if I died in the middle without having quicksaved I wouldn't be willing to replay it from the start all over again. 

MAX_MAP_NODES

Only came up with it during a compile with a leak, after fixing that it hasn't, but again, curious as to exactly what it's refering to :) 

Zealousness.

http://qbism.com/index.php?topic=12.0;wap2

Written by AguirRe (Bengt Yardrup who wrote TxQBSP and TreeQBSP, and the core of the lighting and vis tools which most of us use) the above linked document contains a lot of explanations for a lot of the errors and warnings.