Niemand

I would be happy to help with testing, although I haven't quite managed to get the groundwork in order yet: I've compiled and installed Mono, but so far I can't get it actually to work. It looks like to get anything graphical to run Mono actually needs a bunch of other stuff installed, and so far I haven't quite been able to figure out how to get glib without all of GTK+, which I would prefer to avoid. I'll take another shot at it tomorrow (since I probably just need to use Google more effectively to find the appropriate tarball). Hopefully I'll get that working soon, so if you have something you would like tested feel free to send it to niemandcw(at)gmail(dot)com with instructions for what you want done.

The default behavior isn't very useful, since it can easily put a game into an un-winnable state. I, for one, see no problem with your choice to alter it. Absolutely. Avernumscript is very slow, as can be seen when designers ask it to do too much. (See for example, A Visit to the Madhouse, which accumulated a fair number of complaints because of frequently running creature scripts.) However, in this case I think you're probably fine, since you're only putting in a single conditional. If you really feel paranoid, you could factor out the body of the conditional into another state and brach to it with set_state_continue() so that there's very little code actually in the START_STATE. (Assuming the interpreter in the game works as the pieces of it leftover in the editor do, even when the body of a conditional is skipped the skipping takes time proportional to the amount of code skipped.)

(Bump) The bug should be fixed and version 1.3.1 is released. Use the 'Check for Updates...' menu item and you should be able to download it directly. Tridash: The same bugs will need to be fixed in the Windows version as well; I'll try to see to it later today, but I thought I'd mention it in writing here in case I forget.

I can reproduce such a crash with r91; I'm looking into why it happens now. It doesn't crash if the first thing I do is creating an Area Description, but it does if I already had an Area Description selected and I create another, or if I add one, delete it, and then add another. I have the bad feeling that this is my fault; something to do with wiring up the undo code. EDIT: I found the problem; a pointer was being initialized to a garbage value due to a typo. This actually affects every undo record of a change which alters a string, not just area descriptions, so I think I'm going to bump the version number to 1.3.1 and make a bugfix release. EDIT 2: It turns out that undo was completely broken for creating and deleting area descriptions anyway. I think I have it fixed, but I made enough changes that I want to take another look at it in the morning (when I trust myself to think a bit more clearly) before I check it in. If it still looks okay then, I'll proceed with the release. (There's also a QOI issue with the description strings for creating and deleting objects and how they change when moved between the undo and redo stacks that I just noticed, but rather than risk breaking stuff that works, in an ugly way, in an attempt to make it pretty, I think I'll leave it alone for now.)

It's good to know that this is possible, although it comes with the disadvantage of having to enter dialogue mode, which may look rather odd, depending on why you wanted to invoke a town script state.

Yes because we definitely need to have an even harder time telling which version is the most up to date and actually has the most bugs fixed. (Not that my opion counts for much, since I hardly contribute anything to BoE, but I personally detest git, and have been repeatedly annoyed by open source projects which I use moving to github and then metastasizing.)

What do you mean by 'entering the value'? Writing it into your scenario data script? If the next creature definition doesn't use `clear` or `import` then it will inherit all of the properties from the one you edited, causing them to cascade to it and possibly other definitions.

BainIhrno: It sounds like you have an old copy. I'm also on 10.8.2 and the version on my website works for me.

I can test this, but the answer is very likely to be no. The Mac editor certainly can't handle this, and I think that it probably uses the same Resource Manager interface for opening the resources (since we have never changed it from Jeff's original code). EDIT: No, the game can't handle it.

You really don't need to worry about the features of HFS; you just need to know the magic suffix to append to a file name to indicate that HFS should treat the file as the resource fork of the same file without the suffix. In fact, having remembered more of my own planning, I realize that we, or at least I, have been overthinking the problem somewhat. If you want to handle this feature (which is really a rather minor one compared to getting the rest of your editor working), you only need to be able to write bitmap data for images using a very limited subset of the PICT format, write that data within a resource map format (for which we have the code I linked above as an example), and write the resource map data to a tar format (which is easy and for which I already have code). You never actually need to do any reading of this data, since while doing so would be nice, it is irrelevant, because it cannot exist on your filesystem.

(Sorry it took me a while to get back to you, I haven't been the most attentive of late.) As far as other tactics go, a lot depends on how you've distributed your skill points and what items you've been able to scrounge up. Things like bows and thrown missiles can be very useful because they can let you do melee-type damage to enemies well across the battlefield. Wands and scrolls can also help, since they can let your fighters cast offensive spells, in basically the way that potions let any character do the equivalent of casting a defensive spell on itself. Another handy trick is that using an item from your inventory only takes 3 AP, and you get 4 AP by default. So, a fighter can drink a potion and then still take another action, like striking an adjacent enemy with a melee weapon, firing an arrow, or using a second item. Similarly, a mage who is out of energy can drink an energy potion, and then immediately cast a spell.

Sorry, I hadn't meant to imply any lack of competence on your part, just that the code wouldn't be directly useful as a library the way I had intended. The best resource I've found on the PICT format is this: http://developer.apple.com/legacy/mac/library/documentation/mac/QuickDraw/QuickDraw-458.html]http://developer.apple.com/legacy/mac/library/documentation/mac/QuickDraw/QuickDraw-458.html . I dug up my old code and worked on it a bit this evening, and got it to the point that I can read in a PICT resource and correctly interpret most of its header data and a few opcodes. I threw everything into a tarball so you can look at it or try it out. In particular, there are some files you could work with if you want to test your own code. I moved their resources to the data forks so that they can survive as normal files on non-HFS filesystems.

I don't quite see why this example is hard, unless space is very constrained; the 'S's are replaced by a single special rectangle, which is moved away from point T until the party is guaranteed not to cross it (4 spaces away for if there are no joinable NPCs in the scenario). This would only fail if for some reason there isn't enough room to move T and S apart.

Both points are true. For the Mac Editor we've transitioned to storing the editor's own graphics (those not already present in the game itself) as png images stored in the application bundle. The images which are in the game we just read from its files, which shouldn't be a problem for you since the Windows editor will only need to read the Windows game's files which should be easy. I'd recommend just being lazy and doing what the existing editor does: if it doesn't know where the game's files are, ask the user to locate them for it, then remember the result. I think that this is probably true; I have been working on this off and on with an eye toward making at least a command line version of Graphic Adjuster for use on Windows. The idea was to take the the Windows BMP graphics and write out the cmg file inside a tarball (to ensure proper preservation and handling of the resource fork). I already wrote the code for writing the resource map, but I haven't yet started on the PICT writing code. I'd be happy to share what I have so far or write in the future, but I guess it wouldn't be useful for direct inclusion in your editor (I've worked in C++ as I usually do). You could always just use it as a subsidiary tool, like the way that AScript just bundles a copy of alint.

I would say that your option 1 is probably usually better if I understand the original purpose of this construction correctly, that is, to trigger the special more-or-less immediately, regardless of what the party does. This won't work, however, if one of the things you need it to do is to move the party to another town, as that is only allowed as a result of the party stepping into a special rectangle. For option 2, I think it may be sufficient to surround the first member of the party (although I don't remember for certain whether special rectangles are triggered if a later party member is already inside and the party leader switches places with that character, that would have to be checked). This can still be a bit tricky, though, since you would need to deal with the party placement rules, which as I recall begin by placing the last party member and then laying out the rest where there is space.

You mean the scenario graphics in the cmg file? Yes, this is a very old style Macintosh resource format, but that isn't the primary problem. The resource map itself isn't all that complicated, so it's not too hard to duplicate enough of the Resource Manager's functionality to read and write them; the real issue is the format of the images themselves. They're stored in PICT format, which is more-or-less a compact binary serialization of calls to the Quickdraw graphics library. While around here we mostly only deal in PICTs that contain a single large bitmap, even reading that might require reimplementing a fair chunk of Quickdraw, and I'm not sure how often our data uses other features.

A BoA outdoor section is definitely capable of holding 8 town entrances, which appears to be the same as BoE. Entrances are only ported if both of their coordinates (in BoE) are greater than 0, and if the town to which they connect is non-negative. I'll see if I can take a look at this case later and tell what's going on.

There are a few things you can do that may help. For one thing, if you haven't already cleared out some of the other easier areas, like the bandits and undead, you can do that to gain more equipment and perhaps another level. You can also enlist the help of the spectre to get some extra melee capability. It isn't quite clear to me whether you're using a party of just two fighters, or you have a larger party of which two are the primary fighters. In the former case the going will be tough, but you may be able to win by using potions, or by having you're character invest in some basic spellcasting. In the latter case you should have you're other character provide support like blessing and hastening. I don't think any of the rats is particularly fast, so only a couple of them can sometimes get two attacks per turn, but if you you use haste you can guarantee giving your characters two attacks per turn. There's no specific level of of hardiness that will suddenly solve your problems; its effect are fairly small. (I'm not certain of details, but the game's description suggests that having N levels of hardiness means that the damage you take can be reduced by up to N, so when enemies are dealing over 20 damage trying to block it all with hardiness clearly isn't feasible.) More Endurance may help; I'd recommend that your lead character should probably have at least 7 levels or so, but it's probably also impractical to raise that stat alone high enough to be able to just soak up all of the damage in the largest fights without needing healing.

It's not hard; similar to BoE you make a resource file with the images in it and set various definitions to refer to particular parts of the images. The main difference is that the graphics are split up into groups in multiple images rather than all put together into a single big image.

One legitimate reason to be interested in asteroids is for mining, I think—the vast majority of the metal on, or rather in, Earth is buried unreachably inside the core. A metal bearing asteroid can't hide its contents near as stubbornly, although we obviously have no experience yet with mining in vacuum and microgravity. For decades asteroid mining has been a staple of science fictional economies, and while that doesn't automatically make it advisable to pursue, it seems worth investigating, and it can be hard to tell whether something revolutionary will actually work until you make a serious attempt at it. I heartily agree with he interest in manned spaceflight in general, as well. No (sensible) person says that it will be easy, but the very long-term potential can be huge.

I'm still around, and always up for a new scenario. What databases do you mean? I'm pretty clueless about BoE stuff, but I'm happy to try to convert file formats or something if I can.

I've long dreamt of replacing the existing editor with a proper IDE for handling all aspects of scenario design, but I've always stayed away from tackling it on the grounds that I know my free time is limited and it seemed better to take what we have and make it at least a bit more functional. On the whole I think it's been a good choice, but I'm happy to see someone looking into doing this the 'right' way for the long term. It is rather annoying to keep four to five different applications open while designing (The 3D Editor for the scenario file itself, a text editor for scripts, Graphic Adjuster for manipulating resources, Preview for reading documentation, the game itself for testing. . . ) Stuff like drag-and-drop to rearrange the outdoors (or the towns, or whatever) would be very nice. At least on the Mac side the current editor is handicapped by the fact that we're stuck with a variety of truly ancient libraries (we still depend on numerous APIs that predate Mac OS X, and we're painfully aware that Apple doesn't expect these things to be used or even necessarily to work anymore). The existing code is deeply intertwined with how these particular libraries work, so modernizing is the same thing as rewriting in many cases. Probably the worst offender by far is the 'abstraction' layer that's supposed to insulate the rest of the code from the system dialog display machinery, since it mostly makes it hellish to add even simple dialog boxes. An object definition editor is an interesting problem because the object definition language both allows an object to inherit properties from a preceding definition and any given object type may be multiply defined. You can see how this arose when you look at the rather simple code used by the game (and editor) to load these definitions, which just plods through dutifully carrying out the instructions in order until it reaches the end, but representing the whole thing at once and allowing changes in the middle is tricky. (If item 499 has 8 definitions, each of which is the parent of a distinct other item, and the user wants to edit it, which one should be changed?) I think it might be possible to use the fact that no one actually uses the full capabilities of the language; instead we mostly stick to simple patterns that can be recognized (like the odd little dance that happens when I just want to alter a couple of the properties of an existing definition without writing the whole thing from scratch). I see you're going to be using a different storage format for scenarios. This is something I've also talked about doing for a while, that might end up being added to the current line of editors (if there's a good reason). I'm curious about the details of why you want to use a different format, and what you plan to use. My concern was never about the 'in-place' modification of the scenario file (in fact while the current editor is rather limited by keeping only a part of the scenario in memory at a time, we've worked around a lot of this, and the limitation also isn't inherent in the file format, just the current code that reads it). My main reason for wanting a new format was so that scenarios could be easily stored in typical version control software, and to that end I had in mind a relatively bulky, textual format. Clearly part of your reason is that you want to introduce new data that the current format doesn't include, like the user's customized aliases. That concern seems orthogonal from my main one, so conceivably we could make a standardized format shared by your editor and whatever the current editor may turn into. Does this seem like a productive thing to try to do? I fear the answer may be no, however, because of the far-reaching implication of your alias system, since even the script code users generate with your editor potentially still has to be 'compiled' into the actual scripts that the game can run.

You don't necessarily have to have a debug build, but you probably need debug symbols to be able to tell which function is which. A debugger usually isn't helpful for answering this type of question, you usually need a dedicated profiler. On Mac OS I use Instruments (Shark was way better but no longer functions reliably thanks to neglect; good job Apple), and callgrind is an option on most unixy platforms. I have no idea what there is that work well for Windows, perhaps pages like this one are of some use. According to some random webpage I just read, running callgrind on Wine running a program may actually work and accomplish something, but don't count on it. The BoA editor definitely had out-of-control CPU use problems at one time, due to polling for events with an infinitesimal timeout. I fixed this in a really dumb way: most of the time it uses a large timeout 60 ms or some such, and switches back to the minimum timeout only while the mouse is being dragged. (Drag the mouse and keep holding to watch your CPU use go through the roof just like the bad old days.)

In good time for Christmas, a new editor version is ready. As usual, if you have a copy already you can upgrade it simply by using the 'Check for Updates' menu item, and otherwise you can get it from our downloads page. Notable features in this release are: A substantially more far-reaching undo system. You can now undo a host of operations like moving a creature, deleting an item, changing the text of a sign, or changing a terrain script's memory cells. The tiles window is now resizable, and the displayed size of the tiles can also be changed. The editor now has shortcuts to open the script corresponding to the current scenario, town, outdoor section, or creature in your preferred text editor. The window layout is saved when you close the program. Arrange your workspace the way you like it and it will be automatically restored the next time you want to use it. This release has been tested on Mac OS 10.4 (PPC), 10.6 (Intel), and 10.8 (Intel). Also, don't forget to thank Tridash for not only working on the coding, but also for reminding me to come back and do my part! ---------- As usual, we are sorry to report that Windows support lags behind. Tridash has been hard at work on it, though, and we hope to have a new and improved Windows release in only a couple of weeks. (We still do not expect to reach full feature parity, but the gap should be narrowing.) ---------- To go with the new Edit <Associated> Script commands, you might want a text editor that knows about Avernumscript. If that is the case, you could try out the newest beta version of my in-progress Avernumscript editor, AScript. I regret that I still haven't scraped together the time to do anything that could be called finishing it, but this version has a copy of alint which should work on both PowerPC and Intel systems, and a few more pages in the Avernumscript reference documentation.

@Actaeon: On the contrary, I certainly remember you. @VCH: It's good to know that my literally several minutes of work in AppleWorks::Paint weren't wasted. @Nikki: It's good to hear that you've been studying; computational dentistry is a very important topic for virtually everyone in our modern society.