Niemand

It's true that the contest was never restricted to BoA, but on the other hand judges were never required to get BoE to work and learn to play it, either. For the most part this was a failure on the part of the organizers to make a decision.

Sorry guys, I really dropped the ball on this. On the other hand, it's now basically the Christmas holidays, so. . . anyone still interested?

Congratulations Handyman, and also to our other, esteemed competitors! Looks like I'll need to get my act together and get my entry out to the general public.

No they are not. They're stored in a very old-fashioned way: Each sheet is a separate PICT resource (image) stored in an alternative part of a file, the resource fork. Virtually no one uses this technique anymore, and while the OS still supports it (for now), there's very little modern software for working with data stored in this way. Conceptually, it's about the same as if the images were in a folder, but practically it takes special software to manipulate them.

Okay, now that I know exactly what you mean: 1) This requires more work on Mac OS: adding item graphics, for example, requires adding the sheets to the Item Graphics file, which requires software no one who isn't either a BoA designer or old-school mac programmer is likely to possess. So, to be cross platform you would need lengthier instructions or an installer program. 2) The game enforces this: Quote: When a party leaves a scenario, all of the items in their inventory come with them. The exception is that some items will be lost: . . . Items that have custom graphics. If it implements this by checking (it_floor_which_sheet<1000 || it_floor_which_sheet>1048), even if you add a new sheet to the games graphics collection, it will be treated as 'custom'. This is what I was trying to say above, but I didn't express it very well. Note also that I don't know that this is the how it works, it's just a worst-case scenario guess. Testing is necessary to know for sure.

I'm not quite sure what you're suggesting here. Certainly, once BoA is installed we can add more graphics to the default graphics files/directories, but we can't change the contents of Jeff's installer, so they would be 'default' only for those of us who have added them, not for anyone who downloads and installs a fresh copy of BoA. I assume the reason behind this is that items with non-built-in graphics can't be transferred among scenarios. (Sadly, it didn't occur to Jeff to cache the item graphics with the party data. This would have been really elegant on Mac OS, but ugly on Windows, I guess.) However, off of the top of my head I'm not sure exactly how the game determines that an item is using a custom graphic rather than a built-in, depending on how it does this merely adding a graphic to the built-in collection might not be enough to convince the game to preserve items using that graphic.

I was figuring it would be complicated based on your statement that "Multiple variables can be changed at the same time." This would require a much more complex user interface (and code to handle that interface) than just picking one variable to find-and-replace on at a time.

Quote: I am now looking at a monster version of Change Terrain Randomly. Firstly, there will be no randomness. Secondly it will be possible to change a lot of the features of monsters: attitude, scripts, some memory cells, timing details and so on. Pressing an LED will select variables to be changed. Then you can enter the old value to found and the new value to replace it with. Multiple variables can be changed at the same time. Why? Is there any demand for this rather complicated feature?

Have a look at the game's page; it should give you a good overview.

Quote: Just finished Towers of Midnight a minute ago. I'm looking forward to it a great deal, but I'm waiting until christmas break to read it. (Technically I'm waiting until christmas to be given my copy.) In the meantime I'm reading old Analog magazines; my grandparents recently moved out of their house into an apartment, and my grandfather gave me his collection of magazines, containing most of the issues since 1966. At the moment, my living room is literally filled with an approximately lifetime supply of science fiction short stories.

Quote: I figure the Windows code should work for Mac I'm sure it will; I just need to find the time to make new button images and put it in.

I doubt he has, and I doubt he will (although I'm still hopeful): all objects and stains are accounted for, but no fields. This kind of makes sense since (with the exception of quickfire) fields are ephemeral, so placing them ahead of time wouldn't do much; they would likely fade before the party would see them. Since quickfire is a special case though, maybe Jeff assigned it a code.

I think there's a way you could make this work even in case the party tries to shop twice. It's similar to what you mentioned already: Quote: SDFs make dialogue into a versatile tool. Added another node: "I'm busy, come back when flag (0,17) is set back to zero." sort of thing. What you do is that when the party tries to shop, you first check whether the flag indicating the start of a transaction is already set. If so, you do whatever it is you want to do to complete the transaction (e.g. record the change in gold). Then, you set the flag and start a new transaction. Then, you need to duplicate the code to complete the transaction in other places to make sure that it always gets run eventually (and probably before the player has a chance to do anything else to modify the party's amount of gold). So, you would probably want to put it in the town's START_STATE and also in the code of any other nodes in the dialogue which depend on the amount the party spent.

Originally Posted By: Celtic minstrel Inferring boats and horses from the INIT_STATE of the scenario script is fine though. Inferring could be reasonable. Maybe. Keep in mind that technically you will have to run the state to find out whether it actually initializes any boats or horses, although we could probably do something more simplistic that would be close enough, since if anyone puts an infinite loop in that state he'll have much bigger problems than confusing the editor. Originally Posted By: Ishad Nha Editor will be used to alter the scenario script file This does not sound like a good idea. I assume that the idea would be to let the designer place boats and horses in the editor, and have the editor modify the script state to add the necessary code. It would mean that the editor would need to not only understand the code, but also be able to make modifications without messing anything up. Originally Posted By: Ishad Nha I can get the horse and boat icons to show for large and medium views. Next will be large 3D view. Tokens are something I have no experience of, so the hard part will be getting the Editor to read the create boat and create horse calls. To read them and only them. I assume you mean that you're just testing out drawing them, not actually parsing a script and depicting the data you've read. Keep in mind that to solve this problem, one technically cannot read only the calls of interest, but must read and understand the entire surrounding area of code. Consider: Code: beginstate START_SCEN_STATE;i = 0;while(i<6){ if(char_ok(i)) set_flag(10,i,1); //oops, never increment i}create_boat(0,0,29,15,0);break; Since the loop is infinite, this code never actually creates a boat at all. In general, the only way to discover this is to actually run the code. (The most charming aspect of which is that it may, of course, fail to ever terminate.) This example is a bit pedantic, but here's a more plausible one: Code: beginstate START_SCEN_STATE;//put in a row of boatsi = 0;while(i<3){ create_boat(0,0,16,i,1); i = i + 1;}break; It's not terribly likely that anyone will write something like this, but there's nothing stopping them from doing so, and no simple textual analysis will correctly determine (in general) that this code in fact creates three boats. So, one must use fairly advanced techniques to parse the script code, or restrict the code which the editor can understand to a very simple form or set of forms. Either of these is doable, but a significant amount of work is involved. Also, there is the issue of the (scenario) editor and a text editor likely potentially making concurrent modifications to the script file on disk. There's nothing terribly special about this problem, since anyone can cause it for himself just by using two text editors, but in this case the probability of it coming up is substantial, and there's no reason apparent to the user that it should, so it would need some consideration, I think.

Quote: As for the 4919 problem I will need to check the source code at some point. Edit: That is a remnant of something found in earlier versions of the source code, it should mean nothing. Yes, it looks like something vestigial that ought to be removed. The variable into which the graphic is loaded appears literally never to be referenced anywhere else. Quote: So that'd make it a remnant of a feature that was commented out originally, or that you were going to add and didn't properly excise when it didn't pan out. I'd actually be less concerned if it were the latter, the mere possibility that you uncommented some buried relic of Jeff's already less-than-stellar code gives me the heebie-jeebies. It's hardly worth making this big a deal out of. It's stupid, it's broken, and we should fix it, but it's not as though this is software for a vital communications satellite or a nuclear submarine. In addition, this is hardly the only useless left-over code in the editor, it just happens to be one that makes itself noticed by being annoying. Quote: doesn't have the annoying 'click' sound present in every other version of the editor Does the Windows editor not have a preference switch to turn off sounds? EDIT: It seems that this change got in in revision 58, and while I didn't check thoroughly, it doesn't look like it ever did anything. In revision 70, it is gone again, as of just now. (The code appears to compile, although I can't entirely verify this at the moment, since I'm working on my Mac.) Today's lesson: check svn status and svn diff before you commit, so you know what you are committing.

Quote: From what I can see the game will accept the inserted mirrors. My party was pushing mirrors around a town okay. Excellent! Quote: my number scheme has no fields in it, there are only objects and stains. Right, I was mis-categorizing the two barrier types as fields. This does, as you point out, make quickfire look like a longer shot, but mirrors are a nice addition. Happily, there's a nice little space where I can fit in buttons for them, too, in the Mac version's button palette. (I really need to make another attempt at rearranging the Windows version's layout to match, but it was such a dismal failure the two times I tried it before. So many changes desperately need porting.)

Some of these are obvious in the code, but others aren't, at least anywhere I can think of. For example, how do you know the indices of the mirrors? Secondly, does the game actually honor all of these? The reason I'm suspicious is that I had pieced together most of this list in another thread around here somewhere, but have been discouraged by noting that while the stains are stored with numbers in the order expected from the values recognized by the game's is_stain_on_space() and put_stain_on_space(), the objects and fields are not, instead being mixed together haphazardly. Note also that the 8 types of stain, 7 objects, 7 fields, and blocking total up to 23 items. Jeff may have just decided to put them in a really strange order, or he may have left some of them out. We'll just have to test to find out.

Quote: uninstall newer and install older. It doesn't sound like he should do that. If update 8 installed cleanly, he should have the latest version of Java available (for Mac OS). Master1, try running Code: java -version in a terminal window. (We really should have done this to start with.) If it reports version 1.6, you're as done as you're going to get; otherwise you'll need to try something else.

I had somehow not noticed the Word version of the Docs. I would indeed be good to edit that and keep it up to date, and I would be most grateful if you wanted to take on the task. In the long run it would probably be best to convert the document to LaTeX or similar (and a few minute with Google indicate that there are numerous methods that could be tried for performing such a conversion automatically) so that it could be kept efficiently in version control along with the program source code, but it's far more important to have something correct available for users first.

According to the page for Java_for_Mac_OS_X_10_5_Update_8, that update is only available for Intel machines, but Update 5 says nothing about being invalid for PPC machines. In fact, I poked through it, and it includes a universal binary for Java 1.6.0_15 with PPC code. So, it appears that installing all Leopard updates on a PPC machine should give you Java 1.6, and you can always try downloading that update directly and installing it; (probably) the worst that can happen is that Installer.app tells you 'no'.

I remembered that there is SoyLatte, which claims to provide a recent version of Java for older versions of Mac OS, but I haven't tried it myself, and it might entail having to tinker with things at fairly low levels.

The original, Spiderweb supplied documentation is no longer entirely accurate. Around v1.0.8 I overhauled the editor's object selection system and extended it to include things like special encounter rectangles and town entrances. So, you can now select them much like creatures or items, edit their properties and delete them using the delete key. Please note, however, that v1.0.8 was still a bit buggy, and I would recommend updating to v1.0.9, which is the current version. The reason I changed the behavior of that particular cancel button is that, while documented, its behavior was not at all what users tended to expect (or at least what I, as a user, expected; I frequently deleted my town entrances by mistake under the old system) and I think that the new method for deleting entrances is more uniform and consistent with the means for deleting other things. Unfortunately, there is very little documentation of the changes to new versions; essential there are only the notes I post when I people know about a new version. I fully realize that complete documentation is a key part of a usable program, but since I don't have the base file(s) for the original documentation, I would need to rewrite all, or at least a lot of it, from scratch, which is a rather daunting task.

What version of Mac OS are you using? I find that the installed version of Java is "1.6.0_22" on my system, which runs 10.6 (Snow Leopard), and while according to Apple's developer documentation 10.5 (Leopard) comes with Java version 1.5, there are notes about updates for it including Java 1.6. If you're still using 10.3 (Panther) you would be stuck with Java 1.4.2 or some such, and it's my suspicion that if you're still using 10.4 (Tiger), 1.5 will be the best you get. (Confused by the version numbers yet?) It may be possible to install a newer version of Java from another source than Apple, but it would likely lack proper GUI support, which is likely exactly what you need if a normal desktop application is demanding Java.

Oh, of course! The terrains with the problems (506 and 508) are exactly the ones for which the characters need to be drawn on top of one icon, but behind the other. In the case of 507 and 509 the characters get drawn on top of both icons, so there's no confusion. So, there are two problems here, it seems to me. One is that the game is apparently using movement blockage as a heuristic to decide whether terrains are drawn after characters or before. The second is that in some cases it is necessary/desirable for one of a terrain's icons to be drawn before characters, and the other after. One has a limited ability to deal with the first problem by using the cutaway feature of terrains, but there's no way to deal directly with the second, since it would require more complication in the definition of terrains and in the engine's drawing code. Unfortunately, this leads me to conclude that using separate, adjacent terrains, as suggested by ES, is the only way to solve your particular problem.

I'm glad you've got at least a work-around, since I can't seem to grasp what's going on here. In your first post, you say that the terrain with problem shown in the image is 506; is the terrain one space west, which apparently works, 507?