>i don't think teleporting items are possible in
>vanilla quake

I don't know if this counts as an item 

Does anyone here care about quake speedrunning? Anyway, maybe someone has some thoughts.

What are the main aspects to make a map speedrunning friendy? The most obvious is to stay clear of clip brushes which block players movement. But I'm shure there are more aspects. What do you think? 

The moving door will not work out well due to this being an outdoor area... Ain't no lid on da' crib.

I was thinking of an area_damage, can this be toggled multiple times via a button / switch? 

I'm no runner but a GL, potential vertical shortcuts and slopes should help. If you haven't already, check out RDE: http://www.planetquake.com/rde . 

'By default, mapobjects to do not block movement. To implement this simply, add a clip brush of the dimensions noted above placed on the floor'

Why did you choose not to make the braziers block movement without using clip_brushes? Did you foresee occasions when not blocking movement was an advantage for this/these models? 

I don't think trigger_hurt entities are triggerable. I think your only triggerable option is to have a func_door that squashes the player. You could, theoretically, have a set of spikeshooters that are triggered by the button, but I suspect that in order to give significant damage, there would need to be so many spikeshooters that they would lag all the players.

Alternatively, you could set a trigger_hurt in the campable area that does 1-2 damage per second. Plenty of time to grab the quad or whatever, but you still don't want to sit around there. 

I have teleporting health in my WIP map but I did it by modifying items.qc. 

I think your only triggerable option is to have a func_door that squashes the player.

This is pretty much what I ended up doing, although in a reversal of what necros (thank you btw) suggested. I have the brush coming up from the floor smashing the player up into a clip brush. I guess it works out ok, I'll find out via beta testing...

The map is ready for a beta run, anyone interested? 

one last suggestion, hope it isn't too late:

You could make the floor of the area a func_door that drops a short distance, maybe 8 units, into a trigger_hurt with massive damage. Just as long as the trigger_hurt was lower than the func_door's raised position, but higher than it is in its lowered position...if you follow o_O

The advantage to this over the vertically moving crusher is that you won't need a clip brush or other solid 'squish' surface overhead.

I used this mechanism for the sacrficial pit in my early DM map Animositania, as an anti-camping measure where the pent was located. 

You could make the floor of the area a func_door that drops a short distance, maybe 8 units, into a trigger_hurt with massive damage. Just as long as the trigger_hurt was lower than the func_door's raised position, but higher than it is in its lowered position...

I like that one and its not too late either, I am in no hurry.

Making that change does not change my need to have it tested in the current state that it is in. It is "finished" and fully compiled, I need suggestions on items / weapons loadout and layout, some lighting tweaks and comments on exactly what is the most common approach to clipping architecture.

/me throws out some bait...

http://www.maricscabinet.com/1q2a.jpg 

well, we decided to leave it up to the mapper because we didn't know where the mapmodels might be used. for example, a map i'm working on has the bordering on corners. if they were clipped to the dimensions, they would hinder movement quite a bit. but since it's not preset, i put a clip brush that clips 45 degrees, so a triangle, basically, instead of a square, and that lets the player move smoothly around the corner but doesn't let them move into the object.

also, for the shorter braziers, you might want to place them out in the middle of a floor where you wouldn't want to clip them at all (so the player doesn't trip on them).

it's all about freedom and customizability. 

that map looks really good! :o

if i was even remotely interested in DM, i'd offer. :P 

Good point, thanks. 

if its for q1, send it to sollers DOT inertia -AT- gmail DOT com and i'll have a look at it for you. additionally, i need to know what player load you are making it for (1on1, 2on2, 3on3, FFA, etc) 

I have a problem with my map, once again. I have "cross connected doors".
What does that mean?
thanks guys 

I'm not sure but I remember I had a problem with 4 door angled 0 90 180 270. At least one door should not have the right angle (271 1 89). 

'doors don't link' spawn flag! rawr! 

a) get rid of the silly clip brushes above the quad
b) make the GA an RA or YA and add in other armors in other places
c) I like the quad placement and the quad teleporter placement
d) the placement of the high powered weapons is not very good:
the RL can see both the GL and the LG... this equals map domination and stuff etc etc

solution: add another rocket launcher on the lower levels, and switch the existing rl and lg positions

see how that plays! I'd suggest more radical changes but 1) i think it will play pretty well how it stands and 2) i dont have a very good qw setup here, so its hard for me to get a perfect grasp on the map dynamics

glhf! it looks really good also...

but make the blackness a sky texture, so rockets die when they hit it, and make it so players die on the vertical walls, not just the bottom of the abyss 

Thanks for the input and sorry for the slow response. I am implementing Neg!ke's "false ceiling/floor" in my latest speedmap, but thanks Mike for the QC idea :) 

Haven't played the map, but it sounds like inertia has some good feedback there.

Except: but make the blackness a sky texture, so rockets die when they hit it

Don't do this. Actually, yeah...go ahead and do it, then see how the map runs while the engine tries to calculate that much sky animation every frame :P
Not very render-friendly if played without a skybox. 

i know!! take away the outer box! nothing beats genuine, grade 'A', grey void! :D 

couldn't he just put a trigger_hurt out there to kill the rockets? i thought some sort of trigger_ would kill things like that... 

Actually, yeah...go ahead and do it, then see how the map runs while the engine tries to calculate that much sky animation every frame :P

This is only really a problem in glquake. Winquake doesn't care, and engines like fitzquake and darkplaces don't care. The solution for glquake (and any gl engine that hasn't rewritten the glquake sky code) is either a really high gl_subdivide_size or, in some engines (like zquake and fuhquake) there is a "fastsky" cvar or something. 

Yeah I know some engines have ways to deal with it, which is why I provided skyboxes for Chapters.

But Maric's map is DM, so I assumed there'd be a different and probably wider array of engines players might be using to play it, and there's also internet play to consider.

Even in FQ, with its efficient renderer and all, turning the skybox off in one of my void maps halves the framerate. 

that are the only real quakeworld clients (well, there's mqwcl but less than 1% use it) have the r_fastsky option as well as skybox support and a software client version. I don't know how well the vanilla sky renders in fuhquake-gl (and it's derivative ezquake-gl) but I believe it's fixed just as much as fitzquake. I understand most of the rendering improvements were made by borisu (qw262) and fuh themselves/together. You could try to run some tests.

So the array is not wide. You are considered a cheater if you don't use one of these clients with a certain ruleset and security module.