Jump to content

Luke

Modders
  • Posts

    881
  • Joined

About Luke

Profile Information

  • Gender
    Male

Recent Profile Visitors

14,218 profile views

Luke's Achievements

  1. @Galactygon Haste/slow does not affect frequency for opcode 333. However, Time Stop does not "freeze" opcode 333... This means that in iwdee creatures affected by Shroud of Flame (which makes extensive use of op333) keep suffering fire damage during Time Stop... Intended...?
  2. So, I decided to give it a shot, but I'm having some issues... I set the app as you recommended, i.e.: frame generation: X3 custom scale factor: 1 resize before scaling: enabled scaling option: AMD FSR (with its sharpness setting cranked all the way up) Thing is that: FPS are still capped at 30 (the FPS counter shows something like 30/89) the cursor speed also seems to be capped at 30 (it is not smooth...) Are there other settings we should be aware of...?
  3. 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...
  4. 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.
  5. 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... 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 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...
  6. Makes sense. If that is the case, then immunity to Hold/Paralysis/Sleep should be removed from "bdplant.itm"... 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... 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...? 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...
  7. 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...) Yes, that should be the plan... 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...) 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... 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...? 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... 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...) 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"... Why would you leave these vulnerable to Web...? (to be continued...)
  8. 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...
  9. 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? 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...? 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...
  10. Please do not hate me, but technically speaking, the macro set_spell_vars should look like this: I mean, in 99% of cases that's probably overkill, but just to be precise...
  11. 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...?
  12. 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...
  13. 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...? Right. I'm wondering if this patch should also be part of the fixpack... Probably not, there would be too many resources to check...
×
×
  • Create New...