Celtic Minstrel

Pretty sure they've always had the Intelligence ability in Blades of Exile. Glancing over the code, it looks like that currently both affects your effective intelligence level and separately affects the intelligence "stat adjust" used for magic. However, the only place the former is actually used appears to be in mindduels. So what you describe is pretty much exactly what they do, though I think the mindduel effect wasn't there originally. More importantly... should the ability strength be raised? Based on the code, this would only affect mindduels, as the "stat adjust" only checks for the presence of the ability and ignores the ability strength. (In fact, if you wanted them to not affect mindduels at all, setting the ability strength to 0 would give that without any need for code changes; ignoring ability strength also means the stat adjust functions even when the ability strength is 0.) The only reason I suggested 8 for the ability strength is because that was the original ability strength set in the Blades of Exile Base.

I've lately been going over old threads discussing errors in the Blades of Exile Base to ensure that all reported errors have been fixed. Most of them were already, and I caught a couple more that had not even been spotted (such as Feldspar Charm, found by comparing to the preset scenarios). There are, however, a few things that I'm still not sure of. The Dark Wyrm - should it or should it not have darkness breath? Someone suggested it should in another thread, but they seemed unsure. (I have E3, so I could check for myself if I knew where to find one at the beginning of the game with a god party - ie, not a hidden town.) I set asps to drop asp fangs with 60% chance, but maybe the percentage chance should be less? Also, I kinda wonder if any other preset monsters should have similar fixed drops. The scenarios disagree with the base on the stats of several of the missiles - arrows, bolts, and javelins. This would probably be troublesome when mixing these items from different scenarios, since they would stack, and whichever one was in your inventory first would take priority. Should I change them all to match the base? Or maybe change the base to more closely match the scenarios? I could also just give them a unique type flag so they don't stack with regular ones. Micah's Gloves has an ability strength of 1. Originally, it had an ability strength of 8, but the game ignored the ability strength. Should it be put back to 8? (For those who don't remember, Micah's Gloves boost your intelligence stat.) And finally... does anyone know of any additional errors that might have never been found? I used this thread and the linked Lyceum articles as my primary reference, so if it's mentioned in one of those places, I probably got it. The fixed bladbase is here; if you can get the scenario editor working and want to view it in the scenario editor, you can download that entire directory (one file at a time, unfortunately), then navigate to the "header.exs" file from the scenario editor (may require setting the file dialog to show "legacy or unpacked scenarios"). It's fairly human-readable too though, at least if you know what all those numbers mean (most are documented somewhere in the BoE documentation on calref).

That was probably an endianness problem, which should be irrelevant now that everything's stored as compressed plaintext on disk. Endianness in particular shouldn't be relevant here, but some other difference in OS versions could be, I suppose.

Hmm. I can't rule out the possibility that my old Mac is simply incapable of producing a build that works properly on modern Macs, though if that were the problem I would've expected crashes rather than subtle bugs like this... but the OSX APIs are Objective-C, so who knows. For my part, I was (by coincidence) doing both the things you described earlier today, without any trouble, so whatever the problem is doesn't show up on my computer, which makes it difficult or even impossible (if it's really due to library versions) to fix. It might even be necessary to get someone else to handle packaging for the Mac builds...

...what? Both those things work perfectly fine for me on the latest master (which only has a few changes relative to the linked build). What the heck is going on here... I suppose it might help if you tell me exactly what happens when you attempt to do those two things, but it seems like a long shot...

... Well, I suppose that's a possibility. I think I'd prefer something that doesn't shell out to an external text editor, honestly. Anyway, shelling out to an external text editor is likely not as easy as it sounds.

The new scenario format (which is .boes instead of .exs) is literally a tarball with a specific directory structure. So yeah, it's compressed. (I guess designers might still pop it into a zip so they can add a readme, though.) Find/replace functionality for strings would certainly be great; you can already open the XML files in a text editor and use the find/replace there, but, well, that's quite a bit less convenient - you need to decompress the scenario first. (You don't need to recompress it though, since the editor can work just fine with a folder that has the same directory structure as a scenario tarball.)

So basically, you're favouring the idea of parsing item descriptions based on whether the item is identified? I'll note that this by itself doesn't do much about eliminating duplicates, though. Size is not the only concern with duplicates. It makes it harder to work with descriptions when several items have the same description, because when you want to change that description, you need to change it in several different places.

Okay, now can I get feedback from people who aren't ADoS? If I only wanted feedback from ADoS, I wouldn't've bothered to post here.

Well, here's a new build for Mac and Windows that fixes some (but probably not all) of the bugs people have reported.

Okay, first of all, let me respond to a couple of things that I missed (or more accurately, skipped over) before. I don't think the item descriptions need to be just boring physical descriptions. I think physical descriptions is their primary role, but there's no reason why humour and additional background info can't be included in some cases (like mention of the sliths or vahnatai). I do think descriptions of the item's properties and uses are a little out of scope (with the possible exception of some items with concealed abilities; I'm mainly thinking of the mist globe here). About swapping graphics... well, that just kinda makes the situation even worse in my opinion. My point is that identifying the item does not change its appearance. If you're swapping the description when it's identified, it doesn't necessarily suggest that the item looks different when identified. If you're swapping the graphic, well... suddenly identifying an item changes its appearance. If you accept that the item descriptions function as a detailed physical description of the item, then it's obvious that the item description should be the same independent of whether the item is identified. On the other hand, from that premise it's also obvious that some items would need to have descriptions which effectively identify what they are, even when they are technically marked as unidentified. For example, "This is a large shield with the name KLIN inscribed on the back." makes it obvious that the item is, in fact, the Shield of Klin and not some other generic shield. Or, "It's a small rock with bits of glitter in it." makes it obvious that what you have is not an ordinary rock but is in fact something more valuable, such as silver ore or rough diamond. So there's a clear problem with accepting that the item descriptions function as a detailed physical description of the item, even if you accept in the first place that that's what they're for. Now, the basic premise - "item descriptions are primarily a physical description of the item" - does not necessarily contradict a system where identified and unidentified items have different descriptions. You could argue that the identified description simply includes additional details that you had not noticed before you identified the item. But when those details are things that you could have easily noticed just on a cursory inspection, it kind of strains belief. Personally, I don't think it's necessarily a bad thing for item descriptions to sometimes hint that the item is more valuable than it appeared at first glance, nor do I think it's necessarily bad for a few items to have unique descriptions that instantly give away what they are, though I would prefer to avoid the latter as much as possible. Still, even in such a system, instantly knowing what the item is doesn't tell you its stats (unless you're metagaming and looking up the stats outside the game). So it's still useful to get that item identified even though you technically know what it is. ----- Now, on to what ADoS just said about the complexity of my earlier proposal. It's true - it's a complex proposal. (I'm particularly uncertain on point #3.) From the designer's perspective, they would be presented with a dialog offering two separate descriptions, but one of those descriptions is shared by multiple items, and changing the item's unidentified name has the side-effect of altering its unidentified description. I'm not entirely satisfied with the solution, which is kinda why this thread exists in the first place. As for your alternate proposal... well, referencing scenario strings is definitely possible. It's not even particularly difficult. However, it causes problems when you leave the scenario, and/or when you enter a new scenario. Copying the strings into the item properties does kinda work as a solution. It feels like an ugly solution, but it's doable, certainly, and it's quite true that it solves any problems of fully-duplicate descriptions (though it doesn't solve partially-duplicate descriptions). In summary... I don't like your solution, but I can't see any strong points against it, either. ----- On an unrelated note... something needs to be done about preset items. These are the starter items that are given to your PCs at character creation time, as well as the potions made with the alchemy skill. Not only do they lack a description currently, they also don't stack with equivalent items in scenarios (when applicable - eg, arrows).

You can easily redirect your clone to point to a fork, if necessary. Unless you get direct push access to the main respository, you would need to have a fork so that you can make any changes available to me. (Both require a github account; if you didn't have a github account you could still submit email patches.) Branches are helpful, allowing you to have multiple proposed changes (ie pull requests) simultaneously, so I'd recommend it. I however work almost entirely on master at the moment.

What do people think of this proposal? 1. Every item has a description stored with it. This description is shown only when the item is identified. In this description, the sequence %% (or something similar) will be substituted with #2, below. Additionally, if this unique description is an empty string, it will be ignored. 2. Each scenario stores generic descriptions that are shown for unidentified items. These are edited in the same way, through the Description button in the item edit dialog, which will now have two text fields and clarify that one of those descriptions will apply to all items with the same unidentified name. 3. Have a flag in the item which makes it use its unique description even when unidentified (alternatively, a separate description stored with the item). This allows things to have customizes unidentified descriptions even if they have the same unidentified name as something else. With this system, unidentified items may change (or even lose) their description when carried into a different scenario. EDIT: Oh yeah, if the item has no unique description, then maybe the generic one could be copied into it when you leave the scenario.

Oh, sorry... I meant to ask where the game was telling you to put them in the wrong folder.

Being hidden wouldn't be a problem if there's a button to open the folder from in-game. (Which there isn't at the moment, but I have thought about adding one. It could replace the How To Order button, or maybe be a button in the scenario selection dialog.) Mind you, I'm not really opposed to moving the scenarios folder to documents or similar, though (but I'd leave prefs and logs there).

Although I've implemented the ability for E3-style item descriptions, I'm having trouble deciding on some of the details. Currently, the descriptions are always visible, even when the item is unidentified (which appears to have been the case in E3, as well). I personally think this is important, but in some cases it might be nice to have a different description for when the item is identified. Also, ADoS wrote his descriptions in the assumption that they are only visible when identified, and it would be a shame to waste the ones that give away what the item is. Personally, I think it makes more sense for the item descriptions to not depend on whether it's identified (it's not like it looks any different once you know what it does!), but I can kind of get why you might want to change them (particularly for items with a concealed ability, such as the mist globes). I'm not entirely sure of the method, however. Also, I don't think it's really a problem for item descriptions (for unidentified items) to occasionally hint at the fact that an item is magical, or even be specific enough that you can pretty much tell exactly which item you have. (For example, "Shield of Klin" might well have Klin's name engraved into it. This doesn't make identification totally useless, though, as identification reveals specifically what it does... in most cases at least.) Another problem I have with my current implementation is that each item has its own unique description, but in many cases these descriptions are identical for a number of similar items. Using scenario strings (instead of strings stored with the item) is also out of the question, because items can be carried between scenarios. Here are some of the possibilities, in no particular order. Some of them may be mutually exclusive. Create a registry of generic item descriptions in the scenario, which would be used only for unidentified items. The description stored with the item would used when identified, if present. Exactly how the generic item description registry would work is uncertain; I was thinking maybe using the unidentified name of the item as a dictionary key, though. Parse the item descriptions differently depending on whether the item is identified. For example, eliminate passages in square brackets if the item is not identified. Store two separate strings with the item, one for when it's identified and one for when it's not. Leave it as-is, but don't show the description when unidentified. I feel that this defeats the point of a description though, which in my opinion should mainly be a physical description of the item. Leave it as-is and accept that some item descriptions may be a dead giveaway. Leave it as-is and rewrite some of the descriptions of unique items. I'm not totally opposed to this, but some of those descriptions are quite nice, and ADoS wouldn't be happy about losing them. (This is an open-source project, so he may have to get used to the idea that his work may be incrementally overwritten, but ... well, this would require more than just minor tweaks. The affected descriptions would need to be rewritten from scratch. And some of them seem pretty good to me.) ... I get the feeling that I forgot one thing I was going to say here. I'm kinda leaning towards #1 and #2 at the moment (or maybe #1 and #3), but I thought it might be good to get some input as well. Perhaps there are other possibilities I haven't thought of. (For the curious, the current descriptions from ADoS can be read on the repository. Some of them still need improvement, particularly the slith spear and vahnatai items, but many of them are quite good.)

The different location is intentional, since applications generally don't have write access to their own directory these days. I should correct the note saying where to place it, though; but I don't remember when that happens? How did you get the game to tell you where to place scenarios? Okay, this is pretty bad. Ugh. It's probably fixable by tweaking a few constants in the code, though. Hopefully. I'll look into it.

I haven't added anything to allow monsters to move through arbitrary walls. There is a way for the player to do so in debug mode, but that's probably not relevant. With the removal of various limits, a solution similar to what you described is likely more viable than it used to be; you could even put the Can't Enter special in the terrain definition (rather than using a ton of placed specials in every town). It's still not a general solution, though; in particular, it won't help the monster pass through doors (they'll just open the door like any other monster). I had nebulous plans for letting individual monsters specify which types of terrain they can move through (for example, to allow for swimming monsters). This could potentially also allow for ethereal monsters. However, I haven't given much thought to this, so it's unlikely to be implemented for awhile. (Probably not in time for 2.0.) If I recall correctly, you can use a node to teleport a monster through a wall with the latest OBoE, making a solution similar to what Balladeer solved more viable, since current hp and status effects will be preserved by teleport. If I do not recall correctly, it probably wouldn't be very hard to implement teleportation of monsters. It's also possible to make a monster call a special node as part of its turn.

Ir: That's definitely a missing zlib, then. I've fixed the three issues you've mentioned, by the way. Jewels: I suspect git is included in the command-line tools that can be installed from XCode preferences (at least, that's how they used to be installed, I don't know if that's still the case). It doesn't matter which folder you clone into. (Generally, cloning automatically creates a folder whose name matches the repository.)

Did you install zlib? That file is the only one that directly references zlib, so if you were missing zlib I would definitely expect errors in that file. I'd have to see the specific unresolved references to know for sure whether or not it's zlib, though. I've reproduced the second of those errors and am guessing it shouldn't be too difficult to fix. Hopefully I'll be able to reproduce the first one too.

Just for the record, anyone interested in contributing (especially to programming) may want to post in the Blades of Exile forum (on this site) so that we know who you are. I can see there's at least one person who said they'd like to contribute to programming without saying who they are.

Are you sure the Text Dump feature doesn't work? They're saved in the same directory as the scenario file, not in the executable directory (as they used to be, if I recall correctly).

You could point it to my VPS if you want (23.226.229.74)... though if we expect high traffic I'd want to tweak some apache settings... Alternatively, you could put up a website via your own hosting service.

I could include this in the header of the directory listing for /oboe/. Making a page separate from the directory listing is also a possibility, of course. I'm not sure if that'll make it easily googlable though...

ADoS: That looks like an improvement, but I think some additional links would be good - the repository (https://github.com/calref/cboe) and possibly also the issue tracker (https://github.com/calref/cboe/issues). Unfortunately you need a github account to start new issues though. There are ways around that, but I haven't set them up yet. EDIT: Also, should we maybe retain the link to the old Win16 / MacOS9 version on Spiderweb's site?