in my experience, it's best to stay away from what you're describing because func_movewalls are just not that reliable when implemented that way.

as you've noticed, if two movewalls are pushing the player, the collision can't be resolved properly which allows the player to sort of wiggle through between them.

the best you can do is to make them insta-kill, either with straight up high damage or setting the movewalls to damage on touch rather than block. 

Yeah I'll have to just bin the sequence, or rather, use it later when I can just place it over lava so there is no need for walls anyway. With the area it's set I can't really just kill the player if they touch it :(

Oh well, the section should be fun as it is anyway :E 

There is a way of doing it without movewalls. Never used it myself (yet), but;

http://kneedeepinthedoomed.wordpress.com/page/3/

Scroll down. You'll need to do some legwork and use a custom progs though. RMQ will work, but the gameplay changes maybe aren't what you're after.

What you're describing sounds like the opening bit of The Pit and the Pendulum... 

...so can't really use any different progs.

I'm over it now though, it's just another thing to add to the 'do in a later map' pile, which is getting pretty big now :E 

Just trying out different engines at the moment, and Fitzquake throws up a fair list of exceeded warning messages when loading my current project. Nothing is crashing or glitching, but I'm curious as to what a couple of them are:

marksurfaces
signon buffer 

I'll answer the latter:

The signon buffer is the first real message message that gets sent to the client. It tells the client the initial state of the world, which means it must contain all of the static entities in the world. It also contains a list of all the visible entities that exist once worldspawn has been run.

The most common reason that people exceed the signon buffer is adding too many static entities to their map. So getting rid of some is one way to fix this issue for old engines. For other trick I'm going to be lazy and refer you to an old post I made:
http://www.celephais.net/board/view_thread.php?id=4&start=8227&end=8227

Have fun... 

hmm, cheers. Doesn't sound like something I'll worry about too much :)

Also have to giggle at myself. Map is full of trigger relays, at lot of which I could bin... cough I forgot Quoth allows multiple targets cough 

It means the amount of triangles in the mesh of the world model. Including bmodels. You can go up to 32767 before you break the limit. You can actually go slightly over this limit without breaking older engines, but only by a very few. 

If you do want to overcome the marksurfaces limit, and you would be under the limit without the bmodels in your map, I have an idea which I have not yet tested (I don't have a large enough map to try it out on).

The idea is to move the bmodels into external files. You'd need some way to create func_ entities which can have external models, which is a very simple QC job if the mod you're using doesn't support it. The hardest part is probably making sure the new models are properly aligned with the position of their original counterparts.

I admitted that I haven't tested this as a way of getting round the marksurface warning. The uncertainty I have is whether marksurfaces are truly limited per bsp file, or whether they are actually a global resource in the engine which cannot be exceeded by the sum total of all bsp models loaded. So if you try it then report back! 

well, it would definitely help with clipnodes. but external bsp models like that would only be helpful for rotaters since they'd loose their collision. :(

of course, you could just clip the areas. 

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

In Q3 you can extract the lightmap and insert it into a bsp, so if the Q1 tools had a similar feature, it would be good here. But, of course, seeing how often external bsp models are actually being used in Quake, it would be a wasted effort. 

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.