Monthly Archives: October 2010

Missions of the Reliant: Receiving subspace message from Alliance HQ

According to my commit log, I’ve accomplished a lot, but I think a lot of that is stuff I’d already done and mentioned here, and just not committed. Bad programmer! Bad! No treat for you! Anyway, there is one thing I know hasn’t hit the blog yet, and that’s incoming subspace transmissions. Those are the big blobs of text in the middle of the screen containing all that awesome plotline Mike wrote. Nice stuff, if you ask me. Those work now, and they come in correctly via the helmsman, using the reports interface and everything. Only part that isn’t quite right yet is there’s no HQ text flashing at the corner of the viewscreen, but that’s easily done. I’m inching ever so slightly closer to having a fully implemented mission here.

Things still missing to make Assault on the Alliance completely functional:

  • Engineer functionality (repairing damaged systems)
  • Doctor functionality (healing wounded crew)
  • Starbase interaction (don’t actually need all of it to make the mission work, though it won’t be as much fun without a Mat-Trans or crew swapping)
  • Cruiser and battleship AIs (actually less complicated than the fighters)

That’s all! Stay tuned for more progress!

The dangers of games

As a programmer, I have the dubious pleasure of enjoying overcomplicated, highly technical games such as EVE Online. For those who don’t know, EVE is an MMORPG that functions essentially on the opposite premise from World of Warcraft. Pretty much nothing is done for you in EVE. There’s a million ways to screw up and nothing you can do once that’s happened. It’s rather like real life in that way. Despite its poorly-done Python UI and downright pathetic Mac port (it’s the cider wrapper layer on top of wine emulation), I enjoy the game, primarily because it exposes so much of the “nitty-gritty” details of how its universe works. A player has control over very detailed numbers and data relating to the functioning of their spaceships and even their bodies. Often it’s too much data; it’s very easy to forget one tiny thing and lose millions of ISK (in-game money) and a great deal of time because of it. Neglecting to bookmark a wormhole exit comes to mind. EVE also does nothing for you. To install implants or activate jump clones, you have to manually pause your skill training queue, for example, even though this is something the game could very easily do for you, and there’s no apparent reason to make the player click the extra four buttons.

In any case, the thought behind this whole bit is, games are addictive. This is not a new discovery, for the world or for me, and I don’t expect anyone to be astonished by the revelation. For people such as me, who fall in love very easily with inane technical details and exacting numbers and gated progression (the need to finish task X before being able to learn the details of the task Y that follows), EVE is particularly so. It’s easy to say “I’ll just do one mission and then get to work,” and in a game like World of Warcraft where quests or even group dungeons are typically short these days (vanilla WoW notwithstanding), that would mean an hour of playing a game and then several hours of productive time. Setting aside the question of the “well just one more” syndrome, which is another problem altogether, the same comment made about EVE usually involves suddenly realizing I’ve spent six hours I meant to use for coding just finishing the one task! It always takes longer to blow up NPC ships than the mission description suggests (even using the Cliff Notes available online). Then there’s travel time between areas of a complex to consider, especially in a slow ship like most of the more powerful ones, and time spent salvaging wrecks (an extremely profitable activity well worth the effort if you have the time to spend, especially on more difficult missions), and then there’s organizing and selling/using whatever you gained from the mission and the salvage.

EVE unfortunately has the problem that for some play styles (including mine), play consists of paying intent attention to the same thing happening over and over for an hour or three, most of that time spent with no user input (and what input there is is also repetitive). Taking one’s attention off for a moment lends itself to finding the entire effort wasted. This would be a spectacular thing for some forms of autistic, but I’m not one of them! Oh well. I still like the game, because there’s a very real sense of accomplishment to completing various tasks.

The upshot of it all is that the existence of such games tends to sap the time I’d otherwise spend making progress. Yet, if asked if I’d rather the game be taken away, I have to say no, because I still need the distraction. What I want, really, is more control over the length of the distraction. “Just do it” doesn’t work for everyone, people!

I would recommend EVE Online to compulsives and the technically minded. I would not recommend it for those who don’t have the patience to wait before being able to explore facets of the game. Some of the higher-end stuff takes literally months to gain the skills for.

This post didn’t really have a conclusion, or a solid point. I just kinda felt like getting all that out. :-)

Lua + iPhone = mess

And now one of the rare not-Missions-related posts.

I found myself with the need to run Lua code under iOS. Yes, this is legal according to the current Apple Developer Agreement. Who knew the journey I’d undertake in the process.

Originally, I got it running by just building the Lua source files into a static library and linking it in, then using the C API as usual. Worked like a ruddy charm. But then I decided to get clever. “Wouldn’t it be great,” I thought, “if I could run the bytecode compiler on the source and make them into unreadable bytecode objects?” So originally, I tried piping the source files through luac and running them otherwise as usual. The story of how I got Xcode to automate this process without a damned Run Script build phase is another one entirely.

Bad header in precompiled chunk.

Docs say, “The binary files created by luac are portable only among architectures with the same word size and byte order.” Fine. x86_64 and armv[67] are both little-endian, but sizeof(long) on x86_64 is twice what it is on armv7. Duh! Running Stuff on Apple Systems 101. Universal binary, here I come! I built lua 32-bit and lipo’d myself a nice universal binary of luac, ran it via /usr/bin/arch -arch i386.

Bad header in precompiled chunk.

What? Byte order and word size are correct. So I delved into the Lua source code. lundump.c, lines 214-226. Precompiled chunks are checked for version, format, endianness, size of int, size of size_t, size of Lua opcodes, size of the lua_Number type, and integralness of lua_Number. All of which should have been correct- until I remembered that I’d changed the luaconf.h of the iOS binary’s Lua to make lua_Number a float. It’s a double by default.

Rebuild my universal binary of luac using the same luaconf.h the iOS project uses. Run it through yet again. Lo and behold, it worked that time. It doesn’t really feel right to me running i386-compiled bytecode on armv7, but since Lua doesn’t even remotely have support for cross-compilation and I don’t feel like jumping through the hoops of making a luac utility on the device without jailbreaking, it’s the best I can do.

I would be remiss if I didn’t remark also upon the journey of learning how to make Xcode automate this process for me. There was more than just running luac to be done. I wanted my Lua scripts run through the C preprocessor, to get the benefits of #include and #define. Easier said than done. The C preprocessor doesn’t recognize Lua comments, and while because comment stripping is part of preprocessing I could have used C comments instead, it would have meant changing a goodly bit of code, and messed with the syntax coloring. And more importantly, my sense of code aesthetics. It’s always bothered me that the C preprocessor can be both Turing-complete and damn near impossible to work with (an aptly-named Turing tarpit). So I wrote a pre-preprocessor (also in Lua, naturally) to strip the Lua comments out first. But then I had to parse and handle #include manually. Oh well. The real benefit of C preprocessing is the macros anyway. It was quite an interesting bit of work making Lua talk to clang; the built-in library for doing things is a little bit lacking. Anyway, the upshot was there were three steps to processing Lua files in the iOS project: preprocess, luac, copy to Resources.

I finally caved in to my sense of danger and went looking for the extremely scanty reverse-engineered documentation on Xcode plugins. It was pretty awful. The API looks to be quite a mess of inconsistently named attributes with strange side-effects. It took me two hours to hunt down the cause of a “empty string” exception as being the use of $(OutputPath) inside a cosmetic attribute (Rule name). It was hardly perfect even when I declared it done, and then I realized I had the architecture problem again. I had to run a different luac for x86_64 than for everything else. If i386 was the only other architecture, I could’ve just let it be done by a universal binary, but no, it had to cover armv[67] too. Ultimately it turned out a second plugin was necessary, lest Xcode be sent into a downward spiral of infinite recursion at launch. Ugh. Don’t talk to me about all the horrifying effects the tiniest typo could have on Xcode. I love the one in particular where the application was fully functional, except for builds and the Quit command. Uncaught Objective-C exceptions equals inconsistent program state, people. And it’s not just that the API is entirely undocumented. You get those sorts of weird behaviors even if you never install a single plugin or specification file; the Apple developers don’t always get it right either. The application is a horrid mess, and I find myself desperately hoping that Xcode 4 is a full rewrite. I can’t discuss anything about Xcode 4 due to NDA, of course.

As a side note to all this, compiling extension modules for Lua also turned out to be an unmitigated nusiance. It turns out, you see, that the extension authors out there tend not to run their code on Darwin-based systems, and so all the ludicrous quirks of dyld tend to hit a user of their code smack in the face. Finding out that I needed to pass -bundle -undefined dynamic_lookup to the linker instead of -shared was easy enough from the Lua mailing list posts on the subject. Figuring out why that didn’t work either meant realizing I’d built Lua itself with -fvisibility=hidden for no good reason at all, causing the dlopen() calls to crash and burn. Figuring out why my self-written pcre interface module randomly crashed with a bad free() during Lua garbage collection meant debugging and valgrinding like nuts until I found out you’re not supposed to link liblua.a to the extension module. Static library + linked to both loader and module = two copies of the code. Anyone’s guess which you get at any given time. One could only wish dyld was able to make itself aware of this ugly situation.

If anyone’s interested, give a holler in the comments and I’ll post the pcre extension as an opensource project. It’s not fully featured (in particular it’s missing partial and DFA matching, as well as access to a few of the more esoteric options of the API), but it does work quite nicely otherwise. It’s built versus PCRE 8.10 and Lua 5.1, and is upwardly compatible with the still-in-progress Lua 5.2 as it currently stands.

I promise I’ll get some work on Missions done this week!