News | Forum | People | FAQ | Links | Search | Register | Log in
General Abuse
Talk about anything in here. If you've got something newsworthy, please submit it as news. If it seems borderline, submit it anyway and a mod will either approve it or move the post back to this thread.

News submissions:
First | Previous | Next | Last
Quake 2: Sonic Mayhem 
Quake 2: Sonic Mayhem 
rejected here because there's no info about what it is at all. need screens and short description at least. 
The day scene is awesome. The night scene isn't as impressive for me, but it has a more consistent visual style. 
What Happened To Nonentity 
it's been awhile since his last visit this place 
Why Does Doom Attract More New Players? 
I don't mean this as a post to stir things up. It's a genuine question. Is it purely down to Doom being simpler to map for?

I love both games but I've often wondered why Quake just doesn't get the same level of newcomers even though the game itself is probably more influential in the industry... 
How Many Layers Of Mapping Are You On 
Simplicity is probably a big part of it. Figure that to get a basic Doom map from the editor to playing in-game, you need maybe one or two programs total, you can make the whole thing from the top view drawing walls and floors and doors, and you play it by dragging the .wad onto the game of your choice. With Quake you have at bare minimum four separate executable files- map editor, qbsp, light, and vis- with the latter three either requiring an editor that can auto-compile by filling out the paths for the tools, a fifth dedicated tool to act as a GUI (like Necros's compiling GUI), or running them all through the command line which is just silly (even though that's how it was done back in the day).

Then once you get a hang of the tools themselves, the world of brush based mapping can be confusing to a newcomer if they're used to Doom's dedicated floors/walls/etc, and despite the incredible amount of flexibility even Quake's basic map system gives compared to Doom's 2.5D (read: not requiring source ports or hacks for completely basic stuff like rooms over rooms or sloped surfaces- when everything counts as just a plain brush face, there's no floor/ceiling nonsense!), they then get to learn about fun things like using light entities instead of fullbright sectors, what leaks are and why their map is running so slow, scripting with triggers, relays and counters, and so on.

So then after all that you've decided instead of just map making, you want to delve into full-on modding, new enemies, weapons, what have you, and you discover there's nothing here but QuakeC which- while again, is arguably more powerful than Doom's various script types and infinitely more versatile as it isn't sourceport-dependent- requires, well, learning QuakeC. Then for actually getting visual representations of your snazzy new gun/monster/what have you, it's time to learn 3D modeling and track down all the tools and limitations required to make your project fit into Quake's ancient model and animation system, there's no fudging around in MS Paint for an hour kit-bashing someone else's sprites to make your very own pixelly masterpiece.

There's also the matter of popularity, which is a self-fueling thing like an engine dieseling after you cut the spark- while breaking 100 maps in a year is a milestone for a smaller community like func_ and the related Q1SP communities, Doom's modding community is staggeringly large, and people who want to make something for a wider playerbase- be it because they want the recognition or just wanting more people to be able to experience their work- will naturally be drawn to the game that already has a large base. It doesn't help that Doom has been basically 'memed to death' (for lack of a better term) ranging from endless agitating skellington 'jokes' to "But can it run Doom?" for every toaster oven, VR headset and digital wristwatch in existence, while Quake has always been kind of a black sheep outside Quakers themselves due to the pretty darn big differences between games and how- much like UT99/UT2004- Quake players seem to always be at each other's throat about why Your Favorite Quake actually sucks and why My Favorite Quake is the best game ever made, with the Quake series as a whole obviously going on to gain fame as a multiplayer franchise, and Q1/Q2 SP left in the dust to be forever shat upon by Doom players angry the double barrel shotgun can't kill an Ogre in one shot.

tl;dr duum is for brainlets, play more quake 
Doom attracts sprite artists. Quake doesn't. 
Job Offer In The Jobs Thread 
Guys, Skiffy posted a real job offer for level designers in the Jobs thread. That thread gets spam so often that people sometimes don't bother looking. But that one is for real. 
Thoughts On Centerprint Print Text? 
For locked doors and such. I like its unambiguity but it's not very elegant and feels too separate from the world. I would prefer a simple sound effect to convey the message but fear that's not clear enough... 
Center Print Icon? 
Less localization to do? 
@Hipnotic Rogue 
"why Quake just doesn't get the same level of newcomers Doom"

Great question. Simple answer.

Doom maps? They can all coop can't they?

Yeah, that's why. You can coop Doom. You can coop Half-Life with svenmod.

No coop support and none of the mappers here except the legendary ones (metslime, czg, necros, tronyn, distrans, scragbait, pulsar) would even know how to make a map that could coop.

DarkPlaces can coop. FTE can coop. Mark V can coop (ask Gunter).

See the thing is coop support is really, really, really hard because you have to know about networking too.

If you don't have any coop users and plenty of single player users that are quite happy, how would it ever get on your radar to learn how it works? 
It is both a technical issue and a lack of support at the same time, in my opinion: there is no support or advertising because there is no demand for it, and there is no demand or advertising because there is no support.

There is also the part that MP communities consider cooperative to be more like SP and don't pay it much attention to it, and SP communities don't play MP so care even less about coop, and both sides are a bit isolated between them with only Quakeone as more or less common ground. Don't know in detail how it is on Doom but they seem to be closer together.

So cooperative, even for ''dummies'', on Quakespasm as cooperative is seen as SP and its considered to be SP's flagship engine, to make it popular would be good. And second, how about Daz or another one that have enough popularity making videos of Quake SP maps make a cooperative play-through? That would help a lot with it. 
Teaser :

Looks faaarking fantastic. Proper dark fantasy (dare I say even Dark Souls-esque) vibe and setting with some meaty looking combat and magic powers?

Hell yes. 
Hey Now 
Some of us specifically add features to our maps to make it coop friendly.

Coop is a huge part of what makes a game compete. Only one of my top 5 games doesn't have coop. Only backsliding lame game companies don't do coop. 
Whoa Whoa Whoa Whoa!!! 
Did I just see like 4 or 5 new maps pop up...crap what are we up to now for the map total of 2017?!? This is great! 
Yeah, Ive neglected coop spawns in pretty much all of my maps. I should start including them.

I have considered doing a coop ONLY map at some point. I loved Portal 2 coop and I'd probably reflect on what made that game fun(to me) and implement some of those ideas into a coop map. 
Qmaster - Quite Possibly, Go Play And Comment! 
i think i remembered to put a coop spawn in my xmasjam map, but i'm also pretty sure that it would be obscenely easy to get locked out of the final area unless both players are together before they run in... Oops. 
Maybe the next map I make will require coop - press 2 buttons at once sorta gimmick :p 
Happy Quake Year From OTP's Geekery: 
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? 
Quakemash Alpha Release 0.001 
Hi there, This is all of quake stitched together into a single map.

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

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. :) 
Qbsp Compile Times 
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 ... 
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). 
When You Have An 8 Core CPU 
And a map the size of texas. 
Q2 Compile 
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 :) 
Help With Key Bindings 
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" 
I Don't Think You Can Toggle A Non-binary Value 
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 
Johnny Law 
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. 
Maiden: About Wateralpha And Novis 
"r_novis" should pretty much always be "0" (i.e. off) -- which is the default anyway, so basically, don't tinker with it. This is why:

What r_novis does, is to tell the engine to ignore vis data, which specify which parts of the map are visible to the player at any given time.

Vis (short for visibility) saves the engine from having to draw the entire map at all times (which is a waste of resources and, especially on large maps and slower computers, can slow the game down). If a map has not been designed and compiled with transparent water in mind, then the water blocks visibility, and whatever is below or above the water (from the player's perspective) is not drawn. Simply setting r_wateralpha to a value lower than 1 will not magically make the water transparent -- in Quakespasm you'll get some ugly visual artifacts.

By switching r_novis to "1" and then lowering the wateralpha, you can force the engine to display the water as transparent -- but at the cost of having the engine ignore vis data and drawing the entire map at all times.

Perhaps more importantly, maps that do not support transparent water have often been deliberately designed as such, so if you "trick" the engine into displaying transparent water, you might also end up breaking the gameplay and/or aesthetics of the map you're playing.

So in summary: only ever adjust wateralpha and leave novis alone. If the map has been designed for transparent water, it will work; otherwise stick with opaque water (i.e. wateralpha 1). 
bind k "cycle r_wateralpha 1, 0.5"

Did cycle exist in vanilla quake? o_O 
Got it. The reason I asked is because one of mfx's maps had to be run with r_novis "1" to make some funky transparent glass in the map show up properly, but that's a special case I guess. Thanks mates. 
Don't think cycle was in the original engines nope. Looks like QS and Mark V support it though. 
Did Alias Exist In Vanilla Quake? If So, That's Ridiculously Cool 
you could place all the stuff in a file too and use the exec command too 
The "zoom" command in vanilla Quake is an alias. It always existed in Quake.

The zoom command also auto-rebinds itself, exactly as described in #29918. 
Darkplaces Vs. FTEQW 
What's the best engine to play online today? Do they support more than 32 players? 
Unreal Editor History 
If you're going to play on quakeworld servers then FTEQW is clearly the better choice. Don't get me wrong, its nice that DP tries, its just that it doesn't really have much awareness of actual QW trends.
Things are a little more even when it comes to NQ servers, and given my bias I'm not even going to name my preference there...
but yeah, depends on personal preference, the server in question, and your choice of engine-specific content replacement stuff.

vanilla nq supports 16 players max.
vanilla qw supports 32 player slots max.
both fte and dp servers can be reconfigured for 255 players max, but don't expect other clients to be happy with it.
for fte you need to set both sv_playerslots and maxclients to 255 (two cvars because maxspectators also exists and shares slots).
although the chances of getting even 16 players is somewhat unlikely nowadays. 
Arenas And Co-op 
Is there a way to combine players vs. environment arena combat in FPSs with co-op play that doesn't suck? Let me explain my question.

By an arena I mean a combat encounter against mobs that happens in a limited area. Door close or other barriers appear to prevent the player from leaving until he has cleared the area. I'm sure you could name various newer FPS games that do this as their main gameplay mechanic, and it's also a common design pattern in Quake SP maps.

This sucks in co-op play if one player goes into an arena and locks it up. The others have to wait until the combat is over to join this one guy, unless there is a way for them to enter during the fight. Being able to teleport in is one way to solve this, but it feels a bit forced and teleporting does not fit with all kinds of games & worlds.

I'd want the players to have the freedom to explore the map while others are possibly fighting and join these fights at any time, or start fights of their own. I wouldn't mind some requirements towards having all the co-op players present for big final boss fights to start, but this should be only done for the main combats that are tuned for the number of players taking part. Freedom to explore should come first, but on the other hand well-crafted arena encounters are really fun.

What ways can you think of combining co-op play with PVE and arena style combat? Are there any games that actually do this in an interesting and natural way? 
If the "lock-in" is due to the player dropping down from a higher area, then that would work. Or maybe have a sort of double-door "airlock" setup that allows only one-way access to an area. 
This is called a "push" game mechanic. This could be any number of things. In SP, doors that slam behind you are very common. For coop, a height push as Kinn mentioned is very useful, natural, and common and works in any game.

You could do other methods, for instance to have player freedom, such as gravity/wind/catpult lifts or devices to take you up to a lifted fight area.

You could also still use a door that slams behind and then open up another pathway to a height push for any straggling players. 
Oneway turnstiles work too. HL2 uses this at the very beginning level in the trainstation. 
add a player counter trigger that activates only once it has been touched by every player. would need new qc though.

possibly fake it with some elaborate counter with timeout, and not enough players are standing on (separate) buttons then it doesn't continue.
sucks if there's only one player though.

one other alternative would be to flood the earlier parts of the map with lava or something. you'd need some teleporter with careful killtarget use to prevent respawning players from dying instantly though.

alternatively place a massive triggered teleporter over the earlier parts of the map and trigger it to instantly teleport lingering players into the arena. would need a teleporter at the start...

or just use one way teleporters so that you can always get in. You could put them behind a door that is toggled when the area starts, and again when it is ended (if desired). 
add a player counter trigger that activates only once it has been touched by every player. would need new qc though.

Easier one would be to put the trigger that targets the counter on a drop down or on a wind tunnel. Would need for the area to be wide enough so only one player passes at the same time and fiddle with the wait key till even if the two players go one right after the other it will trigger for both. 
Is True 
How very interesting, I'm sure you could talk for hours about GPL given the go. 
Co-op Gating 
I'm gonna share a simple trigger setup you can use to only trigger something once all the players have progressed beyond a "gate" (and then ruin it a bit at the end). We need to build something I call the "dead man's switch".

The idea of "dead man's switch" is that we build a system of entities with an input and an output, where the output fires if we haven't had an input in the past 0.5 seconds. I'm gonna prove it's theoretically possible using spike-shooters and doors - if I put more effort in I expect there's a cleaner way to build it, but that will have to wait until the blog post in a few years time.

Build a spikeshooter, firing continuously at the output trigger: a shootable trigger_once. Now position a door such that the door blocks the spikes when open, but allows them to pass when the door is closed. Make this door return rapidly to closed after fully opening.

Now add the input: a rapid firing trigger_multiple in the actual level which targets the door. So long as at least one player stands in this trigger, the door is retriggered repeatedly and kept in the open position. As soon as this stops happening, the door closes, a spike passes through, and the output trigger fires. The dead man's switch is complete!

How do we use the dead man's switch to create a gate that all the players must pass beyond before the level progresses? By defining the gate in negative terms. We cover all the portions of the level before the gate with trigger_multiple inputs to the dead man's switch. As long as at least one player remains in the pre-gate parts of the level, the switch cannot trigger. As soon as the last player leaves the triggers, the dead man's switch activates.

Now I've shared how to pull the basic version off, here's the first problem: the dead man's switch will trigger if there are no players in the pre-gate region, and one way to achieve that is to have zero living players anywhere in the server! This could happen if all the players die at once (especially easy if there's only one in the server) or if some network problem causes all clients to drop from the server (the "zero players connected" state at the root of many rare co-op bugs).

There's a reasonable workaround to this though: require a positive input to the spikeshooter, using a trigger_multiple from the region after the gate. Now we've changed the conditions to "no players before the gate, 1 or more after the gate".

The last thing to worry about is what happens if players die after you've fired the gate event. They will presumably respawn in the pre-gate area of the map, so you have to remember that you can't guarantee that players will remain trapped on the far side of the gate. This is especially important if you're locking an arena with a door - how will dead players rejoin the map? If your answer is that they can't, are you happy that the map will be impossible to complete if everyone dies? Or get disconnected by a network glitch? Don't worry unduly, but do try to bear these in mind. Good luck! 
Simplest solution to the problem at the end that I can imagine is to have a second, drop-down pathway that opens when the gate closes. Small, short & simple but enough to let players rejoin the ongoing fight. 
3 cheers for Khreathor and all the modeling help he gives me. 
I am seeing a lot of new users here. Both posting maps and questions. New blood is always good in the Quake scene. Glad to have you all. Stay... please!!! 
I now have beef with dumptruck for interrupting my round of cheers. 
2 posts not shown on this page because they were spam
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.