Luke
-
Posts
879 -
Joined
Content Type
Forums
Events
Downloads
Gallery
Mods
News
Store
Posts posted by Luke
-
-
17 hours ago, DavidW said:
I think it is probably more sensible to fix the resource instead of deleting it
-
On 12/27/2023 at 1:50 PM, Galactygon said:
How many SPLSTATE entries would we need then? Is there enough to have some amount remaining for mods? It's worth to have an open discussion imo.
As part of one of my pending pull request, I added the following splstates: CONFUSION_IMMUNITY, STUN_IMMUNITY, CHARM_IMMUNITY, BERSERK_IMMUNITY, DEAFNESS_IMMUNITY, BLINDNESS_IMMUNITY, SILENCE_IMMUNITY, HOLD_IMMUNITY, PARALYZED_IMMUNITY, POLYMORPH_IMMUNITY, FEEBLEMIND_IMMUNITY, PANIC_IMMUNITY, GREASE_IMMUNITY, WEB_IMMUNITY, ENTANGLE_IMMUNITY, PETRIFY_IMMUNITY.
-
6 hours ago, Galactygon said:
Note that some creatures (i.e. Death Tyrants) have a venn diagram of overlapping immunities and need multiple rings. However, they also wear IMMUNE1.itm (nonmagical weapon immunity). So a set of weapon immunity amulets, say IMMUAM1.itm need to be created to allow for those creatures to wear an extra ring.
What about getting rid of immunity items? That is to say: what about transferring immunities from equipped items to CRE effects? That should matter most in case they wear droppable (PC-usable) rings/amulets/etc, though I must admit the circumstances are very rare...
6 hours ago, Galactygon said:This will require numerous spells to be patched to either use opcode 318 (no feedback) or 324 (IWD-style feedback) so those SPLSTATEs completely block the entire spell.
As a rule of thumb
- use 324 if the parent SPL has a name or there exists an ITM with the same "resref" that is meant to be used by the Player
- use 324 if the parent ITM is meant to be used by the Player
- 318 in all other cases
6 hours ago, Galactygon said:IDS files should be identical between BG1:EE, SoD, and BG2:EE but not IWD:EE (though it's convenient they are).
As I've already said above, demons and devils should deserve some love...
Aside from that, I too think the IDS files should be the identical between all the games... Speaking of this, I suggest adding SALAMANDER_FIRE and SALAMANDER_FROST to BG CLASS.IDS so as to match IWD CLASS.IDS... In BG(2) / SoD Salamanders are flagged as ELEMENTAL_FIRE / ELEMENTAL_WATER, which sounds a bit inaccurate...
-
15 hours ago, Galactygon said:
BDPLANT.itm is a much better alternative to the undead immunity ring RING95.itm which Shamblers currently have. Immunity to Backstab, Petrification, Poison/Disease, Polymorph (plants are a different kingdom compared to creatures), and Stun all make sense. They're semi-intelligent species so they're not immune to Sleep, Charm, Hold, Paralysis, Confusion, etc. in the source material.
Makes sense.
If that is the case, then immunity to Hold/Paralysis/Sleep should be removed from "bdplant.itm"...
15 hours ago, Galactygon said:Myconids are also plant creatures but they should be vulnerable to everything except Poison/Disease, Petrification, and Polymorph. They currently share a hand-to-hand attack with Umber Hulks (UMBER01.itm) which for some reason also grants immunity to Confusion.
In SoD Myconids wear "bdplant.itm" and do not use "umber01.itm"... As a result, we should either make a new skin or patch the CRE files so as to grant them only Poison/Disease, Petrification, and Polymorph immunity...
15 hours ago, Galactygon said:All plant creatures (incl Jellies, Slimes) should use the already existing GENERAL.ids entry 7-plant which can then be used to do an IWD-style check in Polymorph Other / Sphere of Chaos. Shamblers shouldn't be classed as (earth) elementals but use the already existing RACE.ids entry 176-shambling_mound.
Totally agree on this.
To be precise, only Olive/Green slimes are technically "plants"... As a result, the other jellies (f.i. Mustard Jelly) should remain flagged as GENERAL=MONSTER...?
15 hours ago, Galactygon said:Fiends/Demonic creatures are a topic within itself with lots of creatures and many types of immunities. We need more information before I can form an opinion.
The source material states nothing (apart from certain types of damage...) The only exception appears to be Lemures and Mariliths, which are supposed to be immune to mind-affecting opcodes (this is already the case in SoD since Lemures are equipped with "ipsion.itm"...) Again, the only thing that seems out of place in "ipsion.itm" is the immunity to Paralysis (op109)... That is to say: should immunity to op175 always be paired with immunity to op109...?
Related (kinda): quite some time ago I advocated for adding CLASS.IDS entries to better identify demons and devils (as opposed to just TANARI and IMP...) I mean, we have an entry for each type of wolf/bear/elemental/etc..., so why not doing something for devils and demons...? @CamDawg already said this is out of scope, though I'd like to know your opinion... Taking inspiration from the source material, even something like GREATER_BAATEZU, LESSER_BAATEZU, LEAST_BAATEZU / LEAST_TANARRI, LESSER_TANARRI, GUARDIAN_TANARRI, GREATER_TANARRI, TRUE_TANARRI should suffice...
-
8 hours ago, CamDawg said:
IWD and BG use different mechanics, and this won't be changed by EEFP.
Yes, but the underlying lore is the same though... Having said that, if you really think some of the proposed changes is out of scope, then I'll submit them for Tweaks Anthology (as I've already done with Cure / Cause Wounds spells vs unnatural creatures...)
10 hours ago, Galactygon said:Spells in BG1/2:EE in general should adopt the use of opcode 324 more often, even when it seems unnecessary so we get more consistent feedback in the combat log. i.e. Charm Person should check for nonhumanoids and those who carry the immune_charm SPLSTATE. Immunity rings that already block the charm opcode with the associated effects should carry a SPLSTATE effect immune_charm. Immunity against particular resource values should be removed from those rings, since the spells themselves would have IWD-style SPLPROT checks instead.
Yes, that should be the plan...
10 hours ago, Galactygon said:Poison/Disease immunity is done by a SPLPROT RESISTPOISON>=100 check that was extended to all such spells in BG1/2EE in the recent patches. Elementals and elemental-kin (i.e. Salamanders, Water Weirds) should have their RESISTPOISON set to 100 if not already.
Disease immunity is only partially done by a SPLPROT RESISTPOISON >= 100 check... Keep in mind that the disease opcode can also cause Strength / Dexterity / Constitution / Intelligence / Wisdom / Charisma loss, as well as Slow... As a result, SPLPROT RESISTPOISON >= 100 might not be enough...
As a side note, in IWD:EE spells / attacks that cause Disease do check (via op318/324) for unnatural creatures... However, we cannot do the same in BG games because there might be some exceptions (f.i. the demon in Watcher's Keep is intended to be vulnerable to Poison...)
11 hours ago, Galactygon said:Backstab, Entangle, Web, Grease, and Petrification immunity make sense for elementals (make a new immunity ring just for them?). These checks should be added (opcode 324) to the relevant spells as well so they display the immunity message. IWD:EE blocks large creatures from being affected by these spells which includes elementals. It would make sense to also specifically block elementals and elemental-kin (Water Weirds, Salamanders, but not Genies) in IWD:EE and large creatures in BG1/2:EE.
Sounds good.
Again, if @CamDawg thinks Entangle, Web and Grease should not check for large creatures in BG games, then I'll submit the change for Tweaks Anthology...
11 hours ago, Galactygon said:Salamanders are immune to sleep (not knockdown), charm, hold, and paralysis according to this source. In IWD:EE they're vulnerable to everything, while in BG2:EE they have RING95.itm which gives them immunities they shouldn't be immune to (Death, Level Drain, Morale, etc.). They're unaffected by Charm anyways, since they're not humanoid (Charm Monster isn't an available spell here). AD&D makes a distinction between Charm and Domination, where immunity to Domination is far less common. Should we make this distinction in the IE? I'm more for it, given that Domination is an underwhelming spell.
Sounds really good (also thanks for sharing the source, I'm saving it right now...)
SoD appears to be faithful to the source since Salamanders (f.i. "bdsalf01.cre") are immune to Sleep , Charm, Hold, and Paralysis... Some comments:
-
As already discussed elsewhere, the immunity to Sleep also protects them from Earthquake and the like (unintended)
- The splstate-based immunity system should solve this issue...
- The source states Hold, not Paralysis... Again, should we consider Hold (op175) and Paralysis (op109) the same thing (and thus block both...?)
- In IWD:EE spells that cause Level Drain check for Salamanders (among others). Should we do the same in BG...?
Finally, how would you distinguish between Charm and Domination? By using two different splstates...?
11 hours ago, Galactygon said:Genies aren't really elemental-kin or elementals. They lack general immunities according to this source and they don't wear immunity rings either ingame. They're fine as they are.
Fair enough.
The only "issue" is that their sleep animation looks "silly", since it's basically invisible (they retreat into their lamp...) Anyway, not really an issue, just saying...
11 hours ago, Galactygon said:Blindness and Polymorph immunity is a borderline case. I can see the argument for elementals, but not for others.
Well, Blindness and Polymorph are powerfull debuffs, and thus should be considered imho...
Creatures that do not rely on sight (f.i. Oozes, Dragons, other...?) should probably be immune to Blindness, shouldn't they...?
As far as Polymorph is concerned, Lycanthropes and Dopplegangers should probably be immune to it (as @kjeron said, they can just change back into their original form...)
11 hours ago, Galactygon said:DRAGRING currently grants immunity to Charm, Silence, Sleep, Stun, Hold, Entangle, Web, and Grease
RING97 currently grants immunity to Slow, Hold, Entangle, Web, Grease, and Level Drain
According to the source, Dragons should only be immune to Normal Missiles, with some exceptions: the one you mentioned and the Deep Dragon ("They are born with immunities to charm, sleep, and hold..."), possibly others...
As you said, we can strip Slow and Level Drain from "ring97.itm" and use it for Dragons... Then, we can add extra immunities to their creature weapons or directly patch the CRE file... And if someone really wants a "cheated" dragon, it can use "dragring.itm"...
11 hours ago, Galactygon said:Even smaller flyers like Gauths and Imps can get yet another new immunity ring that only protects against Grease and Entangle and not Web.
Why would you leave these vulnerable to Web...?
(to be continued...)
-
As already discussed elsewhere, the immunity to Sleep also protects them from Earthquake and the like (unintended)
-
9 minutes ago, Luke said:
especially if EEex is not installed...
Forgot to say that if EEex is not installed, it is possible to abuse the bugged op182 to bypass op101 and thus reuse the same opcode in different scenarios...
-
On 12/27/2023 at 1:50 PM, Galactygon said:
There is also an element of contextuality to that requires a bit of digging into some of the files in oBG2 or even oBG1 to see what developer intent was.
Assuming you know very well the underlying AD&D lore, may I ask you to clearly state which creature type (i.e. Undead, Constructs, Elementals, Extraplanar and the like) should be immune to Charm / Hold / Paralysis / Berserk / Polymorph / Sleep / Stun / Confusion / Feeblemind / Petrification / Disease / Poison / Cure Cause Wounds / other...? Could you also include partial immunities such as Elves/Half Elves partial immunity to Charm...?
That is to say: if you were to design the so called creature skins (i.e. "ring95.itm" , "ring97.itm", etc...) from scratch, what would you do...? I mean, as I said in the OP, AD&D 2nd edition is not very informative about that, and it'd be nice to have a clear template to refer to... Additionally, it is also likely that it is now possible to implement things that were not possible before (pre EE engine)...
So to sum up: theoretically speaking, what should be immune to what?
On 12/27/2023 at 1:50 PM, Galactygon said:For example, RING97.itm in oBG1 granted immunity to just the opcodes entangle, paralyze, web, grease, and slow that has since evolved into granting immunity to level drain text but not the level drain opcode in BG2EE.
As I said before, without having a template to refer to, it may be difficult to understand developer intent... We can all agree that the immunity to paralyze is there because back in the days the Web opcode was cosmetic-only... As a result, it should be removed... As far as Slow and Level Drain are concerned, I think they should be removed as well...? I mean, "ring97.itm" should be the creature skin for Wyverns, and I cannot see why they should be immune to both Slow and Level Drain...
Speaking of this, trolls come to mind: they are immune to most (all?) disabling opcodes probably because back in oBG1 their special death mechanic used to rely on scripts... But since nowadays all of that can be handled via op232/op272, such immunities should probably be removed...?
On 12/27/2023 at 1:50 PM, Galactygon said:Do we want to clear the opcode immunities? I think that can be done in some cases where an opcode might be reused for different categories of spells i.e. the feeblemind opcode is reused in different types of spells (would also make sense for IWD EHopelessness to use this instead of Stun). In these cases, it would be preferrable to remove those immunities accross the board and outsource to via SPLSTATEs i.e. immune_feeblemind, immune_hopelessness, etc. How many SPLSTATE entries would we need then? Is there enough to have some amount remaining for mods? It's worth to have an open discussion imo.
Yes, getting rid of op101 would probably be the best solution, especially if EEex is not installed... The only issue is that existing mods would need to adapt to the new (splstate-based) system, otherwise the feeblemind / sleep opcodes (among others) cannot be reused in different scenarios...
-
Please do not hate me, but technically speaking, the macro set_spell_vars should look like this:
SpoilerDEFINE_ACTION_MACRO set_spell_vars BEGIN LOCAL_SPRINT spell_name "" LOCAL_SPRINT spell_res "" LOCAL_SPRINT SOURCE_DIRECTORY "" LOCAL_SPRINT SOURCE_FILESPEC "" LOCAL_SPRINT SOURCE_FILE "" LOCAL_SPRINT SOURCE_RES "" LOCAL_SPRINT SOURCE_EXT "" LOCAL_SET SOURCE_SIZE = 0 LOCAL_SPRINT DEST_DIRECTORY "" LOCAL_SPRINT DEST_FILESPEC "" LOCAL_SPRINT DEST_FILE "" LOCAL_SPRINT DEST_RES "" LOCAL_SPRINT DEST_EXT "" // COPY_EXISTING_REGEXP - "sp\(in\|cl\|pr\|wi\)[0-9][0-9][0-9]\.spl" nowhere SPRINT spell_res "%SOURCE_RES%" TO_UPPER spell_res LPF NAME_NUM_OF_SPELL_RES STR_VAR spell_res RET spell_name END SPRINT "%spell_name%" "%spell_res%" END
I mean, in 99% of cases that's probably overkill, but just to be precise...
-
52 minutes ago, Galactygon said:
Yeah, it's a mess... Also because it was me that brought this up to your attention...
I mean, probably the pre v2.6 behavior is desirable only if the subspell's projectile is AoE (Vitriolic Sphere, Mordenkainen's Force Missiles, Shroud of Flame, etc...), whereas the new v2.6 behavior should only apply if the subspell's projectile is single target...?
-
40 minutes ago, Galactygon said:
So far I haven't found a way to bypass this sort of behavior (selectively ignore opcode 102 while still respecting turnings/reflections)
If I'm not wrong, non-decrementing reflection opcodes (f.i. op202) work like that with respect to op146*p2=2 / op326 / op333, i.e.: the subspell cast by those opcodes gets reflected and at the same time affects the primary target.
Prior to v2.6, that was also true for decrementing reflection opcodes (such as op200...) So this behavior was flagged as a bug and got fixed for the decrementing reflection opcodes but not for the non-decrementing ones...
-
1 hour ago, Guest dead drunk said:
Could it be possible to remove the new EE NPCs altogether?
Have a look here.
-
2 hours ago, DavidW said:
(I'm not assuming EEEx, though.)
Well, should be relatively easy to support it... And by the way, I also provided an alternative if EEex is not installed... Again, since that opcode does not work as expected, why not abusing it...?
2 hours ago, DavidW said:Oh, the reason I'm using an instantaneous projectile is that it plays more nicely with Timestop. (I do this as a general patch in v35, in fact.) If you use projectile=none, a spell comes in instantly, even in Timestop. If you use an instantaneous projectile, it resolves immediately after the Timestop ends.
Right. I'm wondering if this patch should also be part of the fixpack... Probably not, there would be too many resources to check...
-
Priest spells:
-
Faerie Fire
- At least on EE games, op7 and op9 should support param2=255 (Character Color)... As a result, you might want to apply a single opcode instead of 7 different opcodes (one for each color location...)
- Spell Projectile should probably be 1|None instead of 0|Default
- op321 and op318 are referencing a non-existing resource, i.e. "FAER_PLC"...
-
Strength of Stone
- At least on EE games, op176 should use param2=5 (Multiplicative stacking percentage modifier), so as not to override Grease, Entangle and friends... As of now, if the priest is entangled and casts this spell, then it can move even if entangled...
-
Protection From Good 10' Radius
-
Projectile Radius is actually 16 (256=16*16), not 10...
-
-
Fiendish Warding
-
At least on EE games, the subspell cast by op201 when it terminates prematurely (i.e., when it can no longer absorb spells) should be "sppr7a0b"... Just leave the resref field of op201 blank, it will be cast automatically when the effect self-terminates... The subspell should of course apply an op321 effect targeting its parent, along with a feedback sound effect (you can take "spwi701" and "spwi701b" as templates...)
-
-
Faerie Fire
-
Wizard spells:
-
Ice Knife
- op333 should be flagged as power=1 (so that it can be properly deflected/reflected/trapped)
- shouldn't the AoE radius of the subspell cast by op333 ("dw-ickns.pro") be 80 (16 * 5) instead of 96...?
-
Stonefist
- At least on EE games, op45 can naturally display the Stunned icon, there is no need to apply a separate op142...
- At least on EE games, op7 should support param2=255 (Character Color)... As a result, you might want to apply a single op7 instead of 7 different op7 (one for each color location...)
-
Combustion
- op321 should be flagged as power=2 (so that it can be properly deflected/reflected/trapped)
- why are you using an instantaneous projectile instead of projectile=1|None in the main spl file...? I don't think this is an issue, but just unusual...?
- the subspell cast by op146 ("spwi2a1b") is displaying the magnetized icon... Guess you wanted to display something else, like a recolored Shroud of Flame icon...?
-
Turn Pebble
-
if EEex is installed, please consider the idea of setting BIT23 (savingthrow field) of op39 to 1, so as to bypass CLERIC_CHAOTIC_COMMANDS and friends (I mean, they are not supposed to block it...)
- If EEex is not installed, you *might* want to abuse the bugged op182 to bypass the immunity...
-
if EEex is installed, please consider the idea of setting BIT23 (savingthrow field) of op39 to 1, so as to bypass CLERIC_CHAOTIC_COMMANDS and friends (I mean, they are not supposed to block it...)
-
Telekinesis
-
all preset_target effects should be flagged as power=5 (instead of 6...?)
-
unless I'm missing something, there is no check for "The spell is ineffective against any creature of ogre size or larger..."
-
unless I'm missing something, op109 is only meant to temporariliy disable the creature during wing buffet... If that's the case, then you might want to opt for op185...?
-
-
Telekinetic Storm
-
all effects should be flagged as power=8
-
-
Stormbolts
-
only the damage opcode checks for Magic Resistance. Intended...?
-
The Stun effect is not dispellable. Intended...?
-
the spell is not compatible with the Seven Eyes spell. In short, if the targeted creature is protected by EYEMAGE, then it will absorb both the Damage opcode and the Stun opcode, which is not intended... As a result, you might want to break the spell into subspells, one applying op12 and another one applying op45 and its ancillary effects... Alternatively, just make one subspell for op45 and move op12 at the end of the effect stack...
-
[iwdee] op139 in the subspell is displaying "Grisella's Dale Ale" instead of "Stunned"...
-
At least on EE games, op45 can naturally display the Stunned icon, there is no need to apply a separate op142...
-
-
Veridon's Icy Ray
-
the Damage opcode in the main spl file bypasses Mirror Image. Intended...? Asking because the spell is single target, not AoE...
-
Spell description states "... slows the creature for 10 rounds...", but it actually stuns it for 1 round...?
-
-
Ice Knife
-
15 minutes ago, DavidW said:
(in due course I'll do a post on how that tool works but I want to work out some kinks in the wild first).
Another out-of-curiosity question: where did you learn coding in Lua? Self-taught...?
Asking because I think it would probably be more beneficial some lessons about Lua in general (i.e., something similar to your WeiDU lessons)... I am trying learning Lua by myself with Bubb's help, but it is not "easy", especially because there is no proper documentation about how the Lua environment interacts with the game... And that's bad, because you have just showed you can do some pretty interesting things with it (and even more if EEex is installed...)
Sorry if all of that is above your pay grade...
-
I see. Out of curiosity, if there's enough room in spell.ids, why don't you use it...?
-
I've got a question about some under-the-hood mechanics (if possible): it appears that you came up with yet another Lua trick to include new spells at CharGen / LevelUp without updating "spell.ids" (as an alternative to this one...?)
The question is: how can we keep track of spells added in this way? As far as the aforementioned method is concerned, it is just a matter of parsing a (lua) file that collects all extra spells along with some info about who can learn them by scribing / by selecting them during CharGen or LevelUp...
-
-
May I propose to you a series components that rework / add some class summoning abilities (f.i. a reworked Summon Familiar for Mages / Sorcerers / Beastmasters, a new summoning ability for Blackguards, ...)? Are you fine or is it out of scope...?
-
3 hours ago, jmerry said:
It would technically work either way, as %WNL% (Windows) is %MNL% (old Mac OS) concatenated with %LNL% (Unix-based systems, including Linux and modern Mac OS)
Yeah, me dumb, you're right...
-
On 6/7/2022 at 5:09 PM, argent77 said:
Another peculiarity involves the end-of-line character $. The symbol matches only Unix-style line breaks. To include support for the (more common) Windows-style line breaks, you have to add %MNL% as an optional match (e.g. "Minsc%MNL%?$").
Just to clarify: you meant %WNL%?$ instead of %MNL%?$, right...?
-
-
20 hours ago, subtledoctor said:
How are you structuring the invisibility check? For on-hit effects most spells will target the victim of the attack - you need to use target mode 9 to check the attacker’s stats. See here for an example to work from.
Will try... Anyway, target mode 1 works fine with other checks...
I fear there is something specific to the invisibility check that I am missing...Thing is that the on-hit check is done after base damage, so of course this cannot work as I expected... -
On 7/18/2023 at 2:30 PM, argent77 said:
Note: This will only check visibility state when the special ability is cast.
Sorry for the necro, but I think I have a similar issue...
If you add op326 (target=1, p2=140) as an on-hit effect to a melee weapon (say "dagg01.itm") in order to cast a spell only if the attacker is invisible, nothing happens... This is easily reproducible by editing your weapon to always hit (i.e. by setting thac0_bonus to 32767)... Is this intended or what...?
SPLSTATE.IDS entry population
in Sword Coast Stratagems
Posted
Fwiw, you are not supposed to install EEFixpack, since it has not been released yet (as always, keep in mind that the master branch might contain untested changes...)
That is to say, the exact number of splstates EEFixpack will add is yet to be determined...