I've considered that as well. less localization is nice but it ultimately suffers from the same issue as text I think. Maybe lights (not the common red/green combo, but something else) + a sound effect. surely that's clear enough? 

Hi there, This is all of quake stitched together into a single map.

https://github.com/plankatron/quakemash/raw/master/release/quakemash.001.zip

Info : unzip this into your root quake folder, the zip contains an id1 dir with a maps folder containing the map.

I recommend these settings for best fun playtimes :

r_shadow_shadowmapping_useshadowsampler 0

r_shadow_shadowmapping_filterquality 0

r_shadow_shadowmapping_bordersize 0


Testing :
Darkplaces : recommended engine to run on.

fteqw : try with sv_bigcoords 1 , if audio echos , try switching sound devices.

quakemash : http://triptohell.info/moodles/qss/quakespasm-spike-r7.zip , set sv_protocol 999

Your Mileage may vary , I am hoping to release this to mainly do bug testing and fixes. Also if anyone feels like writing some qc to get stuff like gravity working there is a basic to crazy feature list outlined on the main github page.

https://github.com/plankatron/quakemash

Thanks to LadyHavoc and Spoike for helping me test it out. 

I've been waiting for someone to do this since I played the merged Beyond Belief.

A half-hearted attempt at getting this working in quakespasm was unsuccessful. Whenever this works in QS I'll be checking this out! 

Andrew Smith started up a Twitter thread about Quake mapping and John Carmack is involved now talking about QBSP and various timings. Fun if you're into that sort of thing. :)

https://twitter.com/meejahor/status/948700123995009025 

The bottleneck used to be vis, then light. Then these awesome people named Tyrann and ericw made the tools threaded and more efficient. Now Qbsp is the bottleneck (unless you use bounce and extra on light).

Is qbsp threaded? Could it be?

I usually get very fast compile times anyways. Does func_detail improve Qbsp time? 

Qbsp is the bottleneck

Since when? 

Then these awesome people named Tyrann and ericw made the tools threaded and more efficient.
*waves hand* Hey, I started it! 

Good god, searching back for the original thread ...

2009?! Jesus wept, I'm getting old ...

http://www.celephais.net/board/view_thread.php?id=60365 

Is qbsp threaded? Could it be?
It's not currently.

The bulk of time in Q1 qbsp tools is spent is CSGFaces: it clips every brush against every other brush (i.e. an O(n^2) algorithm, so the qbsp run time will be proportional to the number of brushes squared).

The solution I have in mind is upgrading to quake 2's qbsp tool (backporting it to support Q1). That eliminates the slow CSGFaces function, has multithreading support built in, and it should be more robust.
(Q1's has this weird design where it converts the brushes into faces, chops them against each other, builds a BSP tree, and then re-generates the leaf contents types by looking at the faces. This is how you can get the player falling through solid floors in some cases; the fact that a volume is solid/empty/etc is only carried through the compilation process in a "accidental" way that is prone to being lost.) 

You could probably do the 3 hull generations on their own threads? Not sure if that would save any time or not ... 

I missed that stage in compiler evolution. I jumped straight from Bengt Jardrup's ol' tools to Tyrutils. Sorry Jne...willemZ.

@ericw that sounds awesome! 

Sorry to be dramatic about it. I'll be on my fainting couch if anyone needs me. 

for Quake 2 compiler. That would be a bigger improvement than any other in the last years: i made maps almost breaking several Quake 2 limits and never had to wait more than five or six minutes for a full compile. That's unthinkable in Quake even when keeping it on the original limits, going heavy on func_detail and surface lights.

Qbsp is the bottleneck

When? In which cases? I'm intrigued. Vis is still the highest time consuming one in all the maps i make by a large margin, even when i don't use func_details or go really heavy on lights (3-10 per source). 

And a map the size of texas. 

The solution I have in mind is upgrading to quake 2's qbsp tool (backporting it to support Q1)

That's sounds awesome. Beyond better compile times, would a Q2-based compile set the stage for any other new features that could be introduced down the line? (in the vein of things like func_detail, which we have now of course) 

I feel like most of the potential features are already implemented (not sure if you saw the detail variants I added last summer: link), so a migration to q2 qbsp code would be mostly speed / stability. I'd want to port over all of those current features though. 

(not sure if you saw the detail variants I added last summer: link)

Yes, I discovered those a few days ago - they sound awesome :) 

Which topic should I use for help with key bindings? 

I'm trying to create a toggle for r_wateralpha "1" and r_wateralpha "0.5" 

you'd have to bind each to a separate key. binding a toggle looks like this, btw: bind x "toggle r_showtris" 

You could use the bind-that-rebinds-itself sort of technique. E.g.

alias w1 "r_wateralpha 1; bind k w05"
alias w05 "r_wateralpha 0.5; bind k w1"
r_wateralpha 0.5
bind k w1 

that's a useful technique, haven't seen that before. 

bind k "cycle r_wateralpha 1, 0.5" 

Thanks. Also when using r_wateralpha "0.5", assuming the map supports transparent water, should r_novis be set to 1 or 0? I'm using QuakeSpasm. 

0