Celtic Minstrel

Perhaps he meant to write "fire" but instead wrote "force".

Field spells do not have a duration per se; instead, they have a chance of fading each round. According to the code, Ice Wall should in fact last longer on average than Fire wall, but the same as Force wall - Ice/Force have a 1/6 chance to expire each turn, while Fire has a 1/4 chance. (And Blade Wall is unique in having a 1/5 chance each turn to fade.) I consider the Spark spell to be an electrical spark rather than a fiery spark, since there are other situations where magic damage is used to represent electricity.

It does work in Windows XP mode on Windows 7 Pro (which is basically Virtual PC, I think).

Maybe a better idea would be to clear the last played sound at the end of each move...

Regarding not hearing the sound, I believe there's something in the code that suppresses a sound if it's the same as the last sound played. The rest, I will look into.

Oh, whoops. I misread the code, confusing "slow" with "haste" since they're inverses.

Looking at the code, it appears they do get the same total amount of action points while slowed, just distributed differently. Which is actually kind of weird...

I emailed Jeff about this, but no response yet. It's been more than a week. I have no idea if he's just busy or if it's gone into the junk folder. (Though I don't know why it would go into junk.)

Yes, the code in the Win32/ directory in the repository is essentially the old CBoE code.

Bless is capped at 8 globally, unless there's somewhere that still directly accesses the status effects rather than going through the apply_status function.

Ah, sorry, if you're using CBoE I can't really help you. That does make me think of something ADoS said about a screen-blanking bug, though. It should work in my builds, if you don't mind a few bugs and don't want to wait for that non-beta version I mentioned. This is not exactly true. I think the only thing that won't work in the coversion is the Display Picture special node. Mind you, I haven't actually tested this... I should probably download Sylae's scenario to make sure it works.

No, that's already used for magic attacks. The thing here is that there are two completely separate sets of "boom" graphics - static boom graphics, such as the one you call a "shock animation", and animated boom graphics. Here they are: The top row is the static booms, which are, in order: fire, magic/unblockable, poison, physical, cold. Subsequent rows are the animated booms, which are, in order: fire, teleportation, cold/unblockable, magic. (And magic used to be the same as cold/unblockable, but since that boom inverts nicely, I added it as an extra animation and now use it for magic damage.) Static booms are normally used for things like terrains and fields that damage you, as well as attacks with weapons. (The "shock" boom is also used for assassination damage, for example.) Spells, however, use the animated booms, as do spell-like effects such as breath weapons.

This implies you're not using my experimental build, as neither Can't Enter nor Secret Passage exist by those names in it. What you describe is essentially equivalent to what I described, and would convert to that when importing into the new BoE. What do you mean by "worked on images"? What do you mean by "not showing up properly"? A screenshot could be useful (you can upload it to an image-sharing site such as imgur, imageshack, photobucket, tinypic).

You're wrong - shockwave deals unblockable damage (what you're calling "darkness" damage). Of the summoning spells, Capture Soul and Simulacrum probably have the greatest potential. With luck, you can get them to summon monsters that would never be summoned by any of the other summoning spells. Invulnerable monsters take one-tenth damage, and Wound does at most 7d4 damage, so technically it can if your level and intelligence is sufficiently high; however, it won't be very effective (that's a maximum of 2 damage per hit!). Divine Thud does magic damage. Your confusion is understandable though, as magic, unblockable, and cold damage all used the same animation. (However, I believe I changed magic explosions to be yellow at some point.)

I have no plans to improve monsters' default AI. In fact, I'd prefer it stays the way it is. However, I'm open to adding more ways to customize how monsters behave. I haven't figured out yet how that should be done, though.

Did you try what I suggested? Also, you could always use a terrain that looks like it can't be walked on but is actually set to allow being walked on, like the built-in cave secret passage terrains. As for the docs, that's kinda strange. I'll look into it later.

...wait, so you got an email response even though I still haven't? :|

Don't quote me on this (I'm not a lawyer or anything), but it was my impression that images and logos can be counted as part of the source. Some projects release assets under a different license, but I don't think Jeff did that.

It must still be the first in a chain. However, you can undo a secret passage node later in the chain. (At least, you're supposed to be able to. I haven't specifically tested it.) In other words, to do what you want, you'd have a chain similar to this: @block-move = 0 # A "Prevent Action" node ex1 = 0 # Allow entry ex2 = 1 # Force goto = 1 @if-trait = 1 ex1 = 4, -1 # If woodsman trait is present, do nothing (end encounter) ex1 = 1, 2 # Same as legacy behaviour (succeed test, ie call node in ex1b, if there's at least 1 member with woodsman) goto = 2 # If no-one has woodsman, go to node 2 @block-move = 2 ex1 = 1 # Disallow entry ex2 = 0 # Cancel "force" setting Really? That doesn't happen in my version, nor in the version up on Sylae's site. Maybe you're looking at an older version of the docs? I consider the builds released in the "Finally some progress" thread to be beta versions. I think a non-beta OBoE 2.0 build may be ready "soon". That could potentially be sooner if I had more testers than just ADoS. And how soon is "soon"? That's a very good question that I don't have a good answer for, but you should allow at least a month before getting impatient. (Note that I'm calling this project "OBoE" rather than "CBoE", partly because I like how it looks like an actual word and partly because it's not really based on any of Ormus's Classic BoE work; I copy-pasted+tweaked or reimplemented a few things from his code, but I was working from Mac source that was updated by Khoth, and even the Windows version is now based off that source.)

It might be polite, but BoE is GPL-licensed, so it's by no means necessary to ask him.

I don't have any quality standards for scenarios. You're welcome to do whatever you want with them. I'm not soliciting for scenarios to be included with the game, though I'm certainly happy that someone besides myself is working on a new one. If you want to try again with compiling the source later, let me know (and either post the errors or join the IRC). Also! If you happen to notice any bugs while making your scenario, please let me know so I can fix them.

Perhaps you need to tell your compiler to use the C++11 standard instead of C++03? Though Jeff does have a note on that (it's even there in doc/), it's no longer relevant. The current dialog engine defines dialogs using XML files. There's a schema for this at rsrc/schemas/dialog.xsd (not dialogue.xsd, that's something different), though the schema might not be a good way to explain the format. There's also a Doxygen config to generate fairly detailed documentation of the dialog engine in src/doxy/; if you don't have Doxygen, most of this documentation can be found in the various header files in src/dialogxml/, and the rest can be read online here on GitHub. The old structures are preserved in src/oldstructs.hpp and used for nothing other than loading in old scenarios. They're not quite identical to the old structures, but they should be functionally the same.

I see. Well, if you do manage to fix any bugs, I'd like to see how you did it, at least. Also, if you want to make and distribute your own separate version of BoE with different features, I would request that you change the following line in scen.fileio.cpp: data.PushElement("type", "oboe"); Just replace oboe with something else. That way, if someone tries to load a scenario created with your version, it'll show an error message instead of trying to load things it doesn't know about (or worse, silently ignoring them). You only really need to do this if you've changed other stuff in the same file, mind you. If you only know the standard C library, you might have a bit of difficulty, since I use the C library almost nowhere. You should definitely learn the standard C++ library as well.

Oh! There might be another option for you! It's very possible that Code::Blocks has an option somewhere to import a Visual Studio solution. If you can find such a thing and import the existing solution, that might get you started a lot quicker. As mentioned before, if you save make a folder called "BoE.cbproj" in the "src" directory and save your Code::Blocks project there, I'll even consider including your project in the official repo.

I'm not quite sure, but that does sound like it might be wrong. How do you open a non-existent BoE scenario file? Launching from the command-line or something?