Thanks message board! Anyway, you get the idea... 

Hm, something ate my post.

That is NOT a secure password. A combination of words is not secure unless the service restricts login attempts. Even more so if they are all lower case.

A secure password has various symbols in it, is not readable like that. Use characters like !"�$%&/()=?`*'_:;

Everyone should really use something like http://www.keepassx.org/ (not some online service for heaven's sake) to generate and maintain your passwords. I do not know 10% of my passwords, I only copy and paste them. 

thanks for that link spirit. looks useful

interestingly i tried my old password on this page and the 'online attack scenario' reported a time of 46.68 centuries. i suspect brute force isn't the only way of getting in... 

1.38 thousand trillion trillion centuries 

So not TOO long then. 

Spirit

I use a password program and generator as well but the idea behind the long string of words IS a solid one. Words strung together without spaces is just as good as anything with random symbols and crap sprinkled through it. Just as hard to crack and easier to remember. 

rj make sure you check your logs and or contact your host to actually know what happened. 

and it turns out they got in with zero failed login attempts which pretty much rules brute force out of it, after all that (unless there's some way of downloading the login info and doing it offline)

i can't rule out possible malware on a past windows install though. in which case i'd be at fault for keeping the same password for ~6 years, regardless of how hard it would have been to crack :)

morals learnt, etc 

Never use your luggage combination as your password... 

I'd be willing to bet that very few "hacks" these days are done by brute forcing passwords. It's generally done via database leaks and/or malware and/or social engineering. 

Here's an interesting quote from teh Carmack from last summer's E3, regarding Quake 5. I imagine this is old for those of you who follow the news more closely than I do, but it's the first I've heard of it:

"We went from the Quake 2 and the Quake 4 Strogg universe. We are at least tossing around the possibilities of going back to the bizarre, mixed up Cthulhu-ish Quake 1 world and rebooting that direction.

"We think that would be a more interesting direction than doing more Strogg stuff after Quake 4.

"We certainly have strong factions internally that want to go do this.

"But we could do something pretty grand like that, that still tweaks the memory right in all of those ways, but is actually cohesive and plays with all of the strengths of the level we're at right now."

http://www.eurogamer.net/articles/2011-06-23-john-carmack-recounts-quake

I have to admit the idea of this rumples my pantaloons in the best possible way. 

http://www.youtube.com/watch?v=N2TsUWTEeVk

pewpew! 

another one of the greats. 

Gmsp3 is one of my favourites and I play it now and then.

I guess that's the intended way from the silver key although you can also slope jump back up to the castle door directly.

Would you consider considering gl_polyblend 0 for water heavy maps? Underwater visibility is almost 0 in the captures (which I otherwise enjoy and subscribe to). The drawback being, I believe it removes powerup glow as well. 

That map was so fucking awesome in so many ways. His previous map was good, but GMSP3 was near perfect. Amazing architecture everywhere, terrific flow and some of the best classic Quake gameplay ever.

Shame he never finished GMSP2. Anyone know what happened to him after he left the Quake scene? Did he go into game dev or anything? I hope he didn't sell his soul and become a lawyer or something (unless he's planning to use the money to fund more maps later :) ) 

he really got the scale of Quake. It's something I have a bit of a problem with as I end up making stuff a little too small and cramped a lot of the time, but looking back on it via that video, the scale in GMSP3 was spot on. A great size for gameplay whilst at the same time having lots of nice detail and not being too chunky and shit. 

Something that should go without saying, but as a reminder: When you release a map, make sure it's compatible with coop mode!

1. The most important thing to remember, apart from the coop starts of course, is ye olde item bug that prevents weapon pickups from firing their targets. So instead of making the weapon item target anything, especially if it's critical for progression, put a trigger_once around it instead. Keys and runes fire their targets just fine (though I'm not sure if they only do it once), so it's probably best to use a trigger_once as well if there are multi-use entities among the targets.

2. Keep in mind players can die and respawn at the start. Sometimes this can be problem if certains doors close when a player enters an area - so try to add extra triggers on the outside that open such doors and allow respawned players to enter, or open teleporters.

3. Not vital, but neat (not only for coop): shortcut teleporters to bypass parts of the map that have already been cleared. It sucks having to run all the way through the level after dying. Of course this won't give you back the weapons. Or if you fought your way up some building, it's nice to have a teleporter open at the bottom in case you fall down. 

Is coop really a consideration for Quake these days? How many people will play a map in coop mode to make it worth the effort? :) 

How many might play Coop if it worked well? 

True, not many people will play coop mode. But the few things I mentioned don't require too much effort really. Just a few things to be kept on the top of one's head when editing.

I mean full coop support with extra modifications - meaning gameplay tweaks that require actual cooperation - would be neat, but here you could indeed ask if it was worth it. Pretty much like deathmatch settings (am I the only one who still adds them to a SP map?). 

My maps are mostly linear and very tightly controlled, so coop support would be a massive amount of effort and probably not work that well anyway.

It just not worth it imo. I'd rather spend time creating a map specifically designed for coop. Looking at all the traps throughout a map and trying to build in support for dead players returning or making sure they're all in the trap etc. Bugger all people will play my map anyway, and even less would want to in coop :p

As for deathmatch, maps not designed from the ground up for deathmatch pretty much suck. And large maps won't load into QW clients anyway iirc :E 

Now the speed at which we connect to the internet is much faster than when Quake was released, is netquake viable foor coop?

I will personally always add coop support to my maps regardless of how many people play. Compared to building the map in the first place, adding coop support is trivial.

Would be awesome if some modern engine like Fitzquake/QuakeSpasm supported a modified QW protocol for coop :) Guess that would be a lot of work :/ 

Why not.

I've been toying with the idea of making a much more complete coop mode as well.

Having players respawn nearby to each other, changes to the rules for collecting keys and so on.

Making it more friendly to play and less likely to break, basically. 

The base coop support should be built into the engine so that all SP mods can be supported. Is that possible?

I had lots of ideas for making maps work better in coop mode, such as unlocking weapon cabinets and teleporters in the start area as the players get weapons and enter new areas. If that could just be done in an engine mod that allows the server or players to configure how much assistance to give them, along with perhaps a few extra settings to increase enemy health or whatever to make coop harder it would be pretty awesome. 

Sort of, but we'd be doing it under our own qc base, so unsupported entities would get lost.

We did include wrappers and so on for backwards compatibility to Quoth and Nehahra, but this essentially converts a map to RMQ.

More complex trigger mechanisms and so on will differ and be hard to translate - they have to be recreated from scratch - so we wouldn't want to shift dev focus that much.

The RMQ codebase has migrated a great distance from id1 and is full of dependencies now - damage calls etc. all carry additional information, making using only part of the code, or turning some of it off, complex.