suy

On 6/23/2022 at 5:07 PM, lalakobe said:

I remember back in the days in GW-BASIC you had to execute RANDOMIZE TIMER command before any randomizer stuff, or else you would be getting same "random" numbers again and again

Yes, the old school way to generate random numbers is to call a function named rand() that generates a random number between 0 and RAND_MAX (32726, often), but that number is calculated via a mathematical function starting with one input called "seed". That seed is initialized, hopefully from another semi-random source using another function called srand(). Current time is often (mis)used for this, and normally that is good enough to make it hard to predict with just a few numbers. If the engine is not setting the seed correctly, or soon enough, maybe it would explain why this pattern on the numbers happens so obviously. Or maybe even the seed is useless because it just changes the starting point.

Note that it is perfectly normal and expected that the numbers generated are creating patterns. It's well known that generate planes when the numbers are used to be points in 3D, and even if you use them in 2D, they can also produce visible patterns.

I am, however, quite surprised that it's so easy to see the patterns that you've showed. I tried to look at the character generation by putting the executable in Ghidra (reverse engineering tool) some time ago, and it's too difficult for me. But if you want to give it a shot (you seem quite motivated and that's cool!), get the debug symbols, then search for CScreenCreateChar::OnAbilityReRollButtonClick.

Great. I'll keep this in mind if I ever give a shot to modifying the code to work in BG1EE. Thank you for the mod and the reply!

3 hours ago, suy said:

Thank you again for making this! My first hint of feedback: note that the code samples have the problem of "smart quotes" (“”), so they can't be pasted into the text editor verbatim, and work. Easy search and replace for me, but probably a problem for newbies.

A bit of an addenda on this: it also affects things like "COPY_EXISTING –". It's an EN DASH (U+2013) instead of HYPHEN-MINUS (U+002D). That is harder to notice visually.

Thank you again for making this! My first hint of feedback: note that the code samples have the problem of "smart quotes" (“”), so they can't be pasted into the text editor verbatim, and work. Easy search and replace for me, but probably a problem for newbies.

Hi @polytope. While I understand that this mod is not that important in BG1, I wanted to try it regardless there, and when I was going to install it, I got a message saying that ToB is required. The check seems to be:

BEGIN @10 DESIGNATED 10

REQUIRE_PREDICATE FILE_EXISTS_IN_GAME ~mel01.cre~ @13

So, how comes that such thing is needed? Isn't BG1EE technically enough? Thank you.

On 5/26/2022 at 3:20 AM, CamDawg said:

Three more posts.

Zero ducks.

See the conversation that I quoted above ("I remove the thief flag, yes, but keep it unusable by thieves by adding the 319 effect").

FYI, this also affects some other special weapons. The Staff of the Magi is the other well known weapon which can't be used to backstab by T/M, for example, because a single class Thief can't use it.

Now that you mention, though, I've remembered this conversation with @CamDawg on Discord a good while ago, which hopefully you don't mind me quote:

[ 5:39 PM ] suy : A pity the backstabbing weapon is so hardcoded. Backstabbing
with an Axe would be fun.
[ 5:50 PM ] CamDawg :

COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~ ~override~
  READ_LONG 0x1e usability
  PATCH_IF ((usability & BIT22) = BIT22) BEGIN // if unusable by thieves
    WRITE_LONG 0x1e (THIS BAND `BIT22) // remove thief flag
    LPF ADD_ITEM_EQEFFECT INT_VAR opcode = 319 target = 1 parameter1 = 4 parameter2 = 5 timing = 2 special = 818 END // add back as 319
  END
  BUT_ONLY  

 
[ 5:50 PM ] CamDawg : EE-only though
[ 6:09 PM ] suy : But that's changing the usability flag for regular use as
well, right? I meant to keep an axe/bastard sword/etc still away for a thief,
but allow a f/t to backstab with a weapon usable for them. I looked at the
decompiled code, and it seemed hardcoded to me. But of course, noob on the
topic, so with a grain of salt.
[ 6:12 PM ] CamDawg : I remove the thief flag, yes, but keep it unusable by
thieves by adding the 319 effect.
[ 6:12 PM ] CamDawg : So it makes all weapons available for backstab without
changing their actual usability.
[ 6:13 PM ] suy : 
[ 6:13 PM ] suy : Why is this not in Tweaks Anthology then? 
[ 6:13 PM ] CamDawg : Because I just wrote it now.
[ 6:13 PM ] CamDawg : But it'll be in the next Tweaks, sure.

I forgot to ask CamDawg about this, so I'll do now: what do you think, should be on Tweaks still, or can be better on the EEFP?

I think the table in P&P, if you expand it from the succinct form to the usual way, makes sense and follows the usual "pyramid progression" (you get more at the low levels than at the highers) that all other tables of this kind have. The table on the manuals and the table on the game match, because very likely one was built from the other, and whoever built it did a mistake when transcribing it. As I mentioned on the other comment, I think someone misread the row on the P&P manual, and started carrying the mistake to the following rows of the game table. I think the fact that all the tables of the game have a certain pattern except this (which doesn't seem to follow any other pattern, AFAIK), is some argument towards what could have been the developer intent.

Same for me. I mentioned the PHB in the first post, and there is no cap that I found. Quite the opposite, it lists till level 20, but it says how to calculate beyond 20. I'm using the revised premium edition in PDF form. I can check the old manuals in paper, but only translated to Spanish.

Here is a simple example of why I think that an optional component is better than a separate mod for users:

The item deduplication is likely to cause some issue with (at least) the Item Randomizer. At the very least, I think it will cause the degradation that the items which are swapped won't be randomized. Some users might not like that, and would prefer the randomization over the fix (at least meanwhile the Randomizer adapts some strategy to detect the EEFP and patch its static table, which can be a moving target anyway, if changes are applied to the EEFP in other releases).

1. If the deduplication is a fixed component, users which don't know how to modify weidu code will have to ask for help, and patched versions of the TP2 will fly on private messages or forum posts. More tech savvy users will have to patch it themselves on each release. Even more tech savvy will have a private clone of the repo with a commit that will rebase after each release.
2. If the deduplication is an optional component, users can say "no" at install time.
3. If the deduplication is a separate mod, it will be confusing to some (less visibility), some extra burden in downloading yet another mod, and... which will be even the name of such mod? EEFP_but_less_compatible? That's gonna scare a bit some users as well.

I think for users option 2 is clearly better.

Now, I'm not denying that option 2 has also some burden on you, if you need to ask about the EEFP being installed, you'll need to ask which components. There are other developer concerns also with option 2, in that is harder to maintain the mod, or compatibility with such mod for other modders. Other options will have also their own problems for mod developers.

OK, so I'm not sure if I got what you mean, but if I did, it would make some sense:

• Warriors progress from 20 to 0, so they improve 20.
• Rogues do so at half the pace, so they improve by 10, and cap at 10 (20-10=10).
• Priests do so at 2/3 and Wizards at 1/3, with the one third being ceiling(20/3.0)=7, hence they end at 6 and 13 respectively (20-14 and 20-7).

The key here is: why should it be rounded up? Or just rounded to the nearest integer, which yields the same value.

It doesn't feel wrong, but it doesn't feel entirely right either. Normally when explaining the rules the phrase "caps at level X" is used often, so I was looking for an explanation based on level.

2 hours ago, Jarno Mikkola said:

and it's granted to them by their god, so them having arcane schools

Schools are not arcane. All divine spells have schools on the PHB and in game.

After reading and thinking about the conversation, I suppose that indeed changing the descriptions is not only easiest, but also probably the most reasonable way to go, as maybe it's the only way...

I've done some searches on the Planescape campaign setting, and I don't really find anything specific about what happens with a planar being on the Prime Material Plane. Magic is supposedly affected on the planes, but not on the Prime. So I don't see why the curing spells should not affect someone like Haer'Dalis. The description from the PHB certainly says so, but I don't know the reasoning. An elemental or Aerial Servant not being affected by healing spells, I would understand. Their "body" is not normal.

Haer'Dalis, though, since he's a Doomsguard, should be affected by this:

Quote

RESTRICTIONS. The Doomguard are naturally resistant to healing and cures. For any such spell or magical device to have effect, a Doomguard cutter must first fail a saving
throw vs. spell. If the save is successful, the magic is negated.

I suppose no-one cares this much to have this implemented.

BTW, there is a much complex can of worms to open if one wants to implement rules that affect creatures and items from the prime in the planes. Items, for example, should lose power when one travels to other planes. We don't even know where the Planar Prison is exactly located (Carceri?), but all the weapons that the primes bring there should be adjusted by some levels and be less effective. I think all the planes that are visitable by the players are Inner or Outer planes, and that's 2 levels less!

11 hours ago, subtledoctor said:

People seem to have dismissed option #1 right off the bat.

I don't think so. Option #1 is removing items which are duplicated, which is what BG2 Unique Artifacts does, and a couple of us have mentioned it. I guess we've not talked much about this because the other mod already does it.

It feels a bug to me, as the lore of the description of the items is a bit inconsistent if there are several with the same name in some cases. As you said, the fact that there are generic versions of those items is quite telling.

Also, I would prefer that there is a way to not install the component, as I fear it could be an issue with some mod (Item Randomiser is one of my fixed ones, and I don't see how this could be made compatible nicely). But the fact that the bg2-uniqueartifacts exists also shows that there is demand for something that fixes the wrinkle of items being duplicated.

I've been working on a tool that (among other things) happens to chart THAC0 progression vs XP. For simplicity reasons, I've been calculating the THAC0 progression manually instead of reading it through THAC0.2da, and I've noticed something that seems a bit inconsistent. I can't tell from P&P manuals if it's a bug or not (they don't mention *any* THAC0 cap in the PHB, they just put a pre-calculated table that stops at 20, but it also mentions using the progression above level 20), so I'm bringing it for discussion.

• Warriors (and Monks) stop improving at level 21, which makes sense given that they "cap" the base THAC0 at 0. Seems OK to me.
• Rogues (Thief/Bard) stop improving at level 21 as well, when they reach 10. Given that they progress at half the Warrior pace, makes some sense to me.
• All the rest (Mages, Sorcerers, Druids, Clerics...) seem to get the last improvement at level 22. That's a bit of a head scratcher for me. I don't know why that value. But capping at 22 it's the more common behavior, aside from the special case for Warriors.

Myself on the first try of the application that I've mentioned, started capping at either 0 THAC0 or level 22, but then realized that Thieves got one point of improvement over what happens on game.

I have no idea how I would proceed on this. But maybe I would just change the Rogues to be consistent with the other classes.

Excuse my most likely mistake, but can I ask how this is supposed to work in the current implementation? I've been looking at the code to try to better understand what the replacement does (for example, of the Amulet of Protection +1), and I could not find the item that is supposed to be replaced with. In vanilla BG1EE and BG2EE I can't find bdamul24.itm. I find the amul14.itm to be what I was expecting, but I can't find the one is replaced with. Unless...

COPY_EXISTING "bdamul24.itm" "override/amul14.itm"

Unless this happens to be in the wrong order? If amul14.itm is the right item, and gets copied to bdamul24.itm in override, then the description gets fixed later to be a generic +1 protective item without a unique name.

But either I'm not understanding the WeiDU code, or something else (most likely my fault).

This has been mentioned in this older thread:

Someone mentioned a scroll of Death Spell working against a Hakeashar, but the Skull of Death failing. I looked into them and found that the former uses 148 (cast spell at point) while the latter uses 146 (cast spell at creature).

CamDawg mentioned that the BG2FP went through many scrolls to correct this, but other items like this might be missing.

Ah, that's an interesting detail. Note that the Unique Artifacts mod goes way beyond this, and removes many duplicates that from the description, one might understand that are unique. But it doesn't include this weapon.

On 3/25/2022 at 11:28 PM, Angel said:

Which looks much more consistent to me.  However, the BG1 and BG2 manuals reflect the table as it is in game.  Developer intend, or an invasive bug?  I really can't think of a reason why the devs would want the faulty table.

Good point Angel. I always knew this table was suspicious, but I never bothered checking with the PnP manuals. The way the table it's specified there is a bit weird, and it's the only table I know of that it's not specified in full detail (like in the 2DA or the BG/IWD manuals), but instead it's just one column saying how much to change from one level to the next. So you need to build the table yourself, carrying from the previous result. I think it's obvious that someone was confused when understanding that description of the bonus spells per score level, or that just read a wrong row by accident. There seems that the mistake is only when reading scores 19, 23 and 24. Since the result carries to the next row, the table gets more and more borked at the end.

PS: I'm not sure if this is EE specific content. Are we in the right thread?

I also have the old edition in paper, but in Spanish, so that's let's useful to share here of course. There it says roughly the same, and instead of "negate" it says "anular", which I would translate as "nullify" or "cancel". I think it makes sense, as it says that the idea is that the target is not aware of the attack, so it can't attempt to dodge it (or, in the case of awful dexterity, accidentally get hit with more ease). So it should just have a 0 bonus/penalty IMHO.

Both Chaotic Commands and Free Action seem a mess that I would not dare to open in "bugfix mode", unless one wants to just rethink the spells at least little bit. Free Action, for example, is always questioned that it blocks Haste or any other beneficial effect. I remember having searched quite a bit (within my limited resources) and could not find where is justified in the books that it blocks something beneficial. The description in P&P said:

Quote

(...) move and attack normally for the duration of the spell, even under the influence of magic that impedes movement (such as web or slow spells) or while under water. It even negates or prevents the effects of paralysis and hold spells.

Additionally, one weird inconsistency of Free Action is that it cures stun, while it doesn't prevent it... And according to a comment I've just read, it doesn't cancel Haste/IH, but it blocks it from being applied. I think that was the case with the Flail of Ages as well.

About Chaotic Commands... I don't know. It is true that what it does, according to its description, it's not very consistent. The issue is, that given that most spells have a verbal component, it is hard to understand why some spells "place a direct verbal command upon a single individual" and others do not. The list on P&P description seems to be open to spells that have this verbal command, but again, how a new spell from an expansion can be known if it fits or not?

This is a quote from the PHB, revised edition (AD&D 2nd edition, of course). It's obviously a bug, IMHO.