Mac/Win Balance [and Other] Differences

[icelizarrd]

As I've been trudging laboriously through the BoE code on both the Mac and Win32 end, I've noticed a few tiny differences that change the game's "balance" with respect to probabilities--i.e., the likelihood of some event succeeding, or the amount of damage it does.

 

I ask other coders, and the user-base at large, do you happen to know what the "correct" values here are? Or do you have an opinion about which ought to be the official version, if there's no "right way"?

 

These are mostly really tiny differences, but in the interest of a unified codebase, it'd be nice to have them settled.

 

--

FYI: as far as I can tell (without having looked TOO closely), a lower hit roll makes a PC more likely to hit its target, since the roll must be BELOW the PC's skill to succeed. (Confusingly, projectile weapons are the other way around: higher hit roll is better.)

--

 

1. Skill items and gauntlets of giant strength apparently detract from your ability to hit in the Mac code, while they enhance it on Windows. The right answer here seems pretty obvious. (That is, go with the Windows code). [pc_attack(), boe.combat.cpp]

 

2. Relatedly, both the hit bonus and the damage bonus for those two item types are calculated based on the item's "ability strength" on Windows, but on the "item level" on Mac. I don't know which is better here.

 

3. When a player attacks, armed or unarmed, the base roll for a successful hit is from 1 to 100 on the Mac, while it is 0 to 100 on Windows. (Keep in mind that lower roll = better. Unless I'm misunderstanding the code at the moment.)

 

4. This is also the case for the chance to assassinate: 1-100 base to-hit roll on Mac, 0-100 on Windows.

 

5. When picking locks, there is a base roll for whether the pick breaks and a separate base roll for the picking success, and again, both are 1-100 on Mac, 0-100 on Windows. For the break roll, higher is better, but lower is better for the pick roll. [pick_lock()--boe.town.cpp on OS X, classes/location.cpp on W32]

 

-- I would almost start to suspect that the random functions were different, but no, they're identical on each platform, and there are too many other places where the rolls ARE the same.

 

6. For the actual lock pick chances, the formula for failure is like this:

Mac: r1 > (unlock_adjust * 15 + 30)

Windows: r1 > (90 - unlock_adjust * 15)

... Where r1 is the modified roll, and unlock_adjust is a flag from the scenario's terrain type.

If I'm understanding this right, a higher unlock_adjust means it's easier to pick on the Mac (at 6, almost guaranteed to fail the above check unaided) but harder on Windows (practically no way to avoid passing the check at 6).

 

7. Same deal with bashing doors, only there's no pick-break check, and the numbers are a tiny bit different.

 

8. When selecting a monster to summon, the Windows code rolls from 1 to 255, while the Mac code rolls from 0 to 255. This is, you might notice, the opposite of the previous discrepancies, where this time the Windows code has 1 as a lower boundary instead of the Mac. This means we're either including or excluding monster number 0 from being considered for summoning. (Regardless of whether it actually qualifies as one of the summon types.) I think the 0 is preferable here, but I don't know if monster 0 has some kind of special significance that should keep it out. [get_summon_monster(), boe.monster.cpp)

 

 

 

Would appreciate some input! Otherwise I'll just, um, decide arbitrarily I guess. Would also appreciate corrections where I'm misunderstanding something or forgetting something else.

[Slawbug]

Most (but not all, I think) of these were discussed in a previous thread by Chokboyz and myself. I think it was one of the incredibly large OBoE threads, and I don't know which one or where. But a number of statements about which version was correct were made.

[Lilith]

On point 8, monster type 0 is always a placeholder "Empty" monster. Empties occasionally showed up in scenarios for reasons nobody ever really understood.

 

Also, it's been reported that if a monster is supposed to drop a specific item 100% of the time, there's a very small chance it will fail to do so. Could this also be an off-by-one error in the random number generation for the item-dropping code?

[icelizarrd]

Hmm, I do remember coming across the strength thing before, now that you mention it. On this page of the code discussion thread, Chokboyz reports fixing the hit-bonus of skill and Giant Strength items. I'm not having a lot of luck finding discussion about the other issues, though. I'll keep looking.

 

Lilith, thanks for the info about monster 0. Given that, I think it makes sense to not ever bother checking it as a possible summon type.

 

About the item dropping, hmm, the number being generated is 1 to 100, which should be fine. But you're right, actually: on the Mac code, the comparison is less than the item drop probability, while it's less than or equal to on Windows. So Mac users will still miss an item drop 1/100 times.

 

Furthermore, neither Mac or Windows code forces the item placement, even when it's set to 100. So you can still lose it from there being too many items already, or whatever else causes item placements to fail.

[Chokboyz]

Like CRISIS on INFINITE SLARTIES said, almost all those differences are fixes, done by me (with the community) in the successive Classic Blades of Exile patches.

Browsing the (two huge) threads in which we explained the reasons of such changes may be a daunting task, so i'll explain them here.

 

Originally Posted By: icelizarrd

Skill items and gauntlets of giant strength apparently detract from your ability to hit in the Mac code, while they enhance it on Windows. The right answer here seems pretty obvious. (That is, go with the Windows code). [pc_attack(), boe.combat.cpp]

You found it right on the Google Code page : the giant strength and Skill items were have a negative effect on hitting chances, so i've fixed that.

(http://code.google.com/p/openexile/issues/detail?id=16)

 

Originally Posted By: icelizarrd

2. Relatedly, both the hit bonus and the damage bonus for those two item types are calculated based on the item's "ability strength" on Windows, but on the "item level" on Mac. I don't know which is better here.

 

Also, it comes from discussion that ability strength should be used, not item level (it should retroactive, since i don't think anyone figure out the way it was originally calculed)

 

Originally Posted By: icelizarrd

4. This is also the case for the chance to assassinate: 1-100 base to-hit roll on Mac, 0-100 on Windows.

 

5. When picking locks, there is a base roll for whether the pick breaks and a separate base roll for the picking success, and again, both are 1-100 on Mac, 0-100 on Windows. For the break roll, higher is better, but lower is better for the pick roll. [pick_lock()--boe.town.cpp on OS X, classes/location.h on W32]

I'll have to see that, i may have overlooked it...

 

Originally Posted By: icelizarrd

-- I would almost start to suspect that the random functions were different, but no, they're identical on each platform, and there are too many other places where the rolls ARE the same.

Yup, because i had to change lots of random checks

 

Originally Posted By: icelizarrd

6. For the actual lock pick chances, the formula for failure is like this:

Mac: r1 > (unlock_adjust * 15 + 30)

Windows: r1 > (90 - unlock_adjust * 15)

... Where r1 is the modified roll, and unlock_adjust is a flag from the scenario's terrain type.

If I'm understanding this right, a higher unlock_adjust means it's easier to pick on the Mac (at 6, almost guaranteed to fail the above check unaided) but harder on Windows (practically no way to avoid passing the check at 6).

Difficulty implementation was wrong in the original game : difficulty 4 doors were easier to lockpick, difficulty 0 were harder (and i'm not going into how town_difficulty is not even set in the original game ).

That has, thus, been fixed in the Windows version (Mac version may be lacking some feature/fixes from the past year or so).

Please note that you can't successfully lockpick doors with difficulty > 4, you have to use magic.

 

Originally Posted By: icelizarrd

7. Same deal with bashing doors, only there's no pick-break check, and the numbers are a tiny bit different.

Same as above : fixed in Windows (the numbers are supposed to be different, by the way).

 

Originally Posted By: icelizarrd

8. When selecting a monster to summon, the Windows code rolls from 1 to 255, while the Mac code rolls from 0 to 255. This is, you might notice, the opposite of the previous discrepancies, where this time the Windows code has 1 as a lower boundary instead of the Mac. This means we're either including or excluding monster number 0 from being considered for summoning. (Regardless of whether it actually qualifies as one of the summon types.) I think the 0 is preferable here, but I don't know if monster 0 has some kind of special significance that should keep it out. [get_summon_monster(), boe.combat.cpp)

The 0 is avoided, because that would (or not depending on the place monster functions, i can't remember) allow to summon Empties.

 

Originally Posted By: icelizarrd

Empties occasionally showed up in scenarios for reasons nobody ever really understood.

It was a consequence of not cleaning the special encounter group flag on town monsters when leaving town. If a place "town special encounter" node was called subsequently in another town, empties would then appears.

 

Originally Posted By: icelizarrd

About the item dropping, hmm, the number being generated is 1 to 100, which should be fine.

That has indeed been fixed some time ago and should be working.

You're right though, no item are forced placed

 

Hope it helps,

Chokboyz

 

Edit :

Originally Posted By: icelizarrd

I'm not having a lot of luck finding discussion about the other issues, though. I'll keep looking.

In case you want them, here they are: http://www.spiderwebforums.com/forum/ubbthreads.php?ubb=showflat&Number=27627&page=1 (oldest, 34 pages; may not be up-to-date) and http://www.spiderwebforums.com/forum/ubbthreads.php?ubb=showflat&Number=179512&page=1 (newest, 7 pages).

If i remember well, the second thread began when the first one became unreadable

[icelizarrd]

Great! Thank you very much, that helps a lot.

 

Out of the ones I posted, that settles them all except for the 1-100 versus 0-100 random numbers with respect to to-hit checks and lock picking checks. If we follow the rest of the code for consistency, it looks like most of those types of rolls are supposed to be 1-100 rather than 0-100, I think?

[Niemand]

Assuming that those are inclusive ranges of integers (which I think is the case), 1-100 probably makes more sense, since it has 100 distinct possibilities rather than 101, allowing thresholds to be interpreted as percentages.

[Chokboyz]

You're welcome

 

Originally Posted By: icelizarrd

Out of the ones I posted, that settles them all except for the 1-100 versus 0-100 random numbers with respect to to-hit checks and lock picking checks. If we follow the rest of the code for consistency, it looks like most of those types of rolls are supposed to be 1-100 rather than 0-100, I think?

In fact, almost all types of rolls were 0-100 (in both Windows and Mac codes)

We've (Celtic Minstrel and I, if i remember well) changed that some times ago, exactly for the reason Niemand is invoking (and it fixed the summon chances problem, along the way).

 

Concerning the to-hit and assassinate checks , i've checked the code this afternoon and i think we should change it to 1-100 (in the Windows code that is, since it seems to have already been changed in the current Mac code). Indeed, the to-hit check is capped at 99, so i think the 100-base was supposed to be used.

Another reason is that <= are used for the hitting chances (< for assassinate, but chances are supposed to be lower than hitting anyway),i.e 99% max with no modifiers.

 

Concerning the lockpicking one, in order to have a 100-base random check, the first one should be 0-99 (the following check is < 75, so picks with no ability strength would break with 75% chances)

Idem with the second check, in order to have 90%/75%/60%/45%/30% chances to lockpicks a difficulty 0/1/2/3/4 door.

 

Hope it helps,

Chokboyz

[icelizarrd]

Ah okay, that makes sense, thanks again.

 

I suspect I'll return to this thread occasionally if/when new discrepancies come up.

[Celtic Minstrel]

Looks like your questions have been answered before I even noticed. Oh well. I'll say a few general things though. First, anything relating to the item ability should be taken from ability strength rather than item level. Second, unless there's a good reason to do otherwise (such as the issue having already been fixed), I'd be inclined to rate the Mac code slightly higher than the Windows code due to it being the original. That said, it is also less advanced in terms of bugfixes, so posting the questions here is still a good idea.

 

Originally Posted By: Chokboyz

(Mac version may be lacking some feature/fixes from the past year or so).

Mac version has a few new features (such as an in-built mechanism for background sounds) but very few of the bugfixes. And some of the new features (notably save and scenario file formats) are pretty buggy and I think will need some work to get right. I'd be happy to field questions on the intent of those, though many of them have their own (relatively short) threads somewhere on the forum.

[icelizarrd]

Originally Posted By: Celtic Minstrel

... I'd be inclined to rate the Mac code slightly higher than the Windows code due to it being the original.

That's assuming we CAN trust the original code, heh heh.


Good to know about ability strength, anyhow.

[icelizarrd]

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]

 

[Celtic Minstrel]

Your decisions sound fine to me, but I'm not entirely sure, especially about the treasure one...

[icelizarrd]

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]

[Slawbug]

On the last point: possibly, no. The original game used item fields somewhat inconsistantly. Look at where regenerating items actually have their strength listed in the item data.

 

This is one of those things to be VERY careful with, since existing scenarios may have used the "item level" field for regenerating item strength for custom items.

 

Really, if there's ANY chance somewhat designed AROUND the existing bug, you either need to craft a custom solution, or more likely, only change it when you branch it!

[icelizarrd]

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.

[Cryolemon]

The problem is that if we get too hung up on trying to preserve compatibility for every bug that might have been worked around or used by designers then we quickly get to the point of not fixing anything.

[Slawbug]

That really isn't true. OBoE has already fixed and tweaked numerous bugs that were essentially impossible for scenario designers to plan around, either because of their nature, or because they were impossible to discover without looking at the code.

 

The "lack of outcry" is because pretty much all the people who designed scenarios back in the day left the community before the BoE source code was released. The few who are still here no longer design for BoE, and there aren't many players around either. So the people participating in these conversations seem to consist of:

 

- 1 person who currently/recently designs scenarios using BoE, and therefore does not care about legacy considerations

- a handful of programmers who, as far as I am aware, were never involved with BoE before the source code was released

 

This is not a criticism in any way; I just want to point out WHY there is no "outcry." That's why I post in these topics: somebody needs to speak for the dead, here.

 

The fact is that the corpus of existing BoE scenarios designed using in the original, buggy version of BoE is HUGE AND MASSIVE AND EXTENSIVE, and it is really not foreseeable that OBoE will generate more than a tiny handful of scenarios to add to that massive pile. Therefore, if you are "fixing" problems that older scenarios may have already had their own workarounds for, you are completely missing the point.

[icelizarrd]

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.

[Chokboyz]

Actually, petrification protection is checked in the kill function of the adventurer class in the Windows code, so it's indeed checked (from changelog : - Fixed class pc_record_type::kill, so that it checks if the character has a protection from petrification item equipped before stoning him. (PC.cpp))

The petrifying chances are completely arbitrary; if i remember well 1/3 was the most accepted one, so it stayed that way. If playing a "new format" scenario, the touch is indeed petrifying.

 

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.

 

Concerning the other "odds" problems, there's been, as far as i know, no consensus on it, so good luck with that

 

Hope it helps,

Chokboyz

[Celtic Minstrel]

Originally Posted By: icelizarrd

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]

I'd agree the Mac code sounds like the correct one here.

Originally Posted By: icelizarrd

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]

Yeah, it should check petrification protection.

Originally Posted By: icelizarrd

This isn't platform-specific, but neither Mac nor Windows seems to allow monsters to petrify other monsters in melee. Has anyone noticed this?

I'm not sure what you mean, but if both codebases agree on this, I'd say leave it (at least for now).

Originally Posted By: icelizarrd

--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.)

I'm going to say that this is more or less correct. The way it should be done is that if the scenario make version (ie the version of BoE it was made with) indicates that it is "legacy", any monsters with Petrification Touch should have their ability changed to Disease Touch. This avoids cluttering up the actual abilities handling section with extraneous code to check if the scenario is legacy. I don't know if that's how Chokboyz did it.

Originally Posted By: icelizarrd

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]

I'm not really sure on this one, but unless Chokboyz specifically changed it in the Windows version I'd probably go with the Mac version.

Originally Posted By: icelizarrd

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]

For this, I say go with the Windows version. Casting Minor Manna only to get no food can't be fun.

Originally Posted By: icelizarrd

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]

Agreed.

Originally Posted By: icelizarrd

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]

Yes, we should use the item ability strength.

Originally Posted By: CRISIS on INFINITE SLARTIES

On the last point: possibly, no. The original game used item fields somewhat inconsistantly. Look at where regenerating items actually have their strength listed in the item data.

This is one of those things to be VERY careful with, since existing scenarios may have used the "item level" field for regenerating item strength for custom items.

Really, if there's ANY chance somewhat designed AROUND the existing bug, you either need to craft a custom solution, or more likely, only change it when you branch it!

Yeah, I agree with the general principle here, but I feel consistency is important here. For item abilities which formerly checked the item level instead of the ability strength, we should have some way of trying to detect that someone designed around it, and copy the item level into the ability strength field, preferably at loading time. With luck, we'll find that all such cases have an ability strength of 0, making it easy to detect. If not, I think I would advocate just assuming everyone designed around it, since that preserves behaviour even if it may not in some cases preserve the designer's intent.

When I was making custom items, I think I generally duplicated the ability strength in the item level field (except for items that used it for something else) because I was unsure of which was checked.

Originally Posted By: icelizarrd

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.)

I think I had an idea of converting Petrifying Touch only if the monster name matched one of the ones in the bladbase that mistakenly had it. I'm not sure if that's a good idea though. Probably better just to convert all Petrifying Touch to be on the safe side.

[Slawbug]

I think Celtic Minstrel's idea about being consistent is a smart one. I would suggest that you also make a list of all potential backwards-compatibility issues so it is easy for people to check that stuff in one place.

[Celtic Minstrel]

A list sounds like a good idea. If anything is forgotten, it could still be found by perusing the original code (which I'm pretty sure is still up on Jeff's website), but it's obviously better to have it in a centralized place.

[Chokboyz]

Originally Posted By: Celtic Minstrel

Originally Posted By: icelizarrd

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]

Yeah, it should check petrification protection

As mentioned above, it does.

Originally Posted By: Celtic Minstrel

I'm going to say that this is more or less correct. The way it should be done is that if the scenario make version (ie the version of BoE it was made with) indicates that it is "legacy", any monsters with Petrification Touch should have their ability changed to Disease Touch. This avoids cluttering up the actual abilities handling section with extraneous code to check if the scenario is legacy. I don't know if that's how Chokboyz did it.

This is exactly what happens.

Quote:

Originally Posted By: icelizarrd

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]

I'm not really sure on this one, but unless Chokboyz specifically changed it in the Windows version I'd probably go with the Mac version.

As far as i know, this function has never been altered since Jeff's release of the Windows code.

Chokboyz

[icelizarrd]

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.