I have no idea how such a great open-source game as Teeworlds has been able to exist without me hearing about it until recently.
Teeworlds is a fast-paced realtime multiplayer shooter. You control a small "Tee" which can hold various weapons (hammer, gun, shotgun, laser-rifle, rocket launcher, ninja-sword) while running and jumping around frantically on the map, trying to frag as many other Tees as you can before you're killed by some other guy. Easy, eh?
There's are many game servers to choose from, as well as various game modes (death match, team death match, capfure the flag and some unofficial "mods"). You can join servers on the Internet, or create your own server, be it a public one or a LAN server.
Usually I would suggest apt-get install teeworlds, but for now the packages in unstable are an older 0.4.x version, whereas upstream released a much-improved 0.5.1 version. I have already filed a bug and I'm optimistic there'll be a new version in unstable soon.
In the mean-time however, you can manually build the game from source via:
$ apt-get install zlib-dev libsdl1.2-dev (maybe also libgl, libglu, and python, if not already installed) $ wget 'http://teeworlds.com/trac/bam/browser/releases/bam-0.2.0.zip?format=raw' -O bam-0.2.0.zip $ wget http://teeworlds.com/files/teeworlds-0.5.1-src.zip $ unzip bam-0.2.0.zip $ unzip teeworlds-0.5.1-src.zip $ cd bam-0.2.0 $ ./make_unix.sh $ cd ../teeworlds-0.5.1-src $ ../bam-0.2.0/src/bam release
$ ./teeworlds
You'll obviously need a working OpenGL/DRI setup (check if "glxinfo | grep direct" says "Yes"), otherwise the game will be way too slow. In case you experience graphics glitches and distortions, first exit the game, then:
$ vi ~/.teeworlds/settings.cfg
Change the "gfx_noclip 0" option there to "gfx_noclip 1" and restart the game.
If you use a local firewall as I do, you need to open at least ports 8300-8303 (UDP), even better 8300-8310 for more choice in game servers:
$ iptables -A OUTPUT -m state --state NEW -p udp --dport 8300:8310 -j ACCEPT
Have fun!
Stuff I didn't expect I'd had to type today:
$ dpkg-repack dpkg-repack
Seriously.
Yes, just when you thought the spamming of Planet Debian with "Lenny released" blog posts had finally stopped, here comes another one :-)
Let me join the crowd by saying a great "thank you!" to all the people who made this release possible, especially so the release team who organized everything, as well as the thousands of contributors (in one form or another) who helped shape the new release!
Personally, I'm eager to try out the new Linux 2.6.28 kernel package in unstable now (which have been uploaded today or so, but haven't yet reached my mirror), since they contain mainline wireless drivers for my One A110 netbook, among many other things.
Also, in the next few days I'll probably re-install my NSLU2 ARM box using the latest Lenny installer, following the HOWTOs by Martin Michlmayr (I'll probably write about the experience later). This re-install is long overdue, as I'm currently running the box from an 1GB thumb drive, which works ok, but I'm slowly running out of space. So I'll re-install on a 4 GB (or bigger) thumb drive.
As I wrote quite a while ago, I set up a RAID5 with three
IDE disks at home, which I'm using as backup (yes, I know that
RAID != backup) and storage space.
A few days ago, the RAID was put to a real-life test for the first time, as one of the disks died. Here's what that looks like in dmesg:
raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:3
disk 0, o:1, dev:hda2
disk 1, o:1, dev:hdg2
disk 2, o:1, dev:hde2
[...]
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 4 bytes in FIFO
hdg: dma timeout error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hdg: DMA disabled
ide3: reset: success
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hdg: DMA disabled
ide3: reset: success
hdg: status timeout: status=0x80 { Busy }
ide: failed opcode was: 0xea
hdg: drive not ready for command
hdg: lost interrupt
hdg: task_out_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hdg: lost interrupt
hdg: task_out_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
That's when I realized that something was horribly wrong.
Not long after that, these messages appeared in dmesg. As you can see the software-RAID automatically realized that a drive died and removed the faulty disk from the array. I did not lose any data, and the system did not freeze up; I could continue working as if nothing happened (as it should be).
md: super_written gets error=-5, uptodate=0 raid5: Disk failure on hdg2, disabling device. raid5: Operation continuing on 2 devices. RAID5 conf printout: --- rd:3 wd:2 disk 0, o:1, dev:hda2 disk 1, o:0, dev:hdg2 disk 2, o:1, dev:hde2 RAID5 conf printout: --- rd:3 wd:2 disk 0, o:1, dev:hda2 disk 2, o:1, dev:hde2
This is how you can check the current RAID status:
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md1 : active raid5 hda2[0] hde2[2] hdg2[3](F)
584107136 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]
The "U_U" means two of the disks are OK, and one is faulty/removed. The desired state is "UUU", which means all three disks are OK.
The next steps are to replace the dead drive with a new one, but first you should know exactly which disk you need to remove (in my case: hda, hde, or hdg). If you remove the wrong one, you're screwed. The RAID will be dead and all your data will be lost (RAID5 can survive only one dead disk at a time).
The safest way (IMHO) to know which disk to remove is to write down the serial number of the disk, e.g. using smartctl, and then check the back side of each disk for the matching serial number.
$ smartctl -i /dev/hda | grep Serial $ smartctl -i /dev/hde | grep Serial $ smartctl -i /dev/hdg | grep Serial
(ideally you should get the serial numbers before one of the disks dies)
Now power down the PC and remove the correct drive. Get a new drive which is at least as big as the one you removed. As this is software-RAID you have quite a lot of flexibility; the new drive doesn't have to be from the same vendor / series, it doesn't even have to be of the same type (e.g. I got a SATA disk instead of another IDE one).
Insert the drive into some other PC in order to partition it correctly (e.g. using fdisk or cfdisk). In my case I needed a 1 GB /boot partition for GRUB, and the rest of the drive is another partition of the type "Linux RAID auto", which the software-RAID will then recognize.
Then, put the drive into the RAID PC and power it up. After a successful boot (remember, 2 out of 3 disks in RAID5 are sufficient for a working system) you'll have to hook-up the new drive into the RAID:
$ mdadm --manage /dev/md1 --add /dev/sda2 mdadm: added /dev/sda2
My new SATA drive ended up being /dev/sda2, which I added using mdadm. The RAID immediately starts restoring/resyncing all data on that drive, which may take a while (2-3 hours, depends on the RAID size and some other factors). You can check the current progress with:
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md1 : active raid5 sda2[3] hda2[0] hde2[2]
584107136 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]
[>....................] recovery = 0.1% (473692/292053568) finish=92.3min speed=52632K/sec
As soon as this process is finished you'll see this in dmesg:
md: md1: recovery done. RAID5 conf printout: --- rd:3 wd:3 disk 0, o:1, dev:hda2 disk 1, o:1, dev:sda2 disk 2, o:1, dev:hde2
In /proc/mdstat you'll see "UUU" again, which means your RAID is fully functional and redundant (with three disks) again. Yay.
$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md1 : active raid5 sda2[1] hda2[0] hde2[2]
584107136 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
Btw, another nice utility you might find useful is hddtemp, which can check the temperature of the drives. You should take care that they don't get too hot, especially so if the RAID runs 24/7.
$ hddtemp /dev/hda dev/hda: SAMSUNG HD300LD: 38 °C $ hddtemp /dev/hde dev/hde: SAMSUNG HD300LD: 44 °C $ hddtemp /dev/sda dev/sda: SAMSUNG HD322HJ: 32 °C
Here's a quick HOWTO for using Wine to play Starcraft on a Linux machine.
$ apt-get install wine (as root) $ winecfg
The winecfg (graphical) utility will setup some config file defaults in your ~/.wine directory. Click on Graphics and activate Allow DirectX apps to stop the mouse leaving their window. Also, click on Audio (a dialog will pop up, just click OK). This will autodect your soundcard and setup Wine to use it. Under Drives click Add (this will add D:) and change the path to /media/cdrom, so that Wine knows about your CD-ROM drive. Finally click OK to close winecfg and save the settings.
The next step is to insert the Starcraft CD-ROM into the drive and start the installer using Wine:
$ mount /media/cdrom (as root) $ wine /media/cdrom/setup.exe
Follow the instructions in the installer until the Starcraft install is finished (you'll need your CD key number), then exit the installer (don't start playing Starcraft right away).
The next step is to get the latest patch and get rid of the need to insert the CD-ROM every time.
$ wget http://ftp.blizzard.com/pub/starcraft/patches/PC/SC-1161.exe $ wine SC-1161.exe
After the patch is installed click OK and Starcraft will be started (very annoying). Leave the game again. We'll get rid of the CD-ROM requirement now:
$ cp /media/cdrom/install.exe ~/.wine/drive_c/Programme/Starcraft/StarCraft.mpq
That's a pretty big file, it may take a while. You might have to change "Programme" in the path (I have the German Starcraft version). That's it. You can now play Starcraft (without needing the CD-ROM) using:
$ wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe
A good thing is, it even works nice and fast with the open-source nv NVIDIA driver (no need to install the proprietary driver).
I noticed one very annoying "bug" with the mouse behaviour at first. The mouse would sometimes just get stuck during the game (which is a total disaster of course, if you're in the middle of a fast-paced game). Left-clicking somewhere would "unstuck" the mouse, but it's still very bad. After many, many hours of reading bugreports and trying various patches I finally found out the root cause for the problem.
It's somehow related to my window manager (IceWM); whenever you move the mouse to the bottom of the Starcraft screen (where the IceWM status bar is, even though it's not on top or even visible, and even though Wine/Starcraft runs in full-screen mode!), something funny happens with X11/IceWM and the mouse gets stuck. I haven't yet found out if/which IceWM option could fix this behavior, but I have a small work-around. Just start Wine directly on a second X11 server with Starcraft (without any window manager being involved):
$ xinit -e '/usr/bin/wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe' -- :1
No patches needed (stock Wine from Debian unstable works fine, that's version 1.0.1 right now). I hope this saves other people some debugging time...
In order to play the Brood War expansion you can follow a similar procedure. Insert the Brood War CD-ROM, then:
$ mount /media/cdrom (as root) $ wine /media/cdrom/setup.exe $ cp /media/cdrom/install.exe ~/.wine/drive_c/Programme/Starcraft/BroodWar.mpq $ wget http://ftp.blizzard.com/pub/broodwar/patches/PC/BW-1161.exe $ wine BW-1161.exe
After you've done that, you can start both Starcraft (classic) and Brood War via:
$ wine ~/.wine/drive_c/Programme/Starcraft/StarCraft.exe
You will be asked in the game whether you want to actually play the Starcraft or Brood War variant.
As of version 1161 for the Starcraft / Brood War patch, there's a new game option which can drastically lower the CPU load while playing Starcraft. First fire up Starcraft and start any game. Then, press F10, select Options / Game speed, and check the "Enable CPU Throttling box". You'll probably need to restart Starcraft afterwards.
Multiplayer LAN games work just fine (didn't try BattleNet that much yet), but if you use a strict firewall rule set as I do (which blocks most ingress as well as egress traffic) you have to open a number of different ports. Here's what I added to my firewall script:
$IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 6111 -j ACCEPT $IPTABLES -A INPUT -m state --state NEW -p udp --dport 6111 -j ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -p udp --dport 6112 -j ACCEPT $IPTABLES -A OUTPUT -m state --state NEW -p tcp --dport 6112 -j ACCEPT # BattleNet
Starcraft works just fine on various netbooks; for instance, I tested it on my One A110 netbook (VIA VX800) with 256 MB of RAM, and the whole .wine directory being on a USB thumb drive (thus slow; but my internal SSD was already full). I bet it'll also work fine on the
Audio works fine, and game speed is quite OK, the only minor "problem" is that you should use an external USB mouse, the touchpad is just too small (and too slow to use) for such a fast-paced game.
The full Wine package (and all dependencies) consume quite a lot of space on the (usually very small) hard drive or SSD of a netbook, but luckily you can get away with only a minimal Wine install for playing Starcraft:
$ apt-get install wine-bin libwine-alsa (as root)
That's sufficient, and a lot smaller than installing the full wine package.
Update 2010-06-23: There's a contributed Hungarian translation now (thanks!)
Update 2009-03-04: Added info about patch 1161 and CPU load reduction.
Update 2008-12-19: Added Starcraft-on-netbooks section.
Update 2008-12-13: Added BroodWar and multiplayer info.
Recent comments
20 weeks 6 days ago
47 weeks 13 hours ago
1 year 2 weeks ago
1 year 2 weeks ago
1 year 3 weeks ago