jastey

Hey, it was only two weeks or so. And BeamDog upated to 2.6.6 shortly after the official 2.6 announcements so waiting a bit before spending time on big updates makes sense. Plus, doing the update needs time, too. I'll only believe k4this to be gone from EET maintaining when he posts here a good bye note.

I sense sarcasm here.

The mod updates to v7.2! Changelog: - Imoen should initiate kickout dialogue in BGII.

Thank you!

No. (Would this be possible?) I will make Ascalon's Mods real repos sometime in the future, Tales of Anegh too, probably.

Is this about GitHub accounts being considered by PI? In this case, I'd like to apply for https://github.com/Gitjas too.

@Ladon thanks for the kind words! There is info on compatible mods here.

Thanks for your answers!

@AL|EN thanks for your answer!

A player has the following error message trying to install my Solaufein mod: Full error message here. It was for EET installation. Where does this error message come from? The player said he was using PI. Is this from Project Infinity, @AL|EN? Is the kit limit valid for EE(T) at all? Also, Solaufein's kit is not available for the PC. This shouldn't count into the 256 kit limit then? Do I need to change something in the mod?

SoD.

Nah, input is always welcome!

@The_Baffled_King the example is how it looks for one of the variables, the only thing that makes my problem more complex is that it's up to 65 variables which can be set to any value in several dialogues along the game of which I do not know in which order the player encounters them.

Nah, I just remembered I've seen this recently.

That is from UB. I filed an Issue here. EDIT: sorry, that was for BGT, though. In my EET the 103012 + 103013 give the correct descriptions for BLUN11.itm.

@argent77 thanks again for your answer! @The_Baffled_King I'm not sure I got your reply correctly, but adding x additional transactions with different triggers and different actions to account for the status of the group's knowledge is not an option. It would not work if it's a state with reply options for once, and for dialogue states with transactions it would skip all existing ones, making the mod highly incompatible with other mods that might have added transactions to the exiting onces. Plus, I have 18 variables with up to 5 states. But maybe I got what you said wrong. What my mod does currently is ADD_TRANS_ACTION to the dialogue states in question and then the value set will be evaluated via script. (The mod also adds variables via script where appropriate.)

@argent77 super cool! I could add a "set area script override" script block to baldur.bcs that changes the area script, then it would be one additional script block only and it would cover all areas (and NPC mods too as they could also set the variable if necessary). This is the same mechanics as in NPC banters in SoD (where the area script is set via the NPC override script). A question to this: where exactly is "the" area script defined - I mean the standard AR/bdxxxx.bcs that is attached to each area file. I think I get confused because I know the OVERRIDE, CLASS, RACE etc slots from cre files - where all the individual actions are inside the OVERRIDE and setting this to nothing would just "delete" it. Is the "normal" area script as it was in the classic engine a slot like these categories or is this something different? Because the possibility to set the area script to something else and reset it by setting it to "" did not exist in BGII, did it? I'm not sure I understand this sentence, but if I trigger the area script change via baldur.bcs is shouldn't make any difference, right? I see two possible problems: 1. In case the area script of the current area is set to the example script myscript.bcs and the player changes areas while it runs - this might mess up either my script or the area script of the left area? I could prevent this by adding a "if this script was called (or is still active) but no variable is detected, reset to the normale area script" fail safe. But this technique is also used for NPC banter which take a while to complete so it should be kind of stable. I never tried to leave an area while they happened. 2. This procedure of set variable -> call baldur.bcs -> call myscript.bcs -> reset area script might take a little moment. It could fail to set my variables just in case e.g. two (paused) dialogues are started one after the other in too short time for the scripts to run through. If the second dialogue (as an example) sets the same variable to a lower number, the higher number could be lost because the scripts didn't finish running. Same situation in case there is a cutscene with a dialogue afterwards, maybe. I would assume chances of this are rather slim, though.

Thanks for your answers. Switch(): I'm not sure. If I understand correctly the Switch() trigger would give different responses depending on what value the according variable specified has. What I need is a way to count a variable up - and only up, despite the value of another trigger variable jumping from lower to higher ot lower values. An example, although I'm sure you don't need it to understand. Let's say I have a variable KnowsLocation which keeps track whether A Location is known to the group. KnowsLocation = 1: group heard about it KnowsLocation = 2: group knows how to travel there KnowsLocation = 3: group visited The Location. What I want to prevent is that, after already traveling to this example area, they might hear it being mentioned by someone else which would set KnowsLocation back to "1". If I do not use another set of variables to keep track this would mean that although the party already visited, the KnowsLocation would be reset to a value which would indicate that they only heard about it, giving NPCs and quest characters all sorts of wrong reply options and reactions. Ooh, that's a good idea. I didn't think about this. That's a really cool idea. I could do the same to area scripts, actually. Instead of having all 250 script blocks I could set one extra trigger variable which sets the area script to another that does the "variable setting" and afterwards changes back to the area script in question. This would mean I have more files in the override unless I'd find a smart way to use only one script for all areas. Would there be any obvious reason not to use this for area scripts? I know NPC banter are triggered this way, to it should be save or would this be a "trick" that could mess up area scripts if too many mods would use it too intensely? Also, can I be sure that in SoD, area scripts of the master area are always also executed in the "lower" areas attached to it or is it not that trivial?

What would the impact on an area script or an NPC override scrip be? Would such an amount of script blocks lead to any lagging/ impact with regard to the specific areas and / or the NPC in question?

I could decrease the number of blocks significantly by not working with variables that get counted up but just using unique variable names for all instances. That would mean I'll introduce ~80 global variables. The concept of the mod is tracking knoweldge the party gathers. Depending on how detailed the info is, the value of the variable gets counted up. This means that I need script blocks that keep track of what the group already knows in case they encounter an info point which would decrese the variable. If I'd work with unique variables for all instances I can just set the variables at the info points (e.g. in dialogues) and wouldn't have to care about variables being decreased again. It would mean I'd have to work with OR structures to know what is already known to the group, though, as I wouldn't be able to work with GlobalGT/GlobalLT any more. I'm not decided that would be a good idea yet, as it would mean I wouldn't be able to use OR structures for more than one variable(group) any more.

If I add many script blocks to (bd)baldur.bcs (bdbaldur.bcs for BG_SoD, baldur.bcs for EET), is there a noticeable impact (lagging etc.) to be expected (EE engine)? I'm talking about ~250 script blocks for SoD. I'll tagg all of them with some kind of %IT_IS_SOD% variable in the hopes it will make the engine skip them faster in the other parts of the game. All of the script blocks are true once max.

Hi Guest mindrot, please post the contents of your weidu.log here inside a spoiler.

At least i didn't run into one so far, and never heard of any. As I said, If you look at some talkative NPC mods I would assume that's more dialogue states (also with triggers) than you'd need for your BG1 - flexible - story mod idea. One thing I don't know is if you'd make the order inside the dlg arbitrary and WEIGHT all dialogue states, whether that would have any influence. What I mean is that most NPC mods just give the dialogue states unique triggers so the engine searches from top to bottom until it finds the true one. Maybe it takes longer if the whole file needs to be checked because there are WEIGHTed states. But then, I guess the engine would have to check the whole dlg always to find WEIGHted states, so it probably looks through the whole file anyway. - I'm not a good source for these kind of questions, though. I'm rather ignorant with regard to which actions get processed first or instantly or whatever, as long as it works in the game. Exactly. If you have a look at Ajantis' PID in BG1NPC (bg1npc/pid/x#ajpcfl.d) and imagine all those different states combined to (almost) one (I think I separated between flirt and engaged), you get an idea about the scope of what made the classic engine hickup.

Are you concerned with dialogue states per dlg or with reply options in one state? For the former I don't see a problem (I don't think any dlg hit a wall and some mod NPCs have a lot to say). For the latter - I did recode Ajantis' PID because before hand it was one state and then all reply options with different conditions lead to the dialogue hang for a second or two before it opened - that was the old engine (Tutu), though. Split it up in several dialogue states sorted by conditions still having a lot of triggered reply options made it work fine.

Thank you very much for this!