Jump to content


Gibberling Poobah
  • Content Count

  • Joined

  • Last visited

About Mike1072

  • Birthday 04/07/1988

Profile Information

  • Gender
  • Location
  • Mods Worked On
    Item Revisions, Shadow Hand, Spell Revisions, Kit Revisions

Recent Profile Visitors

25,497 profile views
  1. Many of the changes made with standard functions could be executed more efficiently if they were done using custom patching code, especially when performing multiple alterations together. However, doing it that way requires much more effort and is more error-prone, so I would only recommend it if performance becomes a concern, or if the standard functions cannot accomplish your goal. I found a couple of my posts with custom patches and some explanations that you can take a look at here and here.
  2. I'm the author and can try to explain. It creates an inlined file with contents: OUTER_SPRINT string @1234 Then, it INCLUDEs the inlined file, which executes that code. Its purpose is to fetch the text for either a TRA ref (@1234) or a strref (#1234). You must include the @ or # symbol as part of the ref variable. WeiDU does have built-in tools that deal with fetching only TRA refs (AT) and only strrefs (GET_STRREF). Here are examples of their usage. In these cases, the ref variable should contain just a number, no symbol. SPRINT string (AT ref) GET_STRREF ref string The home for my function (named FETCH_STRING) is here. There is a companion function named RESOLVE_REF in the same file, which is what Item Revisions actually uses. It behaves similarly, taking either a TRA ref or strref, but instead of returning the associated string, it returns the associated strref. In the case of a TRA reference, this involves adding the string to dialog.tlk. This would be more useful for a situation where the .tra file contains complicated entries that need to be preserved, like associated sound effects or male & female lines for the same reference. That extra information is normally lost when putting the string into a WeiDU variable.
  3. Those last 2 columns should be strrefs according to IESDP.
  4. I wouldn't have anything against you using the current icon, if you cleared it with @bob_veng.
  5. Mike1072


    I've moved those posts into this topic to help de-confusify.
  6. You want the FnP & SR variants to co-exist? The old icon is no longer being used in SR. You could ask the original artist for permission - @DreamSlaveOne.
  7. Sounds like the discussion has run its course.
  8. For vanilla BG1 scrolls, the store in High Hedge has most of them up to level 3 and Sorcerous Sundries has most of them up to level 5 (with the selection diminishing for the higher levels). Each scroll can also usually be found in a couple of containers in the world and in the inventory of a single unique enemy mage. The level 1 through level 3 scrolls (and some level 4 ones) are present in RNDSCROL.2DA, which is referenced by the other random treasure tables and so may appear randomly as loot. The spells introduced in BG2 are rarer, with their scrolls showing up in perhaps just one or two locations in BG:EE.
  9. I'm simply maintaining SR. kreso may be more open to implementing new content, but including spells from other mods is not one of SR's goals. Firstly, SR is intended mainly as a rework of the existing spells in the game. It adds some spells where necessary to fill gaps (e.g. differentiating druids from clerics, filling out specialist spellbooks), but arbitrarily adding new spells is not the focus. Secondly, if the spells exist in working form in another mod, you can use that mod together with SR; there's nothing gained by duplicating the content within SR. If it's a matter of wanting to rebalance spells added by other mods, that won't be addressed in SR. Your best bet for that is to address it at the source, or if that proves impossible, to create a separate mod specifically for rebalancing mod content.
  10. Off-hand THAC0 bonuses and penalties have no effect unless you are dual-wielding, so it is indeed harmless to have on a two-handed weapon. It wouldn't be hard to add a two-handed check to the item patch, though.
  11. Here's a combination of my understanding of your steps 3 through 5 mixed with some suggestions. I have no experience with using these opcodes, just operating based on the descriptions in the IESDP. To add the appropriate spells, you have 7 different 326 effects, each comparing a different bit of the stat and casting a spell that adds all spells the appropriate number of times: if bit 0 of stat is set, cast spell "add1x" if bit 1 of stat is set, cast spell "add2x" if bit 2 of stat is set, cast spell "add4x" if bit 3 of stat is set, cast spell "add8x" if bit 4 of stat is set, cast spell "add16x" if bit 5 of stat is set, cast spell "add32x" if bit 6 of stat is set, cast spell "add64x" Then those spells cast subspells for each level. "add1x" casts: "addlvl1" "addlvl2" "addlvl3" "addlvl4" "addlvl5" "addlvl6" "addlvl7" "addlvl8" "addlvl9" "add2x" casts "add1x" twice "add4x" casts "add1x" four times "add8x" casts "add1x" eight times "add16x" casts "add1x" sixteen times "add32x" casts "add1x" thirty-two times "add64x" casts "add1x" sixty-four times When the player has 1 spell point remaining, you want "addlvl1" to be applied and none of the other "addlvlX" subspells, so you're trying to apply an immunity to "addlvl2", etc. It sounds like you're using the correct relation, so I don't know why that isn't working. Instead of applying immunity to those subspells, you could try changing "add1x" so it conditionally casts the subspells, using opcode 318 to only cast when the stat is greater or equal (relation 4) to the spell level. New "add1x": if stat >= 1, cast spell "addlvl1" if stat >= 2, cast spell "addlvl2" if stat >= 3, cast spell "addlvl3" if stat >= 4, cast spell "addlvl4" if stat >= 5, cast spell "addlvl5" if stat >= 6, cast spell "addlvl6" if stat >= 7, cast spell "addlvl7" if stat >= 8, cast spell "addlvl8" if stat >= 9, cast spell "addlvl9"
  12. Yes, you won't be able to push directly to a G3 repo unless you are the maintainer of the mod. Our standard practice is for contributors to create a fork of the G3 repo, push their changes to the fork, then submit them to the G3 repo via pull request. After you create your fork, you can adjust the remotes in your local repo with these commands (using the appropriate URL for your fork in the second). git remote rename origin upstream git remote add origin https://github.com/yourusername/SpellRevisions.git With these remotes, you'll be able to push to origin (your fork) and pull from upstream (the G3 repo).
  13. I'm encountering an error when trying to install iesh. I'm using Python 2.7.17 and running python ./setup.py install in the repo folder. I receive a message about a syntax error on this line. The full output is below.
  14. I commented on Faerie Fire in your original thread. This is a bug that I can fix.
  15. You should definitely apply your changes to the resource files inside the mod folder instead of the ones installed in the game. There is little chance that SR patches will override what you do, because SR doesn't really use patches that way. The patches that exist in SR mostly do things that can only be done at install-time. If you're comfortable creating separate branches for each feature as you suggest, that's absolutely the best way, because it lets us add further commits on that branch if necessary and then squash when merging. Many modders are newcomers to git, so this is not a requirement.
  • Create New...