Is there a pre-made texture wad featuring all the textures from Quake, Rogue and Hipnotic? I had been using one called q.wad that claimed to be, but I got around to finishing Rogue and realised there were many textures there that weren't in the .wad. 

Hipnotic WAD
Rogue WAD 

I've updated my FGD file for version v0.15.9 of Ericw tools so you can now set phong on brush models and projected textures on lights.

https://dl.dropboxusercontent.com/u/33279452/quake4ericwTools.fgd

Tested with J.A.C.K steam release 

Too many vertices (65579 > 65535). Recompile with the "-bsp2" flag to lift this restriction.

is this bad? is compiling in bsp2 a bad thing? 

Is your map sealed? If not, then seal your map and the problem will go away.

If your map is sealed, then it usually means your map is bum-splashingly large. This is not generally a problem now, and bsp2 is not bad, but it means people can only play it in bsp2-supporting engines. Is that an issue today? I doubt it. If something thinks it is, I'd like to hear reasons. 

If something thinks it is

If *someone* thinks it is 

Thanks for clearing that for me! 

Are there any basic map scripting guides? I'm wanting to make a brush (or rather a group of brushes) move 64 units while rotating so that it appears to be rolling out of the way. Attempting to search for this turns up a lot of unrelated results, or stuff to do with HUD scripting for Quakeworld. 

Rotating brushes are not a feature of vanilla Quake. You'd need to use the mission pack Scourge of Armagon or another mod that has the same feature.

Hipnotic quake-c (original release 3.12.97) - with compiler warnings fixed. A great mod code base if you want: rotating brushes / doors, water swell, rubble, clocks, earthquakes, etc. Featured in "Scourge of Armagon" - Mission Pack 1. NOTE: any code that requires models / sounds must be modified or you must acquire the mission pack.

http://www.moddb.com/groups/qc/downloads/hipnotic-quake-c-release 

Ah, in that case I might just move the brush rather than delving into this for my first map, it's only for a secret, so digging into this to add a little bit of detail rather than focusing on the map itself is missing the forest for the trees. Although I'll certainly have a look once I become more adept at making maps.

If I shift into stuff more pertinent to actual design, the best kind of secret seems to be one where the player notices a potential rocket/nade/slope jump, tries it and is rewarded both for being observant and having the ability to make the jump. But when that isn't on the table, is it best to make the reward for finding a secret visible to make them start hunting for it? Originally I had the key hidden behind an octagonal panel, and the key could be seen around the edges, but I'm unsure whether it's better to directly signpost secrets like this or just to create interesting areas in the map that prompt investigation, that then leads to finding a secret. It probably doesn't matter as much for little ammo caches and the like, but for something like a key that will unlock a sizeable secret or the only LG/RL available in the map I'm not too sure which approach is best. 

1. I once had documentation on the amount of map unit the player can traverse per second, when he jumps, how he climbs stairs, anybody still has it?

2. Can sky brushes be turned into func_doors, especially func_door_secret? 

I'm assuming you're wanting to hide a secret in the sky rather than actually move the sky brushes that seal the map. You should be able to make a "fake" sky brush that has a space behind it in order to hide something, as you can see in the linked image any brush that isn't actually part of the skybox but has been given a sky texture will just blend into the skybox (here I removed the bounding skybox so it's visible): https://s30.postimg.org/5cjbru1q9/spasm0000.png

If you're actually wanting to move the skybox that seals the map I'm fairly sure that's impossible because a door is considered a brush entity, and in order for the map to be built no entity can trace a line into the void. 

the best kind of secret seems to be one where the player notices a potential rocket/nade/slope jump, tries it and is rewarded both for being observant and having the ability to make the jump.

Err, I would disagree completely. Very few maps hide their secrets in areas accessible only via rocket/grenade-jump, and I would say a secret should be accessible in some other way. Rocket jumping and especially grenade jumping are advanced player skills that are used for speedrunning and sequence breaking. They shouldn't be required by any area of your map, including secrets, for at least two reasons:

1) If your map requires specialised/advanced movement skills, you're excluding a large number of players.

2) Because rocket/grenade-jumping are tricks used in sequence-breaking, there is the implicit assumption that the designer would not require them. Hence even players who are able to do these jumps would often refrain from using them when playing through a map, in order to experience the map as intended by the mapper. So someone might spend a lot of time looking for the "correct" way of accessing a secret, despite being able to rocket-jump to it. So if your secrets require rocket/grenade-jumps, you're bound to frustrate/annoy certain players.

The same would mostly apply to slope-jumping, but it's a slighly different animal. On one hand, many players may not even know that slope-jumping is a thing in Quake -- so it's even more "advanced" in a sense -- but on the other hand, it does not damage the player, so it carries less risk than rocket jumping. It is something that may in theory even happen by accident. So you could, if you design your map well, get players to slope-jump even if they never knew if was possible. There are a few maps that do exactly that -- but you really need to know what you're doing as a mapper. I would say that if you're still figuring out good map/gameplay design, refrain from requiring any trick jumps in Q1SP. 

This is what I've been doing, I'm glad you confirmed me what I'm intending to do works. Thanks! 

is it best to make the reward for finding a secret visible to make them start hunting for it? Originally I had the key hidden behind an octagonal panel, and the key could be seen around the edges, but I'm unsure whether it's better to directly signpost secrets like this or just to create interesting areas in the map that prompt investigation, that then leads to finding a secret.

In my conceited opinion, little glimpses of items that are not directly accessible but tease the player are cool, so if you can easily do that in your map, I'd say go for it. It's not crucial, though, so if it would e.g. ruin the aesthetic of the area, there's no need to force it.

The important thing for me as a player, whether or not the secret is "signposted" by a visible item, is that the solution to the secret should make sense, and not be completely random (e.g. a secret door or func_illusionary that is in no way visually differentiated from its surroundings).

interesting areas in the map that prompt investigation, that then leads to finding a secret --> you can't go wrong with this, I think (with or without a teasing item). I personally love these kinds of secrets and am always a little disappointed when I explore around and am not rewarded. I know that some mappers will look at how their beta testers play through their map and which nooks and crannies they tend to discover while exploring the map, and then add secrets there. 

Yeah, I just want to agree wholeheartedly with total_newbie, because this is also a pet peeve of mine.

The overwhelming problem with trick jumps - as total_newbie says - is that more often than not, you can use them to utterly break a map, because map designers typically do not do extensive QA to determine all the ways that rocket/slope/grenade jumps can break the design, so players should assume that if they are trickjumping around, they may be breaking everything anyway, and any hidden areas found may not actually have been intended to be found that way by the designer.

On the other hand, there may be a case for doing it if the mapper specifically states that trickjumping is a valid way to play the map, but you'd have to communicate that to the player clearly somehow, and it will still probably annoy people who aren't the l33t speedrunner type. 

It is good to experiment though, something not so relevant might become relevant if it is expressed in a right way.. maybe making circular shaped pillar "J" and on top of it secret weapon or something. But remember make it possible, that player can jump on top of it without using slope jump skill, but that would be the first possible "easy slope secret" if you're making more maps that would extend that idea further.

I think some player's might try to run against that J-shaped pillar and press jump accidentally at the right moment and angle, and then possible learn that nice trick first time. Make the pillar small that it looks like player could barely jump on top of it, that might strive players most likely jump against it and try running. 

 

Isn't slope jumping in id1, in e4m1? That makes it seem pretty legit. 

I used sky textured doors (or maybe func_walls) to hide monsters up in the sky in Castle of Oblivion. I remember testing it in an early version of Fitzquake and the sky textures didn't animate, but that was fixed in later versions. 

Isn't slope jumping in id1, in e4m1?

I think you're right.

To be honest, I still think requiring trick jumping for secrets is a bad idea, but an even worse idea is me being all preachy about it, so I'm gonna change my advice to "just do whatever you think is cool". 

I absolutely disagree that building maps to facilitate or encourage rocket jumping should be off-limits. In fact it's a pet peeve of *mine* that while rocket jumping is such a well-known, recognized mechanic, there are only a handful of single-player maps that are built with it in mind. Not that I think every map should require it, but just that considering how many maps are out there I think I could use more like digs07.

I agree with Kinn that it would be a good idea to explain in the readme that your map requires rocket jumping, or state that there's a "super secret" that requires a rocket jump to access. It's really unfortunate that, as Kinn states, most mappers seem not to care about this extremely cool mechanic, and it has resulted in players assuming it's only a way to "break" the map.

I do enjoy "breaking" maps with rocket jumps if I see an opportunity, in all honesty, but there is so much potential to make really cool levels built with the skill in mind. Might make a few quick proof-of-concept maps after I finish my QUMP entry. 

The moment you begin building a map where rocket jumping is an intentional means of progression, players will start using rocket jumping as if it was an "allowed" mechanic in maps where it wasn't.

"I can't find any way to get up, guess I need to rocket jump! *breaks progression and gets annoyed at "the map being unfair* "

This isn't me theoretizing either, it's already happened: https://www.youtube.com/watch?v=RDCtyDycIOI&t=36m27s 

I don't think anything in a single player map should require a rocket jump.

I generally build things in a way that it will be obvious to the player when they are not supposed to be able to get somewhere. If they want to ignore that, it's not a problem. No clip is easier though.