11 replies to this topic

[prune1]

I am just trying to figure out a few things, so bear with me while i fumble and mumble my way through typing out what's in my head in a comprehensible manner.

If trying to add lines to a script, a .BCS file, how does one easily add to anywhere within the script.

Allow me to explain what I mean. I know, roughly, about extend_top and extend_bottom but let's say I wanted to add lines somewhere in the middle instead, is there:

1) An easy enough way to do this?

2) Does it always work out? I mean, let's say other mods add to the script in question then if i'm trying to add something by line number...well, the number of lines will have changed and so my additions would end up in the wrong place, causing real problems.

3) Is it necessary? What I mean by this is, would it really be that inefficient to copy out the conditions you would have used from where you are trying to add and simply use extend_top/extend_bottom?

Perhaps some of the above is clearer with an example. I want to add a new line to the actions within the following coding block (is that the right terminology here? I refer to the whole block from IF to END, regardless)

[codebox]IF
Global("WorkingForBodhi","GLOBAL",1)
Global("SpawnBodhiFriends","AR0801",0)
THEN
RESPONSE #100
SetGlobal("SpawnBodhiFriends","AR0801",1)
CreateCreature("ANTENOS",[750.1758],14) // Antenos
CreateCreature("CHORE",[795.1019],14) // Chore
CreateCreature("FETCH",[575.862],10) // Fetch
CreateCreature("FOOD",[1451.1052],2) // Food
CreateCreature("COHNTA",[1167.498],10) // Cohn Ta'glaen
CreateCreature("LAUNE",[514.696],2) // Meredath
END[/codebox]

How would I go about doing this? I guess things are done by line number, but i'm unsure of the method(s).

If some other mod(s) changed the whole script from which this block is obtained, then I could run into real problems. The easiest solution in my mind is to just extend_bottom the following to the script file, with my own actions:

[codebox]IF
Global("WorkingForBodhi","GLOBAL",1)
Global("SpawnBodhiFriends","AR0801",0)
THEN
RESPONSE #100
My Actions
END[/codebox]

This is what I meant by 3) above. Is it a problem to be doing this a lot? I have no idea what kind of script size becomes a problem, I sincerely doubt it affects me directly right now, but just hypothetically speaking? I want to do things the right way and not cause any slowdown in script running, obviously.

[Mike1072]

I think the easiest thing to do would be to determine where exactly you want your code to hook into, and then do a REPLACE_TEXTUALLY. REPLACE_TEXTUALLY is a search/replace function. As an example:

COPY_EXISTING ~script1.bcs~ ~override~
  DECOMPILE_BCS_TO_BAF
  REPLACE_TEXTUALLY EXACT_MATCH
	~SetGlobal("SpawnBodhiFriends","AR0801",1)~
	~SetGlobal("SpawnBodhiFriends","AR0801",1) MyFirstActionHere() MySecondActionHere()~
  COMPILE_BAF_TO_BCS
  BUT_ONLY_IF_IT_CHANGES

In the example I add two actions after all instances of SetGlobal("SpawnBodhiFriends","AR0801",1) in the file.

[prune1]

Sounds like exactly what I need. Thanks a lot.

[prune1]

Another query: Could someone explain or direct me to a tutorial that explains how the <<<<<<<< fileName fileBody >>>>>>>> .TP2 action works? The one about creating inlined files. It's all a little unclear.

I have a vague idea from reading the Weidu documentation, but could do with concrete examples and info on exactly what is going on.

Why would you use such an action? It seems to create a file via the .tp2 as far as i can tell, if so...why? Why bother, why not just create the file you want the 'normal' way.

Let's use the weidu docs example as a starting point, so i can ask some questions:

BEGIN ~MyMod Component 1~

<<<<<<<< .../mymod-inlined/myfile.baf
IF
True()
THEN
RESPONSE #100
Kill("Anomen")
END
>>>>>>>>

COMPILE ~.../mymod-inlined/myfile.baf~

Right, so the way I interpret this is as follows: From IF to END is the file, inclusive of the IF and END, and it is a .baf file, which is then compiled to a .BCS as per normal.

First of all, why would you do this, rather than creating an actual, separate file, say file1.baf with that code, and just compiling it?
My guess would be if you wanted to create a hotfix type thing, then it is easier to update just the .tp2 and distribute that, rather than a new file AND changes to the .tp2? Other than that, I do not see other uses immediately.

Also, where does this file now go? To the override?

How does it get used? Does it not need to be attached to some area, or .CRE? (This is more a general question about scripts now, so fill in my lack of knowledge someone, please - if a .BCS is not "attached" to some area or creature does it act as some sort of global script file that is always running? I realise in this particular case whoever and whatever it may be attached to, Anomen will die, since true is always, er, true...).

Moreover, how do I access it and attach it to any area or .CRE since it isn't an actual file?

Some of the above questions may not even make sense, so just correct me if i'm off track completely. Thanks.

Edit: Another little, unrelated to the above, query:

What, if any, is the limit to file size names. I came across a mention of such a limit in the following tutorial http://www.katbella.net/npcguide.htm, where it mentions that:

NPCs need to have a few different files to function properly in the game. This includes files that will hold all the NPCââ?¬â?¢s dialogues if they are in the party, bantering, leaving the party, or just having their introductory talk with the PC. You can name these anything you want as long as it's 7 letter or less.

I'm unsure if this refers just to .d files being 7 characters or less, or any and all files (.d, .baf, .CRE etc) should always be 7 characters or less?

Also, what is the reason for this? I think I saw somewhere, someone saying 8 characters was the limit; I don't have a source for this one but any clarification on the matter would be great.

Edited by prune1, 18 November 2009 - 07:39 AM.

[Icendoan]

Another query: Could someone explain or direct me to a tutorial that explains how the <<<<<<<< fileName fileBody >>>>>>>> .TP2 action works? The one about creating inlined files. It's all a little unclear.

I have a vague idea from reading the Weidu documentation, but could do with concrete examples and info on exactly what is going on.

Why would you use such an action? It seems to create a file via the .tp2 as far as i can tell, if so...why? Why bother, why not just create the file you want the 'normal' way.

Let's use the weidu docs example as a starting point, so i can ask some questions:

BEGIN ~MyMod Component 1~

<<<<<<<< .../mymod-inlined/myfile.baf
IF
True()
THEN
RESPONSE #100
Kill("Anomen")
END
>>>>>>>>

COMPILE ~.../mymod-inlined/myfile.baf~

Right, so the way I interpret this is as follows: From IF to END is the file, inclusive of the IF and END, and it is a .baf file, which is then compiled to a .BCS as per normal.

Yes. Although, I don't think you can nest inlined files (have one inside the other).

First of all, why would you do this, rather than creating an actual, separate file, say file1.baf with that code, and just compiling it?
My guess would be if you wanted to create a hotfix type thing, then it is easier to update just the .tp2 and distribute that, rather than a new file AND changes to the .tp2? Other than that, I do not see other uses immediately.

It is useful if you want something temporarily, such as a .bat file to organize files and folders, or to delete something. Immediate use isn't obvious, but it can be used. Another usage of it is the COPY flags, where you can COPY_EXISTING to an inlined file, which if you want to put your dialogue on the top of an already existing dialogue file without changes, you can.

Also, where does this file now go? To the override?

When it is COMPILEd, it goes to the override. If it is COPYed, it goes to the target directory. In both, the file is written to the hard disk and becomes a real file. If you do nothing with it, it is lost once WeiDU.exe closes (but whenever it runs through the .tp2 it will be generated again)

How does it get used? Does it not need to be attached to some area, or .CRE? (This is more a general question about scripts now, so fill in my lack of knowledge someone, please - if a .BCS is not "attached" to some area or creature does it act as some sort of global script file that is always running? I realise in this particular case whoever and whatever it may be attached to, Anomen will die, since true is always, er, true...).

Scripts do need to be 'attached' to things to be used, and this includes the game engine. Baldur.bcs is a script which the engine runs all the time, and is used globally. Also, some other scripts are referenced, such as a cutscene script for the PocketPlane Spell.

Once copied or compiled, your inlined script to kill Anomen becomes as real as any other script, so, it is used in exactly the same way.

Moreover, how do I access it and attach it to any area or .CRE since it isn't an actual file?

The moment it is COPYd or COMPILEd, it becomes a real file and is written to the hard disk, ready for the game to use. You would attach it to a .CRE or whatever as if it had always been a real file written to the hard disk.

Some of the above questions may not even make sense, so just correct me if i'm off track completely. Thanks.

Edit: Another little, unrelated to the above, query:

What, if any, is the limit to file size names. I came across a mention of such a limit in the following tutorial http://www.katbella.net/npcguide.htm, where it mentions that:

NPCs need to have a few different files to function properly in the game. This includes files that will hold all the NPCâââââ??¬Å¡¬ââââ??¬Å¾¢s dialogues if they are in the party, bantering, leaving the party, or just having their introductory talk with the PC. You can name these anything you want as long as it's 7 letter or less.

I'm unsure if this refers just to .d files being 7 characters or less, or any and all files (.d, .baf, .CRE etc) should always be 7 characters or less?

Also, what is the reason for this? I think I saw somewhere, someone saying 8 characters was the limit; I don't have a source for this one but any clarification on the matter would be great.

I believe 8 characters to be the limit to which the engine understands things. I assume all files have this limit, but this may not be the case.

Icen

Edited by Icendoan, 18 November 2009 - 08:06 AM.

[prune1]

It is useful if you want something temporarily, such as a .bat file to organize files and folders, or to delete something. Immediate use isn't obvious, but it can be used. Another usage of it is the COPY flags, where you can COPY_EXISTING to an inlined file, which if you want to put your dialogue on the top of an already existing dialogue file without changes, you can.

Why would one prefer this over APPEND_FILE, or EXTEND_TOP/BOTTOM in regards to making non-overwriting changes to files, if i'm understanding correctly?

When it is COMPILEd, it goes to the override. If it is COPYed, it goes to the target directory. In both, the file is written to the hard disk and becomes a real file. If you do nothing with it, it is lost once WeiDU.exe closes (but whenever it runs through the .tp2 it will be generated again)

When you say 'do nothing with it', am I right in saying you mean if I do not COMPILE, or COPY or perform some similar action to actually 'save' the file somewhere, it will disappear?

Or do you mean I must perform some other action with the file in order for it to remain created? i.e. COMPILE/COPY is not enough.

Scripts do need to be 'attached' to things to be used, and this includes the game engine. Baldur.bcs is a script which the engine runs all the time, and is used globally. Also, some other scripts are referenced, such as a cutscene script for the PocketPlane Spell.

Yes of course, silly of me, I meant in relation to .d files and such, rather than scripts. Keep reading, I'll explain more in a minute.

Once copied or compiled, your inlined script to kill Anomen becomes as real as any other script, so, it is used in exactly the same way.

Allright, so this is the gist of the issue in some ways. This script should now be created, and since I COMPILEd it, I should be able to find the file in the override?

Now, it won't be active in any way though right, unless and until I specify a .CRE, or area file to attach it to, or if I call it within another script? But, as I said, it should be a file visible to me if I were to open up the override, or the target folder, correct?

The moment it is COPYd or COMPILEd, it becomes a real file and is written to the hard disk, ready for the game to use. You would attach it to a .CRE or whatever as if it had always been a real file written to the hard disk.

Excuse my ignorance again, but the way I attach scripts and so on to .CREs is via near infinity. Or more accurately I name the appropriate fields with the filename that will be made for it to use.
Does this work the same way? Is there any way via .TP2 actions to assign scripts?

I believe 8 characters to be the limit to which the engine understands things. I assume all files have this limit, but this may not be the case.

I appreciate the answer, but if you're not certain as you say, I'd like some other(s) to confirm it please.

Back to inlined files a sec, and let me just post a real example or two, which hopefully someone can lead me through, so I can get things straight in my head:

<<<<<<<<inlined/dialogues/are/gauche/imoenfixtake2.d
REPLACE_STATE_TRIGGER imoenp 3 ~Global("ImoenRunning","LOCALS",1)~
SET_WEIGHT imoenp 3 #-1
>>>>>>>>

COMPILE ~inlined/dialogues/are/gauche/imoenfixtake2.d~

The above is from the BG2 fixpack BETA core fixes.

So, it is creating a new file named imoenfixtake2.d, and replacing the trigger associated with state 3 with Global("ImoenRunning","LOCALS",1) in imoenp.dlg?
Then changing the weighting of state 3.
Then it compiles the file.

But I cannot seem to find the file imoenfixtake2.d/dlg, from the way I figure things above I should be able to right? But there is no file named imoenfixtake2.dlg in either the DLG files, nor the override.

Finally, could you achieve everything the above does with APPEND_FILE and/or EXTEND_TOP/BOTTOM? (Or do I mean REPLACE_TEXTUALLY perhaps, even...the point being, are there other methods other than this crazy inlining that I just do not seem to grasp). This was my first question, but just to reiterate.

I really seem to be missing something here quite clearly, so let me thank anyone who took the time to read all that and I really appreciate any help people can provide.

Edited by prune1, 18 November 2009 - 11:56 AM.

[Wisp]

When you say 'do nothing with it', am I right in saying you mean if I do not COMPILE, or COPY or perform some similar action to actually 'save' the file somewhere, it will disappear?

Inlined files are not so different from "real" files. If you have a "real" .baf file in your mod folder and do not somehow make use of it during installation of the mod, it will remain where it is and have no impact on the game. It's the same deal with a inlined script. The fact that it only exists while the mod installers are running doesn't change this.

Allright, so this is the gist of the issue in some ways. This script should now be created, and since I COMPILEd it, I should be able to find the file in the override?

Yes, if you COMPILE a inlined script, you will find the resulting .bcs file in your override and it will be as real as any other file there.

Does this work the same way? Is there any way via .TP2 actions to assign scripts?

You can use e.g. WRITE_ASCII to do this.

I appreciate the answer, but if you're not certain as you say, I'd like some other(s) to confirm it please.

Yes, 8 characters is as long as a file name can be.

But I cannot seem to find the file imoenfixtake2.d/dlg, from the way I figure things above I should be able to right? But there is no file named imoenfixtake2.dlg in either the DLG files, nor the override.

You are misunderstanding how those two D actions work. When that inlined .d file is compiled, they make changes to an existing file. They do not create a new file.

Finally, could you achieve everything the above does with APPEND_FILE and/or EXTEND_TOP/BOTTOM? (Or do I mean REPLACE_TEXTUALLY perhaps, even...the point being, are there other methods other than this crazy inlining that I just do not seem to grasp). This was my first question, but just to reiterate.

You could do it just as well with a "real" file called imoenfixtake2.d with the same contents.

[prune1]

Thanks for all the info to you, aswell as Icendoan and Mike1072.

I think I've got it now. This is what made things clearer:

You are misunderstanding how those two D actions work. When that inlined .d file is compiled, they make changes to an existing file. They do not create a new file.

I was desperately trying and wanting to find a file to assure myself I knew how it worked.

But I understand now, i've read over more of the weidu documentation and things are clearer now.

Let's say there was another line in that code for the .d file though, something like APPEND and then a state. Would it NOW need to create a file? I'm not sure, since it could just be treated as an action like the 2 you mention and simply make the change, or equally it could create the file and then APPEND the states from that.

And just to show I've been listening, my guess is it does not create the file, just as with the other 2 actions. Could be wrong though.

Edited by prune1, 18 November 2009 - 01:36 PM.

[prune1]

imoenfixtake2.D is never created as a file. An inlined file is treated as a file (by WeiDU), but the contents are held in memory, not stored separately on disk (since WeiDU eventually has to read all "real" files it uses into memory anyway, there's no functional difference between a normal "disk" file and an inlined file). If you define an inlined file (which is the entire contents from the newline after the inlined file's name to the closing 8>) but do nothing with it, then it's simply disposed of when WeiDU exits.

.D files contain a list of actions to perform on dialogue files. The most basic is BEGIN (where you define your whole dialogue), but there are tons. All .D actions specify a target dialogue to operate on (it's possible to modify hundreds of dialogues from a single .D file). With your example, IMOENP will be read (from either the override folder if it's already there, or it will be extracted from one of the game BIFFs), modified, and the complete compiled IMOENP dialogue saved to override.

The .D file itself is just a list of commands to feed WeiDU (like a .TP2 file); although it's common to have complete dialogues in a .D file that has the same name as the resulting .DLG, it's not necessary (you can decompile a copy of IMOENP.DLG to IMOENP.D, change the name of the .D file to ThisWillStillCompiletoIMOENP.D, and WeiDU will still output only IMOENP.DLG when the .D file is compiled). In this case, as an inlined file, imoenfixtake2.D is simply disposed of when WeiDU is finished.

Great. I understand now. I was looking at it the wrong way i guess, you're right the only output needed would be .dlg files and .bcs files, and it makes no difference whether the .d and .baf files they are compiled from are 'real' or not.

Appreciate all the help guys. My mind is at ease, for now.

Edited by prune1, 18 November 2009 - 03:23 PM.

[GeN1e]

First of all, why would you do this, rather than creating an actual, separate file, say file1.baf with that code, and just compiling it?

It's always handy to have one large file than a ton of tiny one-liners. Secondly, when passing code over forums you can just post tp2 code with 1-2 inlined files and tell how to install instead of packing an archive and uploading it somewhere. Having done so several times I find it incredibly useful.

[prune1]

First of all, why would you do this, rather than creating an actual, separate file, say file1.baf with that code, and just compiling it?

It's always handy to have one large file than a ton of tiny one-liners. Secondly, when passing code over forums you can just post tp2 code with 1-2 inlined files and tell how to install instead of packing an archive and uploading it somewhere. Having done so several times I find it incredibly useful.

Yes, I suggested that was the one use I could immediately see.

Anyhow, thank you all for the contributions, and you'll be pleased to know I actually made use of this inlining business in the latest update to my mini-mod (and here comes the shameless plug), so be sure to check out 'Zalnoya and the Shadow Thieves'!

Edited by prune1, 19 November 2009 - 12:06 PM.