Jump to content

grodrigues

Members
  • Content Count

    91
  • Joined

  • Last visited

About grodrigues

Recent Profile Visitors

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

  1. 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).
  2. 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.
  3. 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.
  4. In SR(R), the level 3 Storm Shield spell (druid/shaman only) also protects against insects.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Made some mistakes with git, but they are solved now. Second PR in.
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...