icelizarrd

I still check here, albeit extremely rarely. I haven't done anything for about a year, though. If anyone wants, I could commit the hacked-together, incomplete Mac-Windows merge I was working on to a separate branch on the SVN, or something. The code's still pretty danged ugly, but it does compile and run on Windows--though loading and displaying scenarios isn't quite working properly. (Going outdoors doesn't really work at all, right now, and some of the text strings are messed up, for example.) I still haven't tested it on Mac yet--will doubtlessly need some adjustment to even compile.

Originally Posted By: Celtic Minstrel By the way, icelizarrd, how's your merging of the code-bases progressing? Or did it stall? It did kind of stall, regrettably. >_> Currently, though, I have the (I think) fully merged code running on Windows. You can make a new party and start it on a scenario, but loading and saving games doesn't work yet. And the outdoors terrain is completely screwed up: when you leave a town, you end up surrounded by cave walls no matter what the terrain is supposed to be. I'm thinking there's some silly offset or indexing problem there, since I had something similar happen with indoors terrain at first. (Or it has to do with loading the scenario improperly. Or I forgot to delete all the references to the older "terrain" arrays; that might explain why it loads cave walls.) I've just been too lazy to track it down. There are also some string issues: messages will display incorrect or empty strings, and some in-game character dialog is messed up. A few item/dialog icons don't display correctly. (Index issues again, I'm sure.) But, other than these bugs, most things seem to be working normally.

Having a means of recording that kind of the 6-paragraph dialog box is an excellent idea, in my opinion, and that's yet another of those little things that used to bug me about the previous Exile games. I don't know that I'll be able to do anything about it for a while, though.

Well that's super annoying, the site I used to host it (Stashbox) is apparently shutting down, as of pretty recently. Rotten timing. I could upload it again, but I can't imagine my version would be any better than Niemand's. For the record, I chopped off the excess tiles on the bottom of the image too, and it seemed to work just fine when I played through the beta test of Crusaders.

Originally Posted By: Niemand It's PICT format data, stored as a PICT resource. Huh. Well, weirdly, the .MEG file I got seemed to have a TIFF in it, somehow. I could open the resulting file in programs that can't handle PICTs, so go figure. But yes, looking at other .MEGs, they don't seem to be TIFFed. Thanks for the format link, anyhow. I may try to figure out a simple tool for Windows to mimic Graphic Adjuster's conversion ability, depending on how much work that ends up being. Originally Posted By: Ahbleza I've 'chopped' a lot of firewood in my time, but I wouldn't have any idea what type axe to use on a 'resource header'. ;^} Hahaha, I used a hex editor. Very crude, as I said.

Hrm, yea, the .exs is supposed to be platform-independent. Regarding .meg files, if I recall correctly, they're basically in TIFF format, but stuck inside the Mac resource fork as a "PICT" or something. (Corrections welcome.) When I was testing Crusaders, I crudely extracted the graphics by chopping out the resource header portion of the file, then opening it in a graphics editor, and that seemed to work. It had a bunch of extra garbage data on the end that needed to be cropped in the editor, however, and I don't really know enough about how the formats work to automate the process. ETA: Now that I try this again, I remember there are also some slight issues with transparency that have to be sorted out by hand.

Oh good! You're welcome, glad I could help. ETA: Oh, I'm a dork, I guess I can upload to the project page after all. It's now downloadable here, for future reference.

Yeah, I think passwords are silly too. But this doesn't change the updated Scenario Editor's file-loading abilities, it'll still open them while ignoring passwords. Now it just saves with a slightly different, more backward-compatible scenario format. I don't have admin privileges on the Google Code site, so I can't upload it there, but give this a try. (That's a direct link; alternatively, here's an indirect link if you prefer that for some reason: http://kiwi6.com/file/15h46y1878) (Alternatively download at the Google Code project page here: http://openexile.googlecode.com/files/BoE%20Scenario%20Editor%20PWF.exe) It's a very very simple change, but I do recommend making a backup copy or two of your scenario first, of course, just in case something horribly unforseen happens. Note that the scenario format is expected to change radically in the future, so eventually, using older editors probably won't be possible at all.

You're talking about the Windows editor, right? (If I recall correctly, the new Mac editor isn't functional at the moment.) It shouldn't be adding a password at all. But maybe that's the problem. I'll look at this in more detail when I get a chance, but it looks like the current Windows editor doesn't write anything for a password into the file (or rather, it writes whatever the uninitialized variable data will be--probably either a series of 0s or just random garbage values?). The Super Editor, I'm guessing, is expecting some data there that was encrypted using a password of "0", instead of whatever junk values are there now. Should be pretty easy to add that kind of functionality back into the code.

Alright! So, I had lost interest in the OBoE project for a little while there, but just tonight I finally got a unified ("cross platform") game codebase to run on Windows. It doesn't work yet—you can't load scenarios or saved games or play anything—but at least it's running without crashing, and the system-related UI (menus, preferences, dialog boxes) is working correctly. The code's messy as hell (yes, even messier now than before), and it'll take a while to even get the game near-functional; it's definitely not ready for anyone to experiment playing with the executable yet. But at least now I can actually do some real work on it instead of endless copy-pasting and RegExing. It won't compile on Mac yet: there were a number of places that I just left comments like "Todo: add Mac equivalent", and a few places where I changed things that the Mac code relied on. But fixing that should be comparatively easy, I hope, since I was adopting the Mac version's data structure approach to replace that of the Windows version. (I.e. there were more deep changes to the Windows code than to the Mac.) Anyway, in the meantime, I'll try to get the Windows copy functional-ish, and I'll start tinkering on a Mac once I've gotten somewhere with that.

I think you just use SVN to make a new directory, then check out the empty branch onto your own computer. That's what this link suggests, anyhow.

Once again, thanks for the input, everyone. Well, I checked back against the older copies of the code that Jeff has posted on the site, since I probably should have started comparing against them a long time ago. Not that it really matters, but it seems the Windows code did used to have the extra (loot == 4) check in return_treasure(). Probably just got lost during some other edit at some point, I know how that can happen. >_> I also looked up the extra +1 for Minor Manna, for fun. This doesn't matter either, but it was in the original Windows and missing in the original Mac code, the way it is now. Originally Posted By: Chokboyz The petrifying touch is indeed fixed, but with a twist : if the scenario played is legacy (that is almost all scenario out there), every monster template with petrifying touch is changed to disease touch. That way, the "vorpal cockroach" symdrom is avoided. Ahhh, I see. I was testing it using "legacy compatible" scenarios, of course, silly me. (I hadn't realized that was the default option in the Scenario Editor, or, actually, that the option was even there.) Good good.

I don't disagree that maintaining backwards compatibility is important. I've just been less convinced about the importance of the issues discussed in the last few threads, I suppose. But, you're right, I was never a part of the BoE community, and my experience playing it back in the day was comparatively limited. So I'm certainly willing to listen to contrary opinions; that's why I post asking for comments in the first place. At any rate, it is easier for me to not bother with any new fixes or features right now, since compatibil-izing the Mac and Windows code is its own special (lengthy) difficulty. So I'll put all of that aside until I (fingers crossed) have a working/mostly-working product.

I have many ideas about how to improve the scenario editor interface; but they will have to wait for quite some time, I'm afraid.

Hmm, fair enough; wasn't that a possible concern with Ogre/Giant Gauntlets too, though? And Petrifying Touch being Disease Touch? (The latter being possibly problematic was discussed before, indeed, but there doesn't seem to have been an outcry against that. If I recall, the decision was to import legacy scenarios as though "Disease Touch" was really "Petrifying Touch". Hmm, though now I also remember talk about doing that conversion for those monsters which had had "Disease Touch" in the older Bladebase, or something. That's still vulnerable to the possibility of someone having used it in their scenario for other custom monsters, however.) Anyway, I will leave it as-is for now.

Okay, thanks. :3 I've also found some more of the 0-100/1-100 problem since then, but now, I'm just using 1-100 unless it looks particularly out of place. Other discrepancies: Monster's petrifying touch, on Windows, basically gives you a flat 1/3 chance of being stoned. It doesn't matter whether you have petrification protection or not. But the Mac code prevents stoning if you have petrification protection, and it takes into account both PC level and PC bless/curse status. I'm pretty sure it should be the Mac code, since that's the same check used for Petrification Ray on both platforms. (It's actually kinda weird that these are different, because I found an earlier post specifically saying that the Windows Petrification Touch now uses the Petrification Ray code; but I guess this got changed back accidentally at some point.) [monster_attack_pc(), boe.combat] Petrification ray, as mentioned above, does have the same 'odds' on both versions. But it ignores petrification protection on Windows. Seems like that shouldn't be. [monst_fire_missile(), boe.combat] This isn't platform-specific, but neither Mac nor Windows seems to allow monsters to petrify other monsters in melee. Has anyone noticed this? --Actually, it looks to me like the Windows project, at least, didn't finish up the Petrification Touch = Disease Touch problem: Disease Touch causes disease correctly, but now Petrification Touch causes disease too. This may be a problem with the scenario editor or with the scenario loading code, however. (The same post I mentioned above also said that Disease/Petrify should have been fixed.) The Mac code has an extra check during treasure selection for monster loot. I don't have a full grasp of how the process works, but in return_treasure(), when the monster's loot variable is 4, the random treasure category gets pushed up a bit extra. So you're generally more likely to get rings, necklaces, and poison; less likely to get food or weapons. [boe.items] When you cast Minor Manna, the "amount of food to add" uses a base roll (also used in regular Manna), then divides by 3. On Windows, it adds an extra +1 to that. That guarantees you won't get 0 food from Minor Manna, like you would if the roll was 1 or 2 (integer division always rounds down. IIRC). [do_priest_spell(), boe.party] Mindduel, on Windows, gives the victim a flat bonus (+20) if s/he has a "Will Protection" item on him/her. The Mac code gives us 5 * the Will item's ability strength. This one should follow the Mac code, I think. [do_mindduel(), boe.party] Lastly, another confirmation for both: both version currently use "item level" for the strength of regenerating items, whereas CM says above that we should use ability strength in general. That's true with this one too, right? [combat_run_monst(), boe.combat]

Some of the files are quite lengthy, but I'm still surprised you'd say that there's "not very many". The current version of the Windows code has some 55ish files, between the headers and regular source files. The Mac version has more than that, because it divides the classes up into separate files. Are you looking at an older copy? Or do I just have lower standards than you about what makes something "not very many"?

Alright, I have another crate load of Mac/Windows discrepancies for you all to look at. Most are very similar to what we've seen before. To try to keep these posts from being so megalithic, monolithic, and monotonous, I'll only post a few at a time now; after they're settled, I'll post again with the others. 1. More of our old friend, the 0-100 versus 1-100 random number roll. Each with 0 minimum on Windows but 1 minimum on Mac. So far, for these, I've gone with the Mac's (1,100) every time, but let me know if you disagree. They appear as: Chances of a demon resisting Ravage Spirit. [do_combat_cast(), boe.combat] Chances of PC hitting a monster with a missile weapon. [fire_missile(), boe.combat] Monster's base "to hit" roll on a PC, both melee and ranged; and on other monsters, both melee and ranged. The melee attacks are basically the same as the PC rolls that we changed earlier, so I'm pretty sure they should be 1-100, not 0-100. [monster_attack_pc(), monster_attack_monster(),monst_fire_missile(), boe.combat] Chances of Sanctuary making a monster miss, with melee and with missiles. [monster_attack_pc(), monst_fire_missille(), boe.combat] Odds of slightly weakening (-2) any disease being added to a PC. [disease_pc() on Mac and player_record_type::disease() on Windows, in boe.party and classes/pc, respectively] When generating treasure from a monster, there's a roll that checks against a table of item type's probabilities for placement. Later, in the same function, the 0 vs 1 thing comes up again for whether the item is identified or not. These two I'm least sure about. [place_treasure(), boe.items] 2. Monster field radiation probability is checked with a "less than" sign on Mac, whereas it uses a "less than or equal to" sign on Windows. I think it should be "less than or equal to", since otherwise there's a 1/100 chance of a monster failing to radiate fields even when it's set to 100%. [do_monster_turn(), boe.combat]

Originally Posted By: The Mystic Actually, a small planet isn't too bad of an idea. Maybe you could wrap it as a cube... Ooh, or like a hypercube, in The Hut of Baba Yaga. My brain hurts trying to think about that, though. Quote: ... or make a "ribbon" world like in Brett Bixler's "Destiny of the Spheres." And now that makes me wonder about a Mobius strip world. Let's see, you'd basically just keep going one direction until you wrap around to where you started only now everything's been flipped left to right. You'd have to take some liberties with that to make it interesting though, probably, instead of making it a perfectly symmetric flip.

Did any scenario designers create conversations that made use of the fact that you can't see right away what's clickable? Something like little bonuses or extra details for being observant with the conversation. You can already spam clicks until you find a word that works, of course, and/or "brute force" by typing in each word you see. But it might "take the fun out of it", if the game highlight keywords; so I'm just wondering if that's a concern to anyone? Plus side: it would make it more obvious to scenario designers during play-testing if their NPCs accidentally used keywords earlier than they were supposed to.

I am highly in favor of a way to pause combat. That's another one of those things that's bugged me about the Exile games for quite a long while.

Ah, I stand corrected. I shouldn't have generalized just from looking at PC attacks. Alright then, I'm fine with it staying.

We could do the legacy compatibility options thing, give people a choice. But, aside from the fact that it feels kind of messy to to leave the code as is, I don't really care either way, honestly. (Theoretically, too much blessing should wrap around to being cursed, though you'd have to get up to 32767 for that to happen, so I doubt anyone's ever likely to encounter that behavior.) Just to confirm--looking at the code again, as far as combat calculations go, bless/curse does indeed have a maximum of 8 and a minimum of -8. So the proposed alteration wouldn't affect the power of blessing or cursing--just the length that it lasts. I believe.

Hmm, from a cursory glance through the Windows code, yeah they do. It's mentioned that there's no cap in the comments, but apparently nothing was done about it yet. I think I remember hearing that blesses do have a maximum "effect" in that any bless value 8 and over gets treated the same. So you can bless yourself up to, say, 100, but the game won't give you any increasing benefits past 8. It's just, it'll take an unnaturally long time for the bless to lose power. I agree that it should be a bug. Should be pretty easy to fix, luckily.

Originally Posted By: Celtic Minstrel The push-related code applies to barriers, not items; specifically the barrel and crate "barriers". Well, that's why I mentioned switching the code to apply to items. Though I did say "terrain" where I should have said "barrier"--I guess I was mentally lumping them together at the time. There may not be many advantages to making crates and barrels into items, and it would be a decent chunk of work; so, upon reconsidering, I say nix the idea. I suggested container items for the future, but, of course, there's no reason we couldn't have container items in addition to barrels and crates as "barriers". Especially since barrels/crates cannot ever be picked up, and items that could not be picked up wouldn't be doing anything useful as "items". I have to agree that making them a terrain type doesn't seem worthwhile either.