Woo! I got an old server World of Warcraft server for Christmas. As expected, it came without hard drives or any way to plug it in. All the servers that were auctioned off were intended for display only. I'm toying with the idea of getting it running, although if I can get it working I probably won't benefit too much. But it will be awesome.
Blizzard auctioned off old World of Warcraft servers a few months ago http://us.battle.net/wow/en/blog/3710218. The server I have was Rexxar, according to it's plaque it was in service from February 10th, 2006 to June 9th, 2010. I leveled up my main on it a few years ago before transferring it off to join some of my guild migrating from a different MMO, Guild Wars. The servers they auctioned off were all pretty old HP Blade servers, I don't know much about them but it sounds like they were powerful servers in their time, power hogs and very noisy. Unfortunately, I haven't found any good sources of information about Blade servers yet, I tried contacting HP support but they haven't gotten back to me yet.
My blade server has three main ports I've found. One on the front, which I assume is for plugging in a terminal. Two in the back, one looks very much like a power port and the other is probably for data. I assume when the server lives in a rack, the power would plug into 48v DC and the data port would plug into some sort of very fast ethernet (I found at least one thing claiming this model used gigabit). I imagine I could hack power together to boot up the server, but I have no idea how I'd interface with it or connect it to the internet yet. Also, I don't know how well the server tolerates variances in voltage. Ideally I'll be able to find a small Blade server rack, but it doesn't look like any small ones exist. Maybe I'll get lucky and I'll run into someone with a space server rack. I'd love to be able to host stuff on an old WoW server.
Friday, December 30, 2011
Thursday, December 29, 2011
RTS Engine
When I first started to learn C, as soon as I finished with learning the syntax I jumped straight into trying to make an RTS engine. I'd written enough of an engine including a server and a client to move units around on both screens and have them collide with each other and pathing blockers. I'd also written a map maker for placing pathing blockers. The whole thing was very crude, basically it was just a lot of colored rectangles that could be selected and move around. After a little over two weeks of working on it, I got bored and moved on to working on an MMO engine (partially shelved at the moment, it's on my GitHub)
Recently, I decided I wanted to work on my RTS engine more. Fortunately I was using git at the time and found an old backup. I hooked up my old repository to GitHub and started working on it about a week ago. Fortunately my coding was neat enough so I didn't have to spend a while figuring out what it all meant.
Over the last week, I focused on implementing pathing. In most RTS's, units automatically find paths around obstacles. I don't know how other RTS engines deal with it, but I decided to break the map up into a grid of rectangular nodes, each of which has a flag for occupied or not. When a unit is ordered to move, it runs the A* search algorithm using euclidean distance as a heuristic to find the optimal path. The current version is a little glitchy, but it seems to work. At the moment it is very crudely coded and would break if multiple units existed on the game or if the pathing blockers moved. I need to clean it up a little, but it's a good proof of concept right now.
I'm not sure how well A* will work as my game becomes more complicated. Right now the engine assumes units can only move to nodes adjacent to the node it's currently in. If I implement any sort of teleportation, I have no idea how to deal with it yet. If teleportation is done by a fixed teleporter, I guess I could test paths to the teleporter and see if they're shorter than direct paths. That doesn't scale very well with large amounts of teleporters, but it might not matter if I can assume there are always few teleporters. There are a few other tricks to A* which I don't entirely understand yet which might cause A* to get non-optimal paths.
Recently, I decided I wanted to work on my RTS engine more. Fortunately I was using git at the time and found an old backup. I hooked up my old repository to GitHub and started working on it about a week ago. Fortunately my coding was neat enough so I didn't have to spend a while figuring out what it all meant.
Over the last week, I focused on implementing pathing. In most RTS's, units automatically find paths around obstacles. I don't know how other RTS engines deal with it, but I decided to break the map up into a grid of rectangular nodes, each of which has a flag for occupied or not. When a unit is ordered to move, it runs the A* search algorithm using euclidean distance as a heuristic to find the optimal path. The current version is a little glitchy, but it seems to work. At the moment it is very crudely coded and would break if multiple units existed on the game or if the pathing blockers moved. I need to clean it up a little, but it's a good proof of concept right now.
 |
| Path 1 |
 |
| Path 2 |
 |
| Oops |
Friday, December 16, 2011
Screen
It's almost finals week, and that means I'm finally done with assignments and only have to study for finals. Before really diving into studying (my first final is on Monday), I decided to take a break and relax.
One of my current pet projects is about terminal emulators. In just about every terminal emulator I've tried (such as gnome-terminal, terminator, and many others) text does not get auto reformatted. That is, when I resize the window the text does not get reformatted to fit the new window size. Mac OS X terminals actually do auto reformat text nicely, as well as the GUI-est terminal I've ever seen. I wish I could get my hands on Mac's terminal's source, but it looks like it's closed source. The other editor is too GUI for me, although I might fish through it's source some day.
I discovered that screen partially does what I want. The output of programs like cat, less, and tail all get correctly auto reformatted. However, ls does not get auto reformatted. I haven't tested it much beyond that yet.
As an experiment, I decided to make have gnome-terminal run screen by default when I run it and do all of my work inside of screen. So far I've noticed almost no differences, other than the auto reformatting I described. The main difference is screen eats my normal ctrl-a for it's own commands. Ctrl-a a does work as a normal ctrl-a. I'm considering seeing if I can change the main screen key to something other than a, although I need to find a safe character first. Maybe I'll try to change it to Mod4-a instead.
In the meantime, I've learned a little more about screen. I learned about .screenrc, which as it sounds gets run when screen is started. Right now, this is my .screenrc:
startup_message off
vbell off
Pretty simple, it suppresses the startup message that screen normally displays and switches off the visual bell. The visual bell is similar to the system beep, except instead of making a noise it flashes the entire terminal for a second. Useful, but I prefer the beep.
For anyone interested in screen who hasn't used it much, one of the most important things about screen is how to use screen commands. Ctrl-a by default is the prefix to most or all screen commands (I'm not sure if there are others). Ctrl-a ? will give you the help menu.
One of my current pet projects is about terminal emulators. In just about every terminal emulator I've tried (such as gnome-terminal, terminator, and many others) text does not get auto reformatted. That is, when I resize the window the text does not get reformatted to fit the new window size. Mac OS X terminals actually do auto reformat text nicely, as well as the GUI-est terminal I've ever seen. I wish I could get my hands on Mac's terminal's source, but it looks like it's closed source. The other editor is too GUI for me, although I might fish through it's source some day.
I discovered that screen partially does what I want. The output of programs like cat, less, and tail all get correctly auto reformatted. However, ls does not get auto reformatted. I haven't tested it much beyond that yet.
As an experiment, I decided to make have gnome-terminal run screen by default when I run it and do all of my work inside of screen. So far I've noticed almost no differences, other than the auto reformatting I described. The main difference is screen eats my normal ctrl-a for it's own commands. Ctrl-a a does work as a normal ctrl-a. I'm considering seeing if I can change the main screen key to something other than a, although I need to find a safe character first. Maybe I'll try to change it to Mod4-a instead.
In the meantime, I've learned a little more about screen. I learned about .screenrc, which as it sounds gets run when screen is started. Right now, this is my .screenrc:
startup_message off
vbell off
Pretty simple, it suppresses the startup message that screen normally displays and switches off the visual bell. The visual bell is similar to the system beep, except instead of making a noise it flashes the entire terminal for a second. Useful, but I prefer the beep.
For anyone interested in screen who hasn't used it much, one of the most important things about screen is how to use screen commands. Ctrl-a by default is the prefix to most or all screen commands (I'm not sure if there are others). Ctrl-a ? will give you the help menu.
Thursday, December 15, 2011
New plan!
So, about a month and a half ago I took down my new blog due to a bot attack and hadn't gotten around to putting it back up yet. I just started working on it again today, and decided against restoring my drupal installation. It was causing me some trouble, (I foolishly tried to update the installation while bringing it back) and I'm planning on completely overhauling my site over January. I decided that for now, I'll stick to using this blog.
Speaking about that, I'm planning on redoing my whole site to combine my original personal site, alex.willisson.org and this blog while revamping it's look so it doesn't look like it hasn't been updated since the 90's. As much as I like having beautifully simple coding, a background that doesn't blind the user, and a site that scaled to any browser with the same block of code, it looks pretty bad. My new site will probably be based on Movable Type, and hopefully someone I know who actually knows how to make websites look good will be helping me design the site.
Subscribe to:
Posts (Atom)
Posts
