The state of Pingus

Pingus has been in development since back in 1998, that is now almost ten years ago (4.Nov 2008 will be the 10th anniversary to be exact) , so how far are we now? Truth to be told, not very far, there really hasn't been much development going on for ages and quite a few parts of the code still could need some cleanup, there are also still critical features missing and of course when it come to content there still is only a single island and a tutorial one as that. So what is missing exactly? Here we go:

• resource system, this got basically "#if 0"'ed when moving from ClanLib to SDL, nothing earth shattering, but it does waste a bit more resources then it should and doesn't react smoothly on errors
  
• delta-drawing, Pingus does currently full screen refreshes, that however kills performance on low-spec devices, namely N700/N800 and OLPC, this is a real problem, not just a theoretical one
  
• multiplayer, this has been on the TODO since forever and also was already implemented a long time ago, but it never got finalized and never made it into a release (that is hot-seat multiplayer, there never was real multiplayer network stuff)
• online updates/submissions, it should be possible to submit and download level files from via the GUI
• option menu, sounds simple and kind of isn't all that hard, but it hasn't been done, code is there, but not final and never made it into a release
• GUI rework, the GUI as it is now doesn't work all that well, i.e. the design is simply inconsistent, in-game we have those glassy-objects, in the menu we have blackboards, this really should be one way or the other and consistent, however the blackboard design is also problematic, since it doesn't follow normal gui conventions, sometimes the blackboard itself is the button, other times a button is represented with a checkbox, the GUI also has an annoying event handling issue
  
• new island, my current plan is: ice, forest, volcano industrial, space, all other graphics will end up as contrib levelsets
  
• highscore tracking and display, the game should keep track of how good or bad a level was solved to encourage better solutions
• demo recording/playback, was available once but got "#if 0"'ed when porting to SDL
• level conversion, the conversion from old XML format to new S-Expr format hasn't been tested much, the scripts are there, but there is no guarantee that they will work
• traps, neither the main Pingus game nor official levelsets currently use traps, I don't want official stuff to be to bloody, so there is still plenty of room for new designs
• Unicode/UTF8 support
• dynamic screen resizing, already partly there in the form of --allow-resize, but only usable in the editor
• MacOSX version, the game should compile on OSX, but it hasn't been done, so we don't have a download for a MacOSX .dmg
  

Thats not all, the TODO file contains more issues, but this should be the main issues. Beside the stuff that should be done, there is however also stuff that should not be done:

• RGBA support, Pingus currently doesn't make use of alpha-blending, mainly for speed issues on slower machines, while it would be possible to fix that without ruining the speed on slower machines it seems to little an advantage to care about, it would also require to change all graphics
  
• OpenGL support, this got kicked out on the switch to SDL, while it is a nice to have, in terms of speed the delta-drawing should provide similar amounts of speed up, scaling might also be implemented in software and even required for the OLPC, if anybody wants to implement it, I won't stop him, but I don't consider it important enough to worry about
• an endless flow of new stuff, the goal is really to get this thing done, not to continue to drag it around forever, users might contribute additional contrib levelsets, but the main-game should stay untouched once finalized
  

The main goal right now really is to get Pingus done, not to update it to current day tech, while possible, that is one of those things that all to often traps games in an unending cycle of never getting anything done.

Some thoughts about FreeMech

So first, what is FreeMech? FreeMech is a game concept/idea that I have been toying around for quite a few years. The game at its core shall be a mech simulation, something not to far away from the early MechWarrior titles for the PC, however it is not intended to be a clone of either those or other mech titles.

The idea behind the game is not just to create a game in which the player can control a mech, but to create a complete battlefield simulation, allowing the player or his teammates to take control over all vehicles and command structures available on the battlefield. Everything from foot soldiers up to orbital laser cannons. The goal is to create an interactive world that doesn't have to many artificial borders. You should be able to walk were you want and only be limited be the terrain layout and your fuel supply. You also shall be able to change your vehicle and interact with other NPCs at close range. The focus shall be on making the game world believable and behave realistically. If you control a 100 ton mech, it shall fell slow and heavy. It shall be a complex machine with parts that can break and be replaced, be it weapon systems or cockpit instruments. Your weapons will be limited in ammunition and energie. If your mech breaks, you shall be able to leave it behind and continue on foot. The game shall be free of artificial rules, such as experience point systems or other artificial ways of leveling up.

Some features I would like to have in the game:

• a virtual 3D cockpit, fully interactive and fully destructible
  
• ability to enter or leave vehicles of all kinds
• the ability to walk around on foot
• a realistic damage system, one hit can kill a foot soldier, a mech might get damaged and his system might fail
  
• very different kinds of vehicles, from motorbikes over jeeps, to tanks to mechs to orbital lasers
  
• a dynamic and persistent campaign that simulates a complete war from start to finish
  
• missions that take place in the context of the campaign, ending a mission will not reset the battle field
• real 3D terrain, not just a heightmap, so that one can have overhangs, cliffs, caves and other natural structures
  
• day and night cycles
• multiplayer with a heavy focus on coop and not so much on vs play
  

Why create this game? Because there really isn't anything close to it around. Operation Flashpoint gets quite close, but portraits a current day war, I want to give it a sci-fi edge, expand it with a dynamic campaign and also give a stronger focus on planes and helicopters.

Is there a chance that this game will be finished or finished in some reasonable time space? Not really, but I might still try it, not to soon, since Pingus, Windstille and SuperTux still keep me busy, but after that it is likely that I move on to FreeMech, which name will of course change.

So how will it look like?

• simple mech sketches
• a mech rendering
• some old 3d models
  

BTW. This is really kind of old stuff, I have been thinking about it for years and those pictures above are already two years old. So this is more of a "things I still haven't even started to implement", then a "things that will be released real soon".

How to eject a usb harddrive that contains LVM?

Documentation seems to be lacking a bit on the common task on how to eject a normal USB harddrive with LVM on it, so here it goes, without guarantee for correctness:

1. umount all the directories on the drive as usual
2. Get rid of the volume groups on the drive via: vgchange -a n /dev/storage_usbhd
   
3. Spin the drive down via sdparm -C stop /dev/sde
4. Pull the USB-Plug
5. Done

Some more notes:

• neither eject nor eject -s work, they don't spin the drive down or remove LVM VG
  
• when you don't do a vgchange -a n the Volume Group will stay active and you won't be able to plug the drive back in, because the device names will change and your Kernel will get pretty confused, so don't do it
  
• you of course have to adjust the device and volume group names to fit your setting
• spinning the drive down might not be strictly needed, but gives a warm and fluffy feeling
• you can reactivate the drive via vgchange -a y or by pluging it out and back in, it should spin up automatically
• if your drive goes into auto sleep a while true; do touch /file/on/usbhd will work around the problem, you can't adjust auto-sleep with hdparm
  
• I have no idea if it is save to pull the powercord without first pulling the usb cord
  

Quick way to detect which process is blocking a mountpoint

All to often when you want to unmount something you get this little error message as response:

$ umount /mnt
umount: /mnt: device is busy

Not exactly very helpful. A call to fuser or lsof doesn't work very well either. Not sure what is wrong with fuser, but sometimes it simply doesn't report a proper answer even so the device is busy. lsof on the other side works, but is very very slow, it simply not fun to use. Luckily there is a quick workaround:

$ ls -l /proc/*/cwd 2> /dev/null | grep -i mnt
lrwxrwxrwx 1 ingo ingo 0 2008-03-02 03:20 /proc/6828/cwd -> /mnt

This gives you the process blocking a directory pretty much instantly. The 6828 here is the process id which you can then kill or force to another working directory. This of course only checks for the current working directory, not all open files, but for most cases this is really all you need.

There is of course also 'umount -l' which will "unmount" something even if it is blocked, the trouble with that is that it won't actually unmount anything, it will just look like that, so a DVD still won't eject when using 'umount -l' until the blocking process is actually gone.

PS: It is kind of surprising that Linux CD/DVD handling still sucks as bad as it did 10 years ago.