I don't think different colours is a problem providing it's introduced to the player. I like replacing shootable buttons with things to blow up, but you need the player to know it's they're doing something right and I agree it is weird when random objects bleed :p

Best solution would be a multiple colours thing where you set up patterns. You just have to make sure a negative is always gray so a different colour should become a sign of 'ah, I shoot this'. 

I can't remember if Quoth Breakables can trigger things when they die, but I put triggers over them to shoot anyway because I want the hit indication. 

I'm with metl on this one - the blood is an obvious cue to the player that they've just hit something and now they can expect a result. It's one of the conventions of the original game.

Of course, if you're happy to stray from the conventions of the original game then you can do whatever you want; otherwise - use blood. 

I like ZQF's suggestion that grey = fail and bright color = success, which allows different bright colors for different object types.

But I would also like shootable buttons to play a "success" sound that's more obvious than the subtle hydraulic hiss or soft click that they normally play (which is often lost due to the louder weapon sound anyway.) Usually the button triggers a nearby door or machine, and that object is moving and making noise, but it's not always on screen and not always audible.

I also felt it was a (minor) design flaw that rockets don't give damage feedback, so for example I spent way too long firing rockets at Chthon the first time, assuming that it was working. When I ran out and switched to nails, suddenly --- "Aha." (And now that I think of it, Shub gives misleading feedback too. Though you can kill her and crash the game with direct damage, it's not part of the design.) 

Yeah, another option since weapon fx can make such indications difficult (seeing a bunch of sparks/blood through a rocket explosion) is a couple of lines around the crosshair or something that blink when damage is caused (like Battlefield), or sounds, but again sounds can be missed in the same way as game fx. 

holy shit!

Before I write my thoughts about the gameplay, I have a quick question though - Did you do all the terrain by hand in radiant? Or do you have some way of exporting it from a modelling app...?

I remember when i did marcher's terrain entirely in the map editor and afterwards I said "never again". Your terrain is an order of magnitude more ambitious so i'm curious as to your method ^_^ 

pretty sure it was hand made. 

yeah it was hand made. by far the longest part of making that map. :P
i remember when i was about 1/3 of the way in, thinking "fuck, why did i want to do this again?"
if you're bored, type:
notarget
sv_friction 0
developer 5
to activate ski mode, then use impulse 103, 104 and 105 to teleport to the different peaks and ski down.
ski mode is the only reason i stayed sane. 

Never a more patient man has graced Quake's hallowed halls as you, necros.

That ski mode is hilarious - I think my current record is around 1500 units/s off of slope 2, and I'm sure I was airborne for at least half the journey :} 

turning up sv_maxvelocity helps too, because it'll cap you at 2000.
it'd be pretty awesome to use the bsp2 format and make a super huge slope map for something like that slide mod, which i still think is awesome.

how did you do your terrain?

for me it helped a lot to sort of build the whole thing at once.
when you do something that takes so long, you've got to be able to really see it coming together or you're gonna loose interest.
i built all the highest peaks first and then expanded them all outwards simultaneously so that i could see the shape of the terrain very early. 

There is that old terragen thingie that makes brush trisoup from a 2d hightmap. Then you load it in a map editor that lets you drag verts on multiply brushes at once and change w/e you need manually. Not that hard to do.
But then qbsp shits on you with collision problems and you spend 10x time fixing than you spent making it. 

how did you do your terrain?
I did it all in quad prisms first (and occasionally higher sided prisms) to get a nice polyflow, and a rough height pass (imagine all the prisms differing in height by jagged steps) then when that was all done I chopped them all into tris and lowered/raised the verts as appropriate to get smooth height variation. Final tweaks like "turning edges" were a pain in the arse as you can imagine :}

There is that old terragen thingie that makes brush trisoup from a 2d hightmap problem with that is that the heightmap is based on a regular grid, which is really ugly - i need my nice polyflow :}

To be honest, I might have a go at banging out some melscript that takes a bunch of triangles from maya and projects them up (or down) to turn them into tri prisms, and then spits out a quake .map file. Shouldn't be too hard to do... (another thing to add to my ever growing list of shit :) 

To be honest, I might have a go at banging out some melscript that takes a bunch of triangles from maya and projects them up (or down) to turn them into tri prisms, and then spits out a quake .map file. Shouldn't be too hard to do... (another thing to add to my ever growing list of shit :)

dude... if you did this... my god, it would be amazing.

i really wish there was a way to extrude a triangle to create a brush this way.

but... if you do decide to, would it be possible to have it work for more than just maya? maybe support ASE for full compatibility? 

I'm sure it would be a similar amount of work to write a maxscript version, although I don't have max, and have never done any scripting in it before. 

with quake and terrain though rears its head when it comes to the issue of placing architecture in the terrain. I've been taught that letting brushes arbitrarily intersect each other is bad for quake, which lead me to carefully tessellate my tri-soup terrain around any architectural elements to avoid intersection, which feels precise yet at the same time messy and annoying to do (it feels inefficient as it means you use more triangle brushes). I did it like this in marcher (when a 12-sided stone column butts into the terrain, the terrain triangles all perfectly meet up to each side of the column.

Now though, I'm thinking this is annoying to do and might put me off making areas where architecture melds with terrain. I think also, my OCD had a large part in me doing it like that.

Considering how quake chops up faces into ugly shit anyway, even in a pure tri-soup with no intersection - would it really matter if I just let random architecture intersect the terrain? How did you approach it necros? 

Something that reads an OBJ file of triangles and spits out a MAP file of extruded brushes should be dead simple. Just saying. :) 

"I've been taught that letting brushes arbitrarily intersect each other is bad for quake"

This has never been explained in a way that would convince me it as true. QBSP chops up the world and removes any inter-penetrating geometry. That's what it does. So how do intersecting brushes cause problems? 

Generated terrain is only ugly if you use large grid. And even then its really easy to adjust it the editor to your liking, making it as irregular as you want. Big timesaver.

Willem: precision problems that cause collision errors. Never experienced falling through irregular angled geometry?

There are several model-to-map progs and scripts, but none that I'v tried output geometry that is friendly to shitty quake compilers. Again precision loss, gaps, edges don't match, collision errors.

Q3map2 solves all the problems. But I know that quake mappers are too afraid of technology advancements. 

I've experienced that but I've never found that manually aligning brushes is a magic fix. As often as not, making them intersect MORE will fix it.

And why the hostility towards Quake mappers? 

Willem, i guess that it may produce more faces than is necessary and odd things like tiny sliver triangles, I have no idea really. I did a really quick test to see what happens in two cases: a square pillar meeting some tri-soup. On the right, i just intersect it into the triangles, but on the left, I chop the tris up and carefully stitch around the pillar, making sure the overall topology matches the first case as close as possible.

http://dl.dropbox.com/u/61424391/Quake%20Stuff/trisbutt.jpg

Results shown in r_drawflat. I guess there's not much in it. The one on the left looks "nicer" and has slightly less faces when all the chopping's been done, but I think the only question that needs answering is "will intersecting like this actually cause any problems when done on a large scale?"

Who knows - certainly letting them intersect is a million times more friendly and flexible for the mapper.

Q3map2 solves all the problems. But I know that quake mappers are too afraid of technology advancements.

Cool - let me know when I can use that to compile a working quake .bsp 

well that small test above is too limited to really prove much so i did something larger scale with bigger terrain and more stuff sticking into it. I conclude that Quake chops up the faces of trisoup terrain into such nasty shit anyway even at the best of times, that it really doesn't make a whole lot of difference whether or not you butt other random things into it. 

it's more to do with hull expansion, but aguirre's bsp has a much better expansion algorithm or whatever which handles all kinds of brushwork that would have normally killed the compiler.
in some cases, it might even be pointless to trisoup around intersecting brushwork.

the ruins start map has both fitted and unfitted intersecting brushwork. i built the fitted stuff first but what i started loosing interested, i just started plopping things down into the terrain and when i noticed nothing overly bad happening, i just let it be. (the map sources are available if you want to look) 

guys!

it runs fine in my mac quakespasm engine, but a friend is having trouble running it in his windows qs.

whenever he types -zone 2048 -heapsize 192000 -game ne_ruins, it doesn't run. the game runs with the command -game ne_ruins, but his console in quake tells him 'unknown command' when he attempts typing the heapsize/zone commands.
i know that the - + switches do not function in the quake console, as they only work in the mac qs command line box.
is there a way to enter the command line via windows qs, without having to do it through the quake console?

and lastly: breathtaking stuff necros! 

He can create a text file in the Quake directory and put the whole line inside, eg:

quakespasm.exe -zone 2048 -heapsize 192000 -game ne_ruins

Then name the file for example quakespasm-ne_ruins.bat and now doubleclicking should launch the game properly. It needs to be a .bat, not a .txt, so make sure he has disable the hiding of "known extension". 

taking that one step further:

make a text file called "qs.bat"

in it, type:
quakespasm.exe -zone 2048 -heapsize 192000 %1 %2 %3 %4 %5 %6 %7 %8 %9

now, in a command prompt, you can run qs -game ne_ruins (or any mod you like) and it will always use the extra ram and zone settings.