Oy vey, a mod uninstall wiped baldur.bcs clean!

[temnix]

I had a small mod installed, my "Initiative" mod actually, and it does this from the tp2 file:

 

EXTEND_TOP ~baldur.bcs~ ~Initiative/INIT_#.bcs~

 

Doesn't seem destructive, does it? Well, it's not, but when I uninstalled the mod (I wanted a clean installation, not a reinstall), and then installed it again, I saw that all of the other sophisticated code I had put in baldur.bcs - above the bit added by "Initiative" - had been wiped away. All that was left, except the fresh bit just added, was the basic file. Since this left me more or less in the situation of Job, I, after sprinkling ashes on my head, had nothing to lose in adding a little new code to baldur.bcs and uninstalling the mod once more. And again all of the text above went with it.

 

Is this normal behavior, in hell, or is a bad Friday coming?

[Jarno Mikkola]

That's what the uninstalling of a weidu mod does, it restores the backup it made, which is the copy it made before you installed the mod. Duh.
You know, you can keep the .bcs code you intent to have in the game in a .baf file that you compile each time instead of a freaking .bcs file. Utilizing .bcs'es is crazy at this point and time. As they can also fail to actually make it into the game, as the .ids file can have overwhelming changes.

You know, use it this way:

EXTEND_TOP ~baldur.bcs~ ~Initiative/INIT_#.baf~

Where the .baf file is just a renamed .txt file.

 

Also extending top of the baldur.bcs is not really viewed as the most positive way to do the things in this cause you know, there might be a little more important things to do than some small changes. For example transition the player character from BG1 to BG2 area should extend top, while checking if say the toilet seat was left up might not be important. Especially in the later areas where the player could take hours to reach the place, as the likelihood of the value getting checked is the same whether or not the check is done at the top of the file.

Of course they have different tools than just the baldur.bcs, but you probably could also be using them instead of the file that keeps the major elements of the game up.

[temnix]

I thought the uninstall removed the lines it added. That's what it does for extra lines to, say, 2DA files or IDS files. You install the mod, they appear. You uninstall, they disappear, but everything else remains. As for the suggestion not to clutter the baldur.bcs, I don't think it matters whether I learn to use baf files or stay with bcs. Thanks for the code, but you haven't given me a convincing reason. The content code still has to go inside baldur.bcs, it's the file the game reads.

 

Now, if the installation process of Weidu is so crude with regard to scripts - if it just restores a backup instead of removing changes - then how should anyone go about uninstalling anything? If I run several mods at once, then decide I don't like the fifth most-recent one installed and remove it, I'm going to lose all changes since then and see again an ancient version of the file?

[Jarno Mikkola]

I thought the uninstall removed the lines it added. That's what it does for extra lines to, say, 2DA files or IDS files. You install the mod, they appear. You uninstall, they disappear, but everything else remains.

Well, you are wrong... you'll run into this while trying to install a mod that uses DECOMPILE_BCS_TO_BAF, as it can't resolve the not existing .ids entry, weidu throws a error.

Try to decompile the BG2's baldur.bcs file in the BG1 game for kicks.

 

The reason to keep everything in a .baf file instead of .bcs file is very simple: The .baf file is .ids file independent.

 

This:

If I run several mods at once, then decide I don't like the fifth most-recent one installed and remove it, I'm going to lose all changes since then and see again an ancient version of the file?

Were you to have them all in a weidu format, the answer is very simple, weidu will auto uninstall the 4 mods before the re-installing of the effected component can be done, where you can also uninstall it, after which the weidu will try to install the rest of the components, according to the instructions it stored before the components were changed.

 

Aka it for example can give you this:

// Log of Currently Installed WeiDU Mods

// The top of the file is the 'oldest' mod

// ~TP2_File~ #language_number #component_number // [subcomponent Name -> ] Component Name [ : Version]

~SETUP-ASCENSION.TP2~ #0 #0 // Ascension v1.41 (requires ToB)

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #0 // BG2 Fixpack - Core Fixes: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #1001 // BG2 Fixpack - Game Text Update -> GTU Classic (from Baldurdash, by Kevin Dorner): v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #3 // BETA Core Fixes (please check the readme!): v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #101 // Improved Spell Animations: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #102 // Cromwell's Forging Actually Takes a Day: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #104 // Ghreyfain's Holy Symbol Fixes: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #106 // Giants Receive Penalties When Attacking Halflings, Dwarves, and Gnomes: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #107 // Remove Dual-Classing Restriction from Archers and Stalkers: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #109 // Corrected Summoned Demon Behavior: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #110 // Additional Script Fixes: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #111 // Bard Song Fixes: v10

~BG2FIXPACK/SETUP-BG2FIXPACK.TP2~ #0 #113 // Additional Alignment Fixes: v10

~SETUP-BGT.TP2~ #0 #0 // Baldur's Gate Trilogy - Core: 1.18 (28 Apr 13)

// Recently Uninstalled: ~SETUP-BGTMUSIC.TP2~ #0 #1 // Baldur's Gate Trilogy - Music -> Hybrid Baldur's Gate/Shadows of Amn/Throne of Bhaal Music

~SETUP-BGTMUSIC.TP2~ #0 #2 // Baldur's Gate Trilogy - Music -> Full Baldur's Gate/Shadows of Amn/Throne of Bhaal Music (WARNING: patches BGMain.exe)

Notice the second last line. It's done by weidu's automatization, not mod code. As the case there was, the two components are alternative ... and the mod was reinstalled with a different imput.

 

It can also go horribly wrong too, which is a good reason to use the BWS, as that can solve most of the problems with this without too many things demanded from the player.. except patience, as the program might need to reinstall everything, including restoring the original game to non moded state.

 

And should you know, you can also build up your mod by adding stuff to the .tp2 file in single digit files... you can EXTEND_TOP the file thousands of times during the alpha phase of the mod. And then at the end, combine the files to a single large file.Or just remove the component starts by quoting them out with // .

[temnix]

A lot of information here, Jarno. What I really need to know is whether using a baf instead of a bcs - for adding to scripts - is going to preserve independent changes. Hand-entered ones. If I understand correctly, the ones from other mods will be reinstalled, so this is not as ruinous as I thought, but I'd like to keep custom changes, if possible.

[agb1]

Since your hand edits do not appear in the WeiDU.log, no consideration is made for them.

 

When you uninstall a WeiDU mod or component, it first uninstalls (in reverse sequential order) every mod and component that was installed after the mod/component you are removing, according to what is recorded in the WeiDU.log file. Each uninstall step restores whatever backup was made by the respective mod at the time of its installation, which will be whatever was in the files that it modified, prior to its touching them. That might include hand edits. After all uninstall steps are done, the targeted mod/component is itself uninstalled, restoring whatever backups it made. Then WeiDU runs all of the installers (in sequential order) to build your WeiDU.log back up to its original form, minus whatever you removed.

 

Therefore, if you make hand edits, WeiDU will obliterate them whenever it restores a backup that was made prior to the edits. If your hand edits predate every WeiDU mod that touches those files, your edits will be preserved because every WeiDU backup will contain those edits.

[Jarno Mikkola]

Hand-entered ones. If I understand correctly...

You probably didn't, because there's no such a thing as HAND-ENTERING anything. You can use the Near Infinity or another moding tools to edit and convert .bcs files, but you have to realize that that too is a form of modifying the game, and weidu can only restore the entries it's instructed to restore, aka the weidu entries.

 

What I am proposing you to do is to just add more weidu components to add the "hand entries" you make... for example you can just use this sort of .tp2 file action:

BEGIN ~component 1~ 
EXTEND_TOP ~baldur.bcs~ ~Initiative/1.baf~
BEGIN ~component2~ 
EXTEND_TOP ~baldur.bcs~ ~Initiative/2.baf~

And the best thing is, you can add as many files as you need, and the previous files don't need to be uninstalled if you don't need to change them, and so eventually you just need to uninstall everything, combine the files with copy paste, remove the extra components, reinstall and you are done.

And if you don't want to do that, you just like said, quote out the component assigner... aka, the above code becomes:

BEGIN ~component 1~ 
EXTEND_TOP ~baldur.bcs~ ~Initiative/1.baf~
//BEGIN ~component2~ 
EXTEND_TOP ~baldur.bcs~ ~Initiative/2.baf~

[temnix]

So what is the advantage of extending tops with baf files vs. bcs files, if both are installed/uninstalled the same way?

[Roxanne]

So what is the advantage of extending tops with baf files vs. bcs files, if both are installed/uninstalled the same way?

They work the same as long as your code is generic and contains no references to stuff in dialog.tlk or 2da files or anything referenced in chitin.key. As soon as the script needs to find something in such game resources your code will only work on your present installation. If you install baf via weidu, then weidu establishes the links to the resources in the target game (or gives you errors if they are not found).

With bcs you limit yourself to your own present install, baf makes it useable beyond that. With BCS stuff you just copy (and that may in some cases be sufficient) BAF is compiled by weidu and the result is BCS code,

 

(Yes I know, this is a very simplified statement and you could add a whole tutorial about it to cover all if's and when's.)

[temnix]

Finally a clear answer. Thank you.

 

But what, for example, could be code referencing a 2da file or dialog.tlk? Or rather, how to put a custom string in a baf?

[Jarno Mikkola]

So what is the advantage of extending tops with baf files vs. bcs files, if both are installed/uninstalled the same way?

You compile the .baf file during the install. To have a .bcs, you need to compile it previously. And yeah, the added content to which is build in.

 

Or rather, how to put a custom string in a baf?

This is easy, usually with replace_evaluate... , for example of a .tp2 code of existing debug mod, I copied from the_bigg:

COPY_EXISTING_REGEXP ~.*\.bcs$~ ~override~
    SET x = 0 - 1
    DECOMPILE_AND_PATCH BEGIN
        REPLACE_EVALUATE ~\(RESPONSE #[0-9]+\)~ BEGIN
                        x += 1
                END ~~~~~\1
        ActionOverride(Player1,DisplayString(Myself,~Running block %x% of %SOURCE_RES%.BCS~))~~~~~
  END
BUT_ONLY

The line ~Running block %x% of %SOURCE_RES%.BCS~ is added to the dialog.tlk for each script in the game as it's "updated", for every .bcs file the game has, to debug what's going on the game.

Of course if you want easier to read example, I need an actual example provided by you, of a thing you want in it ! Aka do not ask way too generalized thing, like "what, for example, could be code referencing a 2da file or dialog.tlk?". Cause the general answer is, "everything".

[temnix]

I guess this will do for now, as a general model. I don't need any custom strings to enter in scripts yet. I just wanted to know what advantages baf files have.

[agb1]

Any string that appears in the game is a reference to dialog.tlk. A simple example is a spell or item name or description. Or any dialogue text. Or DisplayStringHead in a script.

 

Any script action non-string non-integer parameter (i.e. text not surrounded by quotes), like a spell name, is an IDS identifier reference.

 

Near Infinity adds // comments after all references in a script, so if you see any yellow highlighting, you know the script is installation dependent and should be distributed as a baf instead of a bcs.

[Jarno Mikkola]

...Near Infinity adds // comments after all references in a script...

I have a great doubt that it does this to the actual .bcs files because the file itself shouldn't -as far as I know- actually contain the information, as it's just a hexadecimal file...

 

Or it could look like:

But I have a doubt that it's actually there.

 

So the comment is just a reference number utilized by the tools look up feature to display the possible translation in the current game. Yeah, were one to see it, then yeah, using it as the .baf file is better, but it won't exclude the option to have it as a .bcs either. Even if it's likely going to be of a worse form.

Also, a fun fact, the .baf extension of the games script files import file is just a co-incidence made up by the old community, as it was agree'ed by the tool makers to utilize the same extension.

[temnix]

Near Infinity adds // comments after all references in a script, so if you see any yellow highlighting, you know the script is installation dependent and should be distributed as a baf instead of a bcs.

 

What will happen if I use a bcs? Let's say, with a reference to a custom spell state added during the installation.