Jump to content

grodrigues

Members
  • Posts

    238
  • Joined

  • Last visited

Posts posted by grodrigues

  1. 2 hours ago, Bartimaeus said:

    Why? It's easier to follow discussion on here, especially since I actually get notifications when people reply,

    Just to put the discussion along the PR. But I can also just link it here, so no problem, do whatever's more convenient for you.

  2. On 9/3/2021 at 7:34 PM, subtledoctor said:

    However, this is also bad, because you cannot leave the area you are in. If you don't happen to have access to Break Enchantment, then this can be game-breaking.

    My knee-jerk reaction was "then memorize Break Enchantment" as I definitely do not like the idea of making petrification temporary. It cuts on some of the danger factor, that is, it is a threat vector that the party *must* account for. Unfortunately, my response does not quite work because as you pointed out one cannot leave the area -- or at least one would have to expel the party member before leaving (if at all possible, I think it is but do not quote me on it), which has its own complications.

    Sigh. As with imprisonment, I do not have a good solution for this.

  3. @BartimaeusThanks for reviewing. Fixed the lack of neutral charm and the missing ".eff" extension. The duplicated opcodes should be fixed as well (typo in the argument to CLONE_EFFECT). Any other comments, holler in the PR itself please.

    As far as the 324 opcode, that is most likely the doings of kreso_eestatSR.tpa. The PR itself does nothing in that regard. The idea is I presume, to block spell if target is under Chaotic Commands.

  4. Finally getting around to implement this, but need some help. We need to filter for hostile and non-hostile (= neutral and ally) via Use Eff to account for the different save on the charm according to whether the creature is hostile or not. The relevant filtering is via ea.ids. My question is: are GOODCUTOFF (30) and EVILCUTOFF (200) enough?

  5. On 9/2/2021 at 3:39 AM, Bartimaeus said:

    Kind of sucks you spent all of that time working on the insane patch version of your fixes and then had to turn around and do it all over again with the base resource files, but that's the way she goes, I suppose...

    Actually it is not as bad as it looks, as all patching is done with WeiDU code, so most of the work was shifting things around and make another pass through spell to uncover any mistakes -- and sure enough, some were caught.

  6. As Bartimeus said. SCS AI compatibility is one of the priorites and restoring the immunity to magic weapons +3 is pretty much the consensus around here I think. The issue is what exactly can we add to make Prismatic Mantle a real option (for the players) instead of just defaulting to PfMW -- I can only speak as a player, but it is what my party mages always do, including bards/fighter-mages that go melee.

    Have to think about this, but the conundrum Bartimeus raised is fair: as a rule, if you are using protection against weapons spell it is because you do *not* want to get hit. Since retals occur regardless of damage ocurring, the problem becomes in the prismatic mantle effect itself. We could prevent shield stacking to help balance -- this is probably a good idea  anyway independently of what exactly we do with prismatic mantle.

  7. The current SR implementation of Prismatic Mantle has dropped protection from any sort of magic weapons and has put in a retaliation. While the concept is good there are several problems: the implementation has several issues not the least the fact that there is left over cruft suggesting that the spell does protect against (some) magic weapons. It ends up gimping the AI and is bound to confuse SCS. If you are a mage, you do *not* want to get hit and with PfMW at level 6 why would you even waste a level 8 slot on such a spell? Maybe, maybe a fighter-mage or a similar frontline fighter would want to cast it to augment his dps, but I doubt it.

    Given this the proposal is to reinstate the protection against +3 weapons (inclusive); to compensate, nerf the retaliation to only happen once a round. One advantage is that SRR already implements such, so we can just shamelessly pilfer the implementation.

    If you prefer what SR currently offers, present your argument. If you have any experience with SRR and its implementation of Prismatic Mantle, could you share your experience with the spell? Is it balanced, the AI (and by AI, I mean SCS AI) does the sensible thing within the constraints of what an AI for the IE engine can do, etc.

  8. All the spell fix PR's are up (and many have already been merged); I still have to open a couple of RFC and submit a few more PR's, then I will declare this first stage done, do some install testing and roll out the next public release.

  9. The problem applies to any spell cast at point via a projectile. Is this a mechanic people want do away with? In itself and separate from any other considerations, I do not see anything wrong with it.

    Then there are the several ways we could go about it: (1) instead of targeting a location, target a creature and maybe bypass invis (2) increase aoe -- but then we have to look at other aoe spells and my general impression is that some of them, namely Glitterdust, maybe Grease, definitely need such a buff independent of this specific problem (3) reduce casting time and/or increase projectile speed.

  10. That is settled then, and by this I mean: implement neutral charm with different saves for hostiles and non-hostiles (numbers as laid out by Bartimeus). I am still undecided on Dire Charm; it is just the oddball. One thing I would like to ask is some kind of blurb, hopefully lore-friendly, to stick in the spell descriptions for this behavior as I intensely dislike opaque (to the user) mechanics.

    @subtledoctornot tied to this RFC, but currently there is a small issue blocking the merge of your nwn spell deflection patch. Could you please fix it? I could do it myself, but it is better to do it at the source.

  11. 1 hour ago, Bartimaeus said:

    For right this second, I would just like to note again that if you use the "neutral reaction" type of charm, it is less strictly "neutral" and more "status returns to whatever it was previously before being charmed" - i.e. if you use the neutral reaction charm type on a character that was an enemy, they will immediately return to being an enemy once the charm has ended (...unless this implementation has changed in the EEs, but I'm fairly though not absolutely certain that it has not).

    Right.

    As far as parsing my proposal, start with what I actually want to achieve:

    3 hours ago, grodrigues said:

    what matters most at the moment is whether the core idea and implementation are sound: this introduces a degree of uncertainty which I personally find good and would prevent douchebaggery as with 1-3 as they stand, trying to charm non-hostiles is essentially safe, the worst it happens is that you loose a spell slot. 

    I imagine there are several ways to go about it, but making the "best charm" = non-hostile have only a middling save, and save the best save (pun intended) for the not-so good charm = "hostile at the end" was a good compromise. In this way, there is something of a risk in the casting the spell, which I think is a Good Thing (tm). But maybe I am looking at things the wrong way and it is just better to have to unlock content safely.

  12. So let me take stock of the situation (have not yet read Bartimeus' latest post, so will not take it into account here).

    1. The charm line of spells should be changed to allow unlocking content (mostly, or all, in the BG1 portion of the saga). Several NPC's deliver special dialogue lines when charmed, so it is desirable to be able to charm the target while not turning them hostile at the end of the charm.

    2. There is, or seems to be, agreement that Charm Person and Charm Person or Animal should implement this and that Mental Domination and Domination should not. The only contention seems to be with Dire Charm. Bartimeus favored treating Dire Charm like Charm Person on grounds of consistency; I favor the contrary but I find it difficult at the moment to articulate exactly why so I am deferring the decision until I have a clearer grasp of the issues.

    3. The non-hostile charm should only work with targets that are non-hostile to begin with; to make the difference even clearer we can give a penalty to the saves for a non-hostile charm of a non-hostile target. The difference in saves, as proposed by Bartimeus is 4, so for example if the base save of the charm is at +2, trying to non-hostile charm a non-hostile target is at -2. The implementation is via Use Eff (to filter for allegiance) -> Cast Spell with the save put on the Use Eff. We will need two subspells, one with hostile charm and another with non-hostile.

    Assuming the above is a fair assessment, maybe we can do even better. Everything with hostile targets remains the same, but for non-hostile we can introduce an hostile charm (with the stronger bonus to the saves) and a non-hostile charm, the "better charm", with a save bonus between the base save and the non-hostile charm. The implementation would then change from:

    Use Eff (non-hostile, save at base - 4) -> Cast Spell (non-hostile charm)

    to:

    Use Eff (filter for non-hostile, no save) -> Cast Spell (subspell, no save)

    Subspell:
    Cast Spell (non-hostile charm, save at base - 2)
    Use Eff (block next spell by giving protection to it, save at base - 2)
    Cast Spell (hostile charm, save at base - 4)

    The exact numbers on the saves are subject to revision, what matters most at the moment is whether the core idea and implementation are sound: this introduces a degree of uncertainty which I personally find good and would prevent douchebaggery as with 1-3 as they stand, trying to charm non-hostiles is essentially safe, the worst it happens is that you loose a spell slot. But what say you? If you do agree with my tentative idea, please also provide a good blurb for the spells to have an in-game as-accurate-as-possible description as I am not very good at writing this kind of stuff.

  13. I have the feeling that what should be a simple change is getting a bit out of hand. Maybe we should resurrect subtledoctor's idea and defer the "charm neutrals" job to a dedicated spell like Friends, maybe even targetting only non-hostiles to prevent douchebaggery. The re-balancing of the charm spells (e.g. the save bonuses) could then be discussed without bringing in the complications of this particular RFC.

  14. There are several types of charm available in the IE engine. For the purposes of this RFC, the two most important are (using the IESDP terminology): neutral and hostile, the main difference between the two being that the former does not change the target's allegiance while the latter does. In practical terms, this means that if the charm is of neutral type, when it ends the victim does not see you as an enemy.

    This is important because in BG1 many dialogue lines can be unlocked only if you charm the target. Currently in SR, all the charms are of hostile type (the same as vanilla EE by the way), so if you charm the target you make the NPC hostile which is undesirable for obvious reasons. The obvious way to go about it is to change the charm type; unfortunately, there are all sorts of complications, so this RFC is to discuss these.

    1. Start with an implementation note. As I said in the preamble, at a very low level this is just changing the first parameter of the Charm opcode. But we can be a little smarter about it and if necessary, use subspells to have a charm type per allegiance (think how Otiluke's Sphere behaves differently whether the target is hostile or not).

    2. The second point is the scope of the changes. I think it is clear that Dire Charm and Domination should be left alone (charms of hostile type). To be explicit, the changes would apply to Charm Person (spwi104) and maybe Charm Person or Animal (sppr204) but not to Dire Charm (spwi316), Domination (spwi506) and Mental Domination (sppr405). However, Charm Person or Animal has double the duration of Charm Person and no save bonus, so balance considerations enter the picture when considering whether it should be hostile or neutral. From a gameplay perspective, it would be nice to use divine casters to unlock said dialogue instead of requiring mages.

    note(s):
    - in vanilla EE the two spells have the same save bonus.

    3. Given that the change is so obvious, one is rightly suspicious that changing the charm type has consequences. @subtledoctor said the following: "I still think it's worth discussing whether/how to make Charm more like a localized Friends effect, than "Domination at 1st level." I know we never found a solution that Demi liked and/or that would play nice with SCS... but I hate this spell as it exists in this engine, and I still hope to find a valid modification of it." So what are the problematic consequences of turning charm into non-hostile, or neutral, and why exactly does SCS have problems with it? Even if we go right ahead and make the changes, we should be aware of the potential pitfalls.

    note(s):
    - the ratial immunities are also implemented in a rather olf-fashioned, haphazard way. But this is just a note to self, not really part of the RFC.

  15. 10 minutes ago, subtledoctor said:

    My version de-emphasizes the damage (1D3 per 2 levels, max 5D3 - but similarly no save) and emphasizes the blindness (3 rounds). Because there are plenty of low-level damage spells, but not many blinding spells (since SR replaced Blindness). 

     

    Actually like this idea. Sticking it in my notes and will revisit later.

  16. 2 hours ago, Bartimaeus said:

    You said you were making an executive decision on the saving throw, but the contention between SD and I was not on whether it should be one saving throw type (we agreed that it should be), but what saving throw type. Which did you choose?

    Sorry, save vs. breath. Taking the interpretation that blindness is a side-effect of the fire damage.

  17. On 7/29/2021 at 9:08 AM, Daft Hunk said:

    Did you find something interesting ?

    Sorry replying only now, firefox seems to have a bug making posting in the forums impossible and I did not want to install chromium, or any other browser actually.

    To answer your question, no I have found nothing yet. The problem, if there is one with SR, is located in the patching code. I have taken up maintenance of SR for the time being, but I will only visit this bit once some other stuff is fixed.

  18. RFC: Greater Malison

    Currently, Greater Malison has this bit in the description: "Those under the influence of this spell make all their saving throws at a penalty of -2, and take an extra point of spell damage for each die rolled." The latter is implemented has a malus of -1 to luck, which is then counteracted by a bonus of +1 to thac0. The problem is that the luck opcode does much more than a malus to spell damage and thac0, so there are two options here: either add opcodes to counteract the other luck effects (this is bound to be iffy, because the luck opcode is weird) or simply do away with counteracting altogether and just impose the luck penalty. If the latter, the description must be changed by replacing the second part of the sentence with some blurb like being affected by bad luck or whatever (any help with this bit appreciated, as I am not a native English speaker).

    Subtledoctor expressed preference for the second option, and that is also my preference, so if you favor the first one state your case.

    A second issue with Greater Malison is that currently the spell does not bypass mr. My gut feeling tells me that it should; that is the second issue to be solved in this RFC.

    I also note, and as food for thought when rebalancing is revisited latter in a more extensive and systematic way, that one of the great problems with the current spell system is that save-or-else spells lose much of their usefulness in the later parts of the BG saga (roughly SoA onwards) because everyone and his dog has such low saves. So general, mid-high level spells to drop saves are welcomed.

  19. Executive decision: since, of the expressed opinions, we have 1-1, using my executive power and going for the option of only one save type. Implementation will be added to the divine level 1 fixes PR (note to self: do not git squash this one).

    As far as rebalancing the spell, I will revisit it latter, but for now my idea is that it is the blindness effect that needs toning down, not the damage. Damage is comparable to Magic Missile, but the latter has faster casting, can eat mirror images, magic damage type which is generally better, etc. Since the blindness duration is 1 round already, the only wiggle room there is is to give a bonus to the save, so my proposal is to make the save at +2.

  20. In the current SR implementation, Sunburst rolls two saves, a save vs. breath for half damage and a save vs. spells to avoid blindness. This is either a bug, and only a save vs. breath should be rolled, or it is not a bug and the documentation should reflect it (which it currently does not).

    Arguments could go either way, but I tend to favor the first option. Spells requiring two types of saves are very rare (actually, off the top of my head, I cannot remember any). The difference in functional behavior is only seen when the victim fails the save vs. breath and receives full damage, but makes the save vs. spell and is not blinded. This is bound to not happen that many times; and if it does not have a big functional impact, choosing the simplest solution makes sense. It also has the benefit of nerfing a tiny bit what is a powerful single-target damaging spell (arguably even OP, but let us leave that discussion for later). But this is hardly dispositive, so if you have a good argument for the alternate solution speak up.

  21. For the time being, I am taking up maintenance of SR. I am proceeding in a piecemeal but systematic frashion, so the first stage is applying the fixes that can be implemented by simply patching the spells that SR copies into the game folder -- this is simply due to how SR is implemented. Once that is done I will proceed to the code itself (e.g. anything that involves petrification, slowing, dispel, etc.), which will involve refactoring and making Bartimeus' job of synching SRR as easy as possible.

    The first PR is already uploaded. When I upload more PR's I will update the list below:

    Arcane spells:

     

    https://github.com/Gibberlings3/SpellRevisions/pull/41
    https://github.com/Gibberlings3/SpellRevisions/pull/47
    https://github.com/Gibberlings3/SpellRevisions/pull/49
    https://github.com/Gibberlings3/SpellRevisions/pull/51
    https://github.com/Gibberlings3/SpellRevisions/pull/53
    https://github.com/Gibberlings3/SpellRevisions/pull/56
    https://github.com/Gibberlings3/SpellRevisions/pull/58
    https://github.com/Gibberlings3/SpellRevisions/pull/61
    https://github.com/Gibberlings3/SpellRevisions/pull/63

     

    Divine Spells:

     

    https://github.com/Gibberlings3/SpellRevisions/pull/46
    https://github.com/Gibberlings3/SpellRevisions/pull/48
    https://github.com/Gibberlings3/SpellRevisions/pull/50
    https://github.com/Gibberlings3/SpellRevisions/pull/52
    https://github.com/Gibberlings3/SpellRevisions/pull/54
    https://github.com/Gibberlings3/SpellRevisions/pull/57
    https://github.com/Gibberlings3/SpellRevisions/pull/59

    They are for the most part an off-shoot of my earlier PR's and my mod spell_rev_rev so they have already had some testing and discussion. I will leave the PR's to stew for a time; if anyone is interested, by all means take a look and if you have any observations comment there. Do note that things get a bit technical and entangled with IE details and WeiDU and that many fixes, while technically correct, have but a small impact on a normal gameplay.

    Since most of the patched files are in the binary format and there is no good way to generate meaningful diffs, if people are really interested, I can even upload how these fixes are being generated -- it is just a WeiDU mod, with a few bells and whistles to partition the work in digestible chunks, correctly move files from place to place, generate some extra debugging info, etc. Any other fixes that you think should be made, holler in this thread. I stress the word "fixes"; let us leave tweaks, rebalancing, new functionality, etc. for later.

    Once I am satisfied with this first stage (and whatever other PR's appear; at the moment of writing this up, subtledoctor already submitted four), I will do a public release. In the meantime, if you are feeling adventurous, you can always git clone or download the latest version for a test run.

    There are a few fixes in which it is not clear how to proceed. For each such would-be fix I will open a new thread with an RFC. If no consensus emerges, or no one cares, I will simply make an executive decision. So if you are bothered by a petty dictator steering things with an iron fist, speak up and present an argument.

×
×
  • Create New...