Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by subtledoctor

  1. But does that exist in BGEE, SoD, bg2EE, and IWDEE? And on the iOS/Android editions? (I assume voicepacks are sold separately there...?) If there's no harm in setting bit9 and bit10 on EEv2.5, I'll just use a general GAME_IS check.
  2. just laughed so hard I spit water out my nose
  3. An idea I just had, maybe for my own other mod: maybe make Dispel Magic a mini-Breach but with a saving throw, and have Spell Deflection boost your save(s). That way Deflection grants some amount of protection even against spells that can bypass it (AoE, or whatever).
  4. Ideal: set the new text as we want it, put word out that we need some translating done, and wait to publish until the translations are done. Less ideal: just update the English version, publish, and if/when the new text gets translated then publish small point updates. Alternative less ideal: put the new English text into the other languages' .tra files. Pros: it is very easy for a translator to find what needs translating if and when someone gets around to it; and in the meantime, even if that description is in the wrong language at least it will be accurate. Con: the descriptions will be quite jarringly inconsistent for players in those languages in the meantime. Now is probably a good time to update what text needs updating (Nondetection is crying for it... it's on my to-do list) and put word out. By the time we sort through updates and pull requests and have something like 4b19 ready, maybe the translations will get done.
  5. Anyone with a connect at Beamdog know/can find out whether the 2.6 patch does/will support all iOS devices? I’m curious about the new iPad Mini, it looks super slick but I hear it has a somewhat weird resolution...
  6. I didn't explain it well. Current SR, enemy has Imp. Invis. + Stoneskin + PfMW + Deflection: cast Detect Invisibility to be able to target enemy cast Secret Word to remove Deflection kill enemy with spells OR cast Breach and then party clobbers enemy If you can cast Secret Word through Invisibility, à la SCS: cast Secret Word to remove Deflection... but note, you still cannot harm the enemy - can't target with spells (including Breach), and party can't clobber cast Detect Invisibility to target the enemy with spells kill enemy with spells OR cast Breach and then party clobbers enemy So, the order is a bit different (and in the second case, either order will work) but the overall amount of effort/time needed to make the enemy vulnerable is the same. It basically just helps the SCS AI a bit. Yes but in the case of the normal Dispel or your variant Dispel, the target is protected by either high level or good saves. AT least it's a dice roll, in any event. Whereas if Dispel becomes "Guaranteed removal of 1 or more combat protections" and it goes through spell protections, then nothing can save them. It goes back to vanilla behavior where you can remove their combat protections without heed to their spell protections, and every mage fight just becomes "Minsc clobber!" Maybe remove 1-3 combat & specific protections, but offer a saving throw?
  7. I think just giving Blindness a short duration is fine. Forcing a caster to meaningfully change/limit their spell options for 3 rounds, even if they are not totally hobbled, is a very good effect from a 1st-level spell. Ditto for applying melee penalties to warriors - I mean, compare it with Ray of Enfeeblement at 2nd level. Even with a very short duration, I'd say Blindness would still be superior. Oh hey, I missed that one too. I remember brainstorming that! But then I forgot all about it and never implemented it. I never cast Dispel Magic, basically for reasons that Lord_Tansheron mentioned. But I would probably actually use this spell. Only suggestion I have is, the vast majority of enemies don't generally have 2-3 combat protections and 2-3 specific protections. So in lots of cases, this will function like a 100% guaranteed full-power Remove Magic. For a 3rd-level spell I would probably limit it to 1 combat protection and 1 specific protection, with no scaling. Also, a balance consideration: if the player does not install "Deflection Blocks AoE," then this can bypass Deflections and the like. In which case a core design tenet of SR and SCS, to wit, that you cannot breach someone who has spell protections up, could be circumvented by this spell. If it acts like an AoE Mini-Breach, then I would probably suggest patching all spell protections to provide hard 206 protection against this. (Of course that raises the question, what good is Dispelling Screen?" To which I don't have an immediate answer. This probably needs unpacking and a lot of careful consideration. But if we could get it right, it is something I would really, really like. By a 6th-level wizard spell, or a 3rd-level priest spell? I wouldn't describe that as "readily" until we are deep into BG2 chapter 2... (unless I'm forgetting something!) I think the script/behavior that leads casters to cast Detect Invisibility/Invisibility Purge/True Seeing more or less takes care of this in most instances. No - it lets you hit invisible enemies with Secret Word to dispel their Spell Deflection, but then they are still invisible so you cannot target them with Lightning Bolt or whatever. You'll still need to make them visible to do much. I like the SR style of relying on opcode 193 from Detect Invisibility and True Sight to achieve this, but mostly for reasons of flavor and perceived consistency. In practice, enabling Secret Word et al. to target invisible mages will be a b it jarring to people like me, but it won't make much difference in terms of what you have to do in a mage duel. (Unless Breach could also target invisible enemies, in which cast it would very much change mage battles. I very much hope Breach would NOT get this flag...)
  8. Introducing my latest excellent mod, sure to strike fear into the hearts of other mods for being so unusually awesome. Herewith, behold: The BLADE of ETERNITY!! This staggering work of abject genius renames the paltry Sword of Balduran into the titular BLADE of ETERNITY! And to reflect the power and majesty of such a weapon, it modifies its enchantment value (and nothing else) from +1 to +2. Enjoy. I mean, I know you will enjoy it. It's incredible. But also please make sure this occupies its rightful place in the attention economy. Tweets, TikToks, hastags, all that stuff. Get out there and advertise!
  9. Is there any reason not to set these flags in the 2.5 engine? If we set the bit values in a 2.5 game to match the values in a 2.6 game, could it cause any problems? If so, or maybe so, then we need a way to distinguish the 2.6 engine from the 2.5 engine, in order to selectively apply these flags only on the former...
  10. Huh... just occurres to me that YARAS does not see and respect this. I can probably account for it. But it will need an opt-in list of all armors categorized as mithral. Will put it on the to-do list... Briefly, only because I clearly haven't looked into this as much as you, what is the issue here? My first thought, trailing Bartimaeus, is to simply LOAD_TRA a different .tra file according to your preferences (in an .ini setting, a subcomponent, whatever). So, questions for you off the top of my head: shouldn't that work fine for the main component? If so, then can I suppose that the problem you ran into is that a later component tries to run regexp-based replacements on the item descriptions, and fails on your modified versions? To which my first response would be, "try to leave alone the part of the description that is subject to the later regexp." But I suppose that is unacceptable because that is part of what you don't like about the IR/pre-EE description style? So the regexp itself needs to be amended? Seems... probably solvable. I'm just not entirely clear on what precisely needs solving. (I note, for instance, that the revised .tra file Bartimaeus linked to earlier does not even specify any variant AC adjustments for different damage types...) I saw no PR at the time of writing, and ended up duplicating the work myself. Oh well. Got it, thanks. I'll play around with it. If I can get it to do something useful, it might want testing from non-EE players, if any readers of this thread are of a mind. I'll post here if/when I have something ready.
  11. Whoops, also: What are you talking about?? It’s the whole reason people are on this thread right now.
  12. Not at all what I said. Staying on the example of the 2.6 update, the invisibility-breaking stuff actually does not affect anything SRR-specific at all. It affects SR - and therefore affects SRR only in a derivative sense. The fix is not complicated, and the difference in effort to apply it to one or the other repo is zero. Literally zero extra effort, to fix it for two groups of players instead of one. And yet you choose not to. That seems pathological to me. I mean admittedly I am extremely utilitarian-minded, to the point of it being a personality fault. But... it’s like the classic runaway trolley problem, but a really stupid version of the trolley problem where saving the people in front of the trolley does not involve any kind of trade-off, it’s just free. What am I missing? It's like, as I've been tinkering with the electrical systems in my home, I've been learning about how to effectively use GFCI outlets. A single GFCI outlet can provide ground-fault protection for all outlets that are "downstream" from it. You keep putting GFCI outlets in the downstream receptacle, when the same amount of work, placed in a different location, would provide twice the protection. Based on what Bartimeus said, I’m fairly convinced that a comparo between IR and IRR would not be fruitful. But I haven’t heard anyone suggest this wouldn’t be worth trying. I didn’t have time to really tinker with it, just added it to IR as a new, initial component. But running it didn’t have any effect. Does it assume SCS is present? I saw what seemed to be some undefined variables, like %data_loc% and %workspace%. Maybe I didn’t feed it a necessary variable? For clarification, I think what I would like to try is 1) generate a list of files that IR copies over (easy enough, I can do that); 2) run this function to record the cosmetic data of the unmodded versions of those files; 3) install IR; and then 4) patch the new versions of that list of files with the data from step 2.
  13. Lazy way is to choose another spell, and patch the new one into every store that already sells the existing one. Done! Globes: I didn’t expand the quote, didn’t see the third option. I thought I have four options... will check.
  14. It detects that Darkmail is +3 enchantment (from the item name) then applies the AC for chainmail (from the user-configurable .ini settings), then applies a 3-point adjustment based on the detected enchantment. Some may change, others may not... it has nothing to do with the original AC; it just applies the YARAS algorithm. Yeah, the nature of the beast is that the AC and thac0 bonuses/penalties take a second or two to work themselves out. Applying things instantaneously led to some effect not being applied consistently. I have no idea how Beamdog's weird yellow-portrait thing works, so I can't really account for it. Frankly I wish we could turn that off, I mostly just find it annoying...
  15. Why I try to focus on replacing existing spells instead of adding new ones, and making sure replacements have the same targeting and general tactical criteria as the one being replaced (e.g. Sunfire->Missile Storm). Making new spells is fun, but generally only as shiny baubles for players to have fun with, or as special kit abilities or something.
  16. Some of these look verrry interesting. Curious how “Web Slows” - I just got my version dialed in, but it took me a while to figure it out. Also “pick familiar” - I have a similar mod, but it’s 3 tweaks in one, and I’ve been thinking about trying to disentangle them. Definitely like #2, #3, #4, #7, #8, #9, #12, #13 (from the initial numbering). I think #14 and #15 should have more options. I already have code for several options for #14, could migrate that over. #15 Could have options for SR-style, vanilla-style, or with a temporary duration... I have no problem with targetable Chant, but then I have no problem with untargetable chant either. Could just expand the AoE... As for Blindness, I thought SR no longer replaces it since using ADD_SPELL? Could easily just add Obscuring Mist separately and keep Blindness... the big problem with Blindness is that it is do ridiculously OP - the only arcane counter is True Sight. I would drop the duration to like 3 rounds. Honestly, maybe even 2 rounds. It applies hefty melee penalties to warriors, and almost entirely hobbles mages. Taking a mage out of commission for 2 rounds is a fairly strong effect... The Web thing has very niche appeal. I like it, you like it, but I think the vast majority of players looove their OP Web spell.
  17. Yeah, my intent in necroing the thread was not to say "here's a version people can use instead of IRR" - it was to say "here's a version people can use instead of the official IR repo." Sure it can. As I suggested to UMNiK in that other thread (not too kindly, but whatever), I tend to operate by the "Field of Dreams" model: if you build it, they will come. I built a modified version of IR with my own fixes just for me; then I figured I would upload it and make pull requests from it, to help the main branch. Those changes are very much not coded the way Demi or Mike would code them, and so maybe those pull requests will never be accepted. But then again who knows? The stuff kreso added to SR was very much not coded the way others would have ("drunken indentation" and all that) but it got blessed, and the mod is much better for it. So I'm going to keep plugging along until Mike or someone else says "hey, stop doing that!" But this goes a bit further - my recollection is that there were particular editorial changes that you asserted were inextricably intertwined with other improvements, and that is the reason your work could not be more integrated. Generalizing, those editorial changes seem to boil down to two categories: visual changes, and mechanical changes. You know me, I don't mind the visual stuff, I would happily accept IRR's visuals if it could have maintained IR's mechanics... but Demi was not like me, he seemed to have very strong preferences about the visuals, and that is basically the last word on the subject. If you recall, and to clarify, any objections I had about your projects (proposed projects, at that time) were very specifically at their beginning, because I knew you were going to put a ton of time and work into them, and that you would be layering all that time and work over a starting product that, because of the editorial differences, could never be integrated and would be difficult to back-port. If there was ever a time to try to disentangle things, that was it. I am under no illusion and have not suggested that you should try to do so now, after having done even more work that distinguishes your versions even more from the originals. But I still don't want to just give up on the originals. So here we are, at a relative disadvantageous position, and it can't be helped. And so I need assistance. But I'm not like UMNiK, demanding some ridiculous form of delegated "collaboration." I'm out here doing this shit. I don't want anyone to do anything for me. And anything I do is always available for use and enjoyment by everyone else. But I'm also a rank amateur so I might very often need information or advice to guide what I do myself. Can you really not put yourself in someone else's shoes and see how frustrating this kind of thing is? It's clearly something that affects SR, and for sure if it is fixed in SR those fixes will immediately flow into SRR - just like every other improvement or fix we have added to SR. So you take it upon yourself to put some time into it... but you sequester that work in your own personal project, which means now I have to start from scratch and do it myself, which means ultimately we've both wasted time and effort. It's such a fucking one-way street, and for no benefit that I can see. You don't know if I'd like how you coded it because I don't know how you coded, or even that you did. Several people were discussing it and then you disappeared. (FWIW, I could care less how something is coded, as long as it works. Again kreso's stuff is an example. I don't mind if a mod ends up with a bit of mish-mash in it. Best if the code is marked as by this person or that person, but at the end of the day all I really care about is that it ends up achieving the desired in-game effect.) I was not even aware there is a problem with that component. Seems to work fine for me in my current game... Because I don't even know what all the creative decisions are, and a long time ago when I asked you not to change any of them, but to simply give me a list of them, so that I could do the work of changing them, you said you were unable to even list them. So my understanding is that it would not be easier. Even above when I had the idea to use a tool like DavidW's to read parts of the .ITM characteristics from IRR to be compatible with 1PP, while retaining the mechanical characteristics that are well-established in what people think of as "Item Revisions," you shooed me away from the idea. So my current idea is much more quixotic: add a power-user .ini option to use DavidW's tool to read the cosmetic characteristics of items as they are before IR's main component is installed; and then install IR; and then optionally patch the items' cosmetic characteristics to match the pre-existing state. To be sure, this would destroy Demi's aesthetic design decisions, so it should at best be tucked away in the settings.ini file. But, very theoretically, it could make the mod visually compatible with any underlying conditions, whether they be an EE game and any subset of 1PP installation options. It probably won't work. And Mike probably won't like it to be part of the official mod. But... maybe? If you build it, they will come. Maybe! But if you don't build it, they definitely won't come (as UMNiK demonstrates).
  18. More relevant question: I have used this in one of my mods where I needed to ALTER_EFFECT something to a negative value. Works great - thank you! But I am a bit worried about dropping this in /lib/ and INCLUDEing it; I have a zillion other instances where I use the traditional *_EFFECT functions, and if they suddenly switch to using this version, with arguments assuming the old version, I don't want something to go astray. My current solution is to simply rename these enhanced functions to ALTER_EFFECT_DW, CLONE_EFFECT_DW, etc. Works like a charm* and has the side-effect of clearly showing where credit for the work goes. But maybe I am being too cautious? Should I just suck it up and completely overwrite the original Weidu functions with these? What worked on the old ones will work on the new ones? ... * (Wait, do charms actually work??)
  19. Eh, I rather think it is nonsense to ask mods that are not being maintained to add compatibility for mods that are being maintained. Install order is meaningless in this case. Uh, if you are referring to this current thread and Then, uh, nobody prodded you. I necro'd a years-old thread for the sole purpose of giving a link to some bug-fixes, and then you jumped in and started talking about 1PP and posting visual comparisons and shit. In no way did I invite "this particular discussion." That said, as long as IR-1PP compatibility is perceived as an issue that needs to be solved (and it is), this discussion will keep happening regardless of what we want. I agree with you in that I would prefer this discussion go away; I think that taking a stab at fixing the problem might be an expedient way to make that happen. I did not say anything like that...? I mean, go read your SRR and IRR threads - I have often participated there, constructively, because I think the discussion of changes is relevant and interesting and can inspire good ideas. And you have good ideas! Not sure where you get the idea that differences of opinion about install methods equals "they shouldn't exist." I have also offered advice and code to help you with them... why would I do that if I wanted them to not exist? I don't want these mods to be gimped. More, I don't want them to be perceived to be gimped. And I think there is some of that perception, and you have a habit of contributing to it. If IR has bugs or problems, I would like to see them fixed, not crow about it. I am not maintaining it, I am just a fan who can contribute some very limited amount of time and expertise (if you can call it that) to tune up the mod and solve some perceived problems. If Cahir thinks the item descriptions are a problem because they were written before the currently-most-popular version of the games were released, maybe I can help solve that! You and others often loudly complain that IR's use of 1PP resources and interaction with 1PP is a BIG PROBLEM. And frankly I credit that, because I have seen similar posts going back five, seven, ten years saying the same thing, even from Demi himself, back when 1PPv3 was released. And since the EE games incorporated some of 1PPv3, that problem is worse now because it affects even non-1PP games. And so I would like to see that problem solved, and help if I can. Get the chip off your shoulder, stop assuming I am unreasonably hostile, and read this fucking thread again. Everything I have posted comes from a place of humility, has been me seeking guidance from people like you and DavidW who have greater knowledge and understanding than I do. What I want, the end goal I would love to see, is a pristine, problem-free version of IRv4 that can be an official release, which does not have these 1PP-derived problems on the EE games, and is in very good condition... and next to it, IRR, similarly problem-free and tailored to your liking - icons, colors, stats, whatever. It's all good. To that end, Thanks, that is good to know. In that case this makes perfect sense: I was going to write something myself, and needed guidance on what aspects of the .ITM files I should target. But in the meantime DavidW posted that and while I haven't looked at it yet, I have no doubt anything he writes in his sleep will be more effective and comprehensive than what I could do. I'll check it out. (I don't suppose this would be a real fix; regardless of the incorporation of 1PP resources, I assume that like you, Demi made a number of editorial choices that differ from what is in the EE games. So this would probably not be a path to a "fixed" version of IR on the EEs... maybe that ship really has sailed. But maybe it is enough to add an optional component (or .ini setting) for players who prefer things to be in that mode.)
  20. Okay so here's what I think we could do. Probably. I'm not exactly sure what you mean by this. But if you meant something like, you can rewrite /item_rev/languages/%lang%/ITEM_DESCRIPTIONS.TRA to better accord with the EE description style, and call the new version of the file "ITEM_DESCRIPTIONS_EE.TRA" (or whatever), then I think we can add an .ini option to let power users like yourself choose those descriptions at install time. I think this would not be against the spirit of the base mod, since the original descriptions would be default behavior. I could certainly add it to my fork to test it out.
  21. It takes the description as it finds it. Pretty much every armor in the game from any source has a line that looks like "Armor Class: ..." and YARAS grabs that and changes it into 3 or 5 or 7 lines. (It can recognize that "Armor Class" line from about 8 languages... but can only replace it with either English or Polish.) Everything before and after that line is completely unchanged. This means with mod-added items, descriptions can be verrrrry uneven. The "STATISTICS" and "Equipped Abilities" lines, and the lines about weight tend to be very different from different sources. YARAS only ensures that the YARAS stat lines (AC, DR, DEX, weapon speed, casting speed, casting failure, and thief skills) are consistent.
  22. Sure, if any bugs are identified and I have the chance to fix them. These changes also have pull requests in to the main branch (except perhaps the most recent one... have to check) so this is not meant to be a standalone version, but just a way for players to get bugfixes that would be easier than, say, installing base IR plus a bunch of hotfixes. My intent here is that, at some point my fork will become obsolete and will go away. In the meantime, though, maybe we can use it as a place to test some experimental stuff. Like... Uh... possibly? Like I say I have never really gotten into the guts of IR's code. Glancing at it, it seems fairly complicated. Not SCS-complicated, but more complicated than most of my mods. But I have an idea of how we could maybe achieve what you want. I'll look into it and report back.
  23. To expand, here is the unmodded BG2EE description for CHAN09.ITM, "Darkmail +3:" Here is the same with YARAS: Now here is the same item with IR installed: Finally, IR + YARAS: So, if I understand your concern, I think that YARAS will not solve it. It inserts itself into the item description but otherwise leaves the description with the same style it already had. If you don't like the IR-style item descriptions, then it must be solved on the IR end. (And, maybe it can be! I'll respond further in that other thread.)
  • Create New...