Chokboyz

Following some requests/reports here : http://www.ironycentral.com/forum/ubbthreads.php?ubb=showflat&Number=179512&page=5 (see Taslim) and on the Google Code site, i've uploaded a quick revision of the Classic Blades of Exile code. Changelog : Blades of Exile : Corrected the Skill and Giant Strength abilities handling so that they actually increase the chances of hitting instead of decreasing it (damages were correctly handled). Now trying to enter a blocked space multiple times won't produce a lot of message but add a (xX) suffix to the "blocked:" message (X number of tries to enter the space) Minor Editor changes : When opening a new town or assigning a new town to a town entry on outdoor map, the input field is already selected (extended the basic function for flexibility). Code-wise : Added a custom makefile for DevCpp which solves the ressources multiple- definitions problem (only Game and Editor, the Character Editor wasn't affected). Readded legacy monster skill constants to CONSTS.h, to make the original code easier to understand for newcomers. Chokboyz

Originally Posted By: Celtic Minstrel I wonder if Windows laptop users can move diagonally, then... They can (although it may be awkward if Home, Page Up/Down and End keys are oddly placed). Chokboyz

Originally Posted By: Celtic Minstrel As previously mentioned, navigation is with the numeric keypad, not the arrow keys. I suppose that should probably be changed sometime, though, to support Macbook players... in which case I'd probably use the following mapping: [...] This mapping has already been succesfully implemented in the Windows code, with the nice side effect that numeric keypad movement works whatever the num_lock position (even diagonal) ... So, i'd say using this mapping is a good idea (on the other hand, i wasn't aware that the Mac version didn't use arrows movement ) Originally Posted By: Celtic Minstrel Allowing the player to select their own keys is fairly unlikely to be implemented... Seconded. Chokboyz

Originally Posted By: Taslim as soon as I can get Dev-Cpp to compile correctly. (any help with that would be nice, but this prolly isn't the best topic to bring it up in). Quick answer : CBoE compiles correctly on Dev-Cpp, but the compiler throws a general error (your code is messed up etc) because too many warnings occurs while linking (the executable is produced anyway). The problem lies in the way Dev-Cpp handle windows ressources compiling/linking : it fuses all availaible .rc into one big ressource file and windres/link using it. Other IDE (Code::Blocks for citing only one) don't do such a thing, thus to be able to compile, ressources files have to be interwened (using mutual inclusions). The problem is that, with those inclusions, when Dev-Cpp fuse the differents .rc into the big file, there's multiple redefinitions of every ressources (because of the inclusions) making the compiler spits lots of warning finally making Dev-Cpp throws a general error. To make the general error go away, just delete the following block on each .rc file : #ifndef _INCLUDED_RC ... #endif Hope it helps, Chokboyz Edit : Originally Posted By: Taslim Scenario Editor: When opening a new town it would be nice if the input field was already selected. By the way, are you speaking of the "Load Another Town" option ? If so, the focus is on the input field already in my version ...

Sorry about the delay, lots of things to do ... Originally Posted By: Celtic Minstrel Does it have a way to change the cursor though? Yes, there is (but i haven't done it yet). Originally Posted By: Kelandon When you do your cross-platform stuff, will that solve the age-old problem that Win-BoE can display more text in dialogue than Mac-BoE could, so Windows designers sometimes overflowed the dialogue box and we couldn't actually read everything they wrote? It all depends on wxWidget well handling of the cross-platformability (if this word even exists ) ... but even if it doesn't (i.e fonts size differs from platform to another), a simple conditional compilation with different sizes would solve the problem. I don't exactly know when the problem occurs, but if it's in dialogs then it would be solved with the new dialog construction, if it's while talking, the above solution would do the job. Originally Posted By: Celtic Minstrel I have been toying with the idea of adding a scrollbar to the dialogue screen, which would solve the problem. That's definitely another possibility ... Chokboyz

Hum, from what i understand you want to use the native API and integrate an SDL surface on which all the drawing will be done, hence solving the menus problems ... Would work, but we'll have to build an (GTK ?) interface for the linux platform in that case. Or i'm completely missing the point Anyway, i'll finish the dialog construction engine and post the execs and sources (then we'll deal with them or not) Originally Posted By: Celtic Minstrel if we're careful it could be set up so that the game code simply hooks into one or the other I'm trying to isolate the platform dependant code as much as possible, but that's pretty hard given the initial code (and the fact i'm rewriting it ). Don't know about the possible cursor problem, but i'd suppose SDL have a way to manage that (loading a small bitmap or whatever) ... Chokboyz

Originally Posted By: Celtic Minstrel I'm still not sure that wxWidgets is the best choice though, which is why I wanted to take a look at the code. I'm sure it'll work, but I'm still thinking SDL would have been better. No problem, we can use SDL instead ... The only downfalls are : no menus or "widgets" supports (meaning we'll have to create menus and text edit area ourselves) and fragmentated libraries (for example, using SDL_ttf for loading the maiden font). Graphical-wise, it's one of the best choice though, because we don't need anything more than blitting (and not at light-speed with that). The multiple windows problem being (partially ?) solved, we're free to go ... Chokboyz

Originally Posted By: Celtic Minstrel Chokboyz, if you're still listening... what do you think? Just how much work have you done with wxWidgets, and does it seem to work well? I'm in the process of finishing to port character editor; in practical, only remains to implement the new dialog construction engine (the one that read xml) which won't be long since all the needed features are already present in wxWidgets. The only remaining problem is the maiden font handling, as i didn't find a way to have wxWidget use custom fonts (the character editor doesn't use it, but the game does). One workaround would be to use freetype or similar library ... So far, the main window of the editor is fully functional (i.e file loading, party member selecting, info displaying, item fiddling, etc ...). Last time i checked, i was able to build it on linux (last Lenny Debian 5.04) without an hitch. Of course, having rewritten (and really simplified) some part of the code (like sound playing), the code is a little rough on the edge (the xml handling is a little crude, but working) but all basic functionnalities are here (except dialogs construction which i will probably finish on my spare time this week-end) and can be improved if the need arise. (for info, i've rewritten the character editor from scratch, because the code was in need of some cleaning ) Concerning the merging/porting process, once the main objects (windows, dialogs,) will be available (and they all nearly are), all that would be needed is a list of differences between Mac and Windows to smoother. Chokboyz

Originally Posted By: Celtic Minstrel Actually, by "widget" I meant an object that you place in a window; the only such object required is a scrolled pane (probably a wxPane or wxPanel with vertical scrollbar?). Oh, my bad ... then I don't plan on using any extra widgets. Speaking of which, won't text edit boxes (white text areas where user can write in) be needed too ? Chokboyz

Originally Posted By: Celtic Minstrel Well, the only reason I was reluctant to use wxWidgets is because it's rather overkill for the job. Agreed, that's the main reason why i hesitated to switch to wxWidget (i had done a semi-functionnal (no dialog) character editor with SFML but wasn't pleased with the final result (strayed too much from the original BoE, although it's probably my implementation)). Originally Posted By: Celtic Minstrel I wouldn't worry about the use of width and height rather than right and bottom. No problem; i've even wrote convenient methods to safely switch between those two concepts (mainly for quick code conversion)). Originally Posted By: Celtic Minstrel Just don't use any of the actual widgets (apart from a scrolled pane), because we aren't going for a native dialog and window appearance; we want the custom BoE appearance. Main window and dialogs drawing is handled by adapted BoE functions, so the apparence is exactly the same as BoE (same background pattern, same cyan dialog frame, ...) . The only "widgets" i use are open file dialogs, menus and, of course, frame and dialog windows (which makes the use of wxWidget even more overkill, i must admit ... ). Originally Posted By: Celtic Minstrel I'd quite like to see something of what you've done on this. I'll have to fiddle a little more with the basic editor code and the ressource management (dialog building) and i'll probably be able to upload a snippet of it looks like. Originally Posted By: Celtic Minstrel There are some fairly minor features added in the Mac version that (as far as I know) didn't make it into the Windows version, but I'd say the main differences are overarching structural changes that Ormus and I did. The main trouble is that he did them one way, and I did them in a different way. Naturally I prefer my way. Take a look at the class files, in particular, to see what I mean. Ok, i'll look at that. On Ormus "boe_sounds.dll", i think reverting back to original BoE sound playing won't be hard using wxWidget sound management. Originally Posted By: Celtic Minstrel ...I'm hoping someone else (Niemand, maybe) will chip in with their opinion. Would be nice indeed Chokboyz

Originally Posted By: Celtic Minstrel I was just wondering whether anyone has looked at the code at all recently? I know I haven't, though I might get back to it again in the next few months. Yup, i've been fiddling with the code on and off, when i find some time, mainly trying to produce multi-platform code ... Which leads to the next question : Originally Posted By: Celtic Minstrel I was also looking around for multiple-window support in SDL, and it turns out SDL 1.3 has it. The only problem is that, according to the official statement, it's still a prerelease version; but I did find at least one person claiming it to be ready for use. I found the same thing, SDL doesn't have multiple-window support (except for the child process method you mention, which would be overkill in my opinion) but it's planned for the next version. Searching a little more, i found SFML that has such support but decided, after much fiddling, that the windowing support was too much of a burden to do without some sort of canvas (not only scrolling, but menus, etc. Not to mention the integrated XML-like ressource management). Then i tried classic frameworks (GTK+, wxWidget, QT (a bit)) and found that wxWidget (2.8.10) has everything that BoE needs, to be easily ported (QT may have too, i didn't dwelve too much in it, having some problems with the integrated IDE). So, i rewrote the main graphical functions (screen drawing, patterns, frames, strings drawing, ...) and i'm currently in the process of finishing to port the character editor (as a test, since the code is pretty straight forward for this one). Problems found so far : wxWidget documentation is really hard to come by (except the official one. That's not such a problem since the basic functions are now done) wxWidget uses width and height instead of right and bottom for rectangles (defined a BoERect class that mainly solved that) wxWidget handling of custom fonts is non-existent (i may have missed something here) and i've not been able to use the maidfont.ttf font. Possible solution : use freetype for this font. Originally Posted By: Celtic Minstrel The only two questions are: Should we wait until it's no longer labelled "prerelease"? That could easily be quite a long time, though. From the look of it, that will not probably be anytime soon. The SVN is said (mailing list, etc) to be pretty stable, but i've not tested it. Originally Posted By: Celtic Minstrel Is it better to merge the Mac and Windows sources before doing something like this, or would it be better to do them simultaneously? I'd say it's probably better to have some kind of common platform before merging codes ... For information : apart from the roads and trims (and specials ?) drawing method (which can easily be integrated while porting), on what does the Mac code differs from the Windows code one ? Chokboyz

I'm a little confused here, is the problem solved (if there was any to start with) ? So far, the last version of Classic BoE has been successfully tested on Win XP and Vista (no 7 here, but it should run fine. If anyone tested it and feels like confirming this ) Originally Posted By: Ishad Nha If someone comes from France are they using the English version of Windows? More likely to use a French (localized) version but the game would run fine nonetheless. The only "problem" that can be encountered is a different keyboard layout (for example getting the Burma Shave message is more esoteric than simply hitting adjacents keys), but one can easily switch to the english (default) layout, so there's no problem with non-english (european, don't know about japanese/chinese/korean/... keyboards ) version of Windows. Chokboyz

Originally Posted By: Ishad Nha All my revisions should have been uploaded. Ok, so i've uploaded the 1.1 patch (don't mind the numbers) to the google code site (direct access : http://code.google.com/p/openexile/downloads/list ). Changelog : Click to reveal.. Classic Blades of Exile version 1.1 : - Fixed a typo in the "Small Rebellion" scenario's name. - In dialogue mode, if the text box is enabled, it now has focus by default. - SDF[0][x] can now be set/checked by using the "Set SDF" debug command (Shift-S). - Implemented working town difficulty for the next scenario formats (difficulty setting doesn't work in legacy scenarios) - Fixed the "reversed bashing/lockpicking difficulty scale" (4 was weakest, 0 was strongest) - Fixed the SDF[0][0] being set to 1 when killing wandering or summoned monsters. (the SDF[0][0] should be safe to use now) - Fixed the Ctrl key behavior when in look mode : one can now multilook by keeping the Ctrl key pressed. (note that it fixes the bug : pressing the down arrow in look mode actually looks but don't quit the look mode after) - Little cleaning (debug leftover and extended events initialization to the 100 possible) - Added a way to force kill the party with the Kill node (if ex1b is set to 2, then force kill. Editor node text updated.) - Implemented Home, Page Up/Down and End for diagonal movement (a side effect is that the Keypad diagonal movement is now working with either Numlock on or off). That should help with keyboard missing numkeypad. - Implemented an old Celtic Minstrel's suggestion : the kill_monst() function does now work on a local copy of the monster. That should be safer and fix all problems with faulty special nodes chains (like in Bandits 2 when the final pink boss form is destroyed then immediately replaced with the blue boss form, so that the "special on death" node checked is the new blue boss one ... effectively locking the game in that case) Classic Scenario Editor version 1.1 : - Corrected the custom graphic file loading procedure in the Scenario Editor, so that files/folders with point '.' characters in their name won't prevent correct loading. (useful if we plan to use a "scenario_filename.exr" ressource folder). - Implemented Ishad Nha's "Concise Town report" function (accessible under Town Advanced). - Fixed some minor errors in the Blades of Exile Base. - Get rid of a graphical glitch on the left of the screen that could appears on higher resolutions. - Included Ishad Nha's work on the editor : -' [ ' is an additional zoom in/zoom out key. - Ctrl + Arrow keys introduced for loading previous/next town and for outdoor zones above/below/left/right. - Town menu was rearranged. - Graying out of menus has been updated. - Version date is now shown in the Help > About Blades Scenario Editor dialog. - New scenario object write up: BoE Scenario Object data.txt - Fixed message about deleting towns when you want to create Scenario Text.txt. - Updated the Editor to include an outdoor zone report. - Added the four scenario flags to the Scenario Object Report, because they reveal whether a scenario is Mac or Windows. Reports may crash if the scenario is Mac (never crashed upon testing). - I introduced the repeat print of last file, it automatically prints a new version of the last report file to be printed. It is activated by Ctrl + P and accompanied by a message in the text area. - Town report now lists all special nodes and dialog nodes. along with the relevant text messages. Irrelevant lines have been removed. The special nodes listings can be extended to scenario and outdoor reports. - Scenario and town timers have been added to reports. - Tables have been included in scenario, outdoor and town reports showing the lengths of the relevant strings. - Now all three types of report show the full details for special nodes. - Ctrl + (Number) shortcuts have been introduced for Town and Outdoor menus. - Area Rectangles now show the lower right coordinates too. - All menus now have hot keys for each item (temporary, so that people can decide what key is the best for each command). Others : - Tweaked and rewrote some part of the code so that newer versions of Windres.exe works and it compiles in Code::Block (side effect, Dev-Cpp may now warn about Ressource duplication during compilation but it's harmless and has no effect). Code::Block project file is now included. - Scenario and character editors code tweaked so that it compiles with newer windres.exe version and Code::Blocks IDE. Code::Blocks project files included for both Editor and the sound DLL project (seems like speed optimization breaks the scenario editor : monster and item dialogs doesn't accept any entered value). - Cleaned unused variables in Scenario and Character editors code. - Cleaned some remaining Exile 3 dialogs (Ishad Nha) As always, report bugs in this thread. Have fun, Chokboyz

To Celtic Minstrel : I've implemented one of your old suggestion, that is to have the kill_monst() function work on a local copy of the killed monster to prevent the killed monster structure being erased by another due to, at least, bad though node chains (see Bandits 2). Currently, it seems to work fine and i've adopted it over the previous fix (it seems safer that way). Since there have been some changes (and requests) to the released Classic Blades of Exile version, i'll probably compile the current stable version of the code and post a "patched executable" with the new additions/fixes sometime this month (probably the coming week). To Ishad Nha : i've included your changes/additions to the editor in the current version of the code, is there anything you've done since the last commit that should be included in the next release ? Chokboyz

Originally Posted By: Celtic Minstrel If I'm not mistaken, the -3 entry would apply if your strength were 0, which isn't possible Based on the skill_bonus array, it also apply if you have 1 strength. Originally Posted By: Celtic Minstrel So, you gain between 0 and 10 health, with higher strength ensuring a higher gain. Exact, except that the random roll is inclusive, so the max is 6 and with the 5 max bonus, the gain is between 0 and 11, until level 26 is reached. Originally Posted By: Celtic Minstrel Another interesting thing to notice here is that you only get 4 skill points per level once you hit level 20. I never noticed that before. Neither do i, but it's in the Windows code as well ... Must be that at such level, the visit to the trainer is less frequent Chokboyz

Originally Posted By: King InuYasha You know what they say about assumptions To be perfectly honest, i was quite tired of checking whether a comma was missing or not in 1600+ lines of ressources and changing the compilation priority of .rc files to understand how Code::Blocks was linking compiled .res files, so my assumption was a little "forced" or "biaised" Nonetheless, both the Scenario and Character editors have been tweaked to compile with newer windres.exe and Code::Blocks .rc handling methode (be careful with speed optimization, i've been lucky to notice that with -O2 optimization, the Scenario Editor was broken (monster and items dialogs weren't accepting any input value)). Note that Code::Blocks produce bigger executable than Dev-Cpp, probably because of compilation options i'm not aware of (but both are tested and working). While i was at it, i've cleaned the two editors code of any unused variables (given the number of such, i'm pretty sure it was the first time someone did so ), so there should be far less warning now Chokboyz

Originally Posted By: King InuYasha I see you updated the SVN, and it compiles! Great ! Now people wanting to fiddle with the code will be able to choose their IDE Originally Posted By: King InuYasha Now I have new errors: Character Editor: Syntax error in BLADPCED.RC Line 293 Scenario Editor: Error: cast from 'HWND__*' to 'short int' loses precision in DLOGTOOL.CPP Line 580 Yup, i (wrongly) assumed you were only interested in the game code and postponed the scenario/character editor code tweaking ... I'll do that soon Chokboyz

Originally Posted By: King InuYasha TDM-GCC 4.4.2-tdm2 in Code::Blocks IDE 8.02. Oh, then you're probably using a newer version of the binutils (i.e > 2.17). The windres.exe included in these is quite picky with the syntax in ressource files and quite incompatible with older coding shortcuts (oddly related to these kind of bug : http://old.nabble.com/-Bug-binutils-6714...td18215541.html ); all-in-all, it's just an omitted comma that crash windres. The next commit will be both old and new windres compatible (and i'll probably throw a code block project file too). Chokboyz Edit : ok, everything is now compiling, but i've hit another bug (put in better word by others, see : http://forums.codeblocks.org/index.php?topic=2334.0;prev_next=next ). The simpliest way to solve that is to fuse the three different .rc ressource files in one big file (something Dev-Cpp automatically does right before compiling, where CodeBlock compiles the three files separately, but link only the first compiled). Or we could write a script that mimic Dev-Cpp's behavior and fuse the three files at compiling time ... Forget that, using some #include did the trick (side effect, Dev-Cpp now warns about ressources duplication. No consequence, since it avoids them) ... I'll upload a CodeBlock/newer Binutils compilant version of the code soon.

Originally Posted By: King InuYasha Whenever I try to compile the Windows version, I get syntax errors for gamedlog.rc, so I know it doesn't compile. What kind of error ? What compiler are you using ? Do you use the last version of the code ? I've just tested it, and it compiled fine (gcc 3.4.2 in last Dev-C++) ... Chokboyz

Just for information, i've implemented Home, Page Up/Down and End for diagonal movement (the code is written, if the need arise to change those keys, changing the key constant check is the only thing needed now). A side effect is that the Keypad diagonal movement is working with either Numlock on or off. Chokboyz

Originally Posted By: King InuYasha since the Windows codebase doesn't actually compile... It does (see the google code project). Originally Posted By: Kung InuYasha The Mac version is also being maintained much more than the Windows one Both versions are actually being maintained ... The main differences are in the project advancement : the Mac code has more code refactored/new format implemented and the Windows code has more bugfixes and new features. The two codes should merge eventually. Chokboyz

Originally Posted By: Celtic Minstrel There are four or five such help dialogs in BoE, all found in the Help menu. True, but the previously mentioned dialogs were extra help (in a separated section under the More Help menu (the old Help menu) which some have been deleted in Exile III and BoE : Status Window Help, Magic Help, Talk Help, Item help, Combat Help (is not Combat Commands), Valuable Tips, Magic Barrier Help (this one has been kept and put under the Exile 3/BoE Help menu). The three dialogs Ishad Nha founds are, indeed, not used in BoE and remnants of those extra help section (in Windows version at least; i'm unable to check any Mac version ...). Chokboyz

It seems to me that the documentation has already been converted to the html (css) format (see the svn trunk/doc folder). I don't know if it has been updated in any way, though ... Chokboyz

Originally Posted By: Celtic Minstrel Are these remnants of an earlier Exile game that have duplicates for BoE? Just found those under More Help/Talk help, Item help and Combat help in ... Exile I (at last version 2.0 with redone graphics, didn't bother to look for my old shareware cd ) and Exile II. These sub-help dialogs disappeared with Exile III (at least in Windows version). Chokboyz

Originally Posted By: Ishad Nha The information in Gamedlog.rc is read in by the game, but then I think it overrides it somewhat with its own info. Oh right, the dialog creation procedure is quite a mess Originally Posted By: Celtic Minstrel Perhaps you could explain what they are? 1089 is EXILE HELP: TALKING AND SHOPS 1092 is EXILE HELP: COMBAT 1095 is EXILE HELP: VALUABLE INFO They are, currently, not accessed in the game. Originally Posted By: Ishad Nha Dialog 962 seems not to be used in actual practice. Originally Posted By: Celtic Minstrel What is this dialog? Good finding Ishad Nha, those are the remains of the old Adventure Journal from Exile 3 (the one that automatically keep notes of how far you are in fighting the plagues). Not used at all in BoE. Originally Posted By: Ishad Nha Not too sure what the label flag is It is a parameter passed to the cd_add_label() function that is used to specify the label properties (if > 1000 text is in bold and it sets the draw position). Hope it helps, Chokboyz