grodrigues

In SR(R), the level 3 Storm Shield spell (druid/shaman only) also protects against insects.

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.

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.

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.

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.

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.

Weidu already has a semblance of "before" and "after" commands: REQUIRE_COMPONENT tells Weidu that a certain mod component must already be installed, so it acts like after, and FORBID_COMPONENT that tells Weidu that a certain mod component cannot be installed, so it works like before. Using MOD_IS_INSTALLED you can wrap these checks in ACTION_IF without necessarily halting the install. Of course, either the modder must do the work, or something like BWP Fixpack patching must be done to patch the source. Or some weidu mod must be coded that orchestrates the install order. The problems remain much the same, it is just the case that a tool is already in place.

Two more questions. - Miscast Magic: the cast spell opcode has dispel/resist 1 and a save: just in case I am misreading the docs, this means that a successfull save or mr *will* block the subsequent effects and that that is the intended effect. - Vampiric Touch: has resist dispel 1 on the damage opcode and 3 on the healing opcode. Two options now: (1) if mr on the target blocks the healing opcode, all is fine and dandy (2) if not, then it could happen that the damage opcode is blocked by mr and the caster gets healed anyway. In this is a real option, then I suggest to change the resist/dispel of the damage opcode to 3 and mention that the spell bypasses mr in the docs. The same problem with Larloch's Drain.

Made some mistakes with git, but they are solved now. Second PR in.

Yeah, SR does not touch Wraith Form so dropping it. Two more questions before I submit the next PR. First, the spells Resist Fear and Protection from Petrification have Modify Script State [282] opcodes, in the first case for state find trap bonus, in the second for the state lock pick bonus. Maybe this is NI, but are these opcodes doing any work or are they spurious -- can be deleted? Second, the spell Sunscorch has two saves, a vs. breath to halve the damage, and a vs. spell to avoid blindness. If this is not a mistake, I suggest making it explicit in the description, e.g. "In addition to sustaining damage, victims who fail their saves are blinded for 1 round." -> "In addition to sustaining damage, victims who fail their saves vs. spell are blinded for 1 round.", which I will implement if everyone is ok with it.

On the two fronts: pushing fixes to SR and concocting a version of SRR plus some changes of my own devising -- but on the grand scheme of things it will be mostly SRR. But the two are completely separate.No ETA on this though, I have barely begun to scratch the surface. Also, and just in case you are wondering, no use asking for options for this or that, at least not now. And even if I do release a public version (after asking permissions) I tend to be a dictator, and not quite a benevolent one.

Duh, now I feel stupid. Just a couple of days ago was reading about the fork and pull workflow here and then forgot all about it. Anyway, thanks for everything. PR is in. By the way, on GitHub I use the nick lambda-dom. Why I chose a nick instead of going by my name (or more correctly, a contraction of my name, G. Rodrigues) I no longer remember. It was probably a very stupid reason.

Sorry to bother, but I am stumped. No matter, what I try (pushing via https over the command line, using GitHub addon on vscode, using ssh with gitkraken) I cannot push my local branch, I am always denied access. My understanding was that the G3 repo's are public. Is some kind of permission needed? If not, there is something messed up with my git setup, or my credentials that I have to sort through.

Three more notes: Checked the ranges of other shield-retaliating spells (Mestil's Acid Shield, Aura of Flaming Death, the remains of Cold Shield) and they all have range 6 so dropping the proposed fix. Also checked other cloud spells that impose movement rate penalties (Grease, Stinking Cloud, Web). The duration is 7 -- why not 6 I do not know, since the opcodes fire once a round as many times as the repetitions in the projectile, and that is a question I submit to anyone reading this -- but at any rate the 24 in Ice Storm seems a clear mistake so the fix will be in, but I will use duration 7 instead of 6 to conform with the other area spells. As far as scaling goes, the cases I caught (Wraith Form, MGoI, Greater Malison), all had to do with scaling duration not scaling of effects, so my inclination is to follow the docs. At any rate, I will leave that to a second batch of changes (the first should go in in a couple of days, mostly easily fixable low hanging fruit).

Ok. Will go the branch way; not too savvy with git but I *think* I can handle it.

Just the ones I caught: Wraith Form, MGoI, Greater Malison. I do not have a preference either way, as in here I am just concerned with fixes. If I want to change the behavior I imlement it in my own copy of SR tweaks. Heh, gonna have to read that description a second time... Oh me neither, I cannot even remember why I poked in there. But SRR makes them the same, and in all cases I have seen they are the same, and since I am already fixing things anyway... Then this is the real question, because I assumed it did not. Glad I asked. Again, glad I asked. Then I better ask another question, just to make sure I did not made a mistake: in Ice Storm I am altering the duration of the movement rate penalty opcode 24 -> 6 because it is my understanding that, given the projectile, the opcode is applied once a round. Am I wrong in my reasoning?

Here are some questions related to particular fixes. All of these were dealt with in a previous post of mine but no definite answer was given: - Scaling: the biggest one. Several spells are documented as having a scaling but in the implementation they do not. What is wrong, the docs, the implementations, depends on the case? Assuming it is the implementation how should I go about fixing it? I suggest this. Suppose the spell has level l, and that the first l level spell is gained at character level c. Then change the first header to min level 1 but with scaling corresponding to character level c - 1 then add headers starting at c until the level cap 20. - Glitterdust: Has protection against non-existent SPPR114F. Delete opcode? If not, what is the fix? - Spell Thrust: trigger and explosion radius of projectile dvsplthr.pro do not coincide. Fix? And what is the radius to use? - Fire Shield: The range of the spell retaliating with fire damage is 6 instead of documented 5. Fix or is +1 accounting for some engine quirk? - Secret Word: says it dispels Dispelling Screen. Are the docs correct, as in it is intended as such? And if so, then the implementation seems incorrect as it lacks the proper remove sectype opcode for k1-dispel (or whatever its exact name is). How to add it, since the implementations relies on casting auxiliary spells and so it it is bound to affect other spell protection removal spells? - Greater Malison: The "take an extra point of spell damage for each die rolled" is implemented as a -1 penalty to luck and +1 to thac0 (??). This is clearly not correct, but what is the exact fix?

Ok, I have cloned the SR repo and am ready to start pushing commits. I have two types of questions: (1) general GitHub and push policy questions (2) specific questions on particular bug fixes. This post is about (1) and (2) will be dealt with in a subsequent post. Sorry if some of these questions are really newbie-ish, but I have only managed a GitHub repo over my sole control, and in that case, edit-commit-push is enough. So my workflow is the following: every patch is done via WeiDU (instead of say, using NI) on the spl, eff, etc. files themselves to keep a record, in WeiDU code, of the exact changes and make it easy to change, reverse etc. The patched spells are then copied into an external folder, reviewed in NI to check everything is fine, and then copied into my local branch. Since I do not wish to delve into SR code, this leads to the first question: (1) Should I patch the spl (eff, etc.) files from a working installation or from the mod folder (e.g. from my local branch)? If the first option, can I go with my present install: SR on top of a medium stack of mods -- in the middle of setting up a full install -- with biffing on the end or should I trim the install to say, ToBEx, bg2fixpack and SR? If the second option, is not there a risk that any subsequent patching done by SR destroys my fixes? (2) What is the exact policy to submit changes? How do you guys do it? Create a new local branch for each batch of changes, make the changes to the branch, push the branch (after rebasing master into local branch), and when changes are accepted delete the local branch? Thanks in advance for any help.

My project is to implement some of the SRR changes and then some on top of SR, by patching (not via NI or dltcep) -- because it is actually easier in most cases. But this is a long term project, which given how life rolls, will probably fizzle out. To give you an idea, I have gone over about 30 spells and have not gone past wizard level 4. All this convoluted, and probably unncessary explanation, to say that no, I do not intend to add such an option. I can tell you how to do it yourself though, as it is pretty easy.

From my post to argent77: "Thanks argent77. " But enough with this useless banter. Next time I pose a question I will try to add as much context as relevant and not respond in a snarky tone to an attempt at being helpful.

Fair enough.

I still maintain that there was nothing unclear or any missing context for the question I posed: how to get the value of a variable if you have its name stored in another variable. Whether or not whatever it is I am trying to accomplish with such an extra level of indirection can be accomplished through other, simpler, more robust means is another question altogether -- a genuine one, I will grant Jarno and you that.

Ha ha. Thanks argent77.

@Jarno Mikkola What you ask is either irrelevant, or I am quite aware of, for my question, but just to humor you: this is in the context of patching a spell. I am adding a projectile via ADD_PROJECTILE except the projectile name is gotten from a variable with value read from a 2da file at mod install time. According to the docs the projectile id is then written to a variable with the *name of the projectile*, so it follows that I got the name of the variable already, but I need to get at its value to write it in the spell. Now that I think of it, I suppose I could open projectile.ids (or whatever it is called) and just look up the id there since I already have the projectile's name, but my question still stands because there were other times where this extra level of indirection would have been helpful -- of course, there is always the chance that I do not know enough WeiDU, or have not structured my code well enough, to not have to resort to such black magic. But coming from languages such as Python or Haskell where such black magic is as easy as pie, that is how I tend to think.

If you have a variable1 with the *name* of a variable2, is there a way to get the value of variable2? For the sake of illustration, assume //var2 is itself the name of a variable. SET var1 = ~var2~ How to get at the value of var2? I assume i have to expand var1, surround it with %'s then expand that, but whatever I tried it did not work -- I suspect I am doing the insertion of %'s wrong.Thanks in advance.