Jump to content

Unearthed Arcana present Tome & Blood: more options for arcane casters


Recommended Posts

EET changes find familiar spell to trigger K#FAMSUM.BCS, which does the same thing as original opcode 192 but allows to easily set which CRE file will be spawned (different in BG1, BG2 and ToB). Also vanilla familiars trigger K#FAMKIL.BCS on death (via cast spell on condition opcode) in order to implement the same penalties as opcode 192. This way the system is completely unhardcoded and does what we need using vanilla CRE files with no other changes necessary.

Quote

Hmp.  There's got to be better ways to do that...

I'm all ears.

Edited by K4thos
Link to comment
45 minutes ago, K4thos said:

EET changes find familiar spell to trigger K#FAMSUM.BCS, which does the same thing as original opcode 192 but allows to easily set which CRE file will be spawned (different in BG1, BG2 and ToB). Also vanilla familiars trigger K#FAMKIL.BCS on death (via cast spell on condition opcode) in order to implement the same penalties as opcode 192. This way the system is completely unhardcoded and does what we need using vanilla CRE files with no other changes necessary.

Sorry, I cross-posted my response in the other thread.  I guess this makes for a pretty hard incompatibility between EET and mods that affect familiars?  At a brief look only at your post,

  • EET disables familiar being summoned if the caster's alignment changes (what about the Helm in BG1, or the Hell Trials?  Not to mention this mod?)
  • A mod that allows players other than Charname to summon familiars will be broken in EET (from my error at least EET seems to enforce the 'protagonist-only' rule)
  • A mod that changes the HP bonus granted by a familiar, and removed on its death, will be broken in EET (since it seems EET applies the penalty, and maybe bonus, automatically)

If we have to code familiar mods in a certain way to be compliant with EET's new system, do you think you could publish a guide or something, on how to do that?  Or, I guess, how to circumvent the EET changes entirely and allow the mod to control familiar stats, and effects on their summoner?

Sorry if I sound grumbly, but I didn't expect I would have to substantially change my mod - indeed, get into scripting stuff that I don't know much about and which were not necessary for the mod itself - in order to work with another mod that has the seemingly unrelated goal of adding more campaigns to the BG2EE game.

53 minutes ago, K4thos said:

I'm all ears.

If the question is the stats of familiars at different stages of the game - 12hp in BG1, 24 hp in BG2, 48 hp in TOB, etc. - then could that not be achieved with different level-based ability headers in the FF spell itself?  Or have the familiar perform a polymorph upon being summoned, into a form appropriate to the caster's level?

I don't know - my mod hads a pretty limited scope, and works with the way familiars already work in the engine.  I don't really know how that affects EET or how EET in turn needs to affect that.

Link to comment
On 2/7/2020 at 11:04 AM, K4thos said:

I'm all ears.

 Hmm, I don't know if this would solve everything, but at a glance, maybe this could be changed:

On 1/27/2020 at 2:42 PM, Bubb said:

EET uses this block in K#FAMSUM.BCS to detect if the summoner was the protagonist:


IF
    TriggerOverride(Player1,Summoned(Myself))
THEN
    RESPONSE #100
        SetGlobal("K#FAMPRO","GLOBAL",0)
END

Looks like you are changing the alignment of the protagonist for a split second before you invoke the summon. The problem lies in Summoned(), and how the engine processes "reactionary" triggers.  The engine saves a snapshot of the summoner's object selector values (plus a few other things) when it summons the familiar, and since you change the character's alignment right before the summon, it saves the altered value. The Summoned trigger runs late enough that the protagonist's alignment has already reverted. It's basically asking the trigger, "Does Player1 match the snapshot I saved earlier?" - and that fails, since the alignment is different.

Rather than checking "(Player1,Summoned(Myself))" maybe the FF spell could use opcode 309 to set a local variable upon the caster.  Then replace that trigger with a "GlobalGT()" trigger looking for the LV.  Then you avoid the finicky behavior of Summoned().  (That might possibly let casters other than Charname summon familiars - not sure.  If so, I say great!  But if you want to avoid that, then you could maybe apply the spellstate to Player1 by script upon starting the game, or something.)

Edited by subtledoctor
Link to comment

By the way I recently noticed a pretty serious bug where, if you put your familiar into the backpack and then try to take it out again, it might disappear entirely.  That, of course, is a Bad Thing.  So if you play with the familiar components of this mod... don't put the familiar into your inventory!  (Or if you do, don't take them out again.  (But then what's the point of the familiar?))

Link to comment
Quote

If we have to code familiar mods in a certain way to be compliant with EET's new system, do you think you could publish a guide or something, on how to do that?  Or, I guess, how to circumvent the EET changes entirely and allow the mod to control familiar stats, and effects on their summoner?

not sure if you've read it: 

Quote

If the question is the stats of familiars at different stages of the game - 12hp in BG1, 24 hp in BG2, 48 hp in TOB, etc. - then could that not be achieved with different level-based ability headers in the FF spell itself?  Or have the familiar perform a polymorph upon being summoned, into a form appropriate to the caster's level?

it's a very old change and I no longer remember exact reasoning behind choosing this implementation over another. Any change to this would require lots of testing, so don't expect it any time soon. Not sure if it's even worth it considering:

- component 66 probably already works if it uses vanilla Find Familiar spl files,

- component 67 should already work (from what I understand from description) if you use vanilla CRE names (just extend this patching to familiar CRE files imported from BG1 - in EET they have _ suffix)

- component 68 could be implemented by patching just K#FAMSUM.BCS (which is pretty self explanatory how to do it if you open the file and look what's in there)

- component 69 is very similar to EET Tweaks component "Familiar death consequences"

 

 

Edited by K4thos
Link to comment
1 hour ago, K4thos said:

- component 67 should already work (from what I understand from description) if you use vanilla CRE names (just extend this patching to familiar CRE files imported from BG1 - in EET they have _ suffix)

Unfortunately no - EET breaks component 67, that is the whole reason we are talking about this.  The base game is hard-coded to give one of 8 familiars for each of 8 alignments; the mod simply does a zero-second alignment change to trick the engine into giving you the familiar of your choice.  EET chokes on that, with an error message about "only the protagonist can summon a familiar."  I thought, like you, that there is no reason this shouldn't work just fine.  But, it doesn't work.

Bubb believes it has to do with the overly finicky Summoned() trigger.  That's why I suggest doing that check in a different way.  (There's got to be any number of ways to check that the summoner is the protagonist...)

1 hour ago, K4thos said:

- component 68 could be implemented by patching just K#FAMSUM.BCS (which is pretty self explanatory how to do it if you open the file and look what's in there)

I highly doubt that.  But then again I don't know that it would even be necessary - this component should probably work just fine, even with the EET changes.  (I think.  I haven't been able to really look into it in detail.  My testing still hasn't gotten past the failure of #67.

1 hour ago, K4thos said:

- component 69 is very similar to EET Tweaks component "Familiar death consequences"

No, this does something different than simply eliminate the CON loss.  It changes the whole "familiar gives you hit points" mechanic; and it has to account for changes made by the previous two components, such that re-summoning your familiar 1] summons the same familiar you originally chose, and 2] summons the familiar with the same spells with which you have imbued it.

Link to comment

I've just uploaded version 0.8.46.  Changes here:

-- Very small new component in the Spell Tweaks category: "Revised Identify Spell."  This uses @Bubb's excellent B3Idenitfy function to allow the Identify spell scale with levels: at 5th level it will identify 2 items, at 9th level it will identify 3 items, and at 13th level it will identify 4 items.  It is moved to 2nd level, both to reflect this augmented effect and to get it out of the way of better and more important 1st-level spells.  (That is up for discussion - please tell us if you like or dislike the level change.). The "Level 1 Cantrips" component will use this new version of Identify as well.

-- A couple bugs were fixed in the "Level 1 Cantrips" component and the "Cantrip Wands" component, which could prevent installation depending on the player's mix of other mods.  Should be smooth sailing now.

-- The "Choose-Your-Own Familiar" component is improved: now when you move the familiars into your pack, the picture will actually represent the new familiars (i.e. the spider and rat will look like a spider and rat, instead of an imp and quasit).  And when you move them out of your pack, they will no longer disappear forever.  :nono:

Choose-Your-Own Familiars still doesn't work on EET, however.

Link to comment

Okay, I think I've finally cracked most of the problems with familiars!  I've updated my fork to version 0.8.47, with the following improvements:

-- 'Choose-Your-Own Familiar' should now be compatible with EET:7up:  (It completely bypasses the EET familiar system, since I don't know how that works.)

-- 'Choose-Your-Own Familiar' will now install the 'Indelible Familiars' component by default.  You can still install 'Indelible Familiars' by itself if you want the vanilla alignment-based familiars and only want to change the hp-bonus/CON-loss system.

-- With 'Choose-Your-Own Familiars,' familiars now level up more or less in line with the protagonist.  They begin at level 1 with:

  • 9 hit points
  • thac0 17
  • AC 4 (plus Dex bonuses)
  • 16 in all saving throws

Then, at certain XP thresholds, the familiar will get 6 more hit points and a 1-point bonus to AC/thac0/saves.  The XP thresholds are:

  • 5,000 XP (only +3 hp here, for 12 total)
  • 50,000 XP
  • 150,000 XP
  • 450,000 XP
  • 1,250,000 XP (double bonus for thac0/saves)
  • 2,500,000 XP (double bonus for thac0/saves)
  • 4,000,000 XP (double bonus for thac0/saves)

At 4 million XP your familiar will have 48 hit points, base AC = -3, thac0 = 7, and all saving throws = 6.  I think this is more or less in line with the vanilla ToB familiars, but there will be a smoother progression up to that point.

Remember, since this now includes Indelible Familiars, you get a 10% hit point boost instead of the vanilla block of bonus hit points; and that 10% boost is only in effect while the familiar is outside your pack.  There is no penalty if they "die," except that you lose their passive benefits until the next time you can re-summon them.

For best results, mix with the Magic Fang and Animal Growth spells in Faiths & Powers.  :saiyan:

Edited by subtledoctor
Link to comment

Okay, I've got major updates ready for most of the mods I've been working on.  Lots of fixes and compatibility improvements.  Tome & Blood is up to version 0.8.48

This update removes the "General Spell Tweaks" component - they were a bit too random and personal for inclusion in a mod like this - you can find them and more in my "Random Tweaks" mod instead.  The "Spell Selection by Dialogue" component is also removed (for now?) since people were apparently installing it and not expecting it to in their game (?).  This also improves the so-called "readme" a bit, removing reference to those components and adding a reference for the "Revised Identify Spell" component. 

Finally, this make some under-the-hood changes to multiclass sorcerers.  First, it standardizes the stats used to track spell slots, using most of stat 108 and the 4th byte of stat 109, instead of a mish-mash of bytes in 108 and 134.  This makes it fall in line with the stats used for the new Bardic spellcasting in Might & Guile, and gets out of the way of the stat used for spontaneous divine casting in Faiths & Powers.  Second, it adds some characteristics to the multisorcerer spell learning function, explicitly for detection by Faiths & Powers later.  The upshot is, multiclass sorcerer casting in this mod can now coexist (somewhat uneasily) with spontaneous divine casting in FnP.  More information in that mod's thread for those who want to take advantage of this.

Cheers.

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...