I can finally show off my weekend project! Well okay the vestiges of it started a couple weekends ago and it bled into this morning by a couple hours, but I think it still counts as a weekend project.
Jasna and I don’t have cable or an antenna for our TV, which means we download everything we watch, or borrow it from friends on rare occasions. My MacBook was starting to run near the end of its useful life as my main work computer — the trackpad was becoming unusable which meant I couldn’t depend on it when travelling — but it’s still got some life in it as a server. It was wireless networking (no cables to string around), uses very little power, is completely silent, comes with media software (Front Row) and comes with a remote control, is really small (less than 2cm tall), which makes it more or less the perfect media server.
The only downside is it was a pain to get shows onto it to watch, as you have to search for the shows manually, download them, then copy them manually over to the server. So, I decided to make a web interface.
Check here for screenshots of the new web interface for the media server. EasyNews, our Usenet provider, provides very handy services like global searches, thumbnails and AutoUnRARing. A big benefit to this is not having to wait until something has finished downloading it before watching it. So far I’ve got services for downloading from Usenet — which is where we get almost all of our TV shows to watch, downloading CFL games from TSN and just uploading individual files from your browser. At some point I need to set up scheduling so that it automatically downloads new episodes of shows when they’re released, but I guess that’s for another weekend.
I’m kind of embarrassed at how proud I am to have actually finished it in a weekend like I’d planned, especially considering I haven’t done any web development in years and years. The astute of you may have noticed I used straight-up CGI instead of technologies the cool kids are using: no love from me for PHP or RoR or Ajax or anything. Since I haven’t put any password security in yet — that’s for another weekend yet — and the box is publicly addressable via IPv6 I’ve had access to the web interface to just within our local network, but if IPv6 takes off some day it’ll be cool to be able to download movies while I’m away from home.
This is an addendum to this post where I was trying to make NHL ’94 more challenging.
I’ve all but given up on trying to give the computer an extra useful player in shootout mode. Giving the computer an extra player who stands and does nothing is trivial. Unfortunately, the “AI” for shootout mode is — maybe not surprisingly — hard-coded — it doesn’t even take into consideration the position of the goalie — and rewriting the AI in 65C816 assembly is beyond the scope of my free time. This is easy to show by watching the differing behaviour between when the computer gets a breakaway (in regular mode) compared to how it behaves in shootout mode.
So I play in regular mode with a 3-man handicap. E.g., we play 5-on-2. If you watched the first video from my last post, you’ll notice that handicapping yourself makes the game beep constantly. It’s very very irritating. Fixing this is actually not completely trivial. For those that are impatient, here are the memory addresses I’m using:
Address
Description
Example value
7E17A6
Number of players for the home team
3
7E18BA
Good question! See below
12
7E1864
Number of seconds left in the penalty
40
Using the values above will stop the incessant beeping.
I haven’t had time to fully explore the implications of 7E18BA. Just from observation, it seems that that the 7E1860 – 7E18C0 range is an array of player state and 7E18BA is an offset into that array which pertains to the penalty. By setting 7E18BA to 0x12, it seems, you indicate which element of the array from which to draw penalty-time-remaining information. I only use the value of 0x12 and the associated address 7E1864 because those are what came up for me during debugging (Mike Gartner, if you’re curious). I haven’t found any rhyme or reason to the number 0x12 yet, but I don’t really care too much at this point.
As a side note, someone really needs to come up with a better tool for “RAM cheating”. For those unfamiliar, the general procedure for this style of black-box debugging — usually used for cheating, though in my case I guess it’s anti-cheating — is to snapshot RAM at various stages of play. You then compare the RAM images according to what state you’re looking for. E.g., if you want to know where the numbers of players on the ice is stored in RAM, you snapshot when you have 6 players on the ice a few times and again when you have 5 players on the ice and look for the numbers “6” and “5” to consistently appear in RAM.
If you have a hacker mentality, this way of doing things can be productive, but it’s pretty crude. Generally the tools available don’t allow you to compare bit-values, only byte-values, and comparison operators are pretty limited. After half-heartedly trying to follow along with Jasna’s AI assignments, I’d be surprised if this problem hasn’t been solved generally and properly in the AI academic community. Oh well.
For the past year or so, I’ve been timing how long it takes for me to go through the checkouts at our grocery store to see which is faster.
The methodology is quite simple. Once I’ve got all my groceries, I go to the same spot near the checkouts. To avoid biasing myself, I check my cell phone to determine whether to go through the self checkouts or the normal checkouts. Because my cell phone lacks a random number generator, I check the last digit of the time: an even digit means I go through the normal checkout and an odd digit means I go through self checkout. I then start the stopwatch and time how long it takes for me to go through the checkout and leave the store.
I’ve got 31 data points and have finally decided that if one type of checkout is faster than the other, the difference is small enough to not really matter. Here’s the scatterplot:
A sample size of 31 is unimpressive, to be sure, but it’s large enough that I can finally rest easy knowing it would be a waste of time to collect more data. Trying to get out of the grocery store in the fastest way possible seems to have more important factors, such as the number of jerks ahead of you in line.
As a side note on how that scatterplot is presented, it probably would have made a lot more sense to measure the time taken as a function of how many items I bought, rather than the cash value of the items I bought. I’m far too lazy to count things, though.
So, from now on I’ll be deciding on self checkout versus normal checkout based on how social I’m feeling. I suspect that means I’ll be using the self checkout a lot.
As anyone born around 1980 would know, gaming reached absolute perfection with the release of NHL ’94. It’s great if you want a 10-minute diversion and I’ve been playing a few minutes of here and there for the past few months.
There’s one serious problem with NHL ’94, however: the AI is absolutely terrible. Playing in single-player mode is way too easy. Playing as the worst team (either Florida Panthers or Ottawa Senators) against the best team (All Stars East) I can win 5 – 0 without much effort.
In shootout mode the AI is even worse. If you put the goalie on automatic mode (the computer controls your goalie) then the opposing team does alright, but it’s no fun. If you put the goalie on manual mode (you control your goalie) I’m not convinced it’s actually physically possible for the computer to score on you.
I had the brilliant idea that maybe the game would be more fun if the human player were handicapped. Maybe shootout mode would be more fun if the computer had 2 players instead of just 1? I have my doubts, but it got me thinking.
So one idea was to disassemble NHL ’94, add in some 2-on-1 shootout code and reassemble it. Fortunately there are people out there who take hacking the Super Nintendo more seriously than any sane person should, so there are some tools available. Learning 65C816 assembly code, disassembling the game and then tracing through and debugging sounded like the sort of thing that one does after they’ve finished writing their thesis, so I filed that under “plan B”.
Plan A became to track down where certain delicious global variables, such as the number of players on the ice, were being stored in memory and modify them as the game was being played. After about 20 minutes of toying around, I got something to work.
Here’s me in regular hockey mode, but with only 1 skater instead of 5:
The constant beeping (sorry) is due to NHL ’94 foolishly thinking that since I’m down 4 men, the other team is on a power play which is ending soon, in 0 seconds to be exact. Note the game mistakenly gives credit for the goal to Zhitnik and Hrudey of the LA Kings instead of Schneider and Roy of the Montreal Canadiens. Weird.
Here’s me in shootout mode:
Unfortunately I accidentally gave myself an extra player instead of the computer, but it still demonstrates that my idea won’t work without a lot more fiddling. The extra player just stands there doing nothing. Sigh.
After yesterday’s failure I brought a bit of extra duct tape and super glue and got the car back in working order with the camera affixed to it nicely. I took it out again this afternoon to see if I could get the camera to survive some small jumps off some staircases.
The good news is my duct taping and super gluing worked. The camera didn’t move an iota — though sadly I had to tilt it a bit to the left to get it seated properly — and the servo controller stayed where it was supposed to.
Before I get into the downsides maybe I’ll just show the video.
So the first downside is that the video ends about five minutes earlier than it should have. When I rolled the car it rolled onto the shutter button, unbeknownst to me. It’s too bad since the crazier/more abusive stuff came after that.
The second downside is that both the camera and car took more abuse than they have before. The metal casing on the camera got scraped off on one corner. One of the front shocks on the car came apart, which is especially bad considering it’s an oil-filled shock absorber. I haven’t decided what I’ll do about that.
The third downside is that since I had to run the car without a body in order to get the camera on, it got more water damage than usual. Currently it only goes in reverse. I’ll take another look at it after it dries out.
I think I’m going to put this short-lived remote controlled car videography project aside until I figure out a way to get things to survive better.
Since it’s been crazy nice lately — 4º for the past couple days — we’ve had a lot of dry pavement coming out, so I took the camera/car combination out again today. I attached the camera directly to the chassis with the help of a styrofoam shim, rather than to the body like I did last time.
It started off promising! Up until the last ten seconds I think it counts as a modest success! There’s not so much bouncing and you can actually see what’s going on.
Sadly, those last ten seconds…yeah, I turned left when I should have turned right. It not only knocked the camera off, but it knocked the controller off the chassis. The design of the car is rather stupid in this regard: the controller is just cantilevered, held in by adhesive, in my case super glue. I’ll re – super glue it and see if I can’t try again tomorrow.
My ultimate plan was to take it off some sweet jumps. Now I’m wondering if the camera will survive the trip: it was just held in place by the aforementioned styrofoam shim and some duct tape. I’ll try it with more duct tape and see if I can’t get it to survive a jump tomorrow.
I’ve always loved remote controlled cars. I think at one point in elementary school I even listed R/C car driver as a future profession of mine. While I did have some actually really nice cars as a kid, one dream of mine which never came to fruition was to put a video camera on the car. It would be like being transported to a miniature world where everything is huge and cars go orders of magnitude faster than they should.
Over Christmas break we stopped by a Winners and I picked up an amphibious battery controlled car. The box had some dramatic pictures of it going from water to land, so I decided to try it out in my own kitchen sink. Not great, but well worth the $2.25, I’d say!