Tag Archives: Tips

Quake Live Tips

Quake Live is a free, manly game to play. QL is a version of Quake 3 that runs as a browser plugin for Firefox, Safari, and IE. It features a skill-matched game finder, a friend’s system, and other modern features. Think a Lite, browser-based version of Steam. Quake 3 came out in 1999, and people have been playing it on a regular basis since. That’s about 11 years ahead of you if you’re new (doesn’t mean you can’t become excellent fast.)

The following Quake Live tips apply to those games: Quake 3, Quake World, Death Match Classic, Warsow, etc.

Quake Live Tips – The Basics

The point of the game is to control the map, not to get the most frags. Kills happen because other players are trying to take over your territory.

Don’t chase your opponent. Chasing is predictable, and will almost always get you killed if you don’t know what you’re doing.

Pay attention to your opponent. What items are they picking up? Their usual routes (surprisingly predictable,) etc.

Pay attention to what your opponent does when their health is low. They will either become very aggressive and erratic, or change their route and generally keep their distance from you.

Learn to strafe jump. It’s not as easy as in Counter-Strike <1.1, but it’s a skill that you can carry into other shooters (listed above), and is a core part of the game. Quake Live makes this easy with a movement practice mode and video tutorials.

Use a low sensitivity. Mine is 1.5. It’s more accurate, and you quickly learn how much force to give the mouse to flick the crosshair if you need to. You don’t need to do 180s and 360s. Once you become good, you will know where opponents are likely to come from, and have the crosshair always in that general direction.

Use ASDW to move, and bind every weapon nearby. I use R for rocket, Q for rail, E for lightening, F for shotgun, etc.

Learn the maps. Duels are a great way to learn maps. You can also learn a map by deciding on a specific item route to follow, and then following it until you’ve memorized it. Then memorizing another route, and so on. For example, rocket to RA to rail to MG to shotgun to rocket to RA ….

Use the right gun for the job. QL/Q3 has the most balanced arsenal in a shooter. Every gun including the machine gun and gauntlet are useable and very powerful. In some situations a machine gun is better than a rocket, such as when the opponent is very far away.

Quake Live Tips – Beyond Basics

Learn the amount of seconds each item takes to spawn. Then learn to countdown internally exactly when that item will respawn. This isn’t as hard as it sounds. Begin by only focusing on big items such as Red Armor (RA), Mega Health (MG), etc. You have to control the map (items), and also be able to spot what your opponent has, and both require that you know when items were taken, and/or when they will respawn. You can make the timer count up or down via

Control important items. Focus on controlling at least RA, MG, rocket and rail.

Try to predict what your opponent has equipped. There’s a good chance your opponent will have equipped whatever items were in the immediate vicinity. If they’re walking out from near the lightening gun (LG), they probably have the LG out. This is especially true in pubs and when you know your opponent just spawned or did not pick up a better gun. If there’s a common route, like from rocket to RA, and you know the RA had spawned recently, your opponent likely has RA with rockets a’blazin’

Fire at spawn points. QL has a very low invincibility time when you respawn, and you can die again right away. Memorize the spawn points in each map, and shoot at them when you expect a respawn. If you frag someone, and you know there’s a spawn point behind you, turn around and begin shooting. If they respawn at that point, they’ll be welcomed back with a rocket or balls of plasma.

Watch demos (replays.) Get the Firefox demo player and hop over to ESReality.

You have to actually play the game. Playing is how you get good. I put this tip at the end because people who don’t read up to this point, who will close this page and go play, don’t need the tip. People who read through this entire page are more likely to also be the type of person looking for a shortcut to becoming pro at QL – there are no shortcuts. You have to play the game, and enjoy every loss. Experience comes from playing.

Quake Live Links

Quake Live – Official Site

List of command variables

Learning to Program on Your Own

Learning how to code is like learning anything else – You have to do it. The hardest part is figuring out where to begin, and then you need some mechanism to show you that you’re making progress. The latter is important because it motivates you to keep going.

First, have a goal. I initially wanted to make AOL “punters” (apps that kicked other users offline) and malware. I found them interesting. Do you want to program games? websites? Facebook Apps? Apps for OS X?

Once you have the goal, do research on how those apps are made, particularly on the language used, APIs/libraries used, and so on.

When starting, you will be learning a lot of concepts that you will see no use for. If-then statements, variables, etc. You might understand the basic idea of what a variable is, but might wonder – why would I ever use this instead of putting the value in directly? At this stage, it’s important that you remain persistant and just go through the examples/exercises in your book (or those provided by your tutor). I noticed that most people will struggle through the first set of concepts, and then lose interest and quit after seeing that they aren’t doing anything interesting. One day, you’ll be doing something and everything will fall into place. An A-Ha moment.

You’re learning a bunch of stuff that doesn’t really connect with each other. How does printing “Hello World” to the screen eventually become a 3D game? How do I go from a console app to a window app? How does knowing what a variable or constant is translate to a web development project?

It’s a plateau — and I want to stress that this applies to almost anything, not just programming. You begin by learning a lot of stuff, very slowly making progress, and over time you begin to see that you kinda “know” what’s happening behind the scenes of the apps you’re using. After that, learning because easier and quicker. Getting to that level requires persistance.

My Turning Point – Stop Asking “What Should I Code?”

When I first began coding, I had the mentality that I had to “learn how to program” before “making app X” – This is logical but the way I structured in my head was important in impeding my progress. I divided learning how to program and making app X into two separate goals. It was a problem because it migrated me away from the goal of “making app X.” I began asking the wrong question – what should I code to learn how to program?

Instead, I should have been asking – what should I learn next, to reach my goal of making app X? I broke down app X into individual tasks, and then began learning how to do each one. For example, let’s say my goal is to program a game.

If I ask “what should I code to learn how to program?” I will spend a lot of time learning things I might not need anytime soon (or ever), I will get nowhere near reaching my goal, and will become unmotivated and quit before getting there. Instead, I would break down the game into individual tasks (this requires research) and work on learning each one.

Let’s see, I need to figure out how to make a window/draw things on screen. That becomes my new short term goal. I dig deeper and learn that I need to learn the Windows API. I learn that the Windows API is how one draws to the screen. But the Windows API is another thing I need to learn, so that becomes the immediate short term goal. Digging deeper, I realize that the Windows API is just a bunch of functions with some conventions that I need to memorize.

Now my goal is somewhat clearer. I begin reading about the Windows API, making different small apps to make sure I understand what I’m reading. Eventually I am able to draw a window and controls. Great. I still don’t have a game. What’s next? I need to draw graphics. I dig into how it’s done and learn that the Windows API provides a set of functions graphics. I’m familiar with the Win API and so I just begin learning the graphics lib. I make a few dozen apps drawing basic circles, loading bitmap images, etc. Now my goal of making a game is starting to take shape in my head. I can mentally structure how the game will be, minus a few concepts I might not have learned yet.


Small Vim Shortcut for PHP Tags

The short tags in PHP have been deprecated as of 5.3.0. Short tags provided a shorter alternative to the annoying-to-type <?php and <?php echo. Instead, you could use <? and <?= respectively. This was great but it caused problems when working with XML files, and the short_tags option was disabled in the PHP config by default on some implementations.

To make life easier, I created this vim mapping that will expand <? to <?php and <?? to <?php echo. You may change the abbreviation as you see fit. Simply place this in your .vimrc

inoremap <??    <?php echo  ?><Left><Left><Left>
inoremap <?     <?php  ?><Left><Left><Left>

Re-open vim or type use :source ~/.vimrc to reload the config. Now just type <? or <?? in insert mode.

The Gmail Captcha is Optional

When you try to login with bad credentials, Gmail gives you a captcha to fill in before your next login attempt. Not only does this captcha appear randomly (keep putting in the wrong username and it will sometimes appear, sometimes not) (update: now it appears to be more consistent), but it’s also optional*. Just put in your correct username and password, ignoring the captcha, and it will log you in.

I probably discovered this out of frustration, but for the past few months (or years) I thought it was something we all knew until I saw one of my friend’s enter the captcha value. I never actually stopped to think about why a captcha would be “optional” – it’s ridiculous, and I’m probably overlooking an obvious point to this.

Enter the correct name/pass and hit login
Enter the correct name/pass and hit login
Seemingly random captcha
Seemingly random captcha

* I’m not sure why, but some people are saying that they cannot login without entering the captcha. I’ve tried on Swiftweasel and Firefox 3.x/Opera 9.x and 10/Konqueror/Chrome on Linux, and on Safari on the Mac, and have never needed to enter the captcha.

Also worth mentioning, a lot of forms you get when you try to download something are optional. For example, if you try to download Mimer SQL, it gives you this form: http://developer.mimer.com/downloads/downloads_licens.tml?id=528 but you can just scroll down and hit the download button without putting any info in.

Bash Tips for Power Users

Every Geek site needs an obligatory Bash Tips post

Copy Files Securely Between Two Machines

I used to always forget the syntax for this, until I realized that the syntax is exactly like the standard cp command. In fact, you can copy files like you normally would using scp, on your local machine. The following are equivalent:

$ cp file file.orig
$ scp file file.orig

Where they differ is, scp lets you copy files over a network, through SSH. Here’s an example:

$ scp contents.txt silver@ssh.domain.com:/tmp

This will copy local file contents.txt to /tmp on the remote machine ssh.domain.com, as user silver. Here are some more examples:

$ scp draft.pdf ssh.domain.com:

(copy draft.pdf to my home dir on remote machine. username is implied to be the same locally and remotely.)

$ scp swine.jpg rex@ssh.domain.com

(read: This will copy swine.jpg to local machine as a file named rex@ssh.domain.com. To make it go remote, append a : to the address, like above)

scp supports, among other things, compression (-C) and recursive copying of directories (-r).

$ scp -rC code/ ssh.domain.com:/archive/code_02032009

Trying to copy to a directory you don’t have permission to (/usr etc) will fail.

Don’t Get Lost Jumping To and Fro Between Directories

You can use cd - to jump to the previous (NOT parent) dir. For example:

kiwi@localhost: ~ $ cd /usr/local/share
kiwi@localhost: /usr/local/share $ cd -
kiwi@localhost: ~ $ cd -
kiwi@localhost: /usr/local/share $

Another way is using pushd/popd – A Last In First Out (LIFO) stack of dirs.

kiwi@localhost: ~ $ pushd /usr/local/share/
/usr/local/share ~

pushd is like cd but keeps note of the current dir before cd’ing into a new one. The stack of dirs is listed every time you invoke pushd (the “/usr/local/share ~” output you see above.)

kiwi@localhost: /usr/local/share $ pushd /
/ /usr/local/share ~

Stack is ordered left to right, latest push first. If we pop the first dir off:

kiwi@localhost: / $ popd
/usr/local/share /tmp ~
kiwi@localhost: /usr/local/share $

We’re back in the share dir. We can keep popping until there’s nothing left (throws an error):

kiwi@localhost: /usr/local/share $ popd
/tmp ~
kiwi@localhost: /tmp $ pushd /lib
/lib /tmp ~
kiwi@localhost: /lib $ popd
/tmp ~
kiwi@localhost: /tmp $ popd
kiwi@localhost: ~ $ popd
bash: popd: directory stack empty

Working with Long Lines

No need for more Bash shortcut cheat sheets, but here are some useful ones to help you work with long lines.

You can jump to the start & end of a line using CTRL+a & CTRL+e respectively. Example (* is the cursor):

kiwi@localhost: ~ $ echo al the ducks are swimming in the w*

and you want to fix the first word. You can hop to the beginning of the line with CTRL+a:

kiwi@localhost: ~ $ *echo al the ducks are swimming in the w

and now you can jump to the end of the misspelled word “al” using CTRL+Right twice to correct it:

kiwi@localhost: ~ $ echo all*the ducks are swimming in the w

Now ctrl+e to jump to the end of line:

kiwi@localhost: ~ $ echo all the ducks are swimming in the w*

Instead of backspacing every character, use ALT+Backspace to backspace entire words. You can also delete all or part of a line using CTRL+u combo. It deletes everything before the cursor. Likewise, CTRL+k wipes out everything after the cursor. I’ve developed a habit of using CTRL+e CTRL+k to delete lines.

Bash has a lot of ALT commands that let you move and manipulate words. ALT+l and ALT+u will make a word in front of the cursor lowercase or uppercase, for example. A neat one I don’t think I ever used is ALT+\ It pulls everything after the cursor left to the first non-whitespace character. Here’s an example, * is the cursor:


$ my     spacebar is    *sticky


$ my     spacebar issticky

Avoid Retyping Commands & Arguments

ESC + . is very useful. Escape followed by a period will output the argument you sent to your last Bash command. Command calls themselves are outputted if they were invoked without any arguments (popd, ls, etc).

Example, unzipping a file and moving the archive to /tmp:

$ unzip archive-with-a-long-ambiguous-name-03092009-5960-1.2.5.zip
$ mv archive-with-a-long-ambiguous-name-03092009-5960-1.2.5.zip /tmp

In the mv command, the archive name was outputted by pressing ESC+. (full command being mv (ESC+.) /tmp) There was no need to type the long archive name twice.

The argument is taken from your bash history. You can keep invoking ESC+. to cycle back through all your recent command arguments. (history -c to clear)

Try not to forget this; You’ll naturally find plenty of uses for it.

Another way to avoid re-typing commands is CTRL+R. It will initiate a search of your command history. Begin typing, and watch Bash try to complete your command from previous ones you entered.

Command Getting Too Big? Send it to your Editor

Sometimes you begin writing what you think will be a simple command, only to realize that it has grown too complex for the command line, and you wish you were in your text editor.

First make sure your default editor is set. This is either in $EDITOR (export EDITOR=/usr/local/bin/vim) or elsewhere depending on the distro.

Use “fc” to open the last executed command in your editor:

ls -paul --sort=size
... ls output ...

Now the ls line will be open in your editor. But what if you hadn’t executed the command yet? No problem. You’re sending off an email, but quickly realize that the command line isn’t ideal for everything:

echo -e "Dear Santa, \n\n\tIt has become evident that your fat ass is contributing to Global Warming, primarily due to the large quantity of coal you distribute annually. We hereby

No matter where you are on the line, hit CTRL+x, CTRL+e to invoke your editor, which now contains what you were typing on the cmd line.

I always find myself wanting to finish a command in vim, but unwilling to type the first few lines over, especially when I’m trying to write a for loop or any ugly multiline Bash code.

IMPORTANT: Whatever you type in your editor is executed automatically after you quit the editor.
Continue reading Bash Tips for Power Users

How to POST Form Data Using Ruby

POSTing data on web forms is essential for writing tools and services that interact with resources already available on the web. You can grab information from your Gmail account, add a new thread to a forum from your own app, etc.

The following is a brief example on how this can be done in Ruby using Net::HTTPand this POST form example.

Looking at the source (interlacken.com/webdbdev/ch05/formpost.asp):

<form method="POST" action="formpost.asp">
<p><input type="text" name="box1″ size="20″ value="">
<input type="submit" value="Submit" name="button1″></p>

We see two attributes are sent to the formpost.asp script when the user hits the submit button: A textbox named box1 and the value of the submit button, named Submit. If this form used a GET method, we would just fetch the URL postfixed with (for example) ?box1=our+text+here. Fortunately, Ruby’s Net::HTTP makes posting data just as easy.

The Ruby code:


require "uri"
require "net/http"

params = {'box1′ => 'Nothing is less important than which fork you use. Etiquette is the science of living. It embraces everything. It is ethics. It is honor. -Emily Post',
'button1′ => 'Submit'
x = Net::HTTP.post_form(URI.parse('http://www.interlacken.com/webdbdev/ch05/formpost.asp'), params)
puts x.body

# Uncomment this if you want output in a file
# File.open('out.htm', 'w') { |f| f.write x.body }

Sending the value of button1 is optional in this case, but sometimes this value is checked in the server side script. One example is when the coder wants to find out if the form has been submitted – as opposed to it being the user’s first visit to the form – without creating a hidden attribute to send along w/ the other form fields. Besides, there’s no harm in sending a few more bytes.

If you’re curious about URI.parse, it simply makes the URI easier to work with by separating and classifying each of its attributes, effectively letting the methods in Net::HTTP do their sole job only, instead of having to analyze and parse the URL. More info on this in the Ruby doc.

Assuming no errors, running this example (ruby postpost or chmod a+x postpost.rb; ./postpost.rb) yields:

<form method="POST" action="formpost.asp">
<p><input type="text" name="box1″ size="20″ value="NOTHING IS LESS
<input type="submit" value="Submit" name="button1″></p>

In practice, you might want to use a more specialized library to handle what you’re doing. Be sure to check out Mechanize and Rest-client.