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.

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.

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

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.