Duskwolf

Blades of Exile is currently available under the GNU Public License, which requires that any publicly distributed modifications be published under the same license. In other words, if you use Blades code in your creations, you are legally required to release your source code.

You don't open applications "with" Classic - as long as everything is set up correctly, anything that's detected as a Classic application is automatically launched under the appropriate environment. Try redownloading the game? I didn't have any trouble running it, myself. However, I will note that there are a lot of glitches in the emulation. I'd recommend digging up an older Mac and running it under "real" OS 9 if at all possible - it's a much more pleasant experience.

By a user's request, I've created a "full version" of the outdoor map. It's obviously too large to include the whole thing here, but here's an appetizer: A 12 MB ZIP archive containing images of all 56 outdoor regions (including the empty ones) is available here: http://files.filefront.com//;8291303;;/ Note that there are a few glitches. In particular, certain border "frills" may be a little off, roads aren't displayed quite correctly, and a few terrain types I haven't decoded yet are displayed as black blocks with characters in them. I'll be releasing a corrected version, along with town images and the tools I used to create these images, as soon as I've got all the bugs (chitraches?) ironed out.

What, the map? As I mentioned earlier, it was mostly an automated process. All I did was decode and colorize it.

Sullust, I PMed you a link to a set of graphics which I'd posted on a download site. Did you get it? If anyone else is interested, it's at http://files.filefront.com//;8273443;;/ I don't have Exile I graphics, unfortunately. (I'd be interested in having them, though.)

Okay, that's really bizarre then. Perhaps it's a difference between the Windows and Mac versions?

Well, it would be, if Exile II allowed you to use flight there. Which it doesn't - if you start flying there and try to move, you get the message "Fly: Ceiling too low." This seems to happen whenever you're within 16 squares of the south edge of the world, probably to keep you from flying off the edge (although I don't think that ever becomes a problem).

No, there's no secret passage. I generated a full map, and the ledge is well and truly unreachable. Here's a close-up of the relevant bit - look at the lower left corner. The passage to get to the pits is through a secret door, but there aren't any secret doors to the part past the pits. The shortest path across the pits flies across five squares of pits (W, W, SW, W, NW, N), which is more than Flight or the Orb can manage. The rest of the maps are in this thread , BTW.

In Exile 2, there's an outdoor special node on a little ledge in the Spore Tunnels which is completely unreachable thanks to being located across 10+ tiles of pit, in a region where flight isn't allowed. It drops ember flowers. Bit of a letdown, if you ask me.

In fact, all special encounters were hard-coded in the Exile games.

I'm not sure I'd want to buy software from a company that's selling obsolete software , anyway.

I've got a Python script that'll "explode" a resource file into a directory full of data files. I don't have one that'll do the reverse yet, but I could probably make it if it'd be sufficiently useful. Interested?

The Exile games are kind of screwy under Classic, though. In particular, a few fights in Exile II would consistently crash under Classic, but run fine on a real OS 9 machine.

Sounds like you've got something screwy installed in your OS 9 partition. Try changing your extension set to Mac OS 9 Base (use the Extensions Manager control panel to do this) and see if that fixes things.

Here you go.

Incidentally, I just built BoE on OS 9 using CodeWarrior, and the windowed mode looked kind of weird there too. I think I figured out what was causing the menu-hiding weirdness, though. BoE defines "HideMenuBar" and "ShowMenuBar", but these were later defined in the Toolbox. Changing these to "DoHideMenuBar" and "DoShowMenuBar" solved a link error on OS 9, and would probably fix some of the startup weirdness under Carbon.

Exile II (my personal favorite) had most of the gameplay advances that were missing from the original Exile. Doors that opened, fields, more spells... if you haven't played it, give it a try.

The terms of the BoE license dictate that its code can only be reused in code that is made available under the same license. In practical terms, though, you're probably much better off writing your own implementation from scratch. BoE is very old and messy; trying to integrate its dialogue engine (which isn't really that complex anyway) into your own code is a recipe for frustration.

1008 mod 256 = 240 My guess is that the talking graphic is a byte-sized value. You'll have to use a picture ID below 256.

A first step in open-source BoE development should definitely be merging the Mac OS and Windows ports into a single source tree. Most of the code is indeed platform-independent (Jeff's confirmed this in another thread), so there's no reason it shouldn't be possible. More importantly, merging the two trees will make it less likely that development on the different versions will diverge in the future (which would be a Very Bad Thing). Even something as simple as generating a set of #ifdefs that'd conditionally enable code for the appropriate platform would be invaluable. As soon as someone's got a working Win32 version, merging it with the Carbon version should be a top priority. I realize this isn't a particularly interesting task, but it needs to be done as soon as possible to avoid creating an inadvertent fork.

Google Code would be an excellent option for hosting if it weren't for the license. They've got Subversion repo, wiki, downloads, and issue tracking. However, they limit projects to using a small set of open-source licenses: Apache, Artistic/GPL2, GPL2, LGPL, MIT, MPL, or New BSD. Wikipedia says the Common Public License (which the Blades code was released under) isn't GPL-compatible, and IBM\'s CPL FAQ says it isn't generally compatible with relicensing. I'm kind of wondering whether Jeff would be willing to cross-license under something less restrictive like the MIT License: Quote: Copyright © <year> <copyright holders> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. The main hang-up with the Common Public License is that it's got a weird clause about granting patents. It's well-intentioned, but ends up making CPL code incompatible with just about every other OSI license.

Big idea #1: Move Blades from a "statically allocated" to a "dynamically allocated" model. Specifically, right now, a lot of the scenario file format is based on a fixed number of "slots" for various things: 16 room rects and 30/40/60 creatures per dungeon, 30 boats per scenario, and so on. While coding Blades this way undoubtedly made certain things easier, it's also an unnecessary limitation. The zero-one-infinity rule applies here. So move to a dynamic model for everything. This would require a transition to a completely new scenario file format, but that's doable - compatibility can be managed by either leaving in support for loading old scenarios, or writing a converter. This would involve rearchitecting a lot of the internal data structures as well, but that's really less of a problem.

As far as I can tell, increasing the limit on the number of nodes executed in a single encounter is just a matter of increasing the constant at special.c:1655: Code: 1655| if (num_nodes >= 50) { The only effect of increasing this value would be that encounters longer than 50 nodes would no longer error out. Otherwise, functionality would be identical. There's a completely separate limit of 50 special nodes per town, which can't be increased without modifying the scenario format. Fixing this would probably be best accomplished by "dynamicizing" allocations throughout the program - probably a good idea in the long run, but not a small task. More on this in OBoE.

r4 is acting stranger than r1 did with regard to windowing. Now it starts up normally but sometimes adds a title bar to the fullscreen window during the startup process, right after the second splash image shows up. I can't figure out what's triggering it, exactly. I'll grab the source after I make this post and take a look at what might be going on. Also, "never show instant help" is completely broken. I'm getting instant help every single time I open the preferences window, whether I've checked the option or not. Rather annoying. Probably want to get rid of the shareware window, too. Replace it with "license info", perhaps? There's certainly no point in telling users that they can send in $30 to get the program on three 3.5" floppies anymore.

Khoth's Carbonized build works quite nicely on my PPC machine. It looks a little "off" in windowed mode, though - the content ends up shifted to the left a bit (maybe 16 px or so), and the splash doesn't quite draw properly. Haven't tried loading an old-style save, so no idea how that works. Issues with those are probably just a matter of a missing or an extra endian swap, though, and might not manifest on PPC anyway. Loaded its own savefiles just fine, though. And yes, the initial "i can has 256 colors plz" dialog is completely redundant under OS X. Kill it with fire.