Jump to content

Celtic Minstrel

Global Moderator
  • Posts

    4,162
  • Joined

  • Last visited

Retained

  • Blades of Exile Maintainer

Contact Methods

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

3,405 profile views

Celtic Minstrel's Achievements

Understated Ur-Drakon

Understated Ur-Drakon (15/17)

  1. 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.
  2. 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.
  3. 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.
  4. 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…
  5. 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…
  6. 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".
  7. 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.
  8. Those all seem to be errors with TGUI… what version of TGUI are you building against?
  9. 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…
  10. 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.
  11. 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…
  12. 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.
  13. 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).
  14. 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; }
  15. 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.
×
×
  • Create New...