grodrigues

Also on Arch with KDE. For WeiDU also use VS Code plus BGforge MLS. For (almost) everything else (lots of text editing as all my notes are in markdown, lots of LaTeX, Haskell, some Python, few Lua) I use a modal text editor. I have come to dislike heavy config-editors like emacs and neovim, so am using Helix right now.

16 hours ago, subtledoctor said:

Hold off for like a day on rc5 - I need to make sure I didn’t screw up the Sleep patch. (Might have forgotten about the pre-EE engine and left an EE-only opcode in it.) I’ll double-check that, and make a PR with an extra component for the saving throw tables.

Already pushed a PR for the saving throw tables, so that is covered. Will wait on you about the sleep patch.

Ha, was not aware of that. I do not have much time, but it is not difficult to segregate the copying of the tables to its own component, so if I can get around to it, and there are no objections, I can put up a patch. Was about to release rc5 after fixing the bug with find traps, but can delay it for this.

Documentation... that is a tougher one.

@Kjeron I see, it is not a bug then. It is bat-shit insane behavior, but not a bug. I will close the issue. Thanks a lot for clearing this out for me.

In case anyone is interested, the smallest test case I could get is in this GitHub repository.

8 hours ago, Magus said:

The inability to isolate it says enough.

No, it is not. But this is entirely my fault, as my question should have been clearer. I should have asked: under what possible conditions can the same string value (in this case, "lore") match against what are obviously mutually exclusive branches in the PATCH_MATCH?

At any rate, I have managed to cut down and segregate to a small-ish, self-contained mod that triggers the behavior above and I have by now a fairly good guess about what triggers it (and if my guess is right, yes, it is a bug).

In order to make it easier to patch items, I coded a function:

DEFINE_PATCH_FUNCTION set_item_field STR_VAR field = "" value = "" BEGIN
    //Lower-case field to avoid trivial mismatches.
    TO_LOWER field
    
    //Match on field to decide which write function to use.
    field_offset = $item_offsets("%field%")
    PATCH_MATCH "%field%" WITH
        "id_name"
        "name"
        "id_descr"
        "descr"
        "flags"
        "usability"
        "price"
        "weight"
        "enchantment" BEGIN
            PATCH_PRINT "set_item_field: writing long '%value%' to field '%field%' at offset '%field_offset%'."
            WRITE_LONG field_offset value
        END
        "strength_bonus"
        "intelligence"
        "constitution"
        "dexterity"
        "wisdom"
        "proficiency"
        "kit_usability1"
        "kit_usability2"
        "kit_usability3"
        "kit_usability4" BEGIN
            WRITE_BYTE field_offset value
        END
        "type"
        "level"
        "strength"
        "charisma"
        "stack"
        "lore" BEGIN
            PATCH_PRINT "set_item_field: writing short '%value%' to field '%field%' at offset '%field_offset%'."
            WRITE_SHORT field_offset value
        END
        "animation" BEGIN
            WRITE_EVALUATED_ASCII field_offset "%value%" #2
        END
        "replacement"
        "inventory_icon"
        "ground_icon"
        "description_icon" BEGIN
            WRITE_EVALUATED_ASCII field_offset "%value%" #8
        END
        DEFAULT
            PATCH_FAIL "set_item_field: field '%field%' is not a valid item field."
    END
END

The function is pretty simple: a PATCH_MATCH over the field to select the appropriate write function. Besides the arguments, the only input to the function is the array "item_offsets". The PATCH_PRINT statements were added for debugging. Now running install on a mod where this is is used, we get in the log (just looking at the relevant section):

copy_items_from_table: copying 'spell_overhaul/components/main/resources/itm/spells/ghoul_touch_a.itm' to 'override/ldwi218a.itm'.

set_item_field: writing long '13048' to field 'name' at offset '8'.

set_item_field: writing short '28' to field 'type' at offset '28'.

set_item_field: writing long '0' to field 'price' at offset '52'.

set_item_field: writing long '1' to field 'stack' at offset '56'.

set_item_field: writing short '10' to field 'lore' at offset '66'.

set_item_field: writing long '0' to field 'weight' at offset '76'.

set_item_field: writing long '1' to field 'enchantment' at offset '96'.
Copying and patching 1 file ...

copy_items_from_table: copying 'spell_overhaul/components/main/resources/itm/spells/magical_stone_a.itm' to 'override/ldpr106a.itm'.

set_item_field: writing long '12902' to field 'name' at offset '8'.

set_item_field: writing long '104228' to field 'descr' at offset '80'.

set_item_field: writing short '14' to field 'type' at offset '28'.

set_item_field: writing long '0' to field 'price' at offset '52'.

set_item_field: writing short '20' to field 'stack' at offset '56'.

set_item_field: writing long '0' to field 'lore' at offset '66'.

set_item_field: writing long '0' to field 'weight' at offset '76'.

set_item_field: writing long '1' to field 'enchantment' at offset '96'.
Copying 1 file ...

Let me home in on the two relevant lines:

set_item_field: writing short '10' to field 'lore' at offset '66'.

set_item_field: writing long '0' to field 'lore' at offset '66'.

As you can see in the second line, the `lore` field ended up in the long branch instead of the short. Note that it also happens with the stack field before lore. Writing a long instead of a short is writing to 4 bytes instead of 2, so this will clobber up the file.

I do not see any possible world in which that could happen, outside of a bug in WeiDU with PATCH_MATCH, but maybe someone is smarter than me and can see how this could possibly happen. The problem is compounded by the fact that I can only trigger this apparent bug with the somewhat complicated setup of my mod; all my efforts to narrow it down to a more manageable test case have failed, suggesting that some really weird interaction is going on.

Any suggestions?

There are no alignment restrictions on the level 3 animate dead (exact name escapes me), but there are on the level 6 one -- not for good, False Dawn not for evil.

Apologies if I am missing something, but the *balance* problem is that Conjurers (e.g. Edwin) cannot strip spell protections from mages with Invis + Non-Detection? Presumably the retort of (1) use area bombing with maybe some summons like Nishruu (or whatever is his name) that see through invis plus (2) bring along someone that can do precisely that, is not satisfying.

As concrete proposals, we have (and once again, correct me if I am wrong):

1. Allow specialists to cast spells from the opposition school of up to 3rd level. In this context, this means allowing Conjurers to cast Detect Invis.

2. Allow spell protections to pierce invis. In EE this can be done by setting the can target invis flag; on old BG2?

3. Rework non-detection to be more like the old Spell Immunity: Divination instead of what it is now (anti-invis buster). This gives Conjurers Glitterdust.

My gut feeling is that 1. and 2. are not good solutions and 3. is the best option.

@khelban12

I've fixed the path to tobexcore.ini. As far as b) as the current SR maintainer, I am a bit wary of making such corrections in SR, because they would have to be systematic, as opposed to some one-off fix.

The fix of adding the required spell.ids entries for the wild mage spells is simple and can easily be made into a mod installable before SR -- it is *not* a good idea to fold them into your copy of SR. If you need help doing it, just holler.

@khelban12

PR opened at https://github.com/Gibberlings3/SpellRevisions/pull/126

4 hours ago, khelban12 said:

When you tried to reproduce it, did you do it on tobex or EE ?

Ah, that is a difference that makes a difference.

Will only have time to go over this on the weekend, but for now let me say this:

1. Just read the weidu docs and "tobex" is indeed not a valid arg for GAME_IS, so that has to change. Will change to check for the existence of tobexcore.ini

2. to answer a) that is indeed correct. With SR, remove magic is renamed to dispel magic and dispel magic becomes AI-only.

3. your b) is more baffling, since the code is telling that the wild mage spells have different symbolic names. I am pretty sure that is not supposed to be happening... The fact that the chaos spells have "no symbol" is doubly alarming -- are they simply not in spell.ids or they literally have "no symbol" as an entry? At any rate, what I need are those symbolic names. Maybe also try

weidu --change-log "spell ref"

to rule out any possible bugs with tobex and the fixpack. "spell ref" is the resource ref for the offending wild mage spells.

I am on linux so I cannot test tobex, so it means that you will have to be a lab test rat (and whatever other metaphor is suitable) and guide me while I try to sort this out.

@khelban12

With the most recent rc4, I pre-generated a Sorc in BG2 and cannot reproduce any of the two bugs -- yes, the behavior you are witnessing should not happen -- you relate, specifically: availability of wild mage spells and two dispel magics. So, I will need some more info to diagnose this.

The most recent rc4 did re-implement the hidespl,2da stuff but it was already present and working.

@Endarire

Thanks. Patch submitted (also corrected other instances of the same mistake).

@subtledoctor

In response to my request for writing fool-proof instructions on using a source release that does not ship with an executable.

@Lianos

This is indeed a problem of not having weidu in the executable path, so what would be needed are instructions to place the executables there. And I do not have a windows install at hand to check things out... hmmm... will think about it.

1 hour ago, subtledoctor said:

No, you only protect against the subspell. Any incoming imprisonment would be cast after Freedom, and the next subspell would be cast on a 30-second delay, so the immunity would have ended. The only hiccup would be in the vanishingly small edge case where Freedom and a second Imprisonment are cast at the same time.

Ah, right, misunderstood your solution. Well patch is in and went with the sectype solution. Tested install and in NI and everything seems fine. Going to let it stew for a couple of days and then merge it.

19 hours ago, subtledoctor said:

Apply the secondary effects via a subspell, and have Freedom apply temporary (five-round) 206 vs. that subspell? 

This would also block incoming imprisons. What does work is adding a custom sectype and then use Remove Sectype [221].

Imprisonment in SR changes imprison to apply maze with a duration and adds a kill effect + freedom after 5 rounds to prevent the several downsides of imprisonment. Unfortunately, freedom now needs to be patched to remove this. In the EE's we can use 321, but on old BG what can be done? Furthermore, barbarian rage explicitly mentions protection against imprison so it must also be patched. (note: IR boots of etherealness, or whatever the hell they are called, need also to be patched). The other rages (berserk, minsc's, etc.) protect against maze, though not explicitly mentioning pro vs. imprison, must also be made to protect against it due to this change.

Is there any other change needed? PR opened at Imprisonment vs. freedom patches

note to self: unrelated, but need to patch Inquisitor's True Sight against Shadow Door aux spell that mazes. PR next to getting this one in

Patch to patch hidespl.2da is in. It ended up being a rather substantial patch; tested only install and in-game in bg2ee, not in eet, so do complain if something is not working. No tesing in iwdee, as I do not have the opportunity to test it right now and there is the question of exactly what spells to hide as well -- for now the answer is "same as in bg2ee".

On 6/12/2023 at 9:29 PM, Lianos said:

Can you please give a brief instruction how to install 4.19rc3? I'm on Windows 11. I tried to follow your instructions under README.md, but with no success.

Can you be more explicit about your difficulties? This is something so obvious, and even trivial to me, that I have a genuinely hard time gauging other people's difficulties and write up fool-proof instructions.

1 hour ago, Graion Dilach said:

I've mentioned my problem on this: If SR should be installed before quest mods, then the compat code goes to the quest mods. If SR should come after quest mods, then SR is where the compat code goes to. There's no clear guidelines on the order.

I do not if you are addressing me or subtledoctor, but if it is me, per the readme as of 4.19rc3: "SR's main component does wholesale spell replacement, so it should be installed relatively early in the install order, certainly before Tweaks Anthology and SCS. On the other hand the "Update NPC spellbooks" component should be installed after all NPC mods."

Should it be more clear? Feel free to make any suggestions, I will patch them in myself.

Any changes to the readme notwithstanding, everything I said earlier stands.

Missed this:

2 hours ago, Graion Dilach said:

Actually, even if we put my personal low opinion on the format away, we still can't. But description inconsistency within a megamod installation is just part of a bigger problem.

My "agree to disagree" reply was just for the "immersion" part. Compatibility is of course a problem.

2 hours ago, Graion Dilach said:

But the other systematic changes it does (like, for example, petrification) are undocumented. If a quest mod introduces new creature effects or spells which would interact with a system SR changed, would SR explain the modder what to do? Or whose job is to ensure compatibility for a case like this?

Agreed. The problem here is that SR does not give mods that come after it the tools to patch and adapt. The same general problem applies to IR. From the top of my head, the more important cases are:

- Insects

- Petrification

- Dispel

- Imprisonment

- Invis and True Sight interactions

- The finer points of spell protections

As the current maintainer, and someone that has tried to wade into say, the dispel code, all I can say is that this is not an easy task, at least not for me.

I opened up a branch to patch hidespl.2da instead of overriding -- see Patching hidespl.2da instead of overriding. Still in draft and not finished.

On 5/31/2023 at 5:14 PM, Graion Dilach said:

deletes and overwrites all changes in hidespl.2da (this affects SoD and the EE Fixpack, EET moves the SoD additional spells trio outside of the exposed spell slots range, so it's safe until one doesn't combine it wiith the fixpack)

Yeah, SR just straight overrides hidespl to hide the spells it deprecates and/or moves to some other level. Bad boy.

On 5/31/2023 at 5:14 PM, Graion Dilach said:

The first two are legitimate issues. I've started slowly writing tweaks to iron out the compat issues, but I'd like to see them acknowledged.

What do you mean by "waste? Do you mean a slot in the spell namespace (say "spwi") that was before used and is now not used? If so, why exactly is that a problem?

On 5/31/2023 at 5:14 PM, Graion Dilach said:

breaks immersion with the summons being statted (but this one is only cosmetics).

This one, we will have to disagree on.

On 5/31/2023 at 5:14 PM, Graion Dilach said:

Note that because of the hidespl messup, all my installs were tested with SR installed first. I also would consider SR as a pure overwrite-mod, being installed early.

Yes, that is also my explicit recommendation in the SR frontpage readme (which reminds me: fix the markdown footnotes).

On 5/31/2023 at 5:14 PM, Graion Dilach said:

I've started slowly writing tweaks to iron out the compat issues, but I'd like to see them acknowledged.

Patches are always welcomed.