Search the Community
Showing results for tags 'FORCED_SUBCOMPONENT'.
Found 1 result
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.