Jump to content

SCS AI and SR


DavidW

Recommended Posts

Demivrgvs concept behind the revised Glitterdust is, for me, excellent and I would not like to see it changed because of compatibility problems with AI mods unless they are directly linked to SCS'/RR's AI and prove to be really insurmountable.

 

Erm, David and I have already noted that this will break the scripts of all opponents in our mods who use invisibility. To work around it, we'd likely have to make a brand new DS state solely for Glitterdust which is not an easy or a particularly desirable thing.

Link to comment
(well, obviously I can't do nothing to make spells like Know Alignment powerful! :laugh: ).
Ahh, but... you can, if you know how to do it! By making it to have a moral bonus on the user for a short while after, when attacking the opposite alignments, and penalty when attacking it's own.

The moral bonus is the same used with drunken chars, though they have luck penalty's... This suggestion made though I don't actually know what the moral bonus does to the basic rules... :)

 

Glitterdust
Well, I would make it to dispel the invisibility without a save. +
mages and thieves who try to go invisible won't be able to, but they can't tell that.
But could the mages and thieves make a saving throw against the effect -every time they try to use invisibility(spell or potion)...

To implement this, an change would need to be made to the invisibility spells... but that's why this is a Spell Revisions Mod. :laugh:

 

So the invisibility spells make a saving throw against the Glitterdust effect(save vs. spell +/- X) if it's on the char, but for it to actually apply, the mage or thief needs to be out of the effected zone, or else he becomes visible cause of the dust.

Link to comment
Erm, David and I have already noted that this will break the scripts of all opponents in our mods who use invisibility. To work around it, we'd likely have to make a brand new DS state solely for Glitterdust which is not an easy or a particularly desirable thing.
I'd like to hear DavidW on the matter, maybe it's not something too easy or desiderable, but it would be great imo. Maybe we can have the spell set something detectable via "modify proficiency" or similar expedients. :)

 

Glitterdust: Just to note that it was already a very powerful spell in vanilla BG, cause the blind effect is devastating (ie: -4 penalty to saves, thaco, AC, and only 2' see radious which is actually the most serious AI scripting implication due to the IE limitations), so, i would actually worth consider implement the invisibility things (taking care of the AI, of course), but discard the blind effect or make it less likely to trigger (let's say +3 or +4 bonus to successfully pass the save)
Something most players (and modders too) seem to ignore is that in spite of vanilla's descriptions "blindness" opcode doesn't cause -4 to thac0 and AC but instead -10 to thac0 (unfortunately, as aVENGER discovered, it's even a -10 cumulative with multiple blindness! :laugh: ), and I'm quite sure Glitterdust, or any other blinding spell, never caused -4 to saves. Anyway, vanilla's Glitterdust was particularly effective because it had a 30'radius instead of PnP's 10'radius, making it a mass disabling, party friendly, low level spell.

 

If you change Greater Malison to cause a -2 save penalty instead of -4, you will have to adapt most of the save related spells to the tactical consequences. Think twice. What is your goal with this modification? A general plan behind the ideas would come in handy. I strongly suggest to make some important global decisions before go further.
If you notice the discussion I had with DavidW, this modification seems desiderable exactly looking at its impact on the general gameplay, as it aims to reduce an excessive effectiveness of Greater Malison and tactics related to it. The examples I provided in the previous posts prove that PnP Malison is already a very powerful spell, and still the best choice to improve all the other save-or-else spells, and tactics related to them.
Link to comment
The examples I provided in the previous posts prove that PnP Malison is already a very powerful spell, and still the best choice to improve all the other save-or-else spells, and tactics related to them.
But you might be forgetting one thing, that the enemies mostly have 10+/-3 general saving throws(in BG2:SoA, never mind the ToB), meaning that you can't actually disable them even with the -4 Malison's help, as generally you have to enmass the weaker disabling spells to get any effect out from them, yes the 5 webs do hold one vampire, but you need the 5 mages to cast them. :) Or you have to use cheese... :laugh:
Link to comment
But you might be forgetting one thing, that the enemies mostly have 10+/-3 general saving throws(in BG2:SoA, never mind the ToB), meaning that you can't actually disable them even with the -4 Malison's help, as generally you have to enmass the weaker disabling spells to get any effect out from them, yes the 5 webs do hold one vampire, but you need the 5 mages to cast them. :) Or you have to use cheese... :laugh:
That's exactly the reason behind SR's new saving throw system. Most SR's save-or-else spells have better save penalties, as now save penalties are tied to the spell level (e.g. all 3rd level spells have -2 penalties, all 7th-8th-9th level spells have -6 penalty!). I've tested it quite a lot, and it seems pretty balanced at the moment, time will say if some refinements are needed.
Link to comment
But you might be forgetting one thing, that the enemies mostly have 10+/-3 general saving throws(in BG2:SoA, never mind the ToB), meaning that you can't actually disable them even with the -4 Malison's help, as generally you have to enmass the weaker disabling spells to get any effect out from them, yes the 5 webs do hold one vampire, but you need the 5 mages to cast them. :) Or you have to use cheese... :laugh:
That's exactly the reason behind SR's new saving throw system. Most SR's save-or-else spells have better save penalties, as now save penalties are tied to the spell level (e.g. all 3rd level spells have -2 penalties, all 7th-8th-9th level spells have -6 penalty!). I've tested it quite a lot, and it seems pretty balanced at the moment, time will say if some refinements are needed.

 

So, if i understand you correctly, you want to:

 

1) Don't modify the average power of the spellcaster's spells, just rebalance the overpowered and underpowered ones either nerfing or boosting them.

 

2) Achieve the first tendency through the level scalable method and/or making the difference between high and low level spells more noticeable.

 

3) Make each spell equally powerful to the rest of the spells of the same level.

 

I mostly concurr, but regarding 1), i would consider downgrade spellcasters power without decrease AI effectiveness a single bit. This change would encourage players to avoid the overuse of spellcasters while forcing them to play wisely. Am i going too far, maybe?

 

That should mean to remove or make harder to launch overpowered combos, reduce some spells damage, and other spells tweaks.

Link to comment

For me it would be okay to have thieves believe that they can turn themselves invisible even after being affected by glitterdust.

 

Too bad for them, they will not be such.

 

After all, how can they tell if the Glitterdust is really revealing them to the enemy after they have drunk a potion of Invisibility or tried to hide in shadows?

 

They do turn invisible! It's the magic dust on them that does the trick.

 

So I, as player, strongly believe in the revised Glitterdust spell made by Demivrgvs. And I will not mind the AI consequences if that means only thieves acting precisely as if they were completely invisible.

 

Thanks.

Link to comment

It's possible to set local variables (and later reset them) to make spells detectable. This might sound a bit technical, but I can expalain how it is done.

 

An opcode #309 would do for setting the variable to 1, and an opcode #272 (with an opcode #146 embedded casting an external .spl) would attempt to reset the variable to zero every second. This external .spl would set the variable back to zero by casting a second external .spl, and make sure the external .spl does that with a delay of one without regard for dispelling. So far, this sounds unnecessarily complicated.

 

In the headers for the actual glitterdust .spl, you will have to place a "protection from spell" (opcode #206) that protects from the second external .spl, and make sure its duration is limited and may be dispelled. Again, unnecessarily complicated.

 

But here is the trick: This means that once that glitterdust is (successfully) dispelled or the duration expires, you are not protected any more from that second external .spl that resets the variable. And that external spell will be fired off regardless with a delay of one after the effects have disappeared.

 

Note that creatures cannot detect local variables on other creatures, but in the case of Glitterdust, it's not really necessary. You can set TRANSPARENCY to 254 or something, which is realistic.

 

The shortcoming of this happens if the .cre dies in that one second interval, and is later revived. But resetting that variable could easily be done manually.

 

IF
 Die()
THEN
 RESPONSE #100
 SetGlobal("MYVARIABLE","LOCALS",0)
// and so on for each detectable variable

 

Hopefully, this will erase the need to revamp Detectable Spells.

 

-Galactygon

Link to comment

@Demi:

 

I did reply about Glitterdust and DS, actually (higher up the thread).

 

To reiterate at greater length:

(i) if Glitterdust is not detected by the AI, this will have major tactical consequences and cause thieves and mages to behave fairly stupidly.

(ii) it would be possible to detect this via Detectable Spells, but I don't want to do this (at least with my version of it), basically because I'd like to keep the DS package fairly standard and because there's not a lot of spare space in it.

(iii) I have no idea whether Galactygon's workaround works, though it sounds as if it ought to.

(iv) Even with Glitterdust detectability, this will be a pain to allow for. There are a lot of places in scripts where creatures try to use invisibility, so writing a mod which can cope with both this being installed and this not being installed is very nontrivial. SCS's scripts are written in SSL, which is fairly flexible, so I might be able to handle it (but to be honest it's close to exceeding the amount of time/hassle I'm prepared to put into DS compatibility). Other mods don't use SSL, so they'll probably have to distribute two copies of the script. I suspect this won't be done.

(v) Over and above all this, it's difficult to allow for from a more strategic point of view, because an attack that removes the ability to become invisible (saving throw or no) is horribly effective against thieves and (many) mages.

 

@Salk:

After all, how can they tell if the Glitterdust is really revealing them to the enemy after they have drunk a potion of Invisibility or tried to hide in shadows?

 

Um... they're covered in highly visible, glittering, dust?

 

 

PS Malison: no, the calculation slip doesn't change my take on it (I only did the calculation out of mathematical curiosity). But as I said before, I don't feel that strongly about it.

Link to comment
@Salk:
After all, how can they tell if the Glitterdust is really revealing them to the enemy after they have drunk a potion of Invisibility or tried to hide in shadows?

 

Um... they're covered in highly visible, glittering, dust?

 

I think I didn't make myself clear: allowing a saving throw against Glitterdust's reveal invisibility effect simulates a borderline situation where the glittering dust over the body might or not be effective.

 

(1) the saving throw is successful: the amount of dust covering the body is so little that the creature can still be considered invisible and attack accordingly.

 

(2) the saving throw is unsuccessful: the amount of dust covering the body is enough to reveal the creature (which anyway is still invisible): the creature attacks and behaves as if in (1) because uncertain of his real level of concealment.

 

If, despite all, this can't work with AI mods then I guess there is nothing to do but drop the (very good) idea. It'd be a real shame...

Link to comment
(v) Over and above all this, it's difficult to allow for from a more strategic point of view, because an attack that removes the ability to become invisible (saving throw or no) is horribly effective against thieves and (many) mages
It last only 4 rounds, and in most situations Detect Invisibility, Invisibility Purge and True Seeing do exactly the same and more. Would it be different if I make Glitterdust "work as those spell" by having it remove invisibility each round? Wouldn't it lead to the same "stupid" behaviour of creatures turning invisible only to turn visible again one instant later? I know True Seeing is taken into account by scripts, I'm not sure about the other two spells.
Link to comment
(v) Over and above all this, it's difficult to allow for from a more strategic point of view, because an attack that removes the ability to become invisible (saving throw or no) is horribly effective against thieves and (many) mages
It last only 4 rounds, and in most situations Detect Invisibility, Invisibility Purge and True Seeing do exactly the same and more. Would it be different if I make Glitterdust "work as those spell" by having it remove invisibility each round? Wouldn't it lead to the same "stupid" behaviour of creatures turning invisible only to turn visible again one instant later? I know True Seeing is taken into account by scripts, I'm not sure about the other two spells.

 

DI and IP are one-off. True Sight is different, you're right (of course, it's sixth level!) It's allowable for by setting the stat TRUESIGHT to 1 on the caster. I don't know what other people do, but SCSII handles it mostly by mages not using invisibility if a good guy with TRUESIGHT=1 is in range, and thieves slugging the potion, trying for a very quick backstab (i.e., don't waste time looking for a target), and risking being brought out again.

 

I'm not saying don't do this; I'm saying there are major AI issues with it. Ultimately it's your call whether you think those issues are a problem or not (so Salk's arguing they're not, for instance).

Link to comment
DI and IP are one-off.
Does this mean Detect Invisibility and Invisibility Purge lead to a very similar sub-optimal behaviour? That would mean updating DS wouldn't be just for Glitterdust but for these spells too, and that SR's Glitterdust may even prove to be less problematic than these two spells (as they last twice as long).

 

I'm not saying don't do this; I'm saying there are major AI issues with it. Ultimately it's your call whether you think those issues are a problem or not (so Salk's arguing they're not, for instance).
Understood. I may reduce its impact allowing a save for now (reveal invisibility still shouldn't allow a save anyway, just the "4 rounds immunity to further invisibilities"). As soon as I come back from vacation I'll work on it again to find a hopefully better solution (maybe the one suggested by Galactygon is the right one).
Link to comment
DI and IP are one-off.
Does this mean Detect Invisibility and Invisibility Purge lead to a very similar sub-optimal behaviour? That would mean updating DS wouldn't be just for Glitterdust but for these spells too, and that SR's Glitterdust may even prove to be less problematic than these two spells (as they last twice as long).

Depends how they work, but probably.

 

Basically, the vanilla game already contains a spell - Truesight - that attaches to the caster and dispels all invisibility, once per round, on enemies of the caster. If Invisibility Purge or Detect Invisibility work like that, it's easy to allow for: you just need to add DS code to make them labelled with the TRUESIGHT label. (You'll get a few false positives - enemies erroneously not casting Mirror Image and the like - but basically it'll work fine).

 

The vanilla game doesn't have anything in it which attaches to enemies and prevents them from using invisibility magic themselves. That means there's no easy way for AI to allow for that effect. So if IP and DI work that way, then yes, the problem will generalise.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...