26/06/2005 @20:19:25 ^22:20:38

Do I conform sufficiently to the ideals of nonconformity?

The eternal worry of goths, punks, ravers, hipsters and all scenesters of all retarded subcultures everywhere

ARSE, INCORPORATED

I'd like to take a break from the usual litany of obsession with a 12-year old game to tell you about how I have found myself confounded by a subtle bug in rsync. In January, I purchased a few bits of hardware including a second attempt to add a large hard disc for the purposes of making live backups of my files (the first, in May 2003, similarly never happened and then the disc itself ended up as caco's primary disc a few months later)

I'd found the page on snapshot backups with rsync and decided to use it, but I put off actually doing anything for a long time because I knew I'd have to write quite a complicated script to get it to work how I wanted. Since my mind never formed a sufficiently complete plan on how to do this, it never got started. But then somehow or other I discovered rsnapshot. It seemed to be the script I hadn't written, and a lot more besides!

OKAY, GET ON WITH IT, WHAT'S THE PROBLEM

After rotating previous backups away, rsnapshot first uses cp -al to make a copy of the most recent backup using hard links so they don't take up any disc space. It then updates the current backup using rsync commands to only update the changed files. In essence they look like this

rsync -a --delete --relative /home/ backup_point
rsync -a --delete --relative /etc/ backup_point
...

where backup_point is an rsnapshot-specific thing which will look something like /backup/hourly.0/localhost/. Note the use of both --delete and --relative and the fact that the source directory has a trailing slash. rsnapshot is very insistent on trailing slashes for directories.

However there is a bug in rsync 2.6.4, fixed in 2.6.5, which causes it to behave badly in exactly the circumstances it is called by rsnapshot. In particular it never seems to delete anything so the amount of disc used by the backups just grows and grows as temporary files that should expire from the backups never actually do (e.g. if you rename a file the backups will forever contain two copies of the file, under the old and the new name) It's not fatal but as you might expect I find this incredibly annoying and wasteful. The bug - at least I think this is it - is in flist.c, and was fixed in revision 1.292 (diff)

Of course the final irritation is that rsync 2.6.5 wasn't released in time to make it into Debian Sarge which was released earlier this month. Now I'm not about to carry on tracking the testing distribution, Etch or whatever it is called, since the most likely time for it to break really horribly is in the first six months or a year after a new stable release. And I don't think this thing is critical enough that they'll patch the version in stable, it's not a security bug (although when I was testing things I found it can delete things from the destination that it is not supposed to, with the trailing slash. It could be a higher priority bug than normal)

There are at least three solutions/workarounds, but I don't like any of them.

Meanwhile, my backups directory continues to grow unchecked, bloated by things that should naturally expire from it...

25/06/2005 @07:26:14 ^10:32:36

damnation! is there anything i can post about that isn't doom and hasn't just been posted by somebody else!

Well, no, it would seem not. I was going to mention how there was a tornado in Coventry yesterday, and post that link, until df copied it into #warwick. Now it just looks like I'm stealing links. Also I was going to post about the ridiculously loud thunder that woke me up after only one and a half hour's sleep yesterday morning, until Stik said he had just posted it too.

So, I give up. Here's some more shit about Doom...

How to fix PrBoom 2.2.6

I must report an injustice in my review of Star Wars Doom last month. I said that the Dehacked patches confused killcount and itemcount. This has been demonstrated to be untrue. The problem is instead that the Dehacked patch loader in PrBoom 2.2.4 misinterprets the flag bits it is given, and sets item count when it should set kill count.

The way I found this out was that I have been playing the much-anticipated megawad Scythe 2 which came out a week or two ago. I guess I'll do a proper review when I've played all of it but I will happily recommend it to you now. It includes a Dehacked patch that creates a couple of new monsters, and having encountered one of them I noticed it was showing up as an item on the map cheat and not counting towards kills.

(Aside: Dehacked was a program that, before the Doom source code was released, would modify certain data tables found in doom(2).exe allowing you to make new monsters, weapons etc. Given its very nature was an unbelievable hack, it was impressive that it worked at all, let alone worked so well! Of course it was totally obsoleted by source ports, but since many famous wads relied on patches for correct operation many ports introduced a compatibility layer so that the patches could still be used)

I dug out the 2.2.6 source code, compiled it, and ran it as a test. Guess what, it fixed this. Of course 2.2.6 also fixes a number of other things, for example the patch overflow check that causes 2.2.4 to kill itself at the end of Doom E3M3 no longer happens. In fact 2.2.6 has been out for a year so why haven't I upgraded before?

THE LIVE MONSTERS COUNTER

Ever since Doom 2 when the archvile was introduced the problem of getting more than 100% kills has been around. Put simply, you kill a monster, the vile resurrects it, you kill it again. You get the kill counted twice, and if you go on to kill the vile and everything else, end up with more than 100% kills at the end of the map. I am anal enough that a percentage greater than 100% bothers me, but there's a more justifiable reason that it is a bug. It is to do with recording maxdemos.

Suppose you're trying for 100% kills but get resurrections. The kills counter thus says you've killed all the monsters, but you haven't, because of counting the kills of resurrected monsters twice. Imagine you do this unwittingly in a demo recording attempt, on which you've already spent weeks. After dozens or hundreds of attempts you finally manage to pull it off. You proudly release your demo... only to have it pointed out that there are missed monsters and it doesn't qualify. Screaming hairy ab-dabs!

I solved this annoyance in DIY a long time ago, firstly by increasing the global variable containing the number of monsters on a map (which is precalculated on level entry) on a resurrection. That didn't work though; if you happened to be using savegames, on reload the total number of monsters was recalculated, and resurrections were forgotten. So rather than change the savegame file format to save the counter and probably cause all sorts of problems later I instead made it reduce the player's kill count, which obviously is saved, upon a resurrection. This works fine in single player when there's only one player from whom to take away the kill, so you don't have to worry about which player to whom the kill was attributed. Since my Risc PC wasn't (and still isn't) networked I didn't see it as a problem.

PrBoom 2.2.6 solves the problem differently. It introduces a new global variable, the live monsters counter. Theoretically, instead of playing until your number of kills equals or exceeds the total number of monsters given, you play until the number of live monsters reaches zero. Obviously it is reduced on a kill; it increases on a resurrection, a boss brain spawn, or a Nightmare skill respawn. From a purist's point of view this solution is better because it maintains intermission screen percentage compatibility with doom2.exe.

But obviously there's a problem with the solution, else I would have upgraded ages ago and wouldn't be writing this! Quite simply, the live monsters counter is very easy to get into a state where it is completely wrong, made entirely useless by its incorrectness, and not only that but it annoys the hell out of me too.

THE FIX

Usually I'd just wait for a new version to come out but with Doom I really need this shit to be fixed. I did some research and this is what came up: totallive is implicitly initialised to zero on game start (it's a static global, so C zeroes it before entering main()) Then it is modified in one of the following ways

  1. It is incremented when a monster is spawned. This is either a nightmare respawn, a boss brain spawn, or most usually simply part of the level initialisation at the start of play or after a death or whatever
  2. It is also incremented on a resurrection (obviously) (this is technically different from a respawn though, it's a different function)
  3. It is decremented on the death of a monster.
  4. It is explicitly zeroed and recalculated on reload of a savegame.

Note the only time is it explicitly recalculated is when you reload a savegame. All the rest of the time it is supposed to maintain itself. Now consider the following

In the same way, if you exit a map with monsters still alive, when you start the next map it just adds the new map's number of monsters on instead of setting it zero first. It doesn't reset if you use the warp-to-level cheat code. It doesn't even reset it if you press F7, quit back to the menu, and then restart explicitly!

Okay I can see one possible application of carrying the live monsters counter over between levels; if you do a speedrun of an episode, it might be nice to see how many monsters you left behind. But it doesn't seem like enough of a justification. I know the guy who maintains PrBoom uses savegames extensively, if you read his map reviews at Doom Underground you can see this. I think that's why the only place it explicitly recalculates live monsters is on a savegame reload; it's the place he mostly likely noticed it goes wrong. It seems a weird omission though. The level setup code explicitly zeroes all the other similar counters.

Anyway here's the patch, it's really simple once I worked out where I thought it should best go

--- prboom-2.2.6/src/p_setup.c  2004-09-15 19:26:13.000000000 +0100
+++ prboom-2.2.6-lm/src/p_setup.c       2005-06-25 00:13:45.000000000 +0100
@@ -1332,8 +1332,8 @@
   char  gl_lumpname[9];
   int   gl_lumpnum;
 
-
-  totalkills = totalitems = totalsecret = wminfo.maxfrags = 0;
+  // [RjY] fix live monsters counter
+  totallive = totalkills = totalitems = totalsecret = wminfo.maxfrags = 0;
   wminfo.partime = 180;
 
   for (i=0; i<MAXPLAYERS; i++)

PS Just before I uploaded this article I was poking around the subversion repository and I found it has exactly the same fix in it as I spent half of last night working out! I'd be annoyed but I wouldn't have known where in the code to start looking if I hadn't worked it out myself, so I can't complain for once. It also means that all my speculation about why the omission might have been deliberate is so much hot air, though.

19/06/2005-20/06/2005 @02:23:00 ^03:36:33

GOSH ISN'T IT WARM? GOSH!

I spend probably three quarters of the year feeling cold so I welcome the warm weather. Nuts to all you haters!

THE ZIPS COLLECTION: AGAIN

I seem to have acquired a /tmp/zips2

Room of Ob "Room of Ob will blink and flicker while the hideous horde of monsters will eat you." Yes, pretty much. There's lots of flashing lights and what I call "noisy" texturing, that is a lot of textures used in a small space, and also a lot of use of textures which contrast lots of different colours and don't really look right in great quantity. Gameplay-wise though it's pretty fun, although the first room, a short corridor with a bunch of mancubi, is fairly pointless, and just serves to make the invulnerability you start with, run out faster. The next area contains a couple of awkward jumps over some pillars, with armour fragments on. I didn't like this because it's more like a secret area thing but you need to do it to progress to the final chamber. Everywhere is stuffed with large monsters but I managed to 100% it after a few tries. The balance is all wrong, the boss monsters at the end are pretty trivial to remove because it gives you an invulnerability, but immediately before that you have two archviles and a crowd of mancubi and arachnotrons to deal with and you don't get squat. The crowd of cacodemons and pain elementals was tough too. Overall I'd say good effort but not great.

Not Enough Brown Shit This map probably would be mistaken for a 1996-era map if it were not for the fact that it has been completely re-textured in this pattern of brown and orange. It is vaguely reminiscent of Doom's E3M3 and also of Quake, although I don't know why I think that as I haven't played Quake in years. But it does feel old, because it uses perpetual platforms. Although interacting with them is optional, it's nevertheless the case that their use is very rare nowadays because they're annoyingly slow. The map is small and cramped but over quickly and all but one of the monsters was a spectre or less. The button you press to get the red key isn't very obvious. There isn't very much health, and quite a lot of zombies, especially chaingunners; I was pretty low on health most of the time but somehow finished with 100% kills. I'm probably being too negative, but it's nothing incredibly wonderful. On the other hand it is well made, and the new textures are a novelty.

JERICHO.WAD Sheesh I don't know what the hell this is, other than obviously very very old and made before the time when you just don't make maps with wild light level differences and ugly texturing and all sorts of stuff like that, I don't know. I rather liked the way that the walls in the start area are false and as you go through the map they lower, but there's an ugly maze and lots of teleporters and a nice setpiece with the red key overlooked by a ledge full of mancubi and a cyberdemon at the end which was kind of pointless as it just gives you an invulnerability and there's a really obvious secret with a BFG and tons of ammo. That kind of sums it up, pointless - and lets not forget it changes all the sounds into stuff from Star Trek ("that's what a teleporter is supposed to sound like", says the text file. How do you know? Anyway, I just don't like sound replacements)

Tides of Sin This is more like it. A replacement of Doom E1M8 that is more like a silvery Doom 2 techbase than an episode 1 map, it is still very nice looking and quite fun to play. The area around the exit has some nice hell corruption work going on, as you'd expect from an end of episode 1 map, I suppose. The patches of skin or whatever the hell that swirly flat is meant to be look good, anyway. The gameplay is quite dependent on luck, as you start you face a number of sergeants armed only with a pistol. The crowd of spectres and demons are not so much of a problem if you're good at the punching thing, but the final crowd of teleporting imps and barons can cause problems if you get trapped in the small room with the rockets and plasma. However the major complaint about this map is that the final two battles are based around large monster teleporters that are very badly designed. You have to kill all the barons to end the map, and it is very possible that you have to wait an irritating length of time for the damned thing to come out of the holding pen. See it's all very well to start with when the holding pen is full because there's lots of monsters that can walk over a teleporter line but towards the end with only one or two in a large and otherwise empty sector, well, you could be waiting for a very long time. This is a blight on an otherwise very decent level. On Doomworld, the newstuff reviewer complained that he couldn't get this map to exit, and I suspect what happened was a baron got stuck in the teleporter and he got fed up of waiting. Summary: looks great, could play better.

13/06/2005 @22:12:23 ^00:00:29

"I travelled half the length of England and all I got was shat on by a pigeon"

hahaha that should be on a t-shirt

HOW TO DO AN EXIT DOOR PROPERLY

Last year I wrote an article about how to use the computer console flats in Doom properly. Recently in the construction of my as-yet-unnamed megawad I found another similarly pointless dilemma that needs answers.

It is to do with exit doors. If you've played Doom you'll know the usual convention for an exit is to mark it some way, usually with a sign that says "EXIT" and often to have it in a small room behind this particular type of door called EXITDOOR that looks a bit like a jetpack with a big golden button in the centre. However these doors are only 64 units wide. The EXITDOOR texture itself is 128x72.

The remaining 64 columns are split into three strips. Firstly, there are two "sides" each of width 24, decorated with extra columns and in particular a pair of red lights in the middle. The two sides are mirror images of each other. The final 16 columns of the EXITDOOR texture are simply a strip of lighting and not relevant here.

The point is, the two 24-wide "sides" at x-offsets 64 and 88 respectively are meant to be used adjacent to the door itself in much the same way DOORSTOP or DOORRED/YEL/BLU are used around other doors in a map. The problem is, which is the left and which is the right? The strip at 64 has its pair of red lights on the right-hand side; the strip at 88, which is a mirror image of the other, has its on the left. Therefore we can talk about having the pair of red lights adjacent to the exit door or opposite it. Now you'd think there would be one convention but as usual the game can't stick to one way of doing it which leaves the dilemma: opposite or adjacent?

(If you need to see this in action to be able to visualise what I'm going on about just go and look at the end of E1M1 or MAP01, both of which are "red adjacent")

So what I did was to go through each Doom map and note down what it did, in the hope that I'd get some answers on how to do it the right way. Here it is:

Conclusions: There are two exits that have sides which are red opposite. Compare this with more than a dozen which are red adjacent (ignore the ones that aren't either, because they're irrelevant) I think it's pretty clear which way round they're meant to go, with the 64 side on the left and the 88 side on the right, just like in the texture - but if you like you can swap them round if you like, it doesn't look too crap. In fact, well... nobody will notice, probably...

PS I didn't go through Doom 2. It's not canonical when determining how to use textures that exist in Doom, anyway.

06/06/2005 @19:43:50 ^00:00:31

Oh dear it doesn't even have a name yet

New Doom projects are often met with ridicule. For every map that is released there are a dozen "INCREDIBLE NEW MEGAWAD!" ideas that never get finished, or indeed, started. On Doomworld this has happened so often that there is a forum extension which allows you to post the following helpful message with a minimum of keystrokes:

<NOOB>, before you start asking for help on your new mega-cool-and-whatnot project, make sure you have something to show first (screenshots, map downloads, etc). Keep in mind we've already seen thousands of upcoming projects that actually never got done.

With that in mind, I've started making a new set of maps.

What's done so far After two weeks, I have three maps finished in a theme I call "Dingy Techbase". Furthermore the girl has made a map and I also plan to do up Speed Villa a bit and put that in. So, there's about five maps.

Screenshots The maps I've done, in order of their construction: the first map, 1, 2; the second map, 1, 2; the third, 1, 2, 3. I don't know how long those links will last for but whatever.

If you would like to help I need beta testers and the more the better. I have a couple of people already, please join us on #megawad on irc.quakenet.org if you are interested.

Notes Doing Elixir taught me a lot of things about how not to make a map. For example, Doom is a game, so just make a map for a game and don't get bogged down by everything having to have a reason and be justifiable and whatever. Then last Christmas Speed Villa was made and the demos forum tore it to pieces. I realised that it's better to make a bunch of small, fun maps than some plodding behemoth that gets on everybody's nerves. You can make them look nice but don't sit up all night making complex machines and computer consoles that serve no purpose, etc.

In fact this is the result of seeing how well Speed Villa went and wanting to do more of it! I want it done for Christmas because I figure more people will play it if it comes out in time for the holiday season when people have time off.

The whole episodes thing is just to divide it up. Also, I can take the guns off the player after a few maps and not have to worry too much about making "balanced" maps. What I mean by that is a map that has just enough ammunition for every kill so that you never end up with too much.

I have a good way of forcing restarts which, although I worked it out independently, the famous megawad Scythe also does. The player teleports on top of a boss brain and a bunch of barrels, which kills him but also the brain which causes the level to exit. Since you are dead you get resurrected with 100% health and 50 bullets, the same way as when you press the use key when you die during normal play.

Stuff to do Make more maps, obviously. I should probably change the sky textures and do new title and intermission screens. Also name the maps and make intermission screen name graphics for them. Oh and name the whole project! The only name I have so far, which gets stupider every time I think of it, is "The Looks Like Arse Megawad"