Niemand

Quote: And I see that the updated documentation now needs to be updated again. Yeah, sorry about that. I'll soon be sending you my comments and suggestions on what we had so far, as well as things that ought to be added.

We (by which I mean mainly The Turtle Moves) have been working on bringing the original editor documentation up to date, but it isn't quite ready yet (in large part because I haven't gotten ready some things that I need to contribute to it), which is why the downloads page has 'Coming Soon' in that section. The bucket icon, as in every paint program I can remember using, is a flood-fill tool. When you use it on a particular spot, it overwrites that space and all adjacent spaces with the same original terrain.

Over the holiday break i got enough time to make some much needed updates to the editor. You can find the new version on the downloads page of the new editor website. You can also read about the changes on the changes page, but I'll summarize the important ones here: Added Sparkle support for updates - It will now be possible for the editor to detect updates automatically, download, and install them for you. Now build a (32 bit) universal binary - Only five years after their introduction, the editor will finally run natively on Intel Macs. Added support for placing movable mirrors - Tip of the hat to Ishad Nha for working out how to do this. Fixed a nasty crash when scrolling among outdoor sections after making changes. A more in-depth note about the first item above: Using Sparkle, updated versions of the editor are verified using DSA. The editor has in it one key, and I have the other. A result of this is that (if everything is working correctly), only I can issue updates via this mechanism. This is consistant with the fact that the URL at which the editor seeks updates is located on my website, where only I can add new data anyway. Should there come to be more people working actively on the editor and it becomes sensible to do so, I will happily share the private key with those other developers. Also, there is as always nothing to stop any interested person from creating a fork and including in it a new update key and new URL for updates. Users would have to download the forked version once manually, but after that it would be fully automatic again. So, even if I become unaccountably uncommunicative someone else can still take over the editor much as in the past. With regard to the new website: I decided that the editor ought to have a space of its own, particularly so we can more closely associate the Mac and Windows versions. It's not quite finished yet, though, as I still need to move over the old Mac versions, work out getting more information organized for the Windows version, and fill in things like documentation.

It will probably be a few extra months, perhaps about three, judging from Geneforge 5 and Avernum 6. There's likely a bit of programming to be done for porting, and then beta testing needs to be conducted.

Originally Posted By: Celtic Minstrel Originally Posted By: Sylae Corell I suppose since both Mac and Linux are UNIX based systems it should be fairly easy to do, right? Probably not... Mac's kernel may be UNIX-based, but I don't think most of the other API's would be compatible, especially the GUI. Right; the undertaking of replicating all of the higher level libraries would be a project of scale similar to WINE. (The differences between Mac OS and Linux may not be quite as big as between Linux and Windows, but they are still fairly fundamental, like a totally different executable file format.) There is The Cocotron, but it's intended to make porting easy, rather than to enable running unported programs, and it only intends to cover Apple's Cocoa/Objective-C libraries and APIs; it ignores the various other system libraries.

I already did almost exactly what you describe in the Mac version; you can have a look at image_resources/town_buttons.png and image_resources/outdoor_buttons.png to see what I did. I'd like the Windows buttons to be arranged as similarly as possible, but one key thing in the Mac editor is that I split apart the object palette drawing space, with its associated scrollbar, from the button drawing space, so that I could get in an extra column on the right side. I haven't been able to make this work in the Windows version, although I can make another attempt today. One other thing that will prevent them from being arranged identically right away is that in the Mac version I've already removed a couple of the old tools which were made redundant by the new selection system. One thing that I did not do is to replace any of the existing button icons. With a few exceptions, I think they are pretty good for getting across what they do, and we'll never be able to cram enough information into those tiny rectangles to fully explain each tool. We should probably get some input from other people on changing the look of the buttons completely, and we'll really need to make it consistent between the two platforms if we want one manual to be able to tell people how to use it.

As a bit of a progress report: I've gotten mirror placing put into the Mac editor, mostly by directly copying the code from the Windows side. I also made a quick check myself of the first 32 preset field IDs, and it looks like there aren't any others assigned besides the ones we now know. While is possible that Jeff used one of the other value out of the full range of -2^31 to 2^31, I rather doubt he did it, and would suggest not bothering to hunt through all values exhaustively. I've also got some more and less visible-to-users shiny things coming, namely automatic updates and a (32 bit) Intel-native build of the editor. I still need to do a little more testing, as there are some crashing bugs in the update process, and I've already found two data corruption bugs arising from endianness details, which leads me to be suspicious that more are lurking. Nonetheless, the new release should come soon.

Quote: ...wasn't there a copy rectangle tool? Maybe it was actually something Niemand added, but I definitely remember two tools on the toolbar, one which lets you select a rectangle to copy and the other which lets you paste it by specifying the top left corner. That's what you should do, rather than making a "selected instance" for them. I added those to the Mac version. The only thing that's stopping me from adding them to the Windows editor is the difficulty I've had with trying to rearrange the button palette so that it can be expanded to match the Mac version's. Quote: Allowing signs to be selected seems okay, but I don't think you should allow them to be moved. I agree on this.

Quote: Yes, currently you can copy/paste floor or terrain from one square only. What on earth is the point of that? It should b fixed, rather than introducing something else, I say. Quote: "Does it just select the sign assignment so that you can now select a sign and move it onto a terrain that's not a sign? Or does it move the sign terrain along with the sign?" Currently, the sign terrain stays where it is, you are only changing "location sign_locs[8]" or "location sign_locs[15]". If you place a sign terrain type on the new location then you have a proper sign. I'm not sure that allowing signs to be moved is a good idea. I'll have to think a bit about the advantages and disadvantages, though.

Quote: Long term, it would be handy to be able to select and move around blocks of terrain and floors. This will require a new selection method that allows the selection of a lot of things at once. I think that this is not a good idea. There isn't a clear logical way that this ought to work (when you displace a floor, what is left behind at the old position?) and there's nothing you can do with a floor or terrain, unlike other objects which have properties that designers need to manipulate.

Quote: Now I am following the ideas found in the Mac code and introducing a wider variety of selected instances. I have included preset fields in this list too. Now they can be moved around at will. Some contain items, this problem will need to be addressed. Everything is now properly mobile. I am retaining the selected item numbers system because I know how to use it. Hm. By 'field', I assume you mean what the editor calls fields (which, as we've discussed before, includes all sorts of things except what the game documentation calls fields). With regard to 'fields' like crates, I'd say that the proper behavior is not to mess with any items that are on the same space except to correct their containedness. It won't be what people most likely want but it avoids sticking in more special cases and makes the behavior consistent with what happens when one erases a terrain which is a container and redraws it somewhere else. (If designers yell at us that this is stupid, we can always just put in the special case code.) It hadn't occurred to me yet to make preset fields selectable, but it doesn't seem like a bad idea. I do think that we ought to use the same code on both platforms for handling selections; I've been meaning to try to start merging those changes into the Windows code but I just haven't been able to get to it. While the old number range system was conceptually simple, it was error-prone and pretty inefficient as well. If you search the Mac source code for SelectionType you'll find just about every place where the new selection system is used. Since none of it touches file I/O or drawing operations directly, it should be possible to copy it almost without modification into the Windows source. I don't want to step on your toes by changing things related to that while you're in the middle of doing it already, but I may be able to start working on the Windows stuff more soon (I know I've said this before. . . ) since I've ow got a full (virtual) Windows installation in which I should be able to run the compiler properly.

That sheet is in a file which is distributed by Spiderweb; we can't change it. What we can do (and what I'm doing right now) is converting the necessary image resources to PNGs and storing them in the editor application's bundle so that we don't use the old file and its numbered sheets at all.

Quote: Unfortunately, get_char_status() will not return a negative number. Any way around this? I just tried this out, and it seemed to work. In the START_STATE of a creature script I put: Code: set_char_status(ME,1,-10,1,0); and in the START_STATE of the town script I put: Code: print_nums(get_char_status(6,1),get_char_status(7,1),get_char_status(8,1)); (Creatures 6, 7, and 8 are ones using the script I first modified.) I saw matching negative numbers being printed out, as hoped for. One thing to watch out for: Did you try using print_num() to have a script report values to you? As I recall that particular print call doesn't handle negative numbers properly, which is why I've made a habit of using print_nums() instead (although doing so necessitates providing three numbers to print, whether that was what you needed or not).

I don't know about the details on the Windows side, but this relates to the (outdated) resource loading system used by the Mac editor and a number collision made by Jeff. Sheet 701 used by the game is of course a set of cave floor tiles. For the Mac version of the game it resides in the file Terrain Graphics. The Mac editor has an additional resource file containing graphics used by it but not by the game named Blades of Avernum Ed Graphics. This file holds various button images, and also an image containing the textures used for backgrounds in the editor. For whatever reason, Jeff assigned that texture image the number 701 as well. When the editor opens both resource files, there can be only one resource of type PICT and number 701, so the sheet in whichever file is opened later takes precedence. In the old, 2D editor this wasn't an issue, since the isometric floor and terrain images were never used. However, with Isaac's upgrade to allow 3D drawing, they are needed, and so the editor runs into the problem that it needs access to both of the sheets 701. Someone (Isaac, perhaps) duplicated the sheet 701 containing floors, and placed it among the editor resources with the new number 916. Then, whenever the editor needs to draw a terrain or floor whose sheet number is supposed to be 701, it uses the special case logic and fetches the graphics from sheet 916 instead. None of this matters to the game, since it never loads the Blades of Avernum Ed Graphics file. I'm not sure what the situation is for the Windows editor, since I've never looked closely into its resource loading and handling systems, so I'll leave it up to your judgement; just do whatever works, I'd say.

Same here. I'm working on it, and will hopefully have it ready soon.

That would make sense from the documentation, however, I'm not aware of anyone having ever observed that call causing a creature to use an item.

Quote: From what I've gathered, confused/charmed party members are treated as "friendly" to enemies by the call char_attitude_to_char() Yes, this seems to be the case in my experience; these statuses effectively change a creature's attitude. Quote: What this means is that anything written after do_attack() is ignored. This makes it difficult to do things like check whether or not a party member was hit by an attack. This is not true, as far as I know. The way (I think) it works is this: The game decides that it is creature X's turn. So, creature X's script will be run repeatedly, each time resuming from the state in which it ended (either by reaching the end of that state or by jumping to it via set_state()). This continues as long as the creature has AP, and do_attack() is just one way that the creature's AP can be decreased and cause the loop to end.

Quote: Is there any way to force creatures to use their expendables? No, there is not. It's rather maddening. (Note that do_attack_tactic(3) claims to do this, but it does not appear to actually work.)

I believe that that is the case. And then there's Dread Curse, which is just a special case.

No, only on and off, unfortunately.

Quote: The problem is more that the user interface is so completely foreign to me that I can't figure out where to go to help myself. BoA requires a lot of manual file moving to get set up, and I'm not used to navigating those odd menus. Sorry you're having trouble, although I'm still not sure just which things are the sticking points. (I'm also not sure which menus are giving you issues; the ones in the editor are about the same as the ones in the Windows editor.) I assume that you've gotten BoA installed the system wide applications folder, /Applications/ (Hopefully it isn't too confusing if I write unix style file paths? They're just like Windows file paths except that / is the root level of the hard-drive and instead of C:\ and they use slashes for separators). To install scenarios (once you can get them unarchived), just drop them in /Applications/Blades of Avernum/Blades of Avernum Scenarios/. That should be exactly the same as on Windows, just in the Applications folder, instead of in Program Files or whatever. The editor application you can download and put wherever you want; the sensible place would be to put it in /Applications/ as well. The first time you run it, it will want to know where the Blades of Avernum Files directory is, so just navigate there (if you put things in the places mentioned above, it will then be /Applications/Blades of Avernum/Blades of Avernum Files/) and press the choose button. That's all of the setup work that I can think of; it really shouldn't be too different from the process on Windows. I hope something in there helps, and that I'm not just repeating things you already know.

Quote: I downloaded a scenario and all I got was this .sit file that doesn't look anything like the standard scenarios in the list. What you have there is a Stuffit archive. Stuffit used to come installed on Macs, so it was a common compression format. Unfortunately, it now doesn't come installed, and it has fallen out of favor, but its previous popularity is now an annoyance. To get it open you'll need Stuffit Expander. Quote: I can't even get the editor to work. You'll need to be a little bit more specific about that one; unless you just mean that the editor couldn't read the Stuffit archive, which is normal, if unhelpful in your case. Quote: Okay, how do Macs work. This one is a pretty big question, but if you really want to know, you can start by reading the roughly 3000 technical notes from Apple.

Yeah, that's screwed up. The Mac version of that same function looks like this: Click to reveal.. Code: void place_items_in_town(){ location l; short i,j,k,x; Boolean place_failed = FALSE; for (i=town.in_town_rect.left; i < town.in_town_rect.right;i++){ for (j = town.in_town_rect.top; j < town.in_town_rect.bottom;j++) { l.x = i; l.y = j; for (k = 0; k < 10; k++){ if (t_d.terrain[i][j] == scenario.storage_shortcuts[k].ter_type) { for (x = 0; x < 10; x++){ if(get_ran(1,1,100)<=scenario.storage_shortcuts[k].item_odds[x]){ if (create_new_item(scenario.storage_shortcuts[k].item_num[x],l,scenario.storage_shortcuts[k].property,NULL) == FALSE) place_failed = TRUE; } } } } } } if (place_failed == TRUE) give_error("Not all of the random items could be placed. The preset item per town limit of 144 was reached.","",0); draw_terrain();} I assume that this is closer to how it ought to be, since it at least uses a probability.

Quote: I really don't want to have to manually punch in the number for each terrain I want the script to check for, so is there any easy work around that doesn't involve simply making sure the spot is devoid of terrain altogether? There is no supported way. I think that there is probably a tricky solution, however, and it should even be pretty portable. I haven't researched it in detail, but I could if you want.

I see what you're trying to do. I'm not sure whom you're attempting to punish, though.