Jump to content


Photo

Modder notes for the sphere system


7 replies to this topic

#1 CamDawg

CamDawg

    Dreaming of a red Xmas

  • Gibberling Poobah
  • 9294 posts
  • Gender:Not Telling

Posted 02 November 2014 - 10:20 AM

Overview

So, first the broad strokes of how the sphere system is implemented. In the IE, divine casters automatically get their spellbooks filled as they level. So, for example, when a normal cleric hits level three:
  • The engine checks MXSPLPRS.2da and realizes the cleric can now cast level two spells
  • The engine goes looking for files named SPPRxyy, with x being the level and yy being 1-50 (defined in spells.2da)
  • The engine checks every one of those spells for restriction flags (e.g. cleric-allowed, good-allowed, etc.).
  • If not restricted, the spell is added to the spellbook.
DR short circuits this process by making step three always fail. Divine spells get flagged as disallowed to priests (this includes paladins) and druids (includes rangers). Previous versions of DR did this with a very broad brush; as of v8 this is done by a series of lookup lists (more below) to be more precise and to help future-proof it against spell mods. Essentially, if it's a spell that DR doesn't know about, it doesn't get brought into the sphere system.

DR instead adds spells to spellbooks directly through a class or kit's CLAB table. The original plan, to apply a single spell to take care of one sphere, failed since we tried to use the learn spell opcode (147)--this granted XP for gaining a spell like a mage using a scroll. Instead we settled on building elaborate tables and then appending long series of stuff like GA_SPPR101, which was messy but functional. We later discovered that using give innate ability (171) would have worked--and v8 has moved back to the original idea using it. Access to the a sphere is now accomplished by applying AP_CDDRxxy at the appropriate level, with xx being a two-letter code for the sphere and y the level. Spell restrictions are preserved by using alignment-targeted EFF files as appropriate.

Previous versions also worked under the assumption that the divine spell tables were unchanged. As of v8, the tables are read dynamically and spells handed out at the appropriate levels based on the current tables. This neatly solves the problem that paladins get up to level six spells in IWDEE and only level three everywhere else, for example, and also means DR doesn't need to worry about the 817 variations of spell progressions in the various tweak mods. This also has the side benefit of fixing the cleric-ranger exploit, where ranger-only spells would be added to the cleric's spellbook as the cleric leveled. Ranger-only spells now only turn up when the ranger levels have earned their addition to the spellbook.

The upshot is a very flexible and extensible system, both for new kits and spells.

HLAs are a little trickier and, at present, not quite as well-implemented, which will be a problem to solve going forward. For now, quest-level spell HLAs are also put into spheres, and then individual HLA tables are built for each kit based on which HLAs are currently present. The tables are no longer overwritten outright; they are instead patched and re-indexed by removing inappropriate HLAs, adding new ones as appropriate, and in most cases non-cleric HLAs are added to offset the reduced selection.

Adding kits to the DR system

If you want your kits to get into the sphere system, there are two macros for you. For kits, code is simple:
ACTION_IF ((MOD_IS_INSTALLED ~DIVINE_REMIX/SETUP-DIVINE_REMIX.TP2~ ~1000~) AND // dr spheres installed
           (FILE_EXISTS ~divine_remix/lib/macros.tph~)) THEN BEGIN             // sanity check for library

  INCLUDE ~divine_remix/lib/macros.tph~

  LAUNCH_ACTION_FUNCTION cd_kit_sphere
    STR_VAR
      table                   = clabpr01 // file name of your kit's clab table
      class                   = cleric   // allowed values: cleric, paladin, ranger, druid
      all                     = none     // use major, minor, or none for each sphere (none can be deleted)
      animal                  = none
      astral                  = none
      chaos                   = none
      charm                   = none
      combat                  = none
      creation                = none
      divination              = none
      elemental               = none
      elemental_air           = none
      elemental_earth         = none
      elemental_fire          = none
      elemental_water         = none
      guardian                = none
      healing                 = none
      law                     = none
      necromantic             = none
      necromantic_restorative = none
      numbers                 = none
      plant                   = none
      protection              = none
      summoning               = none
      sun                     = none
      thoughts                = none
      time                    = none
      travelers               = none
      war                     = none
      wards                   = none
      weather                 = none
    END

END
For example, this is what the mod itself uses to add spheres to Watchers of Helm:
 
LAUNCH_ACTION_FUNCTION cd_kit_sphere // helm
  STR_VAR
    table           = clabpr03
    class           = cleric
    all             = major
    astral          = major
    combat          = major
    creation        = minor
    divination      = major
    elemental       = minor
    elemental_air   = minor
    elemental_earth = minor
    elemental_fire  = minor
    elemental_water = minor
    guardian        = major
    healing         = minor
    protection      = major
    sun             = major
    war             = minor
    wards           = major
  END
Spheres are set to none by default, so you don't need to list spheres without access. Necromantic is also split between restorative forms only vs. all necromantic to allow for Morninglord's partial access. For full necromantic access, be sure to grant minor/major to both. If you want to radically alter your kit when spherized, like DR's cleric kits, make your changes before the macro.

This macro will do a couple of things. First, it will extend your kit's CLAB table out to level 50, if it isn't already, and then append the spells necessary to populate your kit's spellbook. It will also look up your kit's description from kitlist.2da and extend the kit description with sphere access information. It will also create the necessary lookup tables so that you can apply your kit to creatures in the game and give them the proper spellbook.

Spellbook adjustments for kitted creatures

Once cd_kit_sphere is run, appropriate tables are built to determine allowed spellbooks. Once again, it's simply a matter if invoking a macro:
 
ACTION_IF ((MOD_IS_INSTALLED ~DIVINE_REMIX/SETUP-DIVINE_REMIX.TP2~ ~1000~) AND // dr spheres installed
           (FILE_EXISTS ~divine_remix/lib/macros.tph~)) THEN BEGIN             // sanity check for library

  INCLUDE ~divine_remix/lib/macros.tph~

  ACTION_FOR_EACH creature IN kpchap01 everard accalia BEGIN

    ACTION_IF FILE_EXISTS_IN_GAME ~%creature%.cre~ THEN BEGIN

      COPY_EXISTING ~%creature%.cre~ ~override~
        LPF cd_spellbook STR_VAR clab = "foo" END
        BUT_ONLY

    END

  END

END
"foo" should be replaced with the file name of your kit's CLAB table, e.g. DR's Feywarden kit uses ~A#FEYW~. Known spells that are disallowed simply get deleted--the spellbooks of non-joinables don't matter, and joinables get a spellbook refresh on joining the party. Memorized spells, on the other hand, will get replaced by a random selection from the pool of allowed spells.

Adding spells to the sphere system

Macros are provided once again. Here's an example for some of the IWDification spells:
 
ACTION_IF ((MOD_IS_INSTALLED ~DIVINE_REMIX/SETUP-DIVINE_REMIX.TP2~ ~1000~) AND // dr spheres installed
           (FILE_EXISTS ~divine_remix/lib/macros.tph~)) THEN BEGIN             // sanity check for library

  INCLUDE ~divine_remix/lib/macros.tph~

  ACTION_CLEAR_ARRAY cd_spheres
  ACTION_DEFINE_ASSOCIATIVE_ARRAY cd_spheres BEGIN
    CLERIC_ALICORN_LANCE                  => an
    CLERIC_ANIMAL_RAGE                    => co
    CLERIC_BEAST_CLAW                     => co
    CLERIC_BLOOD_RAGE                     => co
    CLERIC_CAUSE_DISEASE                  => he
  END

  OUTER_SET sphere_descript = 1
  OUTER_SET hla = 0
  LAUNCH_ACTION_MACRO CD_BUILD_SPHERE

  // now do it again for secondary spheres
  ACTION_CLEAR_ARRAY cd_spheres
  ACTION_DEFINE_ASSOCIATIVE_ARRAY cd_spheres BEGIN
    CLERIC_BEAST_CLAW                     => ne
  END

  OUTER_SET sphere_descript = 2
  LAUNCH_ACTION_MACRO CD_BUILD_SPHERE

END
First, you need a table that maps a spell's IDS reference to a two-letter code for its sphere (list below). Two variables control how the spell is handled, HLA is set to zero for normal spells, otherwise it's treated as an HLA. At present, spells flagged as HLAs will not really do a lot until an extensible HLA system is developed. The variable sphere_descript takes values of 0-2. A value of 1 will overwrite the existing sphere information on a spell (or add if not present). A setting of 2 will find the existing sphere line and append the selected sphere. So, from the example above, CLERIC_BEAST_CLAW is both a combat and necromantic spell. So it's first run through with sphere_descript = 1, which clears out any existing sphere references and changes the line to Sphere: Combat. Running it through the macro again with sphere_descript = 2 will then append Necromantic to the line, making it read Sphere: Combat, Necromantic. Since I assume most mod-added spells will already have spheres in their descriptions, it's likely that outside of DR itself that non-zero values will be needed for the sphere_descript variable.

The spell will also be added automatically to the appropriate CDDRxxy spell. Alignment restrictions will be looked up and accounted for as appropriate. In the example above, Beast Claw, being a second level spell, would be added to CDDRco2.spl in the first run and CDDRne2.spl on the second. This will automatically add it to the spellbooks of any priest with minor access to combat or necromantic.

Spells from IWDification and Galctygon's beta 6 spell pack are already on the lists.

The complete list of two letter codes:
  • al - all
  • an - animal
  • as - astral
  • cs - chaos
  • cm - charm
  • co - combat
  • cr - creation
  • di - divination
  • ex - elemental (all)
  • ea - elemental (air)
  • ee - elemental (earth)
  • ef - elemental (fire)
  • ew - elemental (water)
  • gu - guardian
  • he - healing
  • lw - law
  • ne - necromantic
  • nr - necromantic (restorative only)
  • nu - numbers
  • pl - plant
  • pr - protection
  • su - summong
  • sn - sun
  • th - thought
  • ti - time
  • tr - travelers
  • wa - war
  • wd - wards
  • we - weather

I came here with a simple dream: a dream of killing all humans. And this is how it must end? Who's the real seven billion ton robot monster here? Not I. Not... I.


#2 subtledoctor

subtledoctor
  • Modders
  • 2211 posts
  • Gender:Male

Posted 21 November 2014 - 02:23 PM

So, I want to make sure I understand things here. Please correct me if any of the following is inaccurate:

As of DR v8, the sphere system is optional. Installing that component essentially makes the mod run like DR v7, in that:

1) Spells are stripped away from all divine casters and granted to each kit according to the sphere system. Mod kits can hook into this system via the macro described in the first post.

2) Kits have more innate abilities, as they did in v7, and have special weapons they can summon once per day, which grow in power as the cleric levels up. Mod kits can emulate this by creating some fun/cool innate abilities and creating special summonable weapons. Nothing a few hours in NI can't take care of.

3) Kitted clerics cast one fewer spell per day of each level compared to the trueclass cleric - essentially, all of those innate abilities take the place of casting one normal spell per level. Mod kits can...

And that's where I trail off. How is the reduced spellcasting implemented? Is it even still implemented in v8? Do modders have to do anything special to work right? Does DR mess with the base spellcasting table? Or just grant an extra spell to trueclass clerics?

Inquiring minds want to know! Thanks in advance.

Faiths & Powers: Spell spheres and kit pack for priests and paladins
Might & Guile: Tweaks and kits for warriors and rogues
Scales of Balance: Game tweaks and rule overhauls
NPC_EE: More options for NPCs in BGEE, SoD, & BG2EE


#3 Grammarsalad

Grammarsalad
  • Modders
  • 449 posts
  • Gender:Male

Posted 21 November 2014 - 05:10 PM

I think you can remove slots with effect #62.

#4 subtledoctor

subtledoctor
  • Modders
  • 2211 posts
  • Gender:Male

Posted 24 November 2014 - 06:15 AM

Right - there are a couple different ways to do it, each of which is bugged in its own special way.  But I'm just interested in specifically how DR approaches it, so that I know precisely what else I have to do (if anything) to make mod kits compatible with sphere system.


Faiths & Powers: Spell spheres and kit pack for priests and paladins
Might & Guile: Tweaks and kits for warriors and rogues
Scales of Balance: Game tweaks and rule overhauls
NPC_EE: More options for NPCs in BGEE, SoD, & BG2EE


#5 Galactygon

Galactygon

    Nostradoctopus

  • Modders
  • 722 posts
  • Gender:Male
  • Location:Sweden

Posted 13 December 2014 - 10:33 AM

Correct me if I'm wrong, I thought it would make the most sense if DR would be installed before other spell mods. The onus of making third party mod DR-friendly would be on other modders such as me since Cam was gracious enough to provide a simple means of doing so. This has the advantage that:
1. Cam doesn't have to go running around updating DR every time somebody releases a spell (or kit?) mod.
and
2. Other modders don't have to wait for a new DR update but instead can opt to INCLUDE the code as posted above.

Older mods that are not updated often can be exceptions, but usually they are installed earlier in the mod installation list.

Edited by Galactygon, 13 December 2014 - 10:42 AM.

Posted Image

Posted Image

#6 Jarno Mikkola

Jarno Mikkola

    The Imp

  • Modders
  • 6296 posts
  • Gender:Male
  • Location:The town where the dead haven't keeled over, yet. In Finland.

Posted 13 December 2014 - 11:02 AM

Correct me if I'm wrong, I thought it would make the most sense if DR would be installed before other spell mods.

Well, that's usually the whole point of mods like the DR, an overhall for the whole system. Unlike other mods that usually just patch a few spells by adding a few effects to them.


Welcome to the sanity, you are free to search for the limit, it's out there, we drew it in the sand.
Here's how to install all the ... mods you ever really could want to Infinity Engine games. I removed the stable word from there as Roxanne began to add BS mods that are likely to break compatibility from the BWS.

#7 Galactygon

Galactygon

    Nostradoctopus

  • Modders
  • 722 posts
  • Gender:Male
  • Location:Sweden

Posted 13 December 2014 - 03:09 PM

Correct me if I'm wrong, I thought it would make the most sense if DR would be installed before other spell mods.

Well, that's usually the whole point of mods like the DR, an overhall for the whole system. Unlike other mods that usually just patch a few spells by adding a few effects to them.


Am wondering because the readme states

Spell packs and high level ability mods

High level ability mods may not be compatible. Spell packs are fully compatible, though if the player wishes to use the sphere system, it is recommended that spell mods be installed prior to The Divine Remix.


Posted Image

Posted Image

#8 Jarno Mikkola

Jarno Mikkola

    The Imp

  • Modders
  • 6296 posts
  • Gender:Male
  • Location:The town where the dead haven't keeled over, yet. In Finland.

Posted 13 December 2014 - 11:50 PM

... recommended that spell mods be installed prior to The Divine Remix... of mods that have had no chance to later configurate their install to the new sphere system.

See, it's always the responsibility of the later mod to confirm it's mechanism to the prior installed mod, if it's said to be FULLY compatible.
Welcome to the sanity, you are free to search for the limit, it's out there, we drew it in the sand.
Here's how to install all the ... mods you ever really could want to Infinity Engine games. I removed the stable word from there as Roxanne began to add BS mods that are likely to break compatibility from the BWS.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users