Jump to content

grodrigues

Members
  • Posts

    235
  • Joined

  • Last visited

Everything posted by grodrigues

  1. @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.
  2. In case anyone is interested, the smallest test case I could get is in this GitHub repository.
  3. 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).
  4. 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?
  5. 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.
  6. 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.
  7. @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.
  8. @khelban12 PR opened at https://github.com/Gibberlings3/SpellRevisions/pull/126
  9. 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.
  10. @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.
  11. @Endarire Thanks. Patch submitted (also corrected other instances of the same mistake).
  12. @subtledoctor In response to my request for writing fool-proof instructions on using a source release that does not ship with an executable.
  13. @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.
  14. 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.
  15. This would also block incoming imprisons. What does work is adding a custom sectype and then use Remove Sectype [221].
  16. 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
  17. 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".
  18. 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.
  19. 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.
  20. Missed this: My "agree to disagree" reply was just for the "immersion" part. Compatibility is of course a problem.
  21. 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.
  22. Yeah, SR just straight overrides hidespl to hide the spells it deprecates and/or moves to some other level. Bad boy. 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? This one, we will have to disagree on. Yes, that is also my explicit recommendation in the SR frontpage readme (which reminds me: fix the markdown footnotes). Patches are always welcomed.
  23. Fixed already in master. Yes, the spell is bugged in 4.18 as it misses the 2da file. Already fixed in master. Edit: I have the clear memory of this file missing the 2da table for spell selection (which would also explain the symptoms you are seeing), but crawling through the git history tells me that the file was there all along, so maybe the problem was somewhere else. At any rate, fixed in master. Try to drop the attached file in your override folder to see if it solves the problem (if it overwrites something, then the problem is somewhere else). Anyone reading this, should hop to the SpellRevisions GitHub and download the most recent 4.19rc3 where these and many other bugs are fixed. DVWI426.2DA
  24. Yup, that is what I would like. I was hoping there was some entry in some ids to match against and only against trueclass paladins that I had missed, but apparently not. Thanks anyway.
  25. For the purposes of using the Restrict Item [319] opcode, how can we match trueclass paladins? The IESDEP says class PALADIN matches all paladins, kits included, so this does not work. The question comes about because I am trying to make a Blackguard-usable but other-paladins-unusable item, and cannot use filtering by alignment as other classes may use it as well. Thanks in advance.
×
×
  • Create New...