Discussion on 'Converting existing mods to the EE engine'

[jastey]

I am asking because OUTER_SPRINT etc. variables are forgotten from one install to the next, so this has to be executed every time. The (in my case) copied UTF-8 encoded files stay in the folder until the whole mod is deinstalled, though, so this is an actiuon that needs to be executed only once. For this "once" I need a possibility to detect whether this action has already be performed on an earlier run of the setup. I understand the variable pro5 suggested does not do this (as it is only valid for the current install process), but i might be mistaken.

[pro5]

I am asking because OUTER_SPRINT etc. variables are forgotten from one install to the next, so this has to be executed every time. The (in my case) copied UTF-8 encoded files stay in the folder until the whole mod is deinstalled, though, so this is an actiuon that needs to be executed only once. For this "once" I need a possibility to detect whether this action has already be performed on an earlier run of the setup. I understand the variable pro5 suggested does not do this (as it is only valid for the current install process), but i might be mistaken.

 

No, you're right, the file placeholder is a safer route. It's still a good idea to wrap ALWAYS with variable check too - it speeds up installation and prevents WeiDU from re-loading all the variable libraries and all TRA files (assuming you use LOAD_TRAs in there) over and over again for each component.

 

To avoid clogging backup folder issue, I think alternatively you could also use COPY with + (OPT_NO_BACKUP) option. That should prevent WeiDU from backing up the tra files in the first place, and the destination file is simply overwritten each time. Keep in mind this also means that copy won't be undone upon component uninstall, though - which may or may not be a desirable thing here.

[jastey]

Not undoing the text file copying is not good, as I tend to edit them, and, most of all, then (in my case of the copying) the texts converted for BGII (original) would be gone. This might be solved by having two different resource folders and just copying the needed one to the path specified by AUTO_TRA, though.

 

But I see now the use of the variable. So, the variable could be used in addition to the marker file to prevent the ALWAYS action be executed several times in one install process. Thank you, that's a good idea.

[Avenger]

Special characters like hash (#) are ok in any 2da, if they are not in column names. (Probably row names are also forbidden, i don't know).

So, you can use (#) in resref, but you cannot use # in kit names.

 

Since kit names are not restricted to 8 characters, you can freely replace them like this WONDER#KIT --> WONDER_HASH_KIT

[Skye]

I'm working on a kit for BG:EE, and I plan on making use of the new features.

 

I took a quick look at the function provided by CamDawg to make sure I accounted for everything, and it seems more complicated than I expected (spent half an hour deciphering the code because I'm rusty).

 

Anyway, since I'll be extending the files with explicit values, can I simply use APPEND_COL to add my values to each 2DA that lists classes column-wise? The column listing is really somewhat annoying. Is there a reason why OH doesn't always list the dynamic side of the table vertically? I thought they were trying to make our lives easier.

 

Also, I'm assuming APPEND_COL appends to each row indiscriminately since it doesn't have a parameter for a minimum number of columns. Do I need to start each string with ~$ $~ to account for the header? If I do, is that gonna append white spaces to the header? And if so, would it be best to clean up trailing white spaces?

 

I'll probably end up trying all of this regardless, but I figured I'd ask anyway. Maybe someone else is gonna have the same problem before WeiDU's ADD_KIT gets extended to include the new features (if it does).

 

On a side note, shouldn't the "CDNEWKIT" in the following code (from CD's function) be enclosed in tildes since it's a string?

 

SET_2DA_ENTRY 0 (col_num - 1) col_num CDNEWKIT

[Jarno Mikkola]

Anyway, since I'll be extending the files with explicit values, can I simply use APPEND_COL to add my values to each 2DA that lists classes column-wise? The column listing is really somewhat annoying. Is there a reason why OH doesn't always list the dynamic side of the table vertically?

I suggest that you use this approach to add the additional features to the EE game for the kit.

[Skye]

Ah, I see Wisp has already done all of the heavy lifting. I think that should do lovely, thank you.

[jastey]

CamDawg: There is an error in the attached "bgee_cpmvars.tpa".

 

This:

/* BGT Chapters */

OUTER_SPRINT "tutu_prologue" "1"

 

needs to be this:

 

/* BGT Chapters */

OUTER_SPRINT "tutu_prologue" "0"

[Jarno Mikkola]

CamDawg: There is an error in the attached "bgee_cpmvars.tpa".

Are you absolutelly sure about it ? As the way I understand it is that the Tutu uses the normal BG1 progression, while the BGT uses the "BG1"+1 chapter numbers... meaning that if say you program the chapter numeration to that of the tutu/BGEE, you could replace the number with this variable, and the BGT get's a +1 to it/them, while the rest will use the one without... yeah, you could name the variable name as bgt_prologue_additional_one, but that might be a little long and then it won't get replaced by the added functional options. This is why the comment is there actually...

[jastey]

This is what I use in the code for setting the journal entries in the prologue:

IF ~Global("Chapter","GLOBAL",%tutu_prologue_reset%)~ THEN DO ~SetGlobal("C#Q08_TalkedToTrun","GLOBAL",5) AddExperienceParty(150) ReputationInc(1) %ERASEJOURNALENTRY_10055% SetGlobal("Chapter","GLOBAL",%tutu_prologue%) AddJournalEntry(@10054%QUEST_DONE%) SetGlobal("Chapter","GLOBAL",%tutu_prologue_reset%) EscapeArea()~ EXIT

IF ~GlobalGT("Chapter","GLOBAL",%tutu_prologue_reset%)~ THEN DO ~SetGlobal("C#Q08_TalkedToTrun","GLOBAL",5) AddExperienceParty(150) ReputationInc(1) %ERASEJOURNALENTRY_10055% AddJournalEntry(@10054%QUEST_DONE%) EscapeArea()~ EXIT

 

And for this the %tutu_prologue% has to be "0" for BG:EE or the journal entry is not put into the journal correctly. I tested it.

[Jarno Mikkola]

And for this the %tutu_prologue% has to be "0" for BG:EE or the journal entry is not put into the journal correctly. I tested it.

That's not the entire code... as you need to set the value... and you can do this with the GAME_IS function, so if the answer is bgt, you reset the variable to 1 just above the code, while the others set to 0 at the start. This will allow you to use the same code in BGT, Tutu and BG1EE..

 

As in:

 IF GAME_IS ~tutu bgee~ THEN BEGIN
OUTER_SPRINT "tutu_prologue" "0"
END

IF GAME_IS ~bgt~ THEN BEGIN
OUTER_SPRINT "tutu_prologue" "1"
END 

 

Which is then followed by the above code of yours... or the END's might be in the wrong place, kill me, you can't, try as you might....

[jastey]

That is what I am doing with the code using the OUTER_SPRINT variables I posted, and yes, that's all the code I need for writing the correct journal entries in all BG1 games. What I did not post, however, is the definitions of "%tutu_prologue_reset%" and "%tutu_prologue%" for BG1, Tutu, BGT, and BG:EE.

 

And I don't think game_is works in a .d file, I really don't. This would be heaven, and I am pretty sure I'd heared about it.

[Jarno Mikkola]

And I don't think game_is works in a .d file, I really don't. This would be heaven, and I am pretty sure I'd heared about it.

Usually one doesn't set too many such restrictions to the .d file, as I thing reading and setting the GLOBAL's is all that's done in BG2 games, as the the scripts themselves do all the hard work(journal entries etc as a responce of the globals variables), and there's the use a different .d file for different parts of the game, one in BG1, one in SoA and one in the ToB... as that's how it's nativelly build into the difference of SoA and ToB.

As if you set different dialog restrictions too heavily and it fires at a different part of the game, you run the risk of non complete dialog tree firing constantly with "no reply" even if the start of the conversation is from the player. Or some such things... as the dialogue firing system is the StartDialogNoSet(player1) .

[jastey]

Not sure I can follow you, sorry.

[Jarno Mikkola]

Not sure I can follow you, sorry.

Then let me make a bad example.

 

You have 3 portions for one dialogue, first inspires the talk and it's in the script:

IF

//timer x runs out one circomstance among Global("hey","GLOBAL",0)

THEN

RESPONSE #100

SetGlobal("hey","GLOBAL",1)

StartDialogNoSet(player1)

END

 

Part 2: Then you have the actual .d dialog response to that that sets the "hey" global to 2 or what ever (higher) value you want if depending on the players response.

Part 3: And then you have the script responding to the new globals, that define the next action, by setting the global to a higher value, making journal entries and other actions like setting up the next timer to a value that are needed for it.