grodrigues

@Daft Hunk Hmm, that is indeed strange as that is the version I have, the latest public release, and the one the mod targets. If you click on the code button (or do a git clone) you will get the latest version with all commits that were pushed since the latest release -- you can see their list in the commits link. The really strange thing though is the slow spell that was really borked. I would have to take a closer look to see what is going on.

@Daft Hunk - spwi312 (Slow): the spell is borked, since it misses the remove spell type protection k1#haste and the immunity from Free Action. The other (minor) alterations are not being applied for some reason I do not understand. note(s): - It could happen that your sectype file differs from mine, so I *strongly* suggest you open Near Infinity, load the spell and check that the two Remove Spell Type Protections (221) have the correct parameters: the field Spell Type should read combination and k1#haste (possibly upper-cased) for the two 221 opcodes. - spwi426 (Protection from Elemental Energy): the warning just means that the version of the spell you have is already fixed, which leads me to suspect that you do not have the latest public release of SR but the latest repo snapshot where it is indeed fixed. Harmless and nothing to do. - spwi707 (Summon Death Knight): have no idea why WeiDU is complaining. The code does not even touch this spell directly. - spwi710 (Spell Sequencer): have no idea why WeiDU is complaining. The code does not even touch this spell directly, but only the auxiliary spell "spwi710d". - spwi715 (Power Word Stun): code not deleting the undocumented one-round stun as it should. Do not understand why. Attached is fixed file -- just drop it in the override folder. Or not and go with the SR version that has the undocumented one-round stun, the difference is minor. spwi312.spl spwi715.spl

@Daft HunkNo, it should not happen. What this means is that you have a mod list different from mine, and those spells are not in the exact same state. It may be harmless, but it may be not, as the code may be intentionally relying on said state. Would you please attach your weidu.log and (copies of) those spells so I can take a look?

I am seeing some spell icons with an ugly green-ish tint in SR. Some of these seem to be fixed in the repo, but not all (Animate Skeleton Warrior, Summon Shambling Mound and a few more). I have no idea what is wrong; at any rate, the SRR icons are just fine, so can I borrow them and install them as a patch to SR?

1. and 2. done, next on the menu 3. (delaying it because there is a further fix I want to add). And contrary to what is stated above, there are some fixes, mostly fixes to my fixes.

PR merged, thanks @AL|EN Next on the menu: 1. Remove dependency on gr-lib 2. improve install instructions 3. make public release. None of this thouches the patches themselves, it is purely an internal refactoring and user-friendly improvement business.

First, apologies for the user-unfriendly release, too much of a lazy bastard (without a suit) to make a git public one. Second, thanks to Bartimeus for his explanation and correct analysis. Will improve things as soon as possible, as currently I'm having some problems on my machine preventing me taking a closer look at this. P.S.: and sure @AL|EN, will gladly accept PR's subject to the caveat above, that is, may take a bit to look at it.

The install of EET_end does not fail, but it spits this at the end: chmod: cannot access './EET/bin/unix/weidu': No such file or directory /bin/sh: line 1: ./eet/bin/unix/weidu: No such file or directory This is on linux. The error is that the weidu executable is located in the subdir x86_64; have to alter lines 701 and 702 of EET_end.tp2 to point to the correct location (or move the weidu executable).

I have used Python since the days of 2.2 and never had, or even have heard of anyone having, the problems you speak of. A Python library for modding would be so much better than WeiDU that it is not even funny. The problem is that, to even have a chance of being adopted and replace WeiDU (as opposed to being used for some one-off project or other) it would have to lure modders with 100% WeiDU compatibility (meaning it could install and uninstall WeiDU mods and WeiDU would be able to uninstall anything installed by it) and then on top offer some really, really good advantages for the non-programming savvy. It is not enough to have something that is better; it must be much better so that the effort in learning pays off. For example, I have written enough of such a library that you can write something like: for p in Path(".").glob("*.itm"): if p.is_file(): with Item.patch(p) as f: if f.type == itemtypes.longsword: f.min_strength = 10 This is, minus some details with working with in-game files that I have elided, a direct translation of the example in the READ_BYTE and PATCH_IF WeiDU tutorial. There are no offsets to remember, error checking is much stricter, you have to try *really* hard to put the item in an invalid state, etc. The syntax is sane, there are no wacky loony things like dynamic scoping to trip you up, you have actual data structures and a vast, solid library of code to reuse, etc. But is it enough? No, not really. 20 years of an established code base amounts to an awful lot of inertia.

Can confirm that the mod now installs in EET. Testing it will have to wait though. Thanks for the speedy response.

Per @AL|EN request, attached is a zip with the debug and the weidu.log file. Nothing jumps out to my untrained eye in the debug -- it seems to be a simple case of WeiDU not locating the (non-existent) file. debug-log.zip

Currently, not installable on my setup. It barfs right at the start with: Copying and patching 1 file ... ERROR: error loading [wheels/bg1_area_list.2da] Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. Stopping installation because of error. ERROR Installing [The Wheels of Prophecy], rolling back to previous state Will uninstall 1 files for [wheels/setup-wheels.tp2] component 0. Uninstalled 1 files for [wheels/setup-wheels.tp2] component 0. ERROR: Unix.Unix_error(Unix.ENOENT, "stat", "wheels/bg1_area_list.2da") Any more info needed, just ask.

Also, the change 'fixed cpmvars Beregost_House08 name', seems to clobber BGQE as now I get the following error in the Worried Farmer component: ERROR locating resource for 'COPY' Resource [%Beregost_House08%.are] not found in KEY file: [./chitin.key] Stopping installation because of error. Since the error did not happened beforehand, I am assuming this is a regression in EET and not BGQE, which is why I am posting in this thread instead of the BGQE one.

Currently getting a PARSE_ERROR in compat/bg1npc/include.tph in latest release. Inspecting the file, it seems to be malformed comments leaving a dangling END. Using // to comment out the whole block fixes the problem.

I have 2.6.6 and have not found any problems -- testing included starting games in all campaigns, and in BG, going to Nashkel and doing a reasonable amount of stuff on the way.

Just in case it matters: with the latest Master from the repo, all components that I have installed have done successfully. However, the Candlekeep component spits out this in the console: [tb#_compile_eval_buffer/weidu_external/workspace/ssl_out/mh#huecu.baf] PARSE ERROR at line 214 column 1-37 Near Text: ) [CheckSpellState] argument [PRIORITY_DISPEL] not found in [splstate.IDS] And then a few more of these -- if you need the debug file and weidu log just holler. No monster enhancement components installed, just in case this particular code was relying on it for some reason. I do not know when and if I will start a new full EET playthrough (I always seem to end up before the Sarevok final fight), but if and when I do, I will relay any bugs I found -- with the exception of Mutamin, the components listed above as not (fully) tested are installed (and I am aware this is an alpha).

My own opinion is that Imprisonment should simply be excised from the spellbooks. It is the ultimate eff you spell if used against the player and a rather cheap way to get rid of a powerful enemy, assuming it is not immune to it. As Bartimeus pointed out, there is really no good way to balance this mess.

As per the readme, EE only. I could do selective patching, but that is a very low priority. Out of lazyness, general unwillingness to set up a second install and do more testing and also because at a few points the fixing is intimately connected with taking advantage of EE, e.g. in Larloch minor drain. Maybe it could be done in classical BG, but once again, low priority.

A combination: some of those patches were dropped, some new added, etc.

I have pushed to GitHub a mod patching SR. Currently, there is no public release, so just click the Code button and download the zip if you want to give it a try. Most of the questions you would want to ask are answered in the documentation. If you want to post an issue or contribute a patch, make sure to first read the todo.md to avoid duplication of effort. Feel free to fork the repo and implement your own fixes.

It might be because originally they were indeed the same spell. But in v2, DavidW made the explicit decision to change it, because (1) he coded a component wherein the main pc regained the lost powers (2) the lost powers, for good pcs, included DuHM, so it made more sense to get as a new ToB-level power a different, beefier one.

No. Divine Gift is a maximized, non-scaling version of Draw upon Holy Might.

Since @morpheus562 original thread is marked as closed, I will comment here. He patches Ascension in two places. The patch to clone-ing Greater Malison is almost surely correct. Clone-ing the Flaming Aura however, is not. In v2.6 this is done via a Use Eff [177] opcode that calls a cast on condition opcode, so this opcode must be deleted too (or patch it to call the right resource but that is more work). Also best to remove the 321 opcode as it was added to be able to refresh spells and is not needed for a permanent spell. A third problem is that the new 232 opcode to add misses important arguments (targetting, timing, etc.) There is also another problem: the code is not deleting all headers but the first, but I do not understand why this is happening, so I am leaving it alone. Attached is a zipped file with the corrected ascension_demons.tpa. Make a diff with the original, if you fear (and you should. Cue ominous music) I may have slipped malware. ascension.zip

@morpheus562: I am seeing the same as you (presumably), as I get two warnings in the debug file: WARNING: no effects altered on SPPR730.spl WARNING: no effects added to SPWI412.spl SPPR730 is aura of flaming death and SPWI412 is greater malison. But this may well completely harmless, as the only thing that is happening is that SCS is not patching the spells.

@morpheus562Thanks for the quick patch! I took a look at the offending code and couldn't make head or tails of it -- and then I figured I was looking at the wrong area baf file... @jasteythanks for the tip.