The bone recess in pic 1 is awesome. I'm ashamed I didn't think of that earlier. 

is awesome indeed 

It reminded me of this infinite scroller experiment I've made over two years ago:
https://youtu.be/-qvli2BFIGk 

dat potato resolution. Do you have a higher res video? 

I don't remember. That thing is really old. 

 

I think computers were made out of vacuum tubes back then, so give him some slack. 

:D I love this place.

Anyway, the variable framerate of the Quake engine (in that case, FTEQW) made the loop get out of sync, so the floor repositioning is noticeably abrupt, and the mountains behind the trees aren't spaced correctly.

This is why one of my goals is to implement scrolling textures. It will be a much better, cleaner, easier, more flexible and more accurate approach. 

wouldn't mind scrolling textures for waterfalls, actually.

but then no one will use it until other engines have it too. :( 

as long as the texture name prefix for it isn't '(' or something dumb, you might have a chance... 

well we already have {, so using } would be a nice bookend to that atrocity! 

? 

most likely
https://twitter.com/SimsOCallaghan 

scrolls maybe? 

To use something that turns your grammar from context free to context sensitive. That would give me another chance to get told to fix my parser when I complain about it. 

? 

I *REALLY* hope editors have started properly using quotes when saving .map files by now...

it'd be really nice to NOT use yet more name prefixes as they tend to fight each other. Maybe we should start hiding our extra surface attributes inside // comments for backwards compatibility! :P 

if we rely on comments then we have to add support to all the map editors, and the map compilers also need to add support and it won't be in comments since there aren't any in a bsp file. If we use prefixes then the only the engines need to add support for the feature. 

What so you mean by using quotes properly? Texture names are not enclosed in quotes, at least according to the unofficial map specs:

http://www.gamers.org/dEngine/quake/spec/quake-spec34/qkspec_2.htm#CMFMF 

I'm certainly going to use surface flags. Q1BSP doesn't support these, but scrolling textures would appear broken in vanilla engines anyway.

Surface flags will also allow for physics scrolling (so conveyor belts will really work), and for entity interaction (bind it to an entity field, so the entity can toggle the scrolling on/off and change direction and speed at will).

And the "{" for alphamasked textures is dumb.

I already have plans for a new map format. Things will eventually happen, and I'm going to do it carefully.

Editor support will also be considered. 

the unofficial map specs are just that - unofficial.

I'm far too lazy to actually test it, but as far as I'm aware the following is a valid-but-sadistic .map file as supported by QBSP (apart from the bit in angle-brackets that denotes the other planes, because I'm too lazy to come up with witty wtfs for those too):

"{" // }
classname worldspawn
sounds 2 "{""(""what" the hell ")"( 1 shoddy parser ) ( hello "2, or 'to' if you'd prefer" you ")" "tex with space"naught//(shift_s) slash(shift_t) there(rotate) 1t(scale_s) 2oo(scale_t) //and a real comment.
<OTHER PLANES>
"}" "wad" "c:\this\is\borked\"
"message" "and somehow\nthat was a newline, at least for the engine" "}""{" classname info_player_start }

thank god nothing actually uses all those quirks... at least not all at the same time...

the various bits of punctuation (especially noteworthy with the ( and ) brackets) MUST be their own token, which is why they normally have extra spaces.
the format is simple and stupid. a token is just a token, once parsed it is irrelevant whether it originally had quotes.
A token is either quoted, or its all chars until the next whitespace where 'whitespace' is any char above 32. Because this check is agained signed chars, any utf-8 chars or non-ascii ansi chars will be considered whitespace but can be quoted to pass them through unmodified.
If a token did have quotes, then whitespace is not needed after the token to determine the end, as this is inferred from the fact that the quotation ended. Additionally, there is no special handling for punctuation (like any kind of brackets).
New lines are disallowed in certain places, but entirely optional otherwise (with the obvious exception at the end of a // comment).
Double-slash/single-line/c++ comments are only recognised as comments when they are at the start of a token. If they directly follow an unquoted token without whitespace beforehand then the token will contain the slashes rather than the parser seeing the comment. Because they are terminated by a newline, they cannot be used anywhere that a newline cannot appear.

*SOME* editors write quotes around texture names (I'm fairly sure I've seen this happen). These editors do not have problems with spaces in texture names, and also avoid the {foo issue when importing in certain other editors (although nothing can be done about those other editors saving and then failing to re-load the file they just wrote themselves, other than fixing the editor).

QuakeEd uses the exact same helper functions as QBSP. It doesn't write quotes itself (and thus will bug out if the file is re-saved thanks to the spaces in the texture name), but it should parse it all just fine (I don't have a machine with actual NEXTSTEP on it).

If you're worried about compatibility with other unofficial tools then just write the quotes only when it has chars that are not azAZ09_*+
If an editor sees "{foo" as literally containing the quotes then at least it'll save it out correctly too, even if it cannot display the texture properly in the editor.
But whatever you do, don't write out a file that the same bit of software cannot then re-load!

So yeah, that's what I mean by 'using quotes properly' - using them in order to stop your importer+qbsp from reading the file wrongly. 

"*SOME* editors write quotes around texture names (I'm fairly sure I've seen this happen)."

I'd like to see an example of that. I've never come across that in all my years of Quake tinkering. 

how does one make a new map format, with everything that modern mappers want without losing the q1 feel?

If we're going to lose the feel of the q1 experience, then why not just use an engine that supports and migrate our mapping HL(2) / D3 / Q4 formats? 

Depends what you mean by "q1 feel". BSP2 already lead to many not very Q1-ish maps. 

Bsp 2 with quake 2 style surface properties would be a dream. Phone shading!!!!!