Jump to content


  • Content Count

  • Joined

  • Last visited

About grodrigues

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. A simple question: If I set resist_dispel to 1 (dispel/not bypass mr) on a Cast Spell opcode (146 or 148) then will mr of the target block the spell casting, and thus the application of the spell opcodes? My answer would be "why yes of course", but just want to double check with the experts around here that the engine will not double cross me if I count on this behavior. If it makes any difference, you can assume the engine is BG(2) EE.
  2. The description of Faerie Fire has the line: "Those who succeed at a saving throw vs. spell are totally unaffected by the spell. The light is too dim to have any special effect on undead or dark-dwelling creatures vulnerable to light." but the first opcode Force Visible [136] has no save and there is no Use EFF to protect undead (do not know what "dark-dwelling creatures vulnerable to light" means exactly). Am I missing something or is this indeed a bug?
  3. Was editing my post at the same time you responded, yeah I misread entry 4 and fumbled the double negation. Thanks a lot anyways, it sure opens a lot of options. At this point I just wished they had made a small DSL, say a concatenative language like Forth, possibly with no looping to avoid blowing the stack, with elementary arithmetic and some other operations to handle this kind of stuff. But beggars can't be choosers and we got to work with what we got.
  4. Ok, got it. Just to check my understanding, let us take Burning Hands. If I open NI, the creature type entry reads as "Not match entries 4 and 147" I presume these are entries in splprot.2da. So if I hunt down the 4th entry it reads as "14 100 2". 14 is lower than 0x100 so it is a stat. Hunting its value in stats.ids. we have RESISTFIRE. The value 2 means less than so *not* matching entry 4 just means if critter is immune to fire, it is immune to Burning Hands. Presumably a similar reasoning can be done for not matching entry 147. Is my understanding correct? Thanks in advance.
  5. I have just bought myself the EEs from GOG and managed to install EET on my arch linux install. Installed SR and now I have some questions about the implementation -- I have zero experience with modding EEs so most likely this all boils down to sheer ignorance. (1) A spell like Mage Armor has as first opcode a Remove Effects by Resource [321] with resource the Mage Armor spell resource. If I understand how the opcode works, this not only prevents stacking but also allows refreshing the spell before it runs out. But this is inconsistent, e.g. other buffs like Shield do not work like this. Is this a case of "We have not had the time to go through every spell and work it out" or there is some underlying reason for Mage Armor receiving this treatment and other buffs like Shield do not? (2) Magic Missile, Burning Hands, etc. have as first opcode a Immunity to Resource and Message [324] with resource the corresponding spell with duration 1. Some buffs have similar opcodes to block for 1 second some other spell (e.g. Free Action for Grease, Chaotic Commands for Charm). What is this supposed to accomplish? (3) Protection from Petrification has a Modify Script State [282] opcode with state Lockpicking Bonus [20] ?? Is this something for detectable spells? But then why is not the Set Spell State [328] opcode enough? Or maybe it is enough but the implementation has not bothered to delete the spurious opcode for the EEs? Thanks in advance.
  6. In my PR with level 6 spell fixes I have this note: Pierce Magic: aux spell display portrait icon and play sound have durations 72 -> 12. Unfortunately I have not caught any SR patching or copying, so it seems this is vanilla. I suggest then to move the fix to some component of SR. Since it is not SR that introduces the problem I have not included any fix in the PR. Maybe I should have?
  7. I know -- don't use REQUIRE_PREDICATE. Instead move everything to a (action) function that checks requirements and FAIL's if they are not met. So basically, it would mean moving from such commands as REQUIRE_PREDICATE or REQUIRE_COMPONENT to using MOD_IS_INSTALLED checks inside the function that checks requirements. And the system can of course be improved, e.g. with per component restrictions, or with special messages (e.g.an extra column with tra references).
  8. I would suggest a slightly different implementation: move the data to a .2da file with columns mod_name, component_number, install_order. The first two are self-explanatory, the last takes values 0 or 1, with 0 meaning must be installed (when the mod is installed) and 1 must not be installed (when the mod is installed). pros: - weidu can read it and it is relatively easy to weidu-code to force these requirements. cons: - mod names cannot have spaces. This could be solved with an extra layer of indirection (e.g. put a tra reference instead). - do not know how PI could handle, but I am assuming it should not be too hard. I have already implemented something like this to use on my mods; the idea is to shift as much as possible from code to data. note(s): a further con: - as far as Raduziel's idea, the problem is that the requirement is a global one, not a local one, meaning it is not enough to make the check at mod install time, but rather the check must be done every time a mod is installed after the mod with such a requirement. This implies some kind of mod coordination, which while a tool like PI can probably handle, weidu has more difficulty as it would need global mod coordination.
  9. Just as an aside, this also means that a fast levelling arcane caster is the ideal candidate for casting dispel magic. There is only one fast levelling arcane caster, and that is a bard.
  10. In SR(R), the level 3 Storm Shield spell (druid/shaman only) also protects against insects.
  11. It is late, so excuse my tiredness and going for the hardest solution first. To concatenate two strings (in a patch block say), stick them in a variable and just TEXT_SPRINT new_var ~%var1%%var2%~. As for expanding a tra reference I use the following piece of black magic stolen from IR (or SR) -- so credits to their authors: DEFINE_PATCH_FUNCTION GET_STRING_FROM_TRA_REF STR_VAR ref = "" RET str BEGIN INNER_ACTION BEGIN ACTION_IF (~%ref%~ STRING_COMPARE_REGEXP ~^[@#]-?[0-9]+$~ == 0) BEGIN <<<<<<<< .../inlined/MI_FS_%ref%.tpp OUTER_SPRINT string >>>>>>>> SILENT COPY - ~.../inlined/MI_FS_%ref%.tpp~ ~.../inlined/MI_FS_%ref%.tpp~ INSERT_BYTES SOURCE_SIZE (STRING_LENGTH ~%ref%~) WRITE_ASCIIE SOURCE_SIZE ~%ref%~ VERBOSE INCLUDE ~.../inlined/MI_FS_%ref%.tpp~ END ELSE BEGIN OUTER_SPRINT string ~*~ END END END If you have the tra reference itself in a variable, in the format say @10000, send the variable to the function preceded by EVAL (unless you have AUTO_EVAL or watcha ma call it on). I confess I really do not understand this code entirely, subtledoctor's seems to be way more manageable. The regexp part is easy, but the inlining throws me off track. Oh well, it works and that is all.
  12. Wait, there is a better solution (I knew there had to be). Check the docs on SPRINTF (if you have coded in C this should be familiar) and use "%s%s" with the two variables as arguments. Do not forget to change the tra ref into text -- the code for this is in Item Revisions somewhere. If you can't find it, I have stolen it for my mods and can put it in here.
  13. First, you have to get the text corresponding to the tra reference -- there is a piece of black magic hackery (e.g. I use, but I do not really grok it) in IR to do this. Second, you have to concatenate the two strings. You would imagine weidu had a function for this: it does not (or if it does I have not found it). You have to sum the lengths of the two strings, create a buffer of that size, then WRITE_EVALUATED_ASCII the strings into it. Not difficult but... sigh.
  14. This has already been said but it bears repeating. This not only assumes that your own vision is closer to what the original modders intended (always a hard guess), but that there is some sort of moral obligation to stay close to what allegedly the original modders intended, or to use your own phrase "for the sake of preserving the integrity of the mod". Now at this point, you could retort that if current maintainers are not willing to preserve "the integrity of the mod" why even give it the same name? Once again, this assumes that crazy-stat creatures and the implied item arms-race is integral to the mod, which is disputed. It may be integral to *your experience of the mod*, but judging by the reactions of many others, it is not to them. And at the end of the day, he who pays the piper chooses the tune. Don't like the work these people have done? Don't use it. It is not like you payed for it. Think you can do better -- whatever better means in your own judgment? Fork the repo and do the work. You can whine, moan and groan all day long, clutter the combox with your visionary ramblings, and maybe Jastey, Angel and whoever else is working on this may even pick up a thing or two (why would they is beyond me, and not because of your extremely rude behaviour, but because of the disparity of visions), but if there is no one willing to embody your vision, tough luck, all you get to do is to play the Active Complainer. Most modders, and most BG2 players I would wager, simply do not favor these old-style tactical mods anymore. Tactics-cheese-a-mole is fun for a while and then... well, pick your favorite metaphor for things turning sour.
  15. I think you are reading more into my message than I intended. I was not offering a solution to what is a genuinely complicated problem, I was just making a technical point: local ordering rules can already be implemented in weidu. Why they are not, or were not, I do not know, as I have not accompanied the modding scene too closely even though I have BG2 SoA from since it came out. And since I have not done it myself, maybe it's more trouble than it's worth? Maybe it does not solve the problems that need solving? Shrug shoulders. Don't know. The REQUIRE and FORBID commands sure. But as I said in the sequence you can use the MOD_IS_INSTALLED wrapped in ACTION_IF to impose before and after rules. What they were intended for or not is irrelevant, they can be used to give a semblance of what the poster I was answering to asked for. Now, that's something I can agree with wholeheartedly.
  • Create New...