Jump to content

DavidW

Gibberlings
  • Posts

    7,853
  • Joined

  • Last visited

Everything posted by DavidW

  1. The ini system for animations was introduced with IWDEE (to make it easier to manage the large number of new animations), and then backported to BG2 and BG2EE.
  2. Avoiding clutter, really. There's no reason to have multiple tokens. How did it get lost?
  3. Dialog: Different people have different tastes. (Some people love the dragon dialog, some don't.) If you've concrete feedback on the dialog, I'd be interested to hear it. I'm reluctant to break up the component - I wouldn't rule it out 100% but this is a niche request and every time I do this it adds install complexity and the possibility of bugs. Treasure: I'm not much moved by the lack of treasure on the dragons: they don't live there, they've just turned up to attack, why would they be carrying treasure? (There is a case for them having scales, as has been pointed out before; that might make it into v34.) Rope: I'm not thrilled with this, to be honest, and might muck with it at some point. The underlying problem is that Abazigal's lair is just not that plausible in the first instance. Yes, it's silly that CHARNAME has to go back to Amkethran for rope; is it more silly than his only being able to make progress in the first place because the monk just happens to have some rope? But it's over a decade since I coded this, and perhaps it's time to think about it some more.
  4. On the general proposal: for the most part I don't think this is realistic as stated, basically for the reasons qwerty1234567 gives. One of the key features of IE modding is that multiple mods can compatibly edit the same game files, and the better-written mods go to great lengths to try to do so. For instance, SCS modifies something like 1,000 .spl files (including pretty much every player-usable spell), 4800 .cre files, 100 .dlg files, and 160 .are files (and much more besides). But most of those modifications are minor things that should play nice with other modifications. Flagging any other mod that alters any of those files as potentially conflicting with SCS would be massive overkill and generate mostly false positives. Designing a syntax that allows more fine-grained flagging of modifications sounds an incredibly difficult task (something between 'would be a good PhD topic in CS' and 'is AI-complete'), and in any case would create a prohibitive amount of work for modders. (There is a closely-related technical issue: compatibility doesn't just depend on *what* is modified but *how* it's modified. (Ascension 1.4 and Ascension 2.0 modify very nearly the same resources relative to an unmodded install, but 1.4 does it by blanket overwrites and 2.0 is much more subtle.) And writing compatibility-friendly modification code is often hard, even with modern tools, so that different mods manage it to different degrees - and many modders are borrowing not-fully-understood code from other sources and aren't fully reliable about how compatibility-friendly their own code is.) There might be a happy medium - something fine-grained enough to be of some use but not so much so as to be unmanageable. But it's not obvious to me that it is, and in any case I think the devil would be in the details - someone would have to design it, in detail, and mark up a bunch of the big popular mods to see how well it worked in practice. (I appreciate SCS is an extreme outlier in the scope and systematicity of its editing, although Tweaks Anthology isn't so far behind.) On the specific point of the Lanthorn quest clash (I assume you mean the clash between Kish's Lanthorn component and my 'restored Lanthorn' micro-mod? - if there's a clash with Wheels of Prophecy, I'm not aware of it): Even a casual read of the two readmes should make it obvious that they clash, so I'm not sure what's to be gained by an automated system in this case. I'm strongly of the opinion that it is a very bad idea to install IE mods (or any software, really) without at least a casual look at their readmes, so I'm not keen to do anything that encourages people to do so. There's perhaps a broader point here: many mods tend to be under-documented or plain undocumented. That's understandable - modding is a hobby; writing documentation is dull; updating SCS's documentation is usually my least favorite step in a mod update. But it's a problem precisely because it makes installation and compatibility hard to judge, at least for the (I assume) majority of end-users who don't spend ages perusing the forums for the latest instructions. I'm not sure I wouldn't rather encourage people to document their mods and keep that documentation up-to-date, rather than introduce what's probably going to seem like another dull chore. (Of course I could be persuaded otherwise by a sufficiently well-designed flag system.)
  5. I've never really tried to mod the original BG1 (only its TUTU/BGT/EE conversions to the BG2 engine). I imagine you can probably move some of the resources over but I don't know what the constraints are (the BG engine is less sophisticated than the IWD one so that's likely to make it harder rather than easier).
  6. Can you give me a slightly more exact description so I can see if I can reproduce it? (It might be an issue from multiple-mod interactions but I'll see if I can reproduce it direct on SCS first.)
  7. Let me know. (And thanks for the nice words.)
  8. I never make release-date promises, sorry. Don't hold your breath, though. It requires substantial effort and has got buried under other things.
  9. Something isn't being removed. Thanks for the heads-up. Can you give me an exact reproduction scenario, so I can reproduce it locally?
  10. Noted, thanks. Neither - it's just an oversight on my part. That said, 2.6 will probably fix this at engine level. I don't think SCS messes with this.
  11. Thanks. It's not obvious to me this is SCS-specific. In-game sequencers have always been a bit glitchy. I can't offhand see a way in which changing the parent spell from Wizard to Innate would affect that. (But of course I could be wrong.)
  12. Hmmm. Any chance you chose the wrong language to play in when you originally installed the first mod in the chain? Open the file weidu.conf in notepad or similar. If you're playing in English, it should read 'lang_dir=en_us'.
  13. Skeletons and other mindless undead are usually neutral. (One could debate whether that's a good idea, but it's standard in 2nd edition AD&D and taken over into the Infinity Engine games.)
  14. I'm again moving this conversation here to avoid cluttering my main release thread.
  15. No, it's intended. (Albeit a bit edge-case). If you check the PPG WEIDU forum you'll see Wisp noting that it does need to be fixed in v248. That isn't true. WEIDU has to parse the tra files of previous mods in order to read the names of components.
  16. @Jarno Mikkola: The concern raised by pochesun was that there was a compatibility problem between SCS and Restored Lanthorn. There isn’t - that’s what I mean by ‘not an error’. Pochesun’s install will be working fine. There *is* a (rather edge-case) bug in Weidu v247 that stops it handling VERSION entries that use tra references, which v246 permits. But that doesn’t cause bugs in either mod (since Restored Lanthorn ships with WEIDU 246), nor compatibility problems between them. It will be fixed when WEIDU updates to v248 (it’s a bug in WEIDU itself, not in any mod); in the meantime I’ll probably also do an update of Restored Lanthorn to v247 when I get the chance, but it’s not really a priority.
  17. I don't think that's an actual error, it's just SCS's version of WEIDU failing to read the name of the Rhynn Lanthorn component. (To be more precise, Restored Rhynn Lanthorn uses my trick of putting a tra reference in the VERSION string. A rare failure of backward-compatibility in WEIDU v247 (which ships with the latest SCS) breaks that trick. It isn't messing with your existing install of Restored Rhynn Lanthorn, but when SCS's version of WEIDU tries to create the weidu.log, it fails to read the name of the component. I should update RRL to WEIDU 247 at some point.)
  18. According to your debug, you're still using 33.6. (Did you update from the github rather than from the official release? The former wasn't updated until more recently.)
  19. v33.7 of SCS should fix the Cure Moderate Wounds issue.
×
×
  • Create New...