Jump to content

CamDawg

Gibberling Poobah
  • Posts

    12,013
  • Joined

Posts posted by CamDawg

  1. Though it looks ugly, the multi-ADD_KITs is probably the simplest way to approach this. Unfortunately, you don't know to which column your kit gets appended in weapprof.2da (clasweap.2da is unimportant in BG2; though I have different lines for it in the tutorial it actually makes no difference at all). So you'd need to first determine the column number in clasweap.2da before you can start throwing S_2_E sequences at it. Not to say it can't be done, it was just a complication with which I didn't want to bother when I wrote the tutorial. (Now that I've mentioned it, I'm sure bigg will now add a %yourkit_weapprof_column% variable in WeiDU v211, coming out Thursday. :O )

     

    If you did determine the column, you could probably save yourself some trouble by copying the parent class' values to save yourself some logic checks--barring, of course, that your kit is supposed to have radically different profs.

  2. You can use a lot of shucking and jiving to get around these restrictions. Unfortunately it generally raises a fair number of incompatibility issues and other design tradeoffs that are suboptimal.

     

    I pioneered a lot of these tricks with SPC because I wanted to keep the kits as close to the author's original idea as possible. In general though I don't think the tradeoffs are worth it.

  3. Where is the class that the kit is a subclass of actually set? I'm sure this is somewhere obvious, however I can't seem to see it.

    The class is the second number in the unusabiity line:

    0x00000004	2

    The above is the kensai kit. The second number is from class.ids:

    1   MAGE
    2   FIGHTER
    3   CLERIC
    4   THIEF
    5   BARD
    6   PALADIN
    11  DRUID
    12  RANGER

     

    In the usability flag if I change the class to any class other than what I originally created it as (cleric as per the example) the kit stops working and becomes the default cleric class.

     

    The usability flag doesn't determine the kit; it's the cclass value, above, that does.

     

    Also, the game has it set so gnomes multi-class to a kit (illusionist instead of mage). Is this easy to set up for other classes? I want to multi-class the kit i've made but I am not sure how to go about it.

     

    Hardcoded, unfortunately. The multi-classes have little flexibility for change.

     

    Glad you found the tutorial helpful, and good luck. :)

  4. You're missing a couple of lines before the SAYS, namely the HLA table and list of ToB starting equipment.  I'm pretty sure you need these even if installing to a SoA-only game.

     

    As for a .tra, it's short for translation file.  Basically, instead of SAY ~Broken Druid~, you could have SAY #1, then in a file called NewDruid.tra, the first line would read "@1 = ~Broken Druid~" (without the quotes).  Some people find it helpful for organizational/efficiency purposes, plus it also helps anyone wanting to translate your mod.

    One correction... SAY #12345 means to use the existing strref 12345 from dialog.tlk. SAY @12345 means to use @12345 from the associated tra file (i.e. adding a new string to dialog.tlk).

     

    edit: And some crossposting. Glad to hear it worked SL, nick work NM. :p

  5. We're pleased to announce three new mini-mods as part of our 8-mod anniversary barrage.

     

    Moinesse's Avatars - v1

     

    This WeiDU mod contains a series of new avatars and paperdolls for BG2. Avatars are the graphics of your characters as they walk around the game world and paperdolls are the graphics that show on the inventory screen.

     

    Plasmocat's Portrait Pack - v1

     

    This WeiDU mod provides a wide variety of ethnic portraits for the Baldur's Gate II protagonist and also alternative portraits for 13 of the joinable NPCs.

     

    Shards of Ice - v1

     

    Icelus' little WeiDU collection of miscellany. From ice: "The two quests really aren't all that bad. Not really. Well, not too much. If you install the Summon Cow spell restoration component, however, you should be ashamed of yourself. Really."

  6. I would like to have a Bard Skald, with the ability to open locks and disable traps, dont really care about the pickpocket ability... so how would I go about doing this? is it possible?

     

    Im on the Sorcerers Place forums under the same name. :)

    The biggest issue is that the buttons on the bottom menu (spellcasting, thieving skills, etc.) are hardcoded and can not be changed. So while you could grant a bard thieving abilities, the corresponding buttons would not appear--he already has the thieving button--he could disarm traps and open locks, but there's no detect traps button. Similarly, trying to recreate a skald via a thief kit would mean no spellcasting or bardsong. There's no kittable class that has spellcasting and a full range of thieving skills. You couls write a script that would allow your character to do various actions via hotkey, but's it's probably overkill for what you're trying to do.

  7. Yeah, the variable is only set on a successful ADD_KIT--if the kit is already present then ADD_KIT never gets executed and the variable is not set. This is also potentially a problem if ADD_KIT and the assignment of the kit are in different components. If the kit is added in one component and then the user quits the variable is lost. If they then begin setup again, the value is null and you'll get the same 'variable not set' error.

     

    You should be able to check the 2das and determine the value through other means if the kit is already present.

  8. And on second thought, use REQUIRE_PREDICATE instead. REQUIRE_FILE will provide an option for non-Tutu installs, and players answering yes will get an ominous failure if they try to install it. REQUIRE_PREDICATE, OTOH, will skip the component outright if it's not Tutu making it easier for the player.

     

    REQUIRE_PREDICATE FILE_EXISTS_IN_GAME ~_sw1h04.itm~ ~~Tutu must be present. Skipping this component.~

  9. I worked out the last question, doesn't seem to have a edit botton. :)

     

    How do you add a new CLABFI01.2da for a new kit and package it into Weidu? :)

     

    The relevant bit is here:

    ~Cleric_Remix/Selune/C!Selune.2da~

     

    This tells WeiDU to copy the C!Selune.2da file as the kit's 2da, and that it can be located in the Cleric_Remix/Selune folder. If you just wish to use the existing CLABFI01.2da found in the game, you should change that line to

    ~override/clabfi01.2da~

    One complication may be that the file is in a biff file and not necessarily in the override folder. To insure against that, either include a copy with your mod and use the path to it or force it to be in the override folder by adding

    COPY_EXISTING ~clabfi01.2da~ ~override~

    before your ADD_KIT command.

  10. First, thanks for the kind words, and welcome to modding. :)

     

    For the questions, it's mainly no. The engine is hardcoded to only grant the extra number of attacks from proficiencies to fighter classes--swashbucklers never get their extra half attack for two stars, for example. AFAIK, this is hardcoded. (I should probably add it to the tutorial too, since it's something that I see a fair bit in kitmaking.)

     

    As for the distinct usabilities, you're kinda stuck unless you implement a hacky workaround. You'd need to do something like making mage robes available to clerics, and then take one of the other kit unusability flags for your new kit. I use this trick in SPC, for example, to allow the Arcane Fist to use robes. I change Undead Hunters to use the same items as regular paladins (since there's no difference in the game) and then use the free flag to implement new restrictions.

     

    It's very hacky and unsatisfying. It has the additional drawback of still not being perfect (regular clerics would be able to use mage robes, unless you added even more hacks). It also has a lot of compatibility issues--other mods may try to use the same flag, or you'll mess up any mod items/kits/etc. that may use the unusability flag you just borrowed.

  11. Gah, missed your fixes for v2. I've added them locally for v3 and I'm going to start working through this list as my next project.

     

    Found some additional variable issues (these may or may not be bugs):

    • aerieq is used as both a LOCALS and GLOBAL
    • AnomenLeaveAngry and AnomenLeavesAngry are both used
    • faceon and faceone are both used
    • MinscWitch is a LOCALS and GLOBAL

    * Variable GLOBALkeldornleaves is referenced only 1 times.

    LOCALS/GLOBAL mixup, plus an additional error of using KeldornLeave and KeldornLeaves. Without the "s" appears to be correct as it's used in subsequent dialogue triggers.

     

    REPLACE_ACTION_TEXT_REGEXP ~keldor[jp]~"KeldornLeaves?","\(GLOBAL\)\|\(LOCALS\)"~ ~"KeldornLeave","GLOBAL"~

×
×
  • Create New...