bbot's blog

My cultural niceties, perhaps as a result of my somewhat erratic upbringing, are less than solidly installed. In particular, I can never manage to say "How are you doing?" quickly enough as to suit the natural flow of a conversation. Being normal, you[*], of course, understand that "How are you doing" is a natural reply to the initiator of conversation, the "Hello".

*: All my readers are normal, even, distinctly above average. Refined artifacts of a more civilized time. Excellent human beings all, possessors of unusual good taste and extraordinary distinction. You should count yourself lucky to find yourself among the ranks of the Few.

Seeing as how the "How are you doing" is an interrogative, I have evolved an excellent response, the "Great!"

"Great!" is a universal response, to be referred to in times of fair or foul, thanks to its wonderful versatility, depending on the manner in which it is spoken.

Delivered as an exclamation, it conveys a wonderful sense of excitement and dynamism, a true "can-do" attitude, and may invoke an impression in bystanders of being "a cheery motherfucker".

Delivered in a sarcastic manner, it impresses in witnesses a sense of your dry wit, and a impression that you are "one sarcastic motherfucker".

But while I have mastered the response, I have yet to grasp the complexities of the question; and it was upon these matters I was reflecting when I happened upon a co-worker of which I am on nodding terms.

I sprung into action! Quickly, I reviewed the four words which I must pronounce, the order in which they must be pronounced, and the manner in which I must pronounce them.

The opening rounds were swift, and suddenly the time for action was upon me. I acted!

"You doing great?"

Disaster! The knowing manner which had been planned for the response had instead acted upon the question, and instead of burning with a dry wit it seethed with contempt.

But either he did not hear, or was not aware of the botched delivery, for he instead commented upon my hat. Disaster averted.

<+gateafk> New York is the capitol of the US
<+gateafk> In this universe of course
<+bbot> Just like your face is the capitol of ugly?
<+bbot> And yo momma is the capitol of fat?
<+gateafk> OH SNAP
<%Guttershark> bbot...those insults were fail
<%Guttershark> I'm tempted to whack you for them because they were so bad
<+bbot> Uh oh, a hater!

I got to use my volt tester twice today, which is good, because I carry it around all day in my pocket protector; but bad, because I only use it if I'm not sure an action that I am about to take will kill me or not.

I replaced a socket in a fluoro can light; because when one of the lights burn out, in this particular type of fixture, the other socket then gets hot enough to melt to the folded tube's plastic base, but not hot enough to trip the thermal protection fuse. When the second lamp dies of accelerated old age[1], you get up there (on a 10-foot ladder, of course) to discover that the lamp can't be changed without pulling the entire fixture apart and replacing the socket.

All this means that every time I walk through the lobby I have to stare up at ceilings, hoping to spot a light out. I can't just look for dark cans, since there's two bulbs per fixture. Thanks, whoever designed this bastard. Thanks a lot.

However, replacing the socket requires shutting off power at the panel, since there's no service disconnect inside the fixture (not enough room) nor on the junction box feeding the fixture. (prohibitively expensive) However, again, this means shutting off the lights in a elevator lobby, so repairing the fixture is best done with haste.

Guess who didn't manage to repair it with haste? Me.

Vlad had been sitting on this fixture for a couple of weeks, hoping that nobody would notice that it was only holding one bulb, but eventually that bulb went out, (Two days after he retired, of course.) and I had to go up and change it. He had told me, quite clearly[2], which breaker controlled that bank of lights, so I switched it off, and screwed on the fiddly little circuit breaker lockout to ensure that nobody would flip it back on while I was at the top of a ladder[3]. Walk back out to the lobby, and discover that, nope, that's the lobby entrance lights, and hey, wow, looks like emergency exit lights start blinking when you cut off their power!

So I start flipping each breaker with the word "lights" in its tag.

Breaker 2? 6? 11? 31?

Ah, that's the ticket.

Replacing the socket was uneventful, (checking it with the volt tester to make sure it was off, returning to the topic) but turning the power back on revealed that shutting the power off at the breaker was traumatic enough to kill lights in two other fixtures.

The second time I used the volt tester was while replacing a ballast. The work order had been for a light out in Reception, and in the employee kitchen. The reception bulb was a weirdo, a BR base (incandescent floodlight form factor) compact fluorescent; (model number CF16BR30, in case you care) but in the kitchen, all four lights in the fixture were out, which is pretty damn rare. Engaging in some forensics while waiting to see if the lights would burn out[4], just working off the dates, it looked like three of the lights went out, and the fixture limped along with one for a couple of years (!) before the last one went the way of its brothers.

On my way out, I noticed some lights out in the secretarial quad, and after getting authorization,[5] I started changing them. One fixture with both lights out did have a bad ballast, (which required using the volt tester for the second time) and by the time I left I had gone through 12 tubes, about half a case.

After dropping my cart off at my office, I went down to the loading dock to get some of those chocolate wafer things, when I discovered that we were in the process of having a new vending machine delivered. The guy had just finished testing it, so I offered to be the first customer.

The vending machine had an XY (rather, YZ, since it didn't traverse the depth of the machine, ah ha ha ha) gantry, with a basket and a motor on it. The gantry would move over whatever row you selected, the motor would engage a sprocket on the front of the row, and vend whatever you selected. I put my money in, it goes through its song and dance, and nothing happens. The gantry resets and repositions itself, nothing happens. Gantry moves back to the bottom row, and now the display reads "SELECT ANOTHER PRODUCT".

Vending machine guy: Huh.
Me: At least it didn't steal my money.

Some troubleshooting later, we figure out that the row itself wasn't positioned correctly. Pop it open, fix it, now it vends correctly. Get back to my office, and the mountain dew's warm, since he had just put it in.

ALL I GOT IS PROBLEMS

---

1: The typical end-of-life failure mode of a fluorescent lamp is failure to achieve discharge due to insufficient gas ionization, which is in turn due to cathode failure, high gas pressure, or incorrect gas mixture.

The electrode filaments on fluorescent tubes are great big beefy things, especially compared to the ones in incandescent bulbs, which have to be thin thanks to physics; but the therminonic emission "catalyst" (not literally a catalyst, since there are no chemical reactions occurring) coating on the cathode filaments still boil off fairly briskly. Some of these newly liberated ions will slam right into the side of the tube, producing the dark spots on the ends of old fluoro tubes, and, eventually, cracking them; allowing the atmosphere in, which both changes the composition of the gas, and raises the pressure high enough to extinguish the discharge, but the rest of the ions are lost forever.

This is bad, because the coating is what enables the discharge, and when enough of it boils off, the lamp won't light, or, in borderline cases, will only light when cold. This causes the light to turn itself on and off (the electronics will manage to light the lamp, but internal pressure will rise as the lamp warms up until the electronics can't supply enough current to sustain the discharge, at which point the lamp turns off, rinse, repeat) until the temperature cycling boils enough catalyst off to kill the lamp dead. This doesn't occur very often in fluoro tubes, since they start so quickly; but is fairly easy to observe in aged low pressure sodium bulbs; since they warm up slowly, thanks to their greater mass.

The point being, heat kills fluorescents, and keeping them hot kills them faster.

2: Lit. "Looby lights, they are controlled by breaker von on panel seeven. I am Russian, despite how bahdly Sam is mangling my accent!"

3: Being shocked at the top of a ladder usually results in death of falling off a ladder.

4: In almost every case, an entire fixture going out means the ballast's bad. So far, I've only seen this failure mode twice.

5: Some tennants like to leave fixtures half-populated, to save energy, and to confuse poor lighting fixture maintenance personnel. On these occasions, I only change lights when directly asked by the person sitting closest to the fixture.

ftl2.html updated. You might have not read it before, so it's reprinted below.

Fall To Life was a free mmorpg which I worked on back in 2004. There were, of course, creative differences, and the project eventually collapsed. More embarrassingly, the only evidence of my participation is an archived copy of the forums. I'm the latest post in the Off Topic subforum, of course.

I wrote rather a lot of material, most of it now embarrassingly obsolescent, but rather liked some of it, and so shall post here what Fall To Life could have been, maybe, a couple of versions down the road.

Fall To Life take 2, version 1

There are a great many FPS tropes which are entirely nonsensical, yet are required to facilitate gameplay. An example, taken at random, of, say, Half Life 2: Deathmatch. (HL2DM) In this game, both the ragtag rebels and the transhuman, cyborg, and generally badass Combine supersoldiers run at the exact same speed, and can keep it up for, apparently, ever. This is because trying to implement a realistic fatigue system and comparative fitness levels would be a lethal double shot of lousy balancing and crappy gameplay.

And, of course, both the combine and rebel reinforcements appear out of thin air, along with their materiel and magical "health kits", which instantly heal a severely wounded, yet visually unharmed soldier back to his full compliment of one hundred "health points". I could literally go on for pages.

Why are video games such a massive, mind-numbing departure from reality? It's because we already have a word for a place where even minor wounds require weeks of hospital time, where soldiers tire after sprinting for a mere hour at a time, and where logistics is almost as critical as combat operations.

It's called Reality.

But it should be possible, if not trivially easy, to design a game that at least gives a cursory nod towards realism while still retaining significant playability.

For starters, let us examine the simplified human as used in pretty much every FPS. E can run at full speed indefinitely, sustain significant damage without slowing or becoming incapacitated, and never needs to eat, drink, or use the bathroom. (With the notable exception of The Ship) In fact, this simplified human sounds rather more like a robot than a human.

There is even a plausible reason for a combat robot to be remotely controlled by a human. (The teleoperator being you playing at war in the comfort of your own home.) In Leo Frankowski's A Boy And His Tank, Strong AI was cheap and and sophisticated enough to be indistinguishable from human, but was significantly worse than human at pattern recognition, which is critically important in combat. Thus, human observers were enlisted to provide human skill without actually risking a human.

Strong realism does not always mean not fun, as recently alleged by an excellent troll on #7chan. Most realistic games are less than exciting because they attempt to closely simulate the limitations of a human body. But, of course, a robot is bound by none of these. There is no reason why a perfectly realistic robot cannot run at sixty miles an hour and leap buildings with a single bound. In practice, this probably wouldn't be implemented, due to a combination of balance and content creation issues. Fast players make large maps seem smaller, which, of course, requires larger maps. It is also damnably hard to shoot a small, fast moving target, which makes it harder to defend your base, which incites frustration in the players. But this is irrelevant. "Fun-ness" is complex and subtle, and depends not on design concepts, which this document is concerned with, but small gameplay details. Fun games are fun because many small things align perfectly, not because someone set out at the beginning to make it fun. (Though someone probably did.)

A good example is of Doom 3 and FEAR. Both are designed from the ground up to be damn scary, but FEAR is fun and Doom 3 is not. It's because, in FEAR, when you pull the trigger, shit goes down. The gun kicks, tracers zoom into the target, there are loud, manly noises, and crap blows out of the target. In a major firefight, things are flying around, people are exploding, gunfire is tearing up the walls, sparks are being kicked off of metal surfaces, shit is blowing up, and everything blends perfectly into a catastrophic melee of death.

In Doom 3, you stumble around in the dark with a shiny nerf gun, and every so often an eight foot tall demon jumps out and tears your head off. It is a tedious, pointless grind, and I played it for maybe twenty minutes before giving up and returning it to the store for a refund.

Think I'm spouting bullshit? Read this wired article. Over and over they emphasize the small changes that make a game fun. You never hear about plot, graphics, overarching themes, mission statements, &c. It's because all this is completely irrelevant to how fun a game is.

Utilizing the robot paradigm leads to interesting conclusions, but first we have to detour a bit. Way, way back in 1999, Unreal Tournament (UT) introduced a mode of play called Domination, where two teams battled over several control points, which awarded points to the team controlling them. Reach a certain number of points before the other team and you win.

Battlefield 1942 (BF1942) improved on this basic concept by making each control point a respawn zone, and spacing them out over a large map. Each control point also produces vehicles at regular intervals, and requires an attacker to first neutralize the control point before capturing it, instead of UT's instant capture model. This makes each point the focus of the match, because they were the source of vehicles, the key to having any fun at all in BF1942.

Since, essentially, robots are small, complicated, vehicles, each abstract "control point" could be implemented as an automated factory, which passively churns out vehicles and combat robots for whichever team holds it.

That is what I've been thinking of as FTL version 1. It could be easily implemented as a mod for BF2142. (The fourth release in the Battlefield series.) It can also be easily expanded.

Fall To Life take 2, version 2.

Since humans are only used to enhance the combat effectiveness of a combat robot (hereto referred to as a drone or remote.) then they would be computer controlled for noncombat roles. One of the major chores of BF2142 is finding a vehicle, which are quickly depleted from the forward control points, since that's where everyone spawns in; and usually end up moldering in some forgotten corner of the map. Since each control point is also a production facility, there's no reason for the commander not to use a RTS-style interface, and order all the unused vehicles to drive themselves to a rally point conveniently near the fight. Each vehicle could be loaded with empty drones, to be conveniently activated by players as the vehicle becomes usefully close to the front lines.

Each control point could also produce automated artillery, automatically firing upon player designated targets, then moving to avoid counterbattery fire; occasionally returning to a control point to resupply. Supply trucks could also transport large numbers of drones or weapons to forward control points quickly, or place NLOS-LS racks or automated defense drones.

Remotes are controlled through an quantumly entangled bit reservoir, which which impossible to covertly listen in on, or overtly jam; but contains a finite amount of bandwidth. When that runs out, the remote falls back on one-time-pad encrypted radio, which can be jammed. When the one-time-pad runs out, then it falls back on public-key encrypted radio, which can be jammed or brute force cracked, and if the encryption is cracked, then the enemy can just hijack the equipment. This introduces an interesting dynamic, in that deep-strike teams or isolated outpost have limited lifetimes, and must reestablish contact or face a two-front war, both physical and virtual.

Fall To Life, version 3.

While version 1 and 2 primarily concern themselves with the tactical level, version 3 would be strategic in scale, covering entire continents, planets, or even solar systems.

In v1/2, autofactories are black boxes, which produce a constant supply of a limited range of units. In v3, factories are revealed to be generic wrappers around often completely different assemblies of individual production elements. While v1/2 autofactories completely ignored resource collection, or handwaved it away by assuming that the relevant equipment was underground; v3 factories producing finished products (rather than subassemblies) will need to draw purified feedstock from numerous resource collection and processing facilities. Automated factories will require different feedstock depending on the product, munitions will require more organic materials than heavy armor, which might require exotic minerals, and thus would have to draw from more RC&P facilities.

The design or modification of existing designs would be available to the player, resulting in corresponding changes in material requirements for the finished product. This would add a whole lot of complex issues, which I'm ignoring right now.

Research could be performed at two different levels. AI expert systems, which require large, expensive computer facilities, could make incremental optimizations of established designs, reducing heat production, decreasing assembly weight, etc. The optimization model also gracefully introduces diminishing returns, which are otherwise arbitrarily imposed game balancing restrictions. Offsite (offplanet, in v.3) human engineers, on the other hand, would produce novel designs; revolutionary, rather than evolutionary, changes. The disadvantage being, that buying their time is expensive, and progress is slow.

In whole solar system scenarios, manufacturing might be easier in orbital facilities, which also adds the possibility of space combat, since all factories are susceptible to damage and fully destructible, unlike in v.1/2.

Computer power permitting, v3 may also abandon the conventional percentage based damage system for a more realistic part based model. Since under the v3 construction model, each product is made of many parts, damage modeling could be based on those parts. Getting shot in the leg would reduce (or eliminate, depending on severity) mobility. if the drone can return to a parts warehouse, then the damaged part could be swapped out for a replacement. The same can be done with vehicles, and weapons.

This might be difficult to implement on a practical level. Different drone variants can easily use the same art, but modeling each individual part would require orders of magnitude more effort than can be expected of a amateur production. The damaged drone could be added to an intake hopper and completely dismantled, with its undamaged parts being added to general inventory, while the player takes a new in stock drone.

Battlefield recycling would be critical under this model. A piece of equipment could be damaged beyond use, yet still have many intact, and valuable, components. A drone that had been shot in the radio would be completely nonfunctional, yet intact in every other component.

Recycling of enemy equipment could add another level of complexity. A hypothetical player designing equipment would want to be able to use as much of the enemy's equipment interchangeably with theirs, while allowing their own equipment to be completely incompatible. This was, IIRC, used in the Soviet rail system, where the gauge of the track was slightly wider than its neighbors. This allowed Soviet equipment to run on the rails of its neighbors, while their engines were completely incompatible with theirs.

A part based damage model, coupled with FTL's enhanced focus on realism, breaks a key part of the Battlefield game design. In the Battlefield series, when the player is damaged enough to pass zero health, but not damaged enough to be reduced to a really nasty stain, they fall to the ground, and can be revived by a medic.

But in FTL, damage is sustained to parts not to abstract health points! Which part, precisely, was damaged sufficiently to cause the player to fall to the ground, but not enough to actually kill them?

This had to be handwaved aside in the Battlefield series; but we are not allowed this luxury with FTL.

The revive mechanic can be, ah ha ha, revived by postulating that whatever compact power source that allows practical combat robots is also shock sensitive. When caught in the concussion wave of an explosion, the battery is destroyed, but the remote is left intact. In this model, the medic is more of a combat engineer than anything else, replacing the batteries of downed remotes and returning them to combat. A contested control point would accumulate a litter of damaged batteries, as well as destroyed remotes.

A significant architectural limitation of the writings of Elizer Yudkowsky is that they are damn near impossible to quote, thanks to their cumulative nature. He'll write about optimization processes, then the blind idiot god that is evolution, then a million different unrelated topics; and it's all very low level and unsurprising, but he'll then write something surprising and interesting that is built on all those previous posts, and is completely incomprehensible outside of that context.

The Standard Blog Format is: witty title, source link, blockquote, analysis/commentary. Most of Etc is of this format, with a scattering in other categories. You can shuffle the individual elements, but you can't outright axe any of them without breaking the format.

So it's damn near impossible to blog about anything he writes without putting in either mountains of context text and scaring people off, (slash boring them to death) or sticking in a few dozen links (as I just did) and hoping your readers follow them before jumping right to the quote and getting confused.

So if some topic comes up that tangently touches on an area of Elizer's work, you end up talking in uselessly broad generalizations^* and abjectly failing to get the point across. This is the same mechanism by which I have apparently convinced a friend that Elizer is a Singularlity nutbag. Don't get me wrong, any word as stupidly broad as "the Singularity" will accumulate all sorts of weird shit, but Elizer doesn't fall under that category.

I got onto this topic in the first place, because I was writing something (unfortunately unpublishable, being fanfiction) a few days ago that tangentially touched on weakly-superhuman AI, and I needed to compactly describe the topic. I muddled along, of course, but it would have been nice to been able to rip off a key paragraph, say, this one:

If the AI is weak, it does nothing, because it is not powerful enough to significantly improve itself - like telling a chimpanzee to rewrite its own brain.

If the AI is powerful enough to rewrite itself in a way that increases its ability to make further improvements, and this reaches all the way down to the AI's full understanding of its own source code and its own design as an optimizer... then even if the graph of "optimization power in" and "optimized product out" looks essentially the same, the graph of optimization over time is going to look completely different from Earth's history so far.

I've got jack-all motivation to go back and polish it, of course. This, in case you care, happens all the damn time. I'll get a idea riding my ass, dash off a couple of paragraphs, then never touch it again. Occasionally I can salvage it, like with what became TWI; and sometimes I can salvage these fragments for completely different stories, but most of the time they gather dust. Publishing them on their own tends to inspire bile and vitriol; since they obviously are meant to go somewhere but don't provide closure, so I can't do that either. The worst case scenario is for me to die without fleshing any of them out, then have the executors of my will delete them.

*You can call Elizer "an AI researcher who sometimes writes about the Singularity" in much the same way you can call me "a custodian^** who sometimes writes science fiction".

** Explaining this, while thematically inappropriate (it ruins the structure of the simile) is necessary to sooth my enormous ego. Plus, it's my blog, nyah ha ha ha. My job title, "Lighting fixture maintenance technician" is a resume friendly synonym for "light bulb changer", which also can be taken to mean "someone who maintains a building", which is a notational definition of the word "custodian". Feel free to laugh uproariously at the freshly explained humor; or rather, smirk appreciatively at the complicated literary device.

---

Speaking of the Singularity, it is amusing to note that damn near all of the "Singularity fiction" is actually "Pre-Singularity fiction", since the point of the singularity is that technology will progress too quickly to extrapolate. Thus, it is impossible for anything that even remotely takes itself seriously to be set during the Singularity. The Continuity series, like most singularity fiction, is set in the pre-singularity period; with the odd exception of stuff like Vinge's Marooned in Realtime, which is actually set after the singularity, and consists mostly of people walking around, going, "What the hell just happened?"

That Which Is, The Face Upon the Deep, and the non-canon Internation are set during the wacky transition to a MNT economy. She was just just the dry smell of gasoline and Coarse Adjustment are set in the post-war period, and thus have hardly any interesting violence, as well as much less bombastic titles.

Lo', it was Said that I have had A Humorous Computer Experence and that it should be Wrote Up. And it was Done. Various things delayed the posting of this, so I back-dated it.

I am an Idiot
or
Why you should always always always make regular backups.

So I'm at my localCompUSA, and I buy a three position fan speed controller, because the fan on my heatsink is rather loud.

I get home and connect the controller, setting it to its lowest setting. The computer gets through POST and crashes while starting windows. I swear, crank it back up to its highest setting again and boot into the bios to slow down the processor. I wind the cpu down to 600mhz from 1100mhz, and attempt to boot into windows. Everything goes okay, I login, start all the programs, and the computer reboots itself in the middle of everything.

The computer post's, windows starts, and chkdsk does its thing, without finding any problems. I login, start all the programs, again and Opera and Gnucleus crash. Opera crashing is not too unusal in the earlier releases, but even then it crashed only when I visited sites that used non-standard tags. What is really strange is gnuclious crashing. It never does that. I go and schedule chkdsk for the next reboot. After finishing that, a system window hangs and I kill its task. Explorer dies, the taskbar vanishes, and explorer respawns. I notice that the tooltips that pop up over icons no longer match the icons themselves.

In the grand windows way, I hope a reboot makes everything work again. After POST, chkdsk starts, takes forever (almost a hour) and finds no problem. Computer reboots, POST's and attempts to boot into windows. Windows hangs, then reboots.

Computer POST's, emergency chkdsk starts, takes forever, and finds two errors. Computer reboots, starts into windows, and crashes, reboots.

After starting again, the system menu pops up, asking me if I want safe mode, last good configuration, or normal windows. I try normal windows. Windows crashes, reboots.

I try safe mode. Windows starts, scrolls through a huge list of errors, and crashes, reboots.

At this point I remember I have made no backups for the month, nor have I made an Emergency Repair Disk. The only backup I have made recently is a disc of mp3's for a road trip. The last system backup was almost three months ago. I reflect on the wisdom of making regular backups.

Ah ha!, I think. A repair install would be the perfect solution! I hunt up the windows install disk(hunt, literally. Took me five days, 7,232 rounds of ammounition, and three good men to capture it. And you wouldn't belive the fight it put up going into the drive! Anyhoo...) and attempt a repair install. Windows Setup loads all of the drivers and pulls a blue STOP screen. I reboot. Windows setup does the same thing. I reboot a third time. Windows setup hangs before even starting the drivers.

I hunt up a Knoppix disc and pop it in. It boots and runs perfectly, yet slowly. I call it a night. It is not a hardware problem, this I now know. At this time is sounds like some files that windows needs to run were corrupted when the computer crashed while booting. At some point during this the dvd drive I had ordered over googlegear arrived.

The next morning I wake, and install the dvd drive in the computer. It is now the master on ide channel 1, with the sony cd-rw as slave. The computer boots, and I place the knoppix cd in the dvd drive.

Nothing happens. The monitor shows "No signal." I reboot the computer. No signal. I power cycle the monitor several times. No signal. I disconnect the dvd drive's power cable and reboot. The monitor gets No Signal a few times, and then starts working again. I swear. I power cycle the monitor again. No Signal.

I reconnect the dvd drive again. No signal.

The next day I turn on the monitor before starting up the computer. The monitor gets a signal. There is much joy. I boot into knoppix and attempt to root through my ntfs drive containing all my files. Quite surprisingly, knoppix can read ntfs. I attempt to play one of the mp3's I have. It plays. I attempt to play a video file. It plays. I reflect of the neccesity of making windows work again. I reflect on the fact that it takes knoppix 45 seconds to open xmms. I log out of knoppix and move the cd from the dvd drive to the cd-rw, because I want to try and play a dvd, and I can't do that when the operating system is running off the dvd drive.

Knoppix boots. I open videoLAN and set the dvd drive to /mnt/cdrom1 from /dev/dvd. I attempt to play the disc that is in the drive. Nothing happens. I swich to xine. It starts reading the disc and crashes. I try again. Same thing. The Matrix crashes it. I try The Transporter. Xine gets through all the "do not copy under penality of law. No, seriously" and crashes. I give up on dvd playback, and see about fixing my computer. I attempt to delete /windows/system32. Linux helpfully informs me that /dev/hda1 is mounted as a read-only filesystem.

I boot into the command line knoppix. Now I can't even find the hard drive to delete the folder. Linux informs me that /dev/hda1 does not exist and that /mnt/hda1 has nothing in it. I call it a night.

Several Days Later: I begin hardware troubleshooting. I swap out the GeForce2 MX with an old TNT2. No change. I swap out the processor, and it manages to get into windows setup. There is much rejoicing.

A little backstory here: A little over a year ago, I went through my usual heatsink cleaning routine, only this time the computer wouldn't boot. Some informal hardware testing revealed that the processor was dead. Much sadness. So I went out and bought a new processor for the machine. I swapped the old Pentium 3 866mhz Coppermine(133mhzFSB version) For the new Pentium 3 Celeron2 (100mhzFSB). It Just Worked, and I was happy.

Swapping in the old coppermine revealed that the processor still worked, although it wouldn't even try to boot at its old, stock, non overclocked speed of 866mhz. Given that the heatsink I now use is vastly beefier and better cooled than the stock heatsink, it is obvious that the clock chip must be fried. Or something.

After two days of blissful problem-free computing, windows informs me that the file C:\$MFT is corrupt. Everything is working perfectly, and yet this file is corrupt. I check C:\ in Explorer and I can't see it. A search can't find it. I can see all the other system files, but not this one. Whatever.

At that point, I didn't actually know what $MFT is, or what it does. I google it, and discover that it is the Master File Table. The index file for the entire drive. The file that is so important, it is flagged so nothing can write over it, or even near it, lest it be deleted, or fragmented in any way. The one file that so important, not even the Administrator can see it, or try to edit it.

Not something you want to be corrupt.

So I schedule chkdsk for the next reboot. Chkdsk runs after said reboot and fixes the one error it finds. Yay.

I've added one or two things to test_garage in the last week or two. For one, stairs between levels! (as usual, click to enlarge)

I put doors on them, since levels 1 and 4 are open to the rest of the shop, which would funnel noise right into levels 2-3. I also modeled the outside world, which entailed cutting a hole in the side of the map, adding a skybox, and exterior brushes, which was a mild pain in the ass.

Of course, there were some brush misalignments. It looks just fine from this angle...

But move to the side a hair and...

Whoops, guess I didn't line those two up. Incidentally, this meant that the map wasn't "sealed", or completely closed off from the void, which causes vvis and vrad to error out. If vvis can't run, then the engine can't tell which parts of the map the player can see at any one place, and so renders the entire thing. Catastrophic on a big map, not so bad for something as simple as test_garage.

If vrad can't run, then radiosity isn't calculated, and the lighting isn't as nice. That's not as bad, but still ideologically impure. That isn't why the lighting in the screenshots look so bad, though; it's because I misconfigured light_environment, and ended up with the sun shining straight up at the bottom of the map.

I also forgot to add "_hdr" to the end of "ep2_outland_12a". (The skybox from EP2 I used for test_garage)

Consequently, the skybox doesn't render properly. Easy fix.

Much better.

With the skybox fixed and the sun lined up properly, the next item was to get the sun shining through the garage door, casting a nice beam, and contrasting against the cool blue garage lighting.

Criminally unimpressive! Another easy fix, crank up the power! I went from 150 to 600. (Unitless variable)

Nice. With that fixed, time to start moving to production textures. First up, grass. I also changed the exterior terrain from brushes to displacements, which render faster, and spawn texture appropriate detail props, in this case, small plants and tufts of grass.

Unfortunately, displacements are two dimensional heightmaps, which means that converting the face of a brush to a displacement converts that face, and that face only, to a displacement. Exposed to the void yet again!

Mildly complicated fix this time, I have to build some brushes to conceal the gap, and seal the void once more. Fortunately, I was planning on doing this, and didn't (notationally) waste any time patching.

Unfortunately, vbsp was still complaining about light leaks. Following the pointfile just slammed full length into the terrain displacement, which was obviously sealing the void. I mean, displacements seal the void, right?

Nope. What kind of moron doesn't know that displacements don't seal, hurf durf? Simple, but ugly, fix; I sealed off the bottom of the map with a great big nodraw textured brush butted up against the sides of the skybox. On to production texturing the interior!


Lovely.

Source file, (11 KiB rar'd .vmf) compiled executable. (443 KiB rar'd bsp) I compiled cubemaps this time, though I, for some reason, can't tell the difference. Oh well.

"The Gaucho" (1927) (movie) at the Paramount, June 23rd.

0, that's right, zero, nada, I hate this movie so god damn much, may it suck cocks in hell, forever out of five stars.

The movie is a pile of shit. Its crimes are legion, but topping the list is its rampant racism and hilariously prevalent misogyny. The characters are about as three-dimensional as a piece of paper, spend half their time praying, and in the ending scenes, crowd into a shrine to bow before YHWH and pledge to set up a theocracy based on the ten commandments. I am, of course, not kidding.

But hey, it's a crappy movie. It was the 20's, this is what they did, in between killing Germans and dying of the Spanish Flu.

But what's worse than the movie is the people who crowd into a theater to see the movie. Apparently, the only thing middle aged white women love more than watching dead people make bad movies is not shutting up for one fucking second for 117 god damn minutes. Painfully obvious plot twist? Cheer at the screen! Awkward, poorly choreographed stunt performed by an incompetent stunt man, and filmed by a blind, palsy-stricken moron! Cheer at the screen! Douglas Fairbanks looked at the camera? Wet your fucking panties, then cheer at the screen!

The whole thing was sponsored by Trader Joe's, of course, middle aged white woman's supermarket of choice. Because if you've got to choose between five different corporate multinationals, then you better go for the one with the stupidly crowded isles and the 200% markup.

The only thing dumber than all of this shit is the moron who gets suckered into watching a fucking silent movie by the promise of free tickets. There's a reason silent movies aren't made anymore! It's because they suck!

Fuck you all!

< ThomasBags> h
< ThomasBags> h
< ThomasBags> h
< ThomasBags> h
< ThomasBags> h
<~king_of_hearts> enough.
< ThomasBags> h
< ThomasBags> h
<~king_of_hearts> .mute ThomasBags
-!- mode/#cake [+b ~q:*!ThomasBags@*.tampabay.res.rr.com] by FBI
<~king_of_hearts> .unmute ThomasBags
-!- mode/#cake [-b ~q:*!ThomasBags@*.tampabay.res.rr.com] by FBI
< ThomasBags> h
< ThomasBags> h
<~king_of_hearts> .mute ThomasBags
-!- mode/#cake [+b ~q:*!ThomasBags@*.tampabay.res.rr.com] by FBI
-!- ThomasBags [ThomasBags@anon-EAD8A139.tampabay.res.rr.com] has quit [Quit: Leaving]
<@bbot> why you always gotta be unmuting t-bags
-!- mode/#cake [-b ~q:*!ThomasBags@*.tampabay.res.rr.com] by king_of_hearts
<~king_of_hearts> because its mean not too
<@bbot> a foolish decision that will bring you only pain
<@bbot> so sayeth I
-!- ThomasBags [ThomasBags@anon-EAD8A139.tampabay.res.rr.com] has joined #cake
< ThomasBags> 8P
<@bbot> behold, vindication of the prophecy
< ThomasBags> wut

So I was browsing the tvtropes wiki, when I came upon a line in Misapplied Phlebotinum.

Sure, for a macro-scale device like that, but something as complex, intricate, and dense (in complexity/volume terms) as a human brain? That's pushing it.

Whoa-ho! I can't let a statement like that stand. Thus:

Let's improve this discussion with some math. Assuming that a human brain has 10^11 neurons (100,000,000,000), then just giving them all 39 digit serial numbers would take, of course, 10^11*2^39 = 54 zettabits or 6.871 zettabytes. Assume we use some of the address space for special characters (we could just use ASCII for the first 128 bits, making this a superset of Unicode, humorously enough.) then 39 bits of address space allows us to address a 5.49*10^11 neuron brain, or a brain with 549,755,813,888 neurons, about five and a half times more complex than a human's.

Now, assuming that the structure of our file is the serial number of a neuron followed by the numbers of the neurons it's addressing, a line feed, the next block, etc; and assuming that each neuron addresses ten others, then we get a final total of 68.71 zettabytes. The brain might be more complicated than this, and each neuron might interconnect more, but handwave handwave, let's keep moving.

Using Stross memory diamond, which has a density of 6.022*10^23 bits per 25 grams, we end up with a final encoded mass of 22.8 grams, which is 6.48 cubic centimeters of diamond.

23 grams, six and a half cubic centimeters. Roughly two orders of magnatude smaller than its organic equivilent. The brain is complicated, but it isn't magical.