Chokboyz

Originally Posted By: Lilith Could this part of the code be version or platform-dependent? This is actually something that we did a lot of testing on back in the day for the BoE Arena, and the conclusion was that slime-type monsters were consistently immune to sleep on some people's copies of BoE (in a way that didn't seem to be dependent on the monster ID number), and not immune on others. Incidentally, the Stone and Undead monster types are also immune to sleep. Indeed, i've just checked and you're absolutely right : in the mac version the stone, undead and slimes types are immuned to sleep (regardless of the number of the monster), while in the windows version the monster between 138 and 142 (basic slimes) are immuned. "Funnily", stone monsters are not immuned to sleep in the windows version (undeads are)... I'll correct that in the next version (i assume that after so much testing, no one dared make a scenario using this buggy behavior...). Originally Posted By: Lilith Ha! That's an interesting one, and probably related to a bladbase bug where monsters like Salamanders that are supposed to have fire fields have Permanent Martyr's Shield instead, and monsters like Ice Drakes that are supposed to have ice fields have Paralysis Ray instead. I'm almost certain this can be chalked up to some kind of glitch in the process of converting the E3 engine to Blades. Jeff's intent was probably for all monsters to be immune to fields that they themselves generate. Ah, thanks for making the connection ! I agree with your theory, since it won't be the first time such a thing happens. After checking the mac code, the bug is also present in the mac version. I'll then replace the wrong ability checks by the "radiate field" ability (compatibility ?). Nothing about the "radiate "shock field" ability though, so i'll probably extend the check for those fields. Thanks for the feedback ! Chokboyz

Originally Posted By: Ahbleza The 'bladbase.exe' file in the version I'm using is dated: 15 Jun 09 and is 99kb. Nop, that's the "bladbase.exS" file (for your information, it's the "base scenario" that is loaded when a new scenario is created). You're probably looking for the "Blades of Exile.exe" file. Nonetheless, don't worry about the date of modification and such, i've put the version number in the title bar and the "About..." entry of the help menu. From the description of your bug, it's exactly the(critical) bug i was thinking about (that explains why i delete the 1.1 patch and subsequents from the download repository). Glad to see the patch fixed it. Don't hesitate to report glitches you may find Originally Posted By: Ahbleza It would appear that I hadn't noticed the updated 'patch', so it must be 'my bad'. [...] I didn't notice that the update had been posted, so I appologize for missing it. Don't worry about that : i've been so many times on and off this project that communication has been pretty poor on my side (proof : over 1000 downloads of Classic Blades of Exile v1.0, less then 300 for the different patches). Originally Posted By: Ahbleza I was an industrial electricain [...] I appreciate all that you've done for this Community No problem I'm glad you (and i hope others) are enjoying Blades of Exile, as i've enjoyed it not so (?) far ago. Have fun, Chokboyz

Originally Posted By: Celtic Minstrel That's odd... I can't think of anything else that wasn't supposed to be equippable in combat though, so I'd say just delete the check. The same here... So, i've deleted the check. Some last remarks i forgot to post last time : When monsters are firing missiles, differents amounts of ap are removed : 1 for heat ray, 2 for good_archer, invisibility (hence not used) and razordisks, and 3 for every others missiles. The invibility part is probably a typo for darts (invisibility number is 11, darts is 1). Anyone can confirm that (from Exile 3 or other) ? Slimes are hardcoded as immuned to sleep (i.e the monster number is checked... leading to monsters bearing those numbers to be sleep-immuned, regardless of the scenario). That should probably be switched to check the monster type (i.e slime). Is there any obvious compatibility breaking doing this ? (scenario where slime type is used, without sleep-immunity in mind) Monsters with "Permanent Martyr's Shield" are immuned to Fire Walls and monsters with "Paralysis Ray" are immuned to Ice Walls. While the former may make sense, i'm not so sure about the second... (normal immunities/resistance are correctly applied.) The monster spell "Heal All" isn't a mass spell as the name may suggest but the most powerful and reliable self-healing spell a monster can cast. I propose we rename it to "Heal All Wounds" or something in that vein. I've finished a quick review of the main part of the game code and replaced lots of numbers by "human readable" constants (from spells to item abilities to monsters abilities) and didn't found obvious bugs, except the ones mentioned above. Finding informations in the code should now be easier and it should be of easier access (quick modifications, etc). Moreover, Classic Blades of Exile seems stable enough (i.e no problem or incompatibility detected - if you know of one, say it !) to be left in state. Except if critical bugs or incompatibilities are reported, the next upload should then be my last. Chokboyz

Originally Posted By: Celtic Minstrel I thought webs last until you explicitly stop to clean them off. With a few exceptions : leaving a town resets all status except poison, disease and dumbness (hence remove webs) and "Long Waiting" cleans all webs. Chokboyz

Originally Posted By: Ahbleza The "Wait 40 moves" is now "Wait 80 moves" From the changelog : "Changed the "Wait 40 moves" dialog to "Wait 80 moves" to better reflect the time actually waited." Originally Posted By: Ahbleza I've noticed that when the Party is in a Dungeon, things like Webs, or Spells cast by the Bad Guys, like Curse, etc. seem to last a very long time, to the point the Party needs to leave the Dungeon for them to go away. The same happens with Combative Spells cast by the Party, such as Bless, Haste, etc. What version of the game are you using ? This sounds like a critical bug (introduced in 1.1, thanks an undetected code collision) that has been identified in May 2010. Chokboyz

CRISIS on INFINITE SLARTIES (name subject to change ) has run through the code, "munchkin style" (his words) and reported back his finding in this topic : http://www.spiderwebforums.com/forum/ubbthreads.php?ubb=showflat&Number=201895#Post201895 . Everything luck related is explained there. Hope it helps, Chokboyz

Originally Posted By: Celtic Minstrel It may be true that no-one willingly used petrification touch, but I still think it should be honoured if someone did willingly use it. Being common BoE knowledge that petrifying touch was in fact disease touch, i doubt anyone used it willingly. Nonetheless, doing a routine check, after loading a legacy scenario, that would correct the "vorpal cockroaches" mistake (and the likes), would easily solve the problem. Then again, someone may have wanted cockroaches with petrifying touch in his scenario (just joking ! ). Originally Posted By: Celtic Minstrel This bug is not retained in legacy mode, then? Yes. The legacy behavior of not needing resurrection balm is thus preserved/assured (as far as i know, the glitch was so esoteric that no one ever reported/experienced it). When finishing to use replace overall_mode constants in the game code some time long, i found something weird in the "equip function". While not being able to equip armor while in combat is a feature of the game, there's also a check to prevent characters from equipping item_variety 11 in combat... Item_variety 11 being food, i wonder if it's a leftover from Exile 1/2/3 and if something wasn't supposed to be equippable in combat (as far as i recall, armor was the only forbidden thing in Exile 3...). Chokboyz

Originally Posted By: Ishad Nha I think it was actually done by someone who can program, unlike me. Odd, everything dialog-wise was already done, i just had to "connect the wires"... Bah, it's not important; it's fixed anyway Sorry about the confusion, Chokboyz

Originally Posted By: Celtic Minstrel You misunderstand my concern, which is that if a designer specifically set a monster to have petrification touch, it should have petrification touch. So, the fix of replacing petrification touch with disease touch should probably be restricted to monsters that can be recognized as being one of the original erroneous monsters from the bladbase. Nothing is changed for new scenarios : the petrification touch is there and working. The check/replacement is only done for legacy scenario (in which, no one willingly used the petrification touch, as far as i know, since it was not working). By the way, such erroneous abilities have been fixed in the current Bladbase. Originally Posted By: Celtic Minstrel Oh, for... *facepalm* Please do not under any circumstances give the designer the ability to directly control the scenario format version. I would support including a "Enable legacy compatibility" checkbox flag which, if set, makes the version 1.x.x and, if unset, sets the version to whichever latest version the editor knows how to read. Allowing the designer to arbitrarily manipulate these flags could potentially defeat the purpose of their existence, which is to check which version of the scenario editor created the scenario. [...] Please replace with a simple checkbox, as mentioned above. The designer should not have the ability to edit internal fields like this. I was just using a feature implemented by (i think) Ishad Nha, in the current scenario editor which allowed to manipulate the "prog make version" directly. It was done as a quick and dirty way to test changes, not meant to last in any way (hence the comment). I'll, when time permits, replace it with a checkbox, as suggested. Quick to do, so it's done... I'll release the new patch after making sure that nothing more needs to be done. It's released : http://code.google.com/p/openexile/downloads/list Originally Posted By: Celtic Minstrel So, does it still check the incorrect field in legacy mode? Yup, as it should. Originally Posted By: Celtic Minstrel In legacy mode, did you keep the old behaviour entirely or simply remove any effect of Resurrection Balm on the spells? No, i've removed the need for resurrection balm entirely for legacy scenarios. In fact, the check was so bugged, that if you had the resurrection balm in an esoteric item slot (let's say 16), casting the spell was prevented and "Resurrection balm needed" message was shown. Chokboyz

Originally Posted By: S M Adventurer Again, I'm not sure if this was mentioned already, but I found a bug with the current release of OBoE. Cockroaches have their ability set to Petrification Touch by default. While Celtic Minstrel is perfectly right in that it is a scenario problem (the basic cockroach had the petryfing touch ability in the default bladbase, hence any scenario made with the old, buggy bladbase would inherit oddly overpowered cockroaches. Of course, that was no problem, since Jeff somehow decided that Petrifying and Disease touches had the same effect code-wise), fixing the petrifying touch ability have indeed created some problems with several legacy scenarios. I've had some time this week-end to fix a compatibility breaking issue with show/hide town nodes that made some scenarios unwinnable (at least "Of Good And Evil" by Alcritas, see http://www.spiderwebforums.com/forum/ubbthreads.php?ubb=showflat&Number=213050). While i was at it, i've put a check when loading monsters so that, in legacy scenarios the petrifying touch is replaced by disease touch. That should fix the problem, without impacting any legacy scenario. Originally Posted By: Celtic Minstrel Obviously this'd have to be done without erroneously "fixing" basilisks or anything like that; it would need to specifically check the ones that were incorrect in the original bladbase. Don't worry about that, the petrifying touch was, originally, exactly the same as disease touch (basilisks and others petrifying monsters use Petrification Ray), so there's nothing specific to check. So, i've release a patch that fixes the two problems mentioned above. Also, i've finally added the ability to change the "scenario format" used, in that designers can now change the "prog make version" array of the scenario. Version 1.x.x is legacy and force the compatibility in the game; anything above (2.x.x , etc) makes use of fixed and new features. As usual, find the patch at : http://code.google.com/p/openexile/downloads/list Click to reveal.. (Changelog) Build 27.09.2010 Classic Blades of Exile : Fixed a compatibility breaking issue concerning Show/hide town nodes. Such nodes work the same way it were (i.e flawed) in legacy scenarios, fixing problems about towns that should appear but don't. Petrifying touch ability acts again as Disease touch in legacy scenarios, preventing the "vorpal cockroach" syndrom. Classic Scenario Editor : Two new working fields in the Scenario Details dialog : Minimum version, which is unused for now (it represents the minimum version of the game that is needed to play the scenario) Program Make Version (not to confuse with Scenario Version), which is the version of the scenario "format" to use : first number is the major version : set to 1 for legacy scenario, hence forcing legacy compatibility. Anything higher is "new scenario" format and makes the game use fixed features (see below). the two next numbers are unused for now. Things affected by using the "new scenario" format ("program make version" of the form 2.x.x) : town difficulty is used (in legacy scenarios, it was set to 0 for all towns, making it useless). Be warned, setting a high difficulty for a town can have dramatic effects on the game : doors of difficulty 10 town are next to impossible to picklock and so on... List of things affected by town difficulty : monsters spawning rate doors (resp. barriers) lockpicking/bashing/magically unlocking (resp. dispelling) difficulty trap disarming difficulty and damage they do a special node can be called when a town becomes hostile (see the "Town/Advanced Town Details" menu). In legacy scenarios, the "Town special to call..." field is ignored (didn't exist). petrifying touch is fully working (in legacy scenarios, petrifying touch was, in fact, disease touch) resurrection balm IS needed for "Raise Dead" and "Resurrect" spells. (in legacy scenarios, the resurrection balm wasn't needed and even, if put in the wrong item slot, could prevent the use of these spells!). the Show/hide node is correctly working (in legacy scenario, the field 2a was checked in place of 1b) Please note that this is mainly a maintenance release, to fix a game breaking bug in legacy scenarios. The "new scenario" format part was something that was floating around, in the code, for some time and not having time to work on BoE anymore, i've put it in so that eventual/casual designers can benefit from the already fixed/done new features. Chokboyz

Originally Posted By: Alcritas In the original BOE, there were a lot of "features" that didn't work. Among these was the "Reveal Town" node. Reveal Town has two options - "Hide Town" and "Reveal Town"; I think "Hide Town" is the default. Unfortunately, in the original BOE, regardless of which option you checked, it functioned as "Reveal Town". I'm guessing you're playing now with one of the open source BOEs, which have corrected many of the flaws of original BOE. The problem is, some scenarios that were programmed in original BOE were programmed to the flaws of original BOE, and don't function quite right without the flaws. Screwy, eh? Exactly. When i found the reveal/hide town node default, i asked the community whether we should fixed it or not and everyone seemed to agree that no one found the correct way it was working (the field 2a was checked instead of 1b if i remember correctly ...) and that fixing it would be harmless. So i fixed it and tested by going through several scenarios (i obviously didn't test the forementioned huge scenarios). Not founding any problem, the fix was added to the working version. Turns out i/we missed something I don't have time to work on Blades of Exile anymore (hence the long reaction time), but since it's a game-breaking problem, i'll probably release a quick "fixed" exe that would force the old buggy behavior for legacy scenarios. If i'm missing something important, don't hesitate to mention it. Chokboyz Edit : uploaded a patch that fix this problem.

Originally Posted By: Miramor There are Linux and Windows binary versions of WxWidgets OBoE available on the Google Code page, but no sources as far as I can tell, and none in SVN for the WxWidgets version either. I'd like to experiment with the OBoE code and maybe eventually contribute, but it seems the sources aren't there... Help? Like Celtic Minstrel said, there's an experimental branch dedicated to the wxWidgets port attempt of OBoE. The character editor is the only program presently converted (as it was the easiest), but the general engine transition is underway,counting a working dialog engine and new dialog/frame classes. The code is always in a messy C/C++ hybrid state, though; so be prepared when fiddling with the code Concerning your java idea (independantly of its "rightfulness"), starting with character editor is a good move, as it will give you a good insight of BoE mechanics, plus gives you useful classes for both the scenario editor and the game. Agreed on the IO file part of the code, don't hesitate to rewrite it (compatibility would be nice though). Finally, if you want to put some time in BoE, be warned it takes a good deal of it and if you're getting a job, you'll probably have a hard time doing both (in fact, life striking back, i have hardly been able to find some for the wxWidgetification of the game and it's presently in a barely compilable state, with lots of functions to be adapted/rewritten... and, given the way things are working out, i'll probably be force to pull out of the project after uploading whatever work i have done ). Anyway, good luck with your java thing; let's hope something comes out of it ... Chokboyz

Originally Posted By: Celtic Minstrel Alright, we should start on converting the other two programs in the near future, then. If you want to do it, please try to commit a bit more regularly. If not, I'll try to find the time. Alternatively, one of use could focus on the game while the other focuses on the scenario editor. It's planned : if there's no negative feedback, i'll probably begin by porting the game ... if you want to give a try at the editor, you're welcome Chokboyz

Originally Posted By: Celtic Minstrel By the way, the wxWidgets code appears to only include the character editor. Is this correct? Yes it is : only the Character Editor has been converted for now (mainly for testing purpose) ... Chokboyz

Originally Posted By: Celtic Minstrel This font is used for what? General dialogue text? Yup ... it's the font used whenever the Maidenword font is not (note that the Maidenword font is not used in the Character Editor). Chokboyz

Originally Posted By: CRISIS on INFINITE SLARTIES Is there any reason -not- to let the OS handle those things? Cross-platformability ... If we let the OS handle these, we'll have to write pieces of code for each platform when we'll introduce some features, say new menu and such (not to mention the fact that we'll have to make a linux (gtk ?) interface from scratch) or when widgets comes into play (wxWidgets makes that unnecessary). I would prefer a code that doesn't rely too much on the platform it's running on, but putting conditional compilation where it's needed would work Originally Posted By: Celtic Minstrel I say that since it's done, let's go with it. If we're worried about size, we can compile the game against a nerfed copy of wxWidgets that has only the components we actually use. Personally, I'm not going to bother with that, but once there's a more-or-less stable release anyone else is welcome to try. Ok, so let's keep and test wxWidgets for now. I'll keep an eye on SDL in case something official happens (compiling SDL 1.3 on Windows right now is a true nightmare anyway ). I forgot to mention that if you want to compile the wxWidgets code on Mac, the only mandatory change to the code is to add a conditional compilation at the beginning of the app to load the right font (uses "MS Sans Script" (as in the original Character Editor) for Windows and the "equivalent" Liberation Sans for Linux). The rest of the code, being non-platform dependent, should work the same (in practise, it will probably need some tweaking as the portability is not perfect (cf linux problems)). Chokboyz

Hello everyone, sorry for the blackout but i just had a busy April month ... Nonetheless, on with the mixed bag of news : - On the good side, i've been able to finish the new XML dialog engine and subsequently the port of the Character Editor using wxWidgets (which needed much more than the new dialog engine, as Murphy's law could have predicted) ... It's actually fully functionnal (at last, as far as i could test it, don't hesitate to send feedback) on Windows and Linux (Debian Lenny 5.04) with some minor problems on Linux (key shortcuts aren't working because the key_down event doesn't seem to be called at all, and the menu breaks don't either, causing giant items menus; all items are accessible though). I've rewritten the mian window/dialog engine mostly from scratch, integrating the original code only when it was needed (event handling and such); i've also been able to clean up the ressource file (now an XML file) and some part of the original code (here again i may have missed some, feedback welcome). I've also updated the Character Editor with some of the last features or missing ones such as : displaying of gold, food, day, location (town name or outdoor), scenario (scenario name or "not in a scenario"), item loading from the scenario file (use Bladbase.exs as a backup if can't find the scenario file, lock menus if can't find both), legacy Mac save (or other endianness) compatible loading procedure, ... The new XML-based dialog engine has been largely tested, but is in no way in it's definite state (for example, dialog items should be accessed via their id and not their position in the item vector ; i've made both coincides for now) and comments are welcome. I've uploaded the code in a new branch, entitled "Experimental" and Binaries for both Windows and Linux are available on the Google Site for testing purpose (or use if you new features, should be stable enough for that ... with a backup, of course ) ... Technicalities : Linux version has been compiled on Debian Lenny 5.04, with gcc 4.3.2 (Debian 4.3.2-1.1); both versions are compiled against the last stable wxWidgets (2.8.11) and Code::Blocks project are available for both platforms. That's it for the good news ... - On the other hand, as Celtic Minstrel mentioned wxWidgets is overkill for Blades of Exile (i should probably fragment the dll for Windows, i'm not really sure how much of it is used) and toying with wxWidgets has confirmed that. While it is convenient to have all those tools to work with (especially the menus and such, see below what is really needed on each platform), i'm not really sure it's worth the increase in size and memory consumption, for a cross-platformability that is not that great code-wise (must read in "my" implementation of it, of course; i'm not attacking wxWidgets ...). While there's no major problem with the current version of the code, i've been thinking about other possibilities, which would fit Blades of Exile better. One of such is, of course (and it has already been mentioned), SDL, which (from my testing) is really great when it comes to platform independance and not too intrusive (size, memory consumption, ... as long as you don't mind 10+ dll in your working folder on Windows ). The main problem we would encounter with SDL is that there's no support for widgets and we would have to either, integrate SDL in a platform dependant window, or create our own set of widgets. From my experience with the code, here's what, i think, is needed to be taken into account for (graphical) cross-platformability : the dialog engine (or ressources in general) : no longer a problem with the XML-based engine. It seems that TinyXML's approach to XML handling is the same as wxWidgets, so convertion should be fairly easy ... scroll bars : actually handled by the OS, shouldn't be hard to make our own. text input (aka Text Control, aka Text Edit Box, aka White Area Where You Input Text ) : actually handled by the OS. This one's tricky ... I've actually seen implementation of such things in SDL (Widelands, ScummVM, etc), but didn't try yet. menus : actually handled by the OS. The big part : if you don't let the OS do the job, we would have to either recreate it or use icon based menus (à la Avernum/Geneforge). System Dialogs : Open File, Save File, etc ... actually handled by the OS. I've seen it done in SDL (ScummVM), but that doesn't sound that easy ... So here we are ... we can choose to go on with wxWidgets (knowing that it's probably too much for the task) or test another way (for example SDL ... we don't need the last 1.3 prerelease though : it would be more practical for programming, but dialogs and such can be done with the old 1.2 ... ) Chokboyz P.S : someone asked for a April release of Win32 Classic Blades of Exile, with some of the recent changes, so i've uploaded an updated version of the program. I remind everyone that wants to compile/fiddle with the code that working (i.e compiling) projects for DevCpp and Code::Blocks are available in the sources.

Originally Posted By: Thaluikhain That also does not want to work. Hmmm... I've redownloaded a fresh copy of Classic BoE, patched it to 1.1 and finally tested the election.zip archive that's on the top of the board : it worked just fine, the Vfndell party was loaded succesfully when using elecmac.sav (no error, party ready to enter a scenario). What exactly is your error (message, ...) and what version of BoE are you using ? Chokboyz

The electpc.sav file is corrupted (or incomplete or whatever since it's only 11ko ...), use the elecmac.sav file instead (assuming you're using Classic Blades of Exile which can read both Windows and Mac savefiles). Hope it helps, Chokboyz

Originally Posted By: Thaluikhain in my version at least, some of the custom graphics of Pyramids need fixing, though You mean the patches of white color appearing in scorpions, elementals and such ? If so, the problem comes from the graphical file (pyramid.bmp) in which the artist use non-white (non 0.0.0 rgb) color for some part of the background. Repainting the background with pure white color will fix this (if someone ever has the courage to do so, i left the file alone when i was sure the game engine was not at fault ). Hope it helps, Chokboyz

Originally Posted By: CRISIS on INFINITE SLARTIES Thanks for the clarifications & corrections! I am a bit embarassed by how many errors my summary had -- guess I shouldn't do this stuff after I stay up all night No problem, the code is pretty hard to read correctly (even more if it's a part that uses non-human readable constants ) in current state ... Your work has definitely been useful though : 2 bugs and a discrepancy in the Windows code have been found, plus i've changed constants to human-readable ones (see classes/consts.h) when checking the code, making it much clearer ... Originally Posted By: CRISIS on INFINITE SLARTIES The code appears to deal this damage to anything in the square when the barrier is cast. I know from experience that barriers definitely do damage when cast, just as the damaging walls do, but the mechanism appears to be different. I was suspecting something like that ... Double-checking the code, it seems like my also-tired-eyes skipped the hit_space line : your force barrier entry is definitely right. Originally Posted By: CRISIS on INFINITE SLARTIES The bonus is definitely present in the Mac BoE code, although it is not possible to join the Anama in BoE so it's irrelevant. Yup, the Mac code is somewhat behind in term of bugfixes, whereas the Windows one is lacking the "new engine" contents (trims, roads drawing, etc). When the multiplatform code will be finished (working on it, time is hard to find this month ...), both those problems will be history. Originally Posted By: CRISIS on INFINITE SLARTIES It isn't possible to have items 17-24 equipped, is it? LH, RH, Bow, Ammo, Cloak, Helmet, Armor, Pants, Boots, Gloves, Ring, Ring, Necklace, Lockpicks... I can only get to 14. I'm not speaking about the item types here (there's 26 of them, with shield being redundantly listed two times, see classes/consts.h for a list). The inventory of a character can hold up to 24 items, whereas in Exile I and II, it was limited to 16 items. The get_encumberance() function is checking every equipped item and summed the awkward value to get the total encumberance. (Un)fortunalety the function seems to have not been updated when the inventory passed from 16 to 24 items in Exile III, so the encumberance of the 8 last object are not taken into account, only the 16 first being checked. Hope, i'm clearer Originally Posted By: CRISIS on INFINITE SLARTIES Whoa -- you're right! I missed that, and WOW does that make Defense skill more useful. You can easily knock off 6-10 damage per attack with a high Defense. Indeed, it's definitely a useful skill. Originally Posted By: CRISIS on INFINITE SLARTIES Whoops, I thought get_prot_level summed all the scores for some reason. It doesn't. Actually, the item checking code is pretty straight forward (if it founds an corresponding item, it keeps it, even if an item with the same ability but higher ability strength is equipped after in the list). Checking (and correcting) the code for Giant's Strength and Skill ability (http://code.google.com/p/openexile/issues/detail?id=16), the issue arose and we're comtempling possibles solutions : 1)keep the item with the higher ability strength (so having two items with the same ability equipped would give no more benefit) 2)somehow summing up the items' ability, so that having two items with the same ability grants a bonus. Chokboyz Edit : Oh, i now remember why the Cave lore and Woodsman food gathering function was left of the Windows code : it's because they were never actually called anywhere. Putting it back wouldn't requires much effort though

Great, someone doing what i couldn't find the time to do, an all purpose guide to BoE stats (not to mention making easier the mac and windows codes comparison) A few precisions to the otherwise correct previous posts : Originally Posted By: CRISIS on INFINITE SLARTIES Chronic Disease:- 1 in 111 chance of getting 4 levels of disease each turn. There's some adjustments inside the "disease" function : (that's what happens for any disease put on a pc) There's a (2* pc_level /101) chance that 2 levels of disease are not applied (to the 4 levels for chronic disease, for example) If the no level of disease are now to be applied, the pc is saved. Else, if an item with Protection from Disease is equipped, (item_ability_strengh / 2) is substract to the remaining level of disease to put. Finally, if the character is "Frail", plus one level of disease to add, and if there's only one level of disease to apply a 1/2 chance to add another. (you mentioned that further in the first post) Originally Posted By: CRISIS on INFINITE SLARTIES Cave Lore and Woodsman:- 1 in 13 chance of getting 2-12 food each turn when in appropriate terrain. - Activates the appropriate checks. Cave Lore also gives a 1/2 chance to fall waterfalls without losing food (else you lose food everytime). Also, the food giving part of Woodsman has apparently mysteriously disappeared from the Windows code ... Thanks, i'll put it back. Originally Posted By: CRISIS on INFINITE SLARTIES Good Constitution:[...] - Appears to do nothing vs disease due to a bug Good catch, there indeed a bug (present in the original code, preventing it from working : a random number was recomputed instead of using the previously adusjted one). This is fixed : 1/8 chance to lose a level of disease without the trait, 3/8 with the trait. Note that a "protect from disease" equipped item automatically removes the level. (Edit : Fixed) Originally Posted By: CRISIS on INFINITE SLARTIES Frail:- Will usually get 1 extra level of poison or disease, when so afflicted The mechanism for poison is exactly the same as for disease (see above). Originally Posted By: CRISIS on INFINITE SLARTIES Conclusion: level is not tremendously important, unless I am underestimating its impact on spell damage. Level is essential for spell casting as most effect are relying on it. Paralysis resistance is also affected by level. Originally Posted By: CRISIS on INFINITE SLARTIES Fire Barrier 6-21 In the Windows code, the damage are 2-20. Originally Posted By: CRISIS on INFINITE SLARTIES Force Barrier 14-49 As far as i know, the Force Barriers don't do damage, just preventing a space from being entered. Force Barriers indeed does damage if on the same square, and the damages are indeed 14-49. Walls are more forgiving to the pc : Ice Wall 2-12 1 in 6 Force Wall 2-12 1 in 6 Fire Wall 1-6 1 in 4 Blade Wall 4-32 1 in 5 Originally Posted By: CRISIS on INFINITE SLARTIES Ice Bolt 20-80 (Level Bonus + Int Bonus)d4 Indeed, it's the max of those two values (idem when it has two values in the second post table). Except that you've applied the initial (at the begin of the function) level is 1 + level /2 convention to the Wound and Flame spells; so for sake of consistency the correct value should be : Ice Bolt 20-80 (Level / 2 + Int Bonus)d4 Idem with Kill : 40-70 + Level and Death Arrows : 0-30 + Level / 2 + Int Bonus*3 Originally Posted By: CRISIS on INFINITE SLARTIES Fireball 10-60 (Level/3 + Int Bonus + 1)Firestorm 14-84 (Level/3 + Int Bonus + 1) * 14/10 These are tricky to put out : Fireball = min(10 , (Level/3 + Int Bonus + 2))*d6 Flamestrike = min(10 , (Level/3 + Int Bonus + 2) * 14/10))*d6 (by the way, the spell 141 is not Fire Storm but Flamestrike) The Firestorm damages are : min(14,3 + (level * 2) / 3 + bonus))*d6 The Divine Thud is missing, it's damages are : min(18,(level * 7) / 20 + 2 * bonus)*d6 (using the level / 2 convention) Originally Posted By: CRISIS on INFINITE SLARTIES Turn Undead 2-28 ??Dispel Undead 6-84 ?? Absolutely correct. Originally Posted By: CRISIS on INFINITE SLARTIES Ravage Demon 15-165 (8 + Int Bonus*2)d11 (note: you also get a flat +25 bonus if you are in the Anama!) Ravage Demon does indeed (8 + Int Bonus*2)d11 damages. For information, the Anama thing is not longer present in BoE, but should be accurate for Exile 3. Originally Posted By: Celtic Minstrel If I recall correctly, monsters have totally separate code for their spells, so the above presumably applies only to PC spells. Absolutely : Code: Spells Damages(if apply)Wrack 2-8StumbleBlessesCurseWound 4-14Summon Spirit/Guardian/HostDiseaseHoly Scourge (slow + curse)Smite 6-26Sticks to SnakesMartyr's ShieldCurse AllPestilenceVarious healsBless AllRevive AllFlamestrike (4 + monster_level / 2)Holy Ravaging 4-32 (slow + poison)AvatarDivine Thud ((monster_level * 3) / 4 + 5) Originally Posted By: CRISIS on INFINITE SLARTIES PICK LOCKS: 5,30,35,42,48, 55,63,69,75,77, 78,80,82,84,86, 88,90,92,94,96,98 2.0 steps @ Dex Bonus 1.0 steps @ Pick Locks Disarm Trap 0.5 steps @ Luck Flat +6% @ Nimble Fingers No, that's Disarm Trap. Aside from that it's correct Note : 1.0 step @ (equipped thieving item ability strength /2 ) * 2 Originally Posted By: CRISIS on INFINITE SLARTIES ASSASSINATION = [...] Note that you can't assassinate Splitters. Originally Posted By: CRISIS on INFINITE SLARTIES Chance of identifying a non-boring item when it is created.1.0 steps @ total of Item Lore skill in the party In fact, the check is done for every pc instead of the whole party, so the item lore is not summed. Originally Posted By: CRISIS on INFINITE SLARTIES Use the Hit Chance table. Do this process for EACH encumbering item. Oddly, i've just noticed that the last 8 items are not checked in this process (that's undoubtly a leftover of Exile 2 when pc could only have 16 items ... i bet it's present in Exile 3 as well). I should fix that, i think ... Originally Posted By: CRISIS on INFINITE SLARTIES LUCK SAVING LIFE It uses the Hit Chance table, so you can't actually be 100% immortal... just 99% immortal. This means that a mere 1 point of Luck gives you a 30% chance to stay alive... you do need at least 1 Luck for this check to take place. Actually 100/101 immortal ... unless the damage type is set to bypass the luck check Originally Posted By: CRISIS on INFINITE SLARTIES Parry reduces damage by 25% of its evasion value (see below). Only on weapon and fire damages. Originally Posted By: CRISIS on INFINITE SLARTIES Defense skill has a chance to reduce damage by 1 using the Hit Chance table with a 20% penalty. For each armor item worn. Originally Posted By: CRISIS on INFINITE SLARTIES MAGIC DAMAGE Onyx Charm reduces energy damage by 50%. Ruby Charm and Ring of Fire Res. reduce fire damage by 50%, or by 75% if two or more are worn. Ring of Warmth (NOT Iceshield -- bug) reduces ice damage by 50%, or by 75% if two are worn. Ring of Resistance is AMAZING -- it reduces fire, cold, energy and poison damage all by 75% and is cumulative with other rings and effects! Magic Resistance status reduce fire and cold damage by 50%. Seems a bit off there ... If the damage type is X and the wearer has a "X Protection" item, the amount of damage is reduced by 50% if the ability strength of the item is < 7 and by 75%, if >= 7. Replace X by magic, fire and cold. If the victim actually has magic resistance activated, fire and cold damages are reduced by 50%. For Magic, Poison, Fire and Cold damages, a "Full Protection" item reduced (even further) the damages by 50 % if ability is < 7 and 75 % if >=7. Originally Posted By: CRISIS on INFINITE SLARTIES PICK LOCKSJust a flat +5% bonus per point, no table lookup. Yup, for every lock picking point. There's more modifiers though : lockpicks quality, dexterity, thieving items, nimble fingers, etc (difficulty also in the new format). Chokboyz

Originally Posted By: Celtic Minstrel Indeed, Geneva lacks bold. Fortunately, both Arial and Verdana do have bold. [...] By doing this, you'll ensure that most people see Arial (or Verdana), but those who lack that font still see a sans-serif font. (At least, I think SWISS is the sans-serif.) Your code is right and i'm rightly using wxFont (i pass the facename to the constructor directly), the "problem" is that wxWidgets only loads fonts from the system font folder (as far as i know), so these would have to be installed if needed (i don't know if arial or verdana is present by default under linux). For information, the font used in Windows's BoE was Times New Roman, which is with serif (hence the need to change the code default values, fonts sans-serif being wider than serif) and it seems that Geneva is sans-serif, so we'd have to agree on a common font ... As proposed, Arial or Verdana are ok ... Originally Posted By: Ishad Nha For an 8*8 zoom display I will need to alter Mixed.bmp to create 8*8 editor icons to replace the present 4*4 variety. This could be done in the BoE Zoom Editor, as soon as I whip up a town with the terrain following the right numerical pattern. Zoom out to 8*8 mode and do a screen capture. From what i've gathered, you want to implement an intermediate (medium) zoom mode in the Editor, is that right ? If so, i think it would be easier to just use the blit stretch function to enlarge the sprites, negating the need to create 8*8 icons. Originally Posted By: Celtic Minstrel I could be wrong, but I think Mixed.bmp isn't where the map graphics are stored anymore... Mixed.bmp has not been rid of yet, so the map graphics (both versions) are indeed there ... Chokboyz

Originally Posted By: Celtic Minstrel Can you give more details about the text problem? For example, what font are you using? [...] (Or might the problem be that a font is not being specified and wxWidgets is using the default system font?) That's the problem, wxWidgets uses its own font mananagement (i didn't find a way to load a font from a ttf file) and it seems not consistant between platforms (will read about these to make sure, maybe i'm missing something after all). So, i'm actually using the default wxWidget fonts. Apart from this font/size problem the text displaying functions are done. Chokboyz

Originally Posted By: Celtic Minstrel So, what of the wxWidgets stuff? How's that coming? The basic dialog creation (size, text via xml) is done, but i ran into some trouble : first the Windows dialog creation variables (width, length) are somewhat off (easy to fix) but more important, wxWidget text handling has proved lacking (may be my fault, i don't put the blame on wxWidgets), as for example the text size is not consistant from one platform to another. I'm now planning to use freetype to handle all font creation and text drawing. Chokboyz