Jump to content

DavidW

Gibberlings
  • Content Count

    6,128
  • Joined

  • Last visited

Posts posted by DavidW

  1. 21 minutes ago, Jarno Mikkola said:

    Really ? Have you given any thought to it being probably because this is non intended to be used in WeiDU

    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. 

    24 minutes ago, Jarno Mikkola said:

    As the variables are meant to be cleansed between mod installs, there's no reason WeiDU should read any of the previous mods install info, when you could just reguire a marker files existance in their own mod folder or similar things and be ok with them.

    That isn't true. WEIDU has to parse the tra files of previous mods in order to read the names of components.

  2. @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.

  3. 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.)

  4. I agree with @subtledoctor that this is clearly an SCS problem. No, SR shouldn't be using a hardcoded non-prefix-guarded name for a resource, and yes, changing that might help to some extent, but ultimately, if my code is mangling a spell's name string then it's not working correctly, and needs fixing on my side. (I just haven't had a chance to sort it out.)

    19 hours ago, subtledoctor said:

    But really, SR - and every mod - should be using a unique modder prefix for every file it adds to the game... even, probably, for icons to be used in SPPR___ files.  Even, probably, for files that are native to a different game like IWD

    FWIW I don't (quite) agree with this. I think of the IWD/BG/BG2 namespace as basically shared - mod files should avoid overlapping any of it (prefixes basically achieve this) but it's okay to move resources between them (unless there's actually namespace conflict). Otherwise you end up with a huge amount of unnecessary (and bug-inducing) work in doing resource transfer between games. I also think it's fine to follow BG2 naming conventions for child resources (SPWI315c.bam for SPWI315.spl's bam, SPWI315b.spl for SPWI315.spl's secondary spell, etc), provided you do it dynamically. The point of these naming rules is to avoid namespace conflict: if all resources either use modder prefixes, or dynamically conform to the rules, there's no problem*. (I think the SR problem is being caused because it's using a static name for a resource without a modder prefix.)

    *Well, provided you don't get namespace conflict within a single modder's files, something I'm getting increasingly worried about for my own mods...

  5. 2 hours ago, jastey said:

    There is no central registration for EET Worldmap locations.

    And there can't be, really. Prefixes are invisible in-game, there's no good reason not to avoid duplication. But if two people want to put an area at the same point in the worldmap, they might both have valid artistic reasons to do so. Of course it's courteous to avoid clashes if you can do so without meaningfully harming your mod, but it can't be an absolute rule.

  6. I am skeptical that this is the underlying problem. Normally, missing language strings should be replaced by the English-language ones, not cause install failures. Something may have been broken by the most recent function update; alternatively it may be a problem with whatever autoinstaller you are using. Can someone playing in German/Polish see if the problem repeats when installing manually (i.e. not with an autoinstaller)?

  7. No.

    It's an extremely clever tool but it's clearly still a bit work-in-progress. But more importantly, there is plenty of room in the standard SPWI/SPPR space for the IWD spells, as demonstrated by the fact that IWDEE itself has them all present there. I can see that if you want to use a huge number of spell mods it would be helpful for some of them to use a tool like this, but IWDification just isn't a good choice for it. Among the reasons: you will break any extant mod that looks for the IWD spells via spell.ids (SCS, for one.) The amount of work required to fix mods to allow for that, and the number of bugs that would inevitably arise along the way, dwarf the advantages for what is a relatively edge-case scenario, especially as OlvynChuru's own mod is using this tool.

    (IWDification is more @CamDawg's baby than mine these days, but I strongly suspect I speak for him too.)

  8. On 10/23/2020 at 2:13 AM, Jarno Mikkola said:

    So if we take a book from it's natural cover, if a monster is not a warrior, they should then get the Thac0 progression of a cleric in respect to their level rather than a fighters... so, is this so ? No. Same thing with most monster hit points being a d8 rather than d10.

    Second edition AD&D fairly consistently assumes that monsters have d8 hit dice and fighter THAC0s, and BG is pretty faithful to that. SCS follows their lead.

     

    On 10/23/2020 at 2:13 AM, Jarno Mikkola said:

    And why you do not ? You don't read the Thac0 table, you just assume the value, buy calculating it from the creatures level(upto 21 from what I can tell).

    I read the THAC0 table for anything with a PC character class. If it's a monster, it gets a hand-calculated THAC0. (Even if the player is using their own THAC0 chart, I've no way to tell if they want it to apply to monsters.) What makes you think I don't?

     

    On 10/23/2020 at 4:56 AM, Valdygar said:

    But isn't the tolerance check made on the difference between 'possible' and 'current' regardless of whether or not that difference is positive (ruleset thac0 is higher) or negative (current thac0 is higher)? In that case, wouldn't that mean that this thac0 adjustment could not just worsen thac0 that are a bit too good, but also improve thac0 that are a bit too bad?

    Yes. That's intentional, though I agree that the readme doesn't make that obvious.

  9. 8 hours ago, Valdygar said:

    Is it supposed to only affect NPCs and not player characters, not matter its value?

    I don't *think* it applies to PCs but I'm not sure. (But PCs really should be conforming to the rules here in any case.)

     

    8 hours ago, Valdygar said:

    Do we have a rough idea of how many creatures are affected with the base value (6)?

    No.

    8 hours ago, Valdygar said:

    Is it a couple of edge cases, or does it actually correct a large number of creatures?

    It's a fairly respectable number. (The reason for doing it is that vanilla BG/BG2 uses ad hoc THAC0 modifiers to make various creatures more powerful, in lieu of actually giving them their bonuses from weapon specialisation etc. Since SCS enforces the latter, there's a danger of overdoing it unless the ad hoc modifiers are reined back.)

     

    8 hours ago, Valdygar said:

    Does this mean that whenever this part of the code is evaluated, "current" is always a better thac0 than "possible"

    'current' is the actually-possessed value. 'possible' is the value calculated from the creature's level according to AD&D rules. So if it always reverts to 'current' that means it never changes.

×
×
  • Create New...