JUST BUILD INSIDE THE SQUARE 

not even sky brush volumes or funcs that clip through the walls? That's a bit shit I reckon. I'm going to adhere to the rules except on those points IF I feel it is justified and forfeit any prize if it is decided they go against the rules.

Or I could just make solid sky which shots hit, rockets explode and grenades bounce off just to abide by the rules. I suppose it isn't that bad really. Maybe just bring the sky in 1 unit from the 768 box or something (though it wouldn't solve the grenade issue).

Guess we'll just have to think hard about how to get our moving platforms etc. working nicely without making stuff out of hundreds of separate funcs. 

what you get with technical limitations ;? 

I'd just place clip brushes that fill up the entire grid but form a 768*768 hole in the middle. After that anything goes. 

...want to have that guys babies. 

I just want to clarify - so we can't have stairs that slide out from the wall?

Okay, Func_ entities can leave the 768 square play area during gameplay, but must fit inside the square when placed in the editor.

I think sky brushes should be allowed to go outside the 768 region. By this I mean that the visible face is within the 768 space we are allowed, but the other faces (which are culled in Fitzquake anyway) can be within a larger range.

Yeah, I think this is acceptable because the visible faces are within the limits, and the inside of a sky brush is solid to players. 

then you could make expanding walls to create more room 

no, because the worldspawn brushes still need to bound the 768 space. if a func leaves the square, you can't see it or touch it. 

:( 

you could in theory create a room within a room that is actually a func_door and slides out of the outer room when you pass through a corridor or go to another floor, thus opening up another space. Although the new room would probably have to be pretty sparse. 

Maybe it's the booze talking, but doesn't all this assume the map compiles without leaks? Otherwise yeah, you could easily construct a map where all faces are inside 768x768 during compile, but they greatly expand to a much larger playing field after the map loads. 

I don't know why there's so much discussion of the specific rules, why not go the speedmapping way and say if someone bends/breaks the rules, oh well, that's on them, it's not the end of the world anyways.

(If I can find some time, I'm gonna try to make a map for this! But thats a big *if*) 

you could have a leaky map, but if you did that, the outside faces would not be culled and you would get less space to work with inside in order to keep solids inside of the space. Either that or go func_crazy and have the level expand from a small box room at the start to a giant tower.

Also, if you move entities outside of the 768*768 space, they won't get lit correctly (are they fulldark or fullbright?) and if anything falls down below the map will break. 

My map will have everything inside 768x768. Cool, eh? 

My protest competition map will have nothing inside the 768x768, and how cool is that? 

We`ll call Riot Police on you! 

we'll have a Horizontal Map Competition next time! 

we'll have a Horizontal Map Competition next time!

Can I build higher than 768 as long as the player can't reach it? 

max height 64 

so mappers only have from -4096 to 64 in which to build their maps? THAT SUCKS.

;) 

for the horizontal map competition of course 

compromise: diagonal map. a giant slope! 

768 is like 3,5 jumps distance
yay for cramped 

Thats a 8192 -floor / ceiling width to fall (or fly) in. 

if anyone is seriously considering making a map that doesn't leak so that they can have a bunch of func_doors expand and create a horizontal map, I will make a new rule: your map must be sealed.