grodrigues

This here is my main reason for preferring Confusion, so by the power invested in me by whomever and whatever and whenever, I am going with that. As for the other options: I confess I never use Waves of Fatigue (which is probably a good reason to revisit the spell in the first opportunity), but I do not want to hamper Avengers (trading a "non-usable spell" for another, while not a net loss is not a win either) and I find myself agreeing with Bartimeus' and liking a "returning to Avenger what is essentially the vanilla spell in the first place". Patch already submitted. This request is more of a symptom that the spells as they are still need refinement. I intensely dislike asymmetry between the player and enemy NPC's and want to keep it at a minimum, as little as the engine allows. Cone spells do present a challenge because of engine limitations, but I do not know what is the best solution -- maybe make them all party-friendly?

As I see it, there are essentially two options here: the first option is (1) to retain Cone of Cold but do the dance suggested guyudennis in the linked thread. The second option (2) is to replace CoC with something more closely resembling chaos; of your suggestions, the clear winner on this front is confusion. I can understand the rationale of giving elemental damage to Avengers, but truth be told, I have zero experience playing them, so any takes? If no clear decision either way, I will use my prerogative as Dictator-In-Office and make an executive decision. Although on the grounds of what fits the kit closest I would say (1) is probably best, Confusion is not out of place by any means and (2) is bound to be the easiest to implement and with less chances to confuse SCS so that is where my preference lies.

No, not addressed. Will take a look at it this weekend.

A. Chaos. The issue was first raised here by polytope: opcode 3 (berserk) does not work on NPC's. More precisely the IESDP notes, and I quote: So the effect is broken on the old, non-ee editions of BG (which from now on will be called oBG). In laying out the possible options, I will follow a maximally conservative approach: do the minimum changes required to make everything work, for whatever "required" is taken to mean. If you think this is a missed opportunity, and instead want to implement that awesome cool idea of yours, then this is not quite the RFC for it -- you can, and maybe even should, state your case, so that discussion can be had, but then the burden of the implementation is also on you (unless the idea is so freakin' good that I might just steal it and implement it myself. Grin). The first option is: do nothing. This opens a precedent though, a bad and dangerous one, of purposely letting oBG by the wayside. Second option is to change opcode 3 to 247. The problem, as subtledoctor mentioned, is that there is no cure 247 opcode (once again, EE has the tactical nuclear warhead of opcode 337). Doing the change only on oBG means that SR will behave differently on different platforms, which is dangerously close to just letting oBG by the wayside. A third option is to change berserk to some other effect. Bartimeus suggested feeblemind, and I concur, simply because feeblemind is a "chaotic" effect and is covered by Chaotic Commands' immunities. Of all the options this is my preferred one, and the implementation is fairly straightforward as well. And this leads to the second related issue. B. Chaotic Commands. I always thought that Chaotic Commands protected against berserk: checking it on NI, it doesn't. So the second question to settle is, should Chaotic Commands protect against berserk (and 247: attack nearest creature). My preferred option is: yes. Berserk is the very embodiment of chaotic-y! This may have unintended consequences though -- e.g. it would block things like the berserking sword in BG whose name I already forgot. I am ok with what I can glean, but maybe I am missing something. If accepted, this will be implemented in a different commit to whatever else is decided for Chaos, to keep the git commit history clean. C. Prismatic Spray. *If* we decide for option 3. then one can note that Prismatic Spray also (has a chance of) inflicts feeblemind, so for variety one might want to change it to something else as, I think, subtledoctor suggested. If one did make a change, what are the options? One obvious one would be cold damage, half on a failed save vs. breath. This would however, break the symmetry that prismatic spray exercises all saves, as feeblemind (and no other effect) checks against a save vs. rod.

FYI, subtledoctor's patch was merged about a month ago.

I have looked at the icons SCS ships (I imagine they are the same as IWDification) and I have to say I do not quite like them; for lack of a better word, they look "too clean". In particular, the Spike Growth icon does not strike me as a huge improvement (and I do not know what "consistent" means in this context). If this all sounds awfully subjective -- in the sense that it is hardly more than "not my taste" -- that is because it is, so if there is more support behind changes like these I will not oppose. It is a pity that at the moment such trivial changes cannot be done more easily by power users, but to achieve that, some larger code changes have to be put in place.

First, apologies for being MIA, for what? 5 months? New patches: - Merged: addition of a README and a new changelog. Undoubtedly the most important patch to SR since it is on GitHub. - Submitted: it is now possible to explicitly clear (that is, set to 0) the break invisibility and hostile spell flags. Still have to comb over the flags table and set sane values and then make an RFC; but honestly, not a priority. There was also the mention of changing Sphere of Chaos' berserk to feeblemind (feeblemind is a chaotic effect and therefore covered by Chaotic Commands immunities) because berserk does not work as expected for NPC's and then change Prismatic Spray's feeblemind to something more appropriate. I will have some time this week and hopefully (but no promises) can at least submit an RFC on this. Along the way I will silently bump the version to 4.19beta. Is there something else that needs fixing? Stick to fixes only, and with links to any discussions, please. I *really* *really* want to get this out. If there aren't, then I will bugger Mike to run whatever is needed to finalize the release (update the docs, run some bat files, etc. I cannot run bats because I am on linux -- at least not without a windows-linux layer, there is bound to be such a thing but I have never used it). note: duh, brain fart, it suffices to have wine installed and then simply "wine start <bat file>" and alias it in bash_aliases or something similar.

This is a well known problem. The best way is to use a case-insensitive partition. Here are my notes on the issue (just pasted, no filtering. Assumes familiarity with linux):

Install barfing in the first component installed, the wider selection of scrolls. Attached is the debug and the weidu log. stratagems.zip note: forget about it, no bug here. Found the culprit and it is not SCS.

I do not see any point in this. The spells that set stats only target strength (DuHM is self-cast and is already an increment) and that is their role. If you already have high strength use DuHM, Righteous Magic, etc. if available, or potions, items, etc. The only thing I would change in the existing set-strength spells (three if memory serves me, two of them self only) is to offset the detrimental effect of actually lowering your strength. I could see how to implement it in EE but not in the classical editions and honestly, is it even worth it? And by "worth it" I mean, given the time constraints and all the other things I would like to do.

On Firefox and I have had this problem for several weeks already. The pain, the pain, the pain....

Fixed in master already. The original spell (borne spwi426 not spwi422 -- it is added via ADD_SPELL) had the wrong table reference. The right table is also copied in tha main component (I just checked). The saves are fixed in master. The difference in opcodes 3 vs. 247 was not something I was aware; the IESDP says: "Note: At least in EEs, the only difference between opcodes #3 and #247, is that opcode #247 will not force the creature(s) to use melee weapons, and is not removed by opcode #4 (Cure Berserk)." so at least in the EEs the opcodes *seems* to work? It also seems to say that this beserker, call it berserk_2, is not cured by cure berserk. So if a change 3 -> 247 one also has to go through all the curing spells and immunities against berserk to patch in the right protections / immunities.

@Bartimaeus@subtledoctor Before discussing the table itself and whatever changes to implement (the PR was merged, a new PR will be submitted with these specific changes), note that the way the code is implemented leads to somewhat misleading conclusions when reading values off the table. The reason is that the code *only* patches the spell if it finds the flag 1 in the column. The value 0 does *not* currently mean "set the flag to 0" but rather "do nothing". In particular, currently we can only enable the flags not disable. So before discussing the table proper, should the code be changed to set the flags to the values in the column? I say yes because it is less confusing and gives more flexibility but what say you?

Let us see if we can systematize your examples into concrete principles. 1. Weapon spells should not break invisibility (Cleric Magic Stone). 2. Spells that target others and have "hostile" effects should be marked hostile and, as a rule of thumb, break invisibility (Faerie Fire, Know Opponent). 3. Summoning spells should be marked hostile. I think there is a case that can be made for animal summoning not hostile -- think about a ranger walking into a village with his animal companion. Exception for Find Familiar , which we could also tag the spell as castable only outside of combat, and arguably Wizard Eye. 4. Healing spells should not be marked hostile or break invis (Restoration, Mass Raise Dead). 5. Polymorph spells should not be marked hostile (Polymorph Self). 6. I tend to think buffs targeting self (aoe or not) should not be marked hostile. Break invisibility only if they have retaliations? If one retorts that GoI conjures a freakin' globe, my answer is that invis covers the globe as well with the in-game presentation merely an engine limitation. My biggest concern however is with the AI. 7. As a general rule, illusions should not break invisible or be hostile. Do you have a link for the Shadow Door discussion? I would argue this applies to Mislead, PI and simulacrum. 8. Sequencers and contingencies should not break invisible or be hostile. I have a tweak to toggle the flag castable only outside of combat (mainly to stop the Sorcerer + Chain contingency douchebaggery) but have to put an RFC, etc. and I want to get the public release out ASAP. 9. Wish spells break invis -- you are holding a conversation. Anything you would like to add?

@BartimaeusCould you please take a look at the break invisibility/hostile flags in the table in the PR? The choices are those @subtledoctor and he gives a rationale in the discussion with which I agree entirely, but maybe there is something that sticks out to your eyes as just plain wrong.

The best option is to use a case-insensitive partition. See https://www.gibberlings3.net/forums/topic/28516-the-linux-users-guide-to-installing-mods-on-the-enhanced-editions/

@BartimaeusNew, fixed PR is up. Tested and seems to be working now. Do note that accompanying the PR there is another PR with some more fixes, and without it, install will throw warnings -- by design.

@subtledoctorPut up a refactor of subtledoctor's pr on the break invisibility and / or hostile spell flags. The original PR is in the master branch (always make a new branch when submitting PR) and does not allow edits by the maintainers. Did some minimal testing and everything seems kosher; at any rate, check at Refactor of subtledoctor's pr

PR is up. Tested installation and spell in NI, but as always the more eyeballs on it the better.

Finally getting around this. For now will defer to using SRR version with the numbers proposed by subtledoctor; the issue is thorny and without testing we cannot go forward, so might as well release an interim version, satisfy SCS and then if something better comes along change it. The next release does not have to be perfect, it just has to be better than what we currently have. @Bartimaeuslooking at your implementation, I have some questions: You have one Use Eff [177] with Cast Spell on Condition [232] but then this is repeated as the last opcode of the main spell. Why the duplication? What am I missing? Wouldn't it be better in the subspell that delivers the effects to protect against the subspell itself and not the parent? Presumably the second Use Eff [177] is to prevent self-stacking. But then, why the extra indirection via Use Eff and not use 206 directly in the main spell? No modify proficiencies [232] opcode. Can we be sure that SCS will pick this up? Do we have to insert this opcode or something similar to instruct the AI note(s): after getting this out, and refactor-ing subtledoctor's patch, I think we are ready for a public release.

I have this vague memory that it was decided to replace con bonuses to a bonus to max hp precisely because of this exploit. Either I am remembering wrong or the replacement was not sweeping and complete.

It is Arzol (not Anzol), a bodyguard in the central arena. As soon as the meeting with the game master Dennaton is finished and you are teleported to the central square he aggros and goes after you. This should not happen and basically guarantees a game over. Only IR's main component besides some UI mods, to be precise LeUI, EEUITweaks and Hidden gameplay options. On linux, in a case-insensitive partition. More info needed, just holler.

In doing some high-level spell testing for SR, I fired up Gladiators of Thay and noticed that Anzol (or whatever the heck he is named) aggro's making the campaign unplayable. I have traced it to the main IR component; this does *not* happen if instead I use IRR. Has anyone traced this or even better, knows where exactly the problem lies?

@subtledoctorcomments on the PR are in the PR itself (having problems posting to G3).

@BartimaeusMissing AUTO_EVAL_STRINGS so as not to have to intersperse EVAL's everywhere. But if I turn it on then the main component no longer installs barfing somewhere in the code that sets spell schools. Putting the PR on draft until I go over it again.