Jump to content

Search the Community

Showing results for tags 'SUBCOMPONENT'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • G3 News and Announcements
    • Infinity Engine Modding News
    • General Mod Discussion
    • Fan Fiction
    • Noobermeet
  • Tools & Resources
    • DLTCEP
    • GemRB
    • The Gibberlings Three Debugging Suite for BG2
    • IESDP Updates and Info
    • Modding How-Tos and Tutorials
    • Modding Q&A
    • Multi-Install Tool
    • Widescreen Mod
  • Released Projects
    • Miscellaneous Released Mods
    • Ajantis
    • Alternatives
    • Amber
    • Angelo
    • Ascension
    • Auren Aseph
    • BG1 NPC Project
    • Baldur's Gate Mini Quests and Encounters
    • The Beaurin Legacy
    • BG2 Fixpack - General Discussion
    • Calin
    • The Calling
    • Cirerrek's AI Scripts
    • Coran's Friendship Mod
    • Crossmod Banter Pack
    • Divine Remix
    • Enhanced Edition Trilogy
    • Evandra
    • Full Plate & Packing Steel
    • Garrick's Infatuation
    • Gavin
    • The Gibberlings Three Anniversary Mod
    • Glam's NPC Pack
    • Icewind Dale Mod Roundup
    • Icewind Dale in Baldur's Gate II
    • Imoen 4 Ever
    • Item Randomiser
    • Item Revisions
    • IWD2 NPC Project
    • IWDification
    • Keeping Yoshimo
    • Kivan and Deheriana Companions for BG2
    • Level One NPCs
    • Mur'Neth
    • NPC Kitpack
    • NPC Strongholds
    • NPC Tweak for BG2
    • Oversight
    • Romantic Encounters (BG)
    • Romantic Encounters (BG2)
    • Sarah
    • Song and Silence
    • Spell Revisions
    • Sword and Fist
    • Sword Coast Stratagems
    • Tweaks Anthology Forum
    • Tyris Flare
    • Wheels of Prophecy
    • Yoshimo's Remorse
  • Unreleased Projects
    • Aklon
    • Baldur's Gate: Shadow Hand TC
    • Aran Whitehand
    • Delainy
    • IWD Tutu
    • Kit Revisions
    • Inactive Projects
  • NWN2 Modding
  • Mod Workrooms

Categories

  • NPCs
  • Quests and Others
  • Tweaks & Fixes
  • Items/Kits/Spells
  • Portrait Packs
  • Mini Mods
  • Tools
  • In Progress

Categories

  • Fixes
  • Items
  • Kits
  • NPCs
  • Quests
  • Spells
  • Tweaks
  • Other
  • Tools

Product Groups

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Discord


Website URL


Skype


AIM


MSN


ICQ


Yahoo


Jabber


Location


Interests


Mods Worked On

Found 4 results

  1. One fun thing about RP that BG2 blows completely out of the water is equipment choice, level, and relative wealth. Well, OK, so there are many areas where it differs from a P&P AD&D game, but there are lots of mods out there to fix some of this... but for Aran, let's give the players some choice. From a RP perspective, it is silly for a L7 fighter to not have a decent magical weapon, good armor, and perhaps even some supplies. I have never been a mercenary, but I would assume that they are like musicians in one respect - a horn player will eat nothing but crackers for days/weeks/months/years before giving up his horn. After all, how are you going to work your way out of debt if you have a garbage old beat-up single Conn, and everyone else is showing up with pro equipment, well maintained and well rehearsed in its strengths and weaknesses in relation to your playing style? And that is not a matter of life and death, like a good shield or sword might be. So we can mess about with helping Aran have gear. We can even let players decide: Is Aran down-and-out poor, having sold off his best gear? Is Aran treasure-poor but equipped with decent L7 equipment? Is Aran equipped with the best equipment possible, because I am going to dual-class him and take his gear so I can be L33T and overpowered, at least up until I run into the first SCSII-enhanced gibberling? Heck, we can take that one step farther. We can set up those four choices of stats with appropriate proficiencies, and give players choice over what gear he has. That could be modified by what RP option was chosen about his relative equipment wealth; if he is poor and down-and-out, he might have a regular mundane long sword, but if he is average that will be a +1 long sword, and if he has been successful he may be starving but he won't stop gripping the pommel of that +2 long sword until he is forced to. OK, lots of fun - lots of choice; that brings up two additional considerations. Q. Why not give the player full choice of everything? A. I've watched Nythrun, and I'm no Nythrun. Between eric, miloch, and Nythrun, Level1NPCs will eventually allow people to completely respec Aran any way they want. I'm counting on that - why else would I be adding dialog options that check to see if Aran is CLERIC_ALL, or MAGE_ALL, or KIT:HEARTWARDER_OF_SUNE and such? Plus, there is a defining of character that can take place. If Aran is setting up to Dual to Cleric, my take is that he would be messing around with many different cleric-able weapons, but not specializing in any of them. After all, his primary start is sword and board, and he is not driven to excel in one specific focused area. Aran as a Kensai? Have you heard him talk? The level of precision and self-control necessary for Bushido does not seem likely to be something Aran would be able to handle. So from a RP standpoint, keeping within character, I can set up some baselines that fit his personality, confident that eventually folks will get to L1NPC him into that magical Kensai->Mage dual class for their power-gaming run. Q. What about the confusing raft of choices? I just want to play - worse, I have a BWP install, and I don't understand all the custom install templates. Why can't I just install him and be done with it? A. Good point. BWP has solved user input at install through scripting, but it can be a huge job to understand what is going on. So, a 'default' configuration needs to be available, so the user does not have to make tons of choices if they don't want to. OK, so on to implementing this mess of choices. MARCO-ME (ok, ok, pun intended. Macrame. Feeble humor, but that's what I got.) Before we get started on implementing this, though, let's mess around with a fancy thing called DEFINE_PATCH_MACRO. Say I have 4 or 5 .cres (or even more) that have the same stuff done to them, with very minor variations. The regular way is to declare everything out front - 5, or 6 variations on CODE /* Area C-AW01 Entry Point - Bouncer on Promenade */ COPY_EXISTING ~kpgrd01.cre~ ~override/c-aw01ep.cre~ SAY NAME1 ~Manson~ SAY NAME2 ~Manson~ REMOVE_CRE_ITEM ~rndtre02~ WRITE_LONG INITIAL_MEETING (BNOT 0x0) WRITE_LONG DIALOGUE_HOSTILE (BNOT 0x0) WRITE_LONG MORALE (BNOT 0x0) WRITE_LONG HAPPY (BNOT 0x0) WRITE_LONG UNHAPPY_ANNOYED (BNOT 0x0) WRITE_LONG UNHAPPY_SERIOUS (BNOT 0x0) WRITE_LONG UNHAPPY_BREAKING (BNOT 0x0) WRITE_LONG LEADER (BNOT 0x0) WRITE_LONG TIRED (BNOT 0x0) WRITE_LONG BORED (BNOT 0x0) WRITE_LONG BATTLE_CRY1 (BNOT 0x0) WRITE_LONG BATTLE_CRY2 (BNOT 0x0) WRITE_LONG BATTLE_CRY3 (BNOT 0x0) WRITE_LONG BATTLE_CRY4 (BNOT 0x0) WRITE_LONG BATTLE_CRY5 (BNOT 0x0) WRITE_LONG HURT (BNOT 0x0) WRITE_LONG AREA_FOREST (BNOT 0x0) WRITE_LONG AREA_CITY (BNOT 0x0) WRITE_LONG AREA_DUNGEON (BNOT 0x0) WRITE_LONG AREA_DAY (BNOT 0x0) WRITE_LONG AREA_NIGHT (BNOT 0x0) WRITE_LONG SELECT_COMMON1 (BNOT 0x0) WRITE_LONG SELECT_COMMON2 (BNOT 0x0) WRITE_LONG SELECT_COMMON3 (BNOT 0x0) WRITE_LONG SELECT_COMMON4 (BNOT 0x0) WRITE_LONG SELECT_COMMON5 (BNOT 0x0) WRITE_LONG SELECT_COMMON6 (BNOT 0x0) WRITE_LONG SELECT_ACTION1 (BNOT 0x0) WRITE_LONG SELECT_ACTION2 (BNOT 0x0) WRITE_LONG SELECT_ACTION3 (BNOT 0x0) WRITE_LONG SELECT_ACTION4 (BNOT 0x0) WRITE_LONG SELECT_ACTION5 (BNOT 0x0) WRITE_LONG SELECT_ACTION6 (BNOT 0x0) WRITE_LONG SELECT_ACTION7 (BNOT 0x0) WRITE_LONG SELECT_RARE1 (BNOT 0x0) WRITE_LONG SELECT_RARE2 (BNOT 0x0) WRITE_LONG CRITICAL_HIT (BNOT 0x0) WRITE_LONG CRITICAL_MISS (BNOT 0x0) WRITE_LONG TARGET_IMMUNE (BNOT 0x0) WRITE_LONG INVENTORY_FULL (BNOT 0x0) WRITE_LONG PICKED_POCKET (BNOT 0x0) WRITE_LONG HIDDEN_IN_SHADOWS (BNOT 0x0) WRITE_LONG SPELL_DISRUPTED (BNOT 0x0) WRITE_LONG SET_A_TRAP (BNOT 0x0) WRITE_LONG BIO (BNOT 0x0) WRITE_EVALUATED_ASCII 0x34 ~%DEST_RES%~ #8 /* small portrait */ WRITE_ASCII 0x248 ~None~ #8 /* override AI script */ WRITE_ASCII 0x250 ~None~ #8 /* disable class AI script */ WRITE_ASCII 0x258 ~None~ #8 /* disable race AI script */ WRITE_ASCII 0x260 ~None~ #8 /* disable general AI script */ WRITE_ASCII 0x268 ~None~ #8 /* disable default AI script */ WRITE_EVALUATED_ASCII 0x2cc ~%DEST_RES%~ #8 /* dialogue */ WRITE_EVALUATED_ASCII 0x280 ~%DEST_RES%~ #32 /* death variable */ But what if I could work this out with just one line, instead of everything? I can... CODE COPY_EXISTING ~kpgrd01.cre~ ~override/c-aw01ep.cre~ /* Area C-AW01 Entry Point - Bouncer on Promenade */ SAY NAME1 ~Manson~ SAY NAME2 ~Manson~ REMOVE_CRE_ITEM ~rndtre02~ LAUNCH_PATCH_MACRO ~support_cre_cleanup~ ... if I set up what I want to happen in a macro, like this... CODE DEFINE_PATCH_MACRO ~support_cre_cleanup~ BEGIN WRITE_LONG INITIAL_MEETING (BNOT 0x0) WRITE_LONG DIALOGUE_HOSTILE (BNOT 0x0) WRITE_LONG MORALE (BNOT 0x0) WRITE_LONG HAPPY (BNOT 0x0) WRITE_LONG UNHAPPY_ANNOYED (BNOT 0x0) WRITE_LONG UNHAPPY_SERIOUS (BNOT 0x0) WRITE_LONG UNHAPPY_BREAKING (BNOT 0x0) WRITE_LONG LEADER (BNOT 0x0) WRITE_LONG TIRED (BNOT 0x0) WRITE_LONG BORED (BNOT 0x0) WRITE_LONG BATTLE_CRY1 (BNOT 0x0) WRITE_LONG BATTLE_CRY2 (BNOT 0x0) WRITE_LONG BATTLE_CRY3 (BNOT 0x0) WRITE_LONG BATTLE_CRY4 (BNOT 0x0) WRITE_LONG BATTLE_CRY5 (BNOT 0x0) WRITE_LONG HURT (BNOT 0x0) WRITE_LONG AREA_FOREST (BNOT 0x0) WRITE_LONG AREA_CITY (BNOT 0x0) WRITE_LONG AREA_DUNGEON (BNOT 0x0) WRITE_LONG AREA_DAY (BNOT 0x0) WRITE_LONG AREA_NIGHT (BNOT 0x0) WRITE_LONG SELECT_COMMON1 (BNOT 0x0) WRITE_LONG SELECT_COMMON2 (BNOT 0x0) WRITE_LONG SELECT_COMMON3 (BNOT 0x0) WRITE_LONG SELECT_COMMON4 (BNOT 0x0) WRITE_LONG SELECT_COMMON5 (BNOT 0x0) WRITE_LONG SELECT_COMMON6 (BNOT 0x0) WRITE_LONG SELECT_ACTION1 (BNOT 0x0) WRITE_LONG SELECT_ACTION2 (BNOT 0x0) WRITE_LONG SELECT_ACTION3 (BNOT 0x0) WRITE_LONG SELECT_ACTION4 (BNOT 0x0) WRITE_LONG SELECT_ACTION5 (BNOT 0x0) WRITE_LONG SELECT_ACTION6 (BNOT 0x0) WRITE_LONG SELECT_ACTION7 (BNOT 0x0) WRITE_LONG SELECT_RARE1 (BNOT 0x0) WRITE_LONG SELECT_RARE2 (BNOT 0x0) WRITE_LONG CRITICAL_HIT (BNOT 0x0) WRITE_LONG CRITICAL_MISS (BNOT 0x0) WRITE_LONG TARGET_IMMUNE (BNOT 0x0) WRITE_LONG INVENTORY_FULL (BNOT 0x0) WRITE_LONG PICKED_POCKET (BNOT 0x0) WRITE_LONG HIDDEN_IN_SHADOWS (BNOT 0x0) WRITE_LONG SPELL_DISRUPTED (BNOT 0x0) WRITE_LONG SET_A_TRAP (BNOT 0x0) WRITE_LONG BIO (BNOT 0x0) WRITE_EVALUATED_ASCII 0x34 ~%DEST_RES%~ #8 /* small portrait */ WRITE_ASCII 0x248 ~None~ #8 /* override AI script */ WRITE_ASCII 0x250 ~None~ #8 /* disable class AI script */ WRITE_ASCII 0x258 ~None~ #8 /* disable race AI script */ WRITE_ASCII 0x260 ~None~ #8 /* disable general AI script */ WRITE_ASCII 0x268 ~None~ #8 /* disable default AI script */ WRITE_EVALUATED_ASCII 0x2cc ~%DEST_RES%~ #8 /* dialogue */ WRITE_EVALUATED_ASCII 0x280 ~%DEST_RES%~ #32 /* death variable */ END Easy, huh? With this predefined snippet of code I can slap most of the .cre silent, set the portrait and dialog and dv and anything else I want to the name of the .cre, disabled the scripts I don't want - everything in one swoop. DEFINE_PATCH_MACRO basically says "here is a list of things I want to do within a patching operation". Putting it at the top of your mod or component means later on, instead of writing it all out or copying and pasting blocks, you can refer to it buy using LAUNCH_PATCH_MACRO. Now, how can we leverage this a bit more, to make life easier? We have to come up with a way to set some of the choices above to "variables", so we can... duh... vary them. We actually already have, because we have leveraged the bigg's WeiDU variables, %DEST_RES%, which equals the name of the resource being worked on by the code at the moment (See Mike1072's post below for a clearer explanation of this). Let's play with this idea for Aran. First off, we want 4 basic choices, as we have said before - Tinker, Tailor, Soldier, Spy (Dual-Classable stats for Ftr->Mage, Ftr->Cleric, Fighter, Ftr->Thief). We would also like to be able to choose some basic equipment and armor, and perhaps roleplay the level of gear he has. We also need a "yeah, whatever - stop messing about and just install the damned NPC and let's get on with it" option. But we can make it much more far-reaching than that. We can let the user choose some of the input.
  2. Well, I started awhile ago on this, asking folks for input, and got some, so it is probably time to figure out where he really goes. Synopsis We want to tell the game where Aran is supposed to meet the party - where he "spawns" in-game. To do that, we use WeiDU to add him in, first having researched area, x.y coordinates, and extended that area's script with the instructions to do so. In addition, we want to allow players to choose where he goes, but they have to choose one area out of the pool of choices, and the instructions must be run out (can' be skipped or uninstalled without replacement, or he will never spawn for players). Starting at Providing Choices In The .tp2 There are some cool ways of getting player input, including very customizable things like ACTION_READLN and setting up multiple components. There are some advantages to READLN we have already discussed, so let's go to a simple way of adding a player choice to an install - SUBCOMPONENT and FORCED_SUBCOMPONENT. Regular WeiDU installation Choices; Simple. Effective. And They Can Roll Back. In our regular WeiDU installation, the easiest way to let things work is to create a separate component and let players choose what they want to install, like this: BEGIN ~This is the first component in my mod.~ BEGIN ~This is the second component in my mod.~ Simple enough, though sometimes it feels odd to do a BEGIN without an END, but don't complain to the bigg - that is way way legacy stuff that can't be changed without messing up about everything out there already coded. He didn't write it like that - it came that way from back in the day, and we need it to say how the game will play. Darn - almost made that work, but it got confusing. Basically, if we want to be able to use older mods, we need backwards compatibility, and the bigg has to stick within certain constraints, this being one of them. With this example above, all we are saying is "WeiDU, do this first set of instructions." "WeiDU, do this second set of instructions." So, a mod .tp2 might have something like BEGIN ~This is the first coponent in my mod. Aran is starting in Candlekeep.~ EXTEND_BOTTOM ~CANDLEKEEP.ARE~ ~aranw/baf/starting_area.baf~ BEGIN ~This is the second coponent in my mod. Aran is starting in East Timbuktoo~ EXTEND_BOTTOM ~EAST_TIMBUKTOO.ARE~ ~aranw/baf/starting_area.baf~ This lets the player choose to install component 1, Candlekeep start, or to install component 2, African Safari start, and we have accomplished our mission. Except... under this configuration, the player could choose 1 AND 2. They could choose 1 OR 2.They could choose 1. They could choose 2. Or they could skip both. Worst of all from a mod author's standpoint, they could choose both, then uninstall them both, and then come complaining when Aran doesn't show up in the game... so we probably do not want to do the installation choice this way. HEY - why don't we use READLN? I mean, it is simple enough - the code is out there, and wee have already gone through it in another post - why would we *not* use that fancy way of creating choice for the player in this instance? Two words... Weidu. Log. When WeiDU puts out the central log of everything, it sees components that are installed. The .DEBUG created from your mod install has lots of cool information for troubleshooting, but standard practice for troubleshooting is to get the big, obvious text file in the game folder named "weidu.log" and use it to determine if things have gone right or wrong in a player's game. Those entries are *only* mod components installed, not the READLN choices, because the WeiDU.log serves a cool purpose - it helps weidu operate. Cluttering it up with inner actions of a component would mess it up, as will PRINT and other commands within your .tp2. Basically, it is an index of mod components, not a listing of every single change to your game in great detail. Here is a sample entry in the weidu.log after installation: Now, I can go with a "list every component approach, like Fixpack: but we just figured out I don't want that approach, because with Fixpack we want players to be able to install and uninstall various things as they choose. With the spawining area, this is not such a good idea. Not only do we want players to choose one, we want them to be required to choose one of several choices, or have the mod pull itself out - because if you can't spawn him, it is just as bad if you have him popping up in a dozen areas, all coming up to various versions of himself like in Multiplicity, saying "Hey, you look familiar - what a handsome dude you are. You got any work?" And READLN doesn't leave a clue in the weidu.log as to which choice the player has made, so 3/4 of the way through a Mega-BGT-BP, when a player is completely confsed, and wants to go pick up Aran, We can't go "gee... do you remember where you told him to spawn, three months ago, while you were spending hours staring at your computer screen willing the installation to move faster?" So we want 1. a way that weidu will ask the player to choose from a panel of choices 2. allow weidu the ability to report which choice was made 3. require/demand/insist/not proceed until the player chooses one of the panel of choices. Enter the world of SUBCOMPONENT | FORCED_SUBCOMPONENT (tadaa!) Let's go back to Grim Squeaker's Tyris Flare mod for a second. I only posted a portion of the Weidu.log. The full entry for Tyris looks like this: Now, that is pretty cool. Grim Squeaker has a second component, that allows players to choose an alternate portrait. Let's look at how it got coded: BEGIN ~Alternate Portrait 1~ DESIGNATED 101 REQUIRE_COMPONENT ~Setup-TyrisFlare.tp2~ ~0~ ~NPC is not installed, therefore skipping alternate portraits...~ SUBCOMPONENT ~Alternate Tyris Portraits~ COPY ~TyrisFlare/Portraits/Alternate1/G#TYRISL.bmp~ ~override/G#TYRISL.bmp~ ~TyrisFlare/Portraits/Alternate1/G#TYRISM.bmp~ ~override/G#TYRISM.bmp~ ~TyrisFlare/Portraits/Alternate1/G#TYRISS.bmp~ ~override/G#TYRISS.bmp~ BEGIN ~Alternate Portrait 2~ SUBCOMPONENT ~Alternate Tyris Portraits~ COPY ~TyrisFlare/Portraits/Alternate2/G#TYRISL.bmp~ ~override/G#TYRISL.bmp~ ~TyrisFlare/Portraits/Alternate2/G#TYRISM.bmp~ ~override/G#TYRISM.bmp~ ~TyrisFlare/Portraits/Alternate2/G#TYRISS.bmp~ ~override/G#TYRISS.bmp~ BEGIN ~Alternate Portrait 3~ SUBCOMPONENT ~Alternate Tyris Portraits~ COPY ~TyrisFlare/Portraits/Alternate3/G#TYRISL.bmp~ ~override/G#TYRISL.bmp~ ~TyrisFlare/Portraits/Alternate3/G#TYRISM.bmp~ ~override/G#TYRISM.bmp~ ~TyrisFlare/Portraits/Alternate3/G#TYRISS.bmp~ ~override/G#TYRISS.bmp~ BEGIN ~Alternate Portrait 4~ SUBCOMPONENT ~Alternate Tyris Portraits~ COPY ~TyrisFlare/Portraits/Alternate4/G#TYRISL.bmp~ ~override/G#TYRISL.bmp~ ~TyrisFlare/Portraits/Alternate4/G#TYRISM.bmp~ ~override/G#TYRISM.bmp~ ~TyrisFlare/Portraits/Alternate4/G#TYRISS.bmp~ ~override/G#TYRISS.bmp~ The initial DESIGNATED 101 is a way of telling weidu that the modder wants this component to be labled 101, even if it is component 2 of 2. Ordinarily, Weidu decides component numbers on the fly, based on what it sees - a component can get swapped around in install order over the course of development, etc. This DESIGNATED locks the component number. You might want to do this if you are making sure things remain available to check for over time by other modders, so that if they put something like line 2, REQUIRE_COMPONENT, or FORBID_COMPONNT, or anything else in that series of choices, the numbering is right. Here, an example. Pretend I made a mod that Grim Squeaker had contributed to that already had Tyris' portarit choice in it. Because he put DESIGNATED 101, I can use that number to avoid duplication - FORBID_COMPONENT ~Setup-TyrisFlare.tp2~ ~101~ ~Tyris Flare's Alternate Portraits are already installed, therefore skipping alternate Tyris portraits...~ and he he could add [FORBID_COMPONENT ~setup-cmorgans_massive_portrait_pack.tp2~ ~27~ ~Sorry, you already chose Tyris' portrait, therefore skipping alternate portraits...~ Of course, if I did not use DESIGNATED 27, and I added another component, it would become component 28, and then Grim is messed up bad - so usig DESIGNATED can help with things like this. Why not just do it Old Skool, and go with BEGIN ~Alternate Portrait 1~ BEGIN ~Alternate Portrait 2~ BEGIN ~Alternate Portrait 3~ BEGIN ~Alternate Portrait 4~ Well... becuse players dont want to be bothered with picking and choosing components for every mod. Some folks would just install everything. Under that setup, Tyris would have her original portrait. Then Alternate 1 would be added. Then Alternate 2, then 3, then 4, each overwriting the last. And the end result would be that most installs of Tyris Flare would use Alternate Portrait v4, and there would be a bunch of extra lines in the weidu.log, and it would be silly. So, putting these into So, next line is already covered. He has 4 components, BEGIN ~Alternate Portrait 1~ BEGIN ~Alternate Portrait 2~ BEGIN ~Alternate Portrait 3~ BEGIN ~Alternate Portrait 4~ Why not just do it Old Skool, and go with this as is? Well... because players don't want to be bothered with picking and choosing components for every mod. Or reading README's and figuring out that they are installing something that does exactly the same thing over the top of what they just chose. Some folks would just install everything. Under that setup, Tyris would have her original portrait. Then Alternate 1 would be added. Then Alternate 2, then 3, then 4, each overwriting the last. And the end result would be that most installs of Tyris Flare would use Alternate Portrait v4, and there would be a bunch of extra lines in the weidu.log, and it would be silly. So, putting these into a new format wuill avoid this. As a side note, he has made them all dependent on Tyris being installed, which is generally a good thing for mod-specific content changes. You don't want players adding stuff that has no use in-game, or worse - if this component had tried to edit Tyris' .cre, the mod component would fail and stop installation with an error message about missing the .cre. So, a line that requires that the central component of Tyris Flare be installed, looking for component ~0~. Adding this line back into our deconstruction - BEGIN ~Alternate Portrait 1~ DESIGNATED 101 REQUIRE_COMPONENT ~Setup-TyrisFlare.tp2~ ~0~ ~NPC is not installed, therefore skipping alternate portraits...~ BEGIN ~Alternate Portrait 2~ BEGIN ~Alternate Portrait 3~ BEGIN ~Alternate Portrait 4~ Now things get fancy. He makes each of these components into be a subset of another component, so that what we originally had as four separate install choices become one of a small group of choices: BEGIN ~Alternate Portrait 1~ DESIGNATED 101 REQUIRE_COMPONENT ~Setup-TyrisFlare.tp2~ ~0~ ~NPC is not installed, therefore skipping alternate portraits...~ SUBCOMPONENT ~Alternate Tyris Portraits~ BEGIN ~Alternate Portrait 2~ SUBCOMPONENT ~Alternate Tyris Portraits~ BEGIN ~Alternate Portrait 3~ SUBCOMPONENT ~Alternate Tyris Portraits~ BEGIN ~Alternate Portrait 4~ SUBCOMPONENT ~Alternate Tyris Portraits~ So far, beautiful. I can adapt the same idea, and go crazy! Except... why SUBCOMPONENT? What happened to the FORCED_ ? Well, Grim Squeaker sent Tyris Flare out into the world with an existing portrait. No player *has* to install *any* of the alternate portrait choices. So under this configuration, the player can choose to skip the whole thing, or choose one of the portraits. I can't do that for Aran's spawning - I only want one of him, and I insist that the player choose one. So, simple enough edit - with Tyris, all I would have to do to make a player not be able to complete the install without the choice being made, is change that SUBCOMPONENT into FORCED_SUBCOMPONENT. Logical, huh.
  3. The GROUP flag came about in discussing component management with an abnormally large number of independent components, e.g. BG2 Tweaks, and was added as a feature in WeiDU v192. Previously WeiDU lacked a satisfactory way to organize such a modâ€"the closest feature would be the top level ASK_EVERY_COMPONENT, which only allows for a single all-or-none approach. The solution is a new component flag, GROUP, with the following syntax (and example): GROUP string BEGIN ~100% Learn Spells~ GROUP ~Convenience Tweaks~ // component code BEGIN ~Identify All Items~ GROUP ~Convenience Tweaks~ // component code BEGIN ~Give Edwin his BG2 Stats~ GROUP ~NPC Tweaks~ // component code BEGIN ~ Give Jaheira her BG2 Stats~ GROUP ~NPC Tweaks~ // component code Upon installing the mod, the player is now presented with meta-options on each group at a high level: Would you like to display the category [Convenience Tweaks]? [Y]es/[N]o Would you like to display the category [NPC Tweaks]? [Y]es/[N]o Selecting [N]o on any group suppresses those options from being displayed, leading to a simpler and more controlled installer experience for the player. In the provided example, selecting [N]o to Convenience Tweaks and [Y]es to NPC Tweaks would result in WeiDU starting installation by asking to install the Give Edwin his BG2 Stats component. GROUP operates independently of SUBCOMPONENT, meaning you can use both to organize the mod as needed. A few other items of note: A component can belong to multiple GROUPs; a component is not offered for install if and only if none of its member groups are selected You could, in theory, have two components in the same SUBCOMPONENT grouping but different GROUPs. Don't do this. If some components of a mod are in a GROUP, but others are not, the non-GROUPed components will always be presented. Using a GROUP anywhere in your mod will act as an implied ASK_EVERY_COMPONENT tp2 flag.
  4. SUBCOMPONENTs allow to group together a set of mutually exclusive mod components into a single menu-style selection. The primary purpose of SUBCOMPONENTs is to streamline mod installation and to make life easier for end users. For example, SUBCOMPONENTS are ideal if you wish to provide multiple portrait selections for an NPC mod, have several kits available to one NPC, or for changes that conflict with one another (i.e. raising an XP cap to 10 million or raising it to 20 million). We’ll use the first oneâ€"multiple portrait optionsâ€"as an example. Without SUBCOMPONENTs, the install dialogue would look something like this: Install Component [Delainy Portrait 1 by Bob] [Y]es, [N]o, or [Q]uit Install Component [Delainy Portrait 2 by Fred] [Y]es, [N]o, or [Q]uit Install Component [Delainy Portrait 3 by Wilhelmus] [Y]es, [N]o, or [Q]uit The end user would need to click through the options each time. Worse, conflicting components could be installed. These problems can be limited somewhat by judicious use of predicates, but taking advantage of the SUBCOMPONENT feature yields far superior results: Install Component [Delainy Portrait] [N]o, [Q]uit, or choose one: 1] Portrait 1 by Bob 2] Portrait 2 by Fred 3] Portrait 3 by Wilhelmus Only one of these options can be installed at any time; re-installing and selecting a different SUBCOMPONENT will automatically uninstall the previously installed one. Setting this up is dead simple: BEGIN ~Portrait 1 by Bob~ /* The string above is displayed in the subcomponent listing, i.e. the list with 1] 2] 3] etc. You can, of course, use TRA references instead for this and the SUBCOMPONENT string below. */ SUBCOMPONENT ~Delainy Portrait~ /* The string above is displayed as the component listing and must be the same for each SUBCOMPONENT. The tp2 code that follows is only executed if this SUBCOMPONENT is selected. */ COPY ~Delainy/portraits/opt1G.bmp~ ~override/CDDELAIG.bmp~ COPY ~Delainy/portraits/opt1M.bmp~ ~override/CDDELAIM.bmp~ COPY ~Delainy/portraits/opt1S.bmp~ ~override/CDDELAIS.bmp~ BEGIN ~Portrait 2 by Fred~ SUBCOMPONENT ~Delainy Portrait~ COPY ~Delainy/portraits/opt2G.bmp~ ~override/CDDELAIG.bmp~ COPY ~Delainy/portraits/opt2M.bmp~ ~override/CDDELAIM.bmp~ COPY ~Delainy/portraits/opt2S.bmp~ ~override/CDDELAIS.bmp~ BEGIN ~Portrait 3 by Wilhelmus~ SUBCOMPONENT ~Delainy Portrait~ COPY ~Delainy/portraits/opt3G.bmp~ ~override/CDDELAIG.bmp~ COPY ~Delainy/portraits/opt3M.bmp~ ~override/CDDELAIM.bmp~ COPY ~Delainy/portraits/opt3S.bmp~ ~override/CDDELAIS.bmp~ Any REQUIRE_FILEs or other module requirements for the whole group should be put with the first subcomponent. If such a requirement fails, none of the subcomponents can be installed. In addition, each individual subcomponent can be guarded by its own predicate. If that predicate fails, that particular subcomponent cannot be installed. One note about SUBCOMPONENTs and mod ordering: WeiDU will display SUBCOMPONENTs in a single grouping no matter if they fall consecutively in the tp2 or not. However, the component number (the one that gets placed in weidu.log and the one you check for in REQUIRE_COMPONENT et al) is still based on their tp2 order. Discussion and comments can be handled in this thread.
×
×
  • Create New...