Celtic Minstrel

Since the minimum value is 1, a 0 in the charm odds would mean a monster of that level can never be captured. So that would imply the level 30 guard really can't be captured?

…except for that calculation done on the generated value. If the generated value is 1, multiplying it by 7 and dividing by 100 would give 0, so there is a very small chance to capture a Guard?

As for the implementation of get_ran, it does use standard random functions inside it, though the implementation varies between the Mac version, the Windows version, and the open-source version. In the Mac version it looks like this:

short get_ran (short times,short  min,short  max)
{
    long int store;
    short i, to_ret = 0;
    
    for (i = 1; i < times + 1; i++) {
        store = Random();
        to_ret = to_ret + min + (((store + 32767) * (max - min + 1)) / 65536);
        }
    return to_ret;
}

The Random() function is part of the Macintosh Toolkit, and I don't know exactly what it does off the top of my head. However, it looks like it gives 4 bytes of precision and he's collapsing the result into 2 bytes.

In the Windows version, it looks like this:

short get_ran (short times,short  min,short  max)
{
    short store;
    short i, to_ret = 0;

    if ((max - min + 1) == 0)
        return 0;
    for (i = 1; i < times + 1; i++) {
        store = rand() % (max - min + 1);
        to_ret = to_ret + min + store;
        }
    return to_ret;
}

That rand() is the standard C function.

The open-source version is pretty much the same as the Windows version, but for some reason is missing the divide-by-zero check.

I don't know of a definite way to determine which monsters are immune in Exile 3. The best I can offer is the Blades of Exile source code, which is probably the same as in Exile 3.

void record_monst(cCreature* which_m, bool forced) {
    short r1;
    
    r1 = get_ran(1,1,100);
    r1 = (r1 * 7) / 10;
    
    if(forced) r1 = 0;
    
    if((which_m->x_width > 1) || (which_m->y_width > 1)) {
        ASB("Capture Soul: Monster is too big.");
    }
    else if(r1 > cCreature::charm_odds[which_m->level / 2] || which_m->abil[eMonstAbil::SPLITS].active
             || which_m->m_type == eRace::IMPORTANT) {
        which_m->spell_note(10);
        play_sound(68);
    }
    else {
        which_m->spell_note(24);
        r1 = get_ran(1,0,univ.party.imprisoned_monst.size() - 1);
        if(univ.party.imprisoned_monst[r1] == 0)
            univ.party.imprisoned_monst[r1] = which_m->number;
        else {
            r1 = get_ran(1,0,3);
            univ.party.imprisoned_monst[r1] = which_m->number;
        }
        ASB("Capture Soul: Success!");
        add_string_to_buf("  Caught in slot " + std::to_string(r1 + 1) + ".");
        play_sound(53);
    }
}
	

You can see that monsters larger than a single space, monsters with the "splits" ability, and monsters with the "important" race are immune. It looks like those are the only conditions for immunity (in case you were wondering, the "charm_odds" is the chance of succeeding when you attempt to capture a monster that's not immune). It's worth noting that resistance or immunity to magic does not appear to be factored in at all.

I think the town guards actually are capturable. They're just quite hard to capture because they're high level.

37 minutes ago, cst1992 said:

27 - Doomguard (4) (Funny how it only requires 4 SP to summon, but capturing it in the first place is the real challenge; perhaps impossible).

I believe monsters with the "splits when hit" ability are defined to be immune to Simulacrum, meaning it is in fact impossible to capture them. The same goes for monsters of type "important", which includes Erika and Rentar-Ihrno. There may be some other classes of monsters that are also immune.

I don't recall seeing performance issues running on Win3.1 in DOSBox. I think the rendering issues I saw when running Exile 3 under WINE (the minimap wouldn't render, and I think there was some issue with dialogs maybe) were also not an issue in Win3+DOSBox. I'd have to give it another try to be certain though…

On 12/27/2023 at 4:21 PM, cst1992 said:

Exile III was actually designed for Mac and ported to Windows 95/98.

 

XP is the last OS which you can use to natively run the game, but OTVDM is the best thing otherwise (or an XP virtual machine).

I'm not sure that this is quite correct. The game runs just fine on Windows 3.1, so I'm not sure if it's correct to claim it was ported explicitly to Windows 95, though the time period definitely matches (I think it was released in 97 or so?).

But, that leads into the second part, which is about the best way to run the game. I think the absolute best way to run the game is actually Basilisk II, a Macintosh emulator; but for the Windows version, the best way in my opinion is a DOSBox image running Windows 3.1. It's admittedly a little involved to set up, though.

EDIT: It would be really nice if we could post pre-built images for playing Exile on Basilisk/DOSBox. Is Windows 3.1 still under copyright? Or the older Macintosh ROMs? Or the SoundBlaster drivers (needed for the DOSBox image)? I don't think I've seen anything to suggest they aren't, but they're pretty old so I wonder if they might be…

C++14 might be close enough, though you probably need to build the whole game with C++14 in that case. I'm not really sure why it would complain that tgui::Gui is not defined, but maybe there's a missing include somehow – it appears to be defined in "TGUI/Backends/SFML.hpp".

Did you install TGUI from a package repository, or did you build it from source? Those errors all look like a C++ version issue – if TGUI is built for C++11, then it should work. Conversely, if you were to build the game for C++17, it should also work. Keep in mind that I have a policy of keeping it C++11-compatible, so if you wish to contribute, it would be preferable to have TGUI built for C++11; however, if you only want to build the game and try it out, it might be easier to force the build process to use C++17.

Those all seem to be errors with TGUI… what version of TGUI are you building against?

Well, section 2 is entirely obsolete, and also section 3 point 4, but I think most of the rest is still reasonable to good advice…

Hmm. Looking at the original source and the OBoE source,  it seems both just subtract one-third the ability strength of a poison protection item from the amount of poison that's being inflicted. There's nothing in there that depends on the hardy trait. It does add 1 to the amount if you have frail… and given that frail is 12 and good constitution is 6, I don't think Jeff could've mixed up the number there.

The Amber Periapt however had an ability strength of 0 in the original Blades of Exile Base, so if that went unnoticed by a scenario author, then it would do nothing at all.

1 hour ago, Ess-Eschas said:

The results for what I believe was the first scenario contest are still online, although they’re a little hidden away. They’re found in the middle of the list of links on the Blades of Exile scenario workshop:

 

http://www.spiderwebsoftware.com/misc/contest_results.html

 

Is this the contest you meant, or am I misinterpreting you?

Yes, that looks like the one I was thinking of – complete with cash prizes totalling $1000!

Regarding the rest – I haven't looked at them yet, but it seems to me that it might be a nice idea to edit together a page summarizing them all for posterity's sake…

Does anyone know if there's a place listing the outcome of the original, Spiderweb-hosted Blades of Exile scenario design contest? I was thinking it would be nice to link to that from the OpenBlades website, but I can't seem to find anything.

Results of subsequent contests would be nice too, but I'm mainly looking for the original one.

If there's only one of each possibility, then that's probably almost all of them. Blades of Exile only has blessed, the two flame ones, and +1 up to +5 (excluding +4 for some reason).

I'm not aware of any bug that prevents Stuff Done Compare from working in legacy BoE. The logic in the original source is:

If Extra 1A >= 0 and SDF >= Extra 1A then goto Extra 1B

Else If Extra 2A >= 0 and SDF < Extra 2a then goto Extra 2B

Else goto Jump To

So, Jump To would ultimately be called in the following situations:

• If the SDF is invalid – it has negative components, or it's larger than the maximum value for an SDF, or something. (I think the editor validates that though, other than -1.)
  
• If Extra 1A and Extra 2A are both negative.
  
• If SDF < Extra 1A and Extra 2A is negative.
  
• If SDF >= Extra 2A and Extra 1A is negative.
  
• If SDF < Extra 1A and SDF >= Extra 2A.
  
  

For reference, in case you think I might have misinterpreted something, here's the actual source code from the original Mac release:

	            if (sd_legit(spec.sd1,spec.sd2) == TRUE) {
                if ((spec.ex1a >= 0) && (PSD[spec.sd1][spec.sd2] >= spec.ex1a))
                    *next_spec = spec.ex1b;
                    else if ((spec.ex2a >= 0) && (PSD[spec.sd1][spec.sd2] < spec.ex2a))
                        *next_spec = spec.ex2b;
                }
	

On 10/3/2022 at 5:01 AM, osnola said:

I'm not really sure about this, i.e. with a little modification of my current code, it would even be possible to present the user with the old interface that allows users to enter their code as nodes and modify them (hiding the fact that the game runs as scripts behind it). But I find that not hiding it allows :

 

• novice users to code almost as before and then decide whether or not they want to start writing code directly,
• to the others to work as they want, including through their favorite code editor (probably using from time to time the syntax checking tools I added and the mini editor to correct typos).

Sure, you might be broadly correct in your analysis. However, building scripting directly on top of the special node system, by compiling scripts down to nodes:

• Presents the user with the old interface by default, with no risk of something breaking.
• Allows users to enter their code as nodes, with no risk of strange bugs caused by code parsing.
• Allows users to code just like they used to and then decide whether or not they want to start writing scripts.
• Allows users to work however they want, including through their favourite code editor.
• Allows loading old-format scenarios without needing to translate their nodes into code.
• Keeps the game engine itself simpler, as it only needs to run the special nodes. No parsing of code or syntax trees required.

In other words, it presents all the same advantages while cutting out several disadvantages that your version has. Modifying a block of text programmatically will always, always be more error-prone and complicated than manipulating structured data in code. You can test it and test it (and unit test it), but the fact still remains that you have to parse it just to present the old interface, then write back the user's original script with the required changes.

There is admittedly one disadvantage to doing it that way, which is that the scripts need to be compiled, adding an extra step. You can't just edit the script and have the change instantly show up in the game just by reloading a saved game. You need to change the script, get the scenario editor to recompile it, re-save the scenario, and then reload the saved game. But there's no reason that can't be automated. The scenario editor could be equipped with command-line paramaters that instruct it to compile a script without loading the UI, or the compilation could be handled by a separate external tool (which the scenario editor calls when it needs to compile scripts).

I appreciate all the work you've put into this project, and I really wish I had more time to review and merge many of your proposed changes. However, your scripting language that replaces nodes is not something I would consider merging. You can feel free to continue to work on it though – your fork is yours, after all – and you can even feel free to post about it here. Even if it's not merged in its current form, some of the ideas that went into it could inform a later scripting language project.

I don't think any amount of working with a scripting system (templates or whatever) will give something as nice as vanilla BoE uses. I still think the only reasonable way to introduce scripting is for it to be compiled down into special nodes – the editor may understand the scripting language, but the main game engine has no need to know it even exists. Sure, you'll probably need more types of special nodes than what currently exists, but that's not an issue, just add them.

3 hours ago, osnola said:

It remains that even incredibly difficult to do.

Yeah, sure, it's difficult. It's basically "writing a compiler". It can certainly be done, but would not be easy.

I don't know how your snippet would be compiled down to nodes. Perhaps some new node types are needed to support what you're doing there. But it's certainly possible to do.

49 minutes ago, osnola said:

Yes, this is probably possible, but I'm afraid that without complex mechanisms to simplify the result, it will generate a lot of special nodes and the result will become totally unreadable.

It's not meant to be readable. It's meant to be interpreted by the game engine.

50 minutes ago, osnola said:

if necessary, I can reimplement these mechanisms, but I'm not sure how often they are used but I fear that when they are, the code quickly becomes unreadable (ie. using static variables probably makes the code longer, but it can remain readable).

It may be better to keep them around for compatibility reasons, if nothing else. Although, admittedly, pointers are not used in any extant scenario… but global text certainly is.

1 hour ago, osnola said:

Even ignoring the fact that I added a lot of functions, converting a script to special nodes doesn't make much sense in my opinion, scripts allow to write code in a too flexible way.

?

The special node syntax I designed was intended to evoke assembly languages. Compiling complex code down to an assembly language (technically, machine language) is a fairly normal thing to do. I think in theory, anything you write in your scripting language should be able to be reduced to a series of nodes (unless of course you've added new features that don't have corresponding node types). There are certainly some complications, such as variables, that might make that trickier, but I believe it should be doable, and it means both systems can sit side-by-side without needing two separate interpretation engines in the actual game.

By the way, does your scripting include the concept of "pointers" that I introduced in the node engine, or is that removed in favour of variables or something?

But in my mind, the point of the existing node system is the ease of use for people who aren't used to coding. A written scripting language presents a higher barrier to entry. The node system could certainly be improved, but I don't think replacing it with scripting is desirable for the most part.

(Scripting also makes it more difficult to create a tool that will list references to an SDF or special node.)

That said, I don't think it's bad to have scripting as an option; in particular, if you actually compile the scripts down to my existing special node syntax, then scripting could exist as a design-time auxiliary tool.

15 hours ago, osnola said:

where I replaced the old methods to define specials by scripts

Doesn't this kinda defeat the point of the special node system…?

I gather that you consider it useful for determining where SDFs are used, which is actually another good enhancement to add, but we were talking about where special nodes are called.

On 9/2/2022 at 8:31 PM, Azalea said:

Honestly, it would be really handy if specials had a 'Called By' section so you don't have to trawl through all your specials, or even towns, looking for the number, like I was doing with VoDT.

That's a good idea. I've opened an enhancement request for it on the GitHub.

I think I forgot to keep up seeding on the torrent when I got my new computer… I think there are some other issues with the archive though, so it's likely better to fix those and then make a new torrent.

Also note, an archive of TrueSite 4 Blades is available at truesite.openboe.com – it's also missing a few things, but it's likely more complete than the Wayback Machine as I got the files directly from the website's original maintainer.

The mac versions of older games store most of the text in STR# or DITL resources (the latter being dialog definitions). There are usually some unused DITL resources that are holdovers from older games though. For resource editors, as far as I know, ResKnife can still run on any Intel Mac, but may present IDs backwards (so it'll show as #RTS or LTID instead). I don't know if it works with Apple Silicon.

It seems likely that the Windows versions of those games would also use string resources where the Mac version uses STR# resources, but I can't be certain. I have no idea how they handle dialogs. Nethergate might be new enough to no longer use native dialogs, though; if so, string resources probably contain most of the text.

1 hour ago, Azalea said:

All this happens just by the special nodes existing in Sweetgrove's list.

This is certainly not true. One of those special nodes is the start of the chain, and it must be referenced from somewhere, most likely in the Town Details or Advanced Town Details screen. Nodes don't run just because they exist. Something has to call them intentionally.