Jump to content

Ascension 2.0.8 out; report bugs here


DavidW

Recommended Posts

@Liliana: thanks, that's reassuring.

@4udr4n: I have no idea: as you say, it's not my mod, and I'm not at all familiar with it.

Link to post
On 5/9/2020 at 1:17 PM, Austin said:

Hello! Found a bug while installing Ascension 2.0.8 and the Imoen Romance 3.9.6 mod. There is a condition in the bimoen25.d file that starts a conversation with Imoen about the forces of Bhaal (dialogue number 91)

ADD_STATE_TRIGGER bimoen25 91 ~Global("YagaShuraHeart1","GLOBAL",2)~

But in Imoen Romance, this dialogue is tied to Gromnir’s death and is forcibly started 15 minutes after his death (in bhaaltalks.d file). At this moment, the value of the variable YagaShuraHeart1 can in no way be equal to 2. And if both mods are installed at the same time, then the dialog tries to start, but cannot. The dialogue freezes, there is a problem with the movement of the player and Imoen, it is impossible to save and relax (the game constantly remains in the dialogue mode, but it cannot start). The second check of the variable in this file (for dialog 100) also causes a conflict with Imoen Romance.

To do this, you need to replace the lines in the bimoen25.d file with these: 

ADD_STATE_TRIGGER BIMOEN25 91 ~Dead("Gromnir")~
ADD_STATE_TRIGGER bimoen25 100 ~Dead("Yaga01")~

And also replace the verification data in the imoe25.baf file.

In this case, the conflict with the "Imoen romance" mod will be resolved (even while installing the Romance and the component "Improved Imoen-Player interaction" from Ascension).

In the attachment, these two files are modified (ready to be replaced).

Ascension fix Imoen Romance.rar 1.17 kB · 1 download

Firstly, this isn't a bug in Ascension. "YagaShuraHeart1" is set to 2 when you retrieve Yaga Shura's heart from the brazier in the fire giant temple; that's Ascension's condition for when Imoen's second special dialog is set (and has been since the mod was released 20 years ago). I've just tested it; it works fine. Similarly, Ascension's condition for the third talk is that the party have met Balthazar (which is when "MetBal" is set). This is a compatibility issue with Imoen Romance, not an Ascension issue per se.

Secondly, this proposed fix removes the conflict, but at the cost of modifying Ascension so that Imoen's dialog lines play earlier. I'm not willing to do that, as it's a change to Ascension developer intent and that's outside the scope of what I'm willing to do when maintaining someone else's mod.

Thirdly, the problem is occurring with this version of Ascension and didn't occur with previous versions. That's because previously the dialog blocks for Imoen could play just by chance, potentially very (unrealistically) early in the story. I added a gate to prevent that happening: I check for YagaShuraHeart1 and MetBal in the dialog file, not just in the script. Imoen Romance assumes those blocks are just there, and tries to call them; since it's trying to do so slightly early, and keeps doing so until it succeeds, the game stutters. Since this was my change, not in vanilla Ascension - and since Imoen Romance's preferred trigger points are only slightly earlier than mine - I'm happy to edit bimoen25.d to use Imoen Romance's slightly earlier checks. I believe this will avoid the incompatibility without the need to change imoe25.baf.

Fourthly, thanks for the research! 

EDIT: Just as a coding note, someone paying attention might wonder why this doesn't lead to a compatibility problem in Ascension itself: when Ascension calls for these same dialogs slightly later than Imoen Romance, doesn't that cause the same hanging? No, because Ascension's blocks have a variable which guarantees they only fire once. This is probably good practice if you're writing blocks to call a conversation, especially a third-party one that might have been triggered elsewhere. (I'm not showing off my own coding competence: I took it over verbatim from the original Ascension.)

Link to post
On 9/27/2019 at 5:43 PM, Arthas said:

I don't know if you can do anything about it... but know that

The new Ascension v2.0.6 is not compatible with Iylos, Edwin Romance, Wheels, Longer Road because these mods want to add content to BALTH2 from Ascension v1 that is no longer existing in Ascension v2.

This isn't a compatibility problem exactly, just a communications issue.

BALTH2 is the combat script used by Balthazar if he is on your side in the final battle. It's still in Ascension - but this version of Ascension splits the "You can recruit Balthazar" part of Ascension's main component into a separate component. So if you install "Rewritten final chapter" without "Balthazar can be redeemed", you don't get BALTH2. 

In general, mods that do things differently according to whether Ascension is installed or not may get a bit confused if you install some but not all components in the "Ascension" section of the new version. I can't fix that inside Ascension; the mods need to be edited to make finer-grained allowance for which bits are installed. (In Wheels of Prophecy that's my problem too, of course.)

In the meantime, the workaround is pretty simple: if you're using one of these mods, either install all or none of the components in the 'Ascension' subgroup. (Actually, I suspect that 99% of problems will be solved by making sure you don't install 'rewritten final chapter' without 'Balthazar can be redeemed'.

Link to post

Sorry for the offtopic, but I was triggered. Hope this doesn't come across as patronizing.

52 minutes ago, DavidW said:

I check for YagaShuraHeart1 and MetBal in the dialog file, not just in the script.

Adding additional checks in the dialogue file is usually not necessary and also not the best practice. It is sufficient to use the trigger variable used in the script and nothing more. The reason is what happened here: additional triggers can lead to a stutter if the additional triggers in the dialogue are not met for some reason. For Ascension alone it's no problem and I understand why Imoen's dialogue is tagged, because you wanted to prevent the engine to call this dialogue earlier because it is scripted into the banter file which gets called randomly by the engine as well. My statement was a general one for scripted dialogues.

57 minutes ago, DavidW said:

No, because Ascension's blocks have a variable which guarantees they only fire once. This is probably good practice if you're writing blocks to call a conversation, especially a third-party one that might have been triggered elsewhere. (I'm not showing off my own coding competence: I took it over verbatim from the original Ascension.)

Again, this works if you are dealing with dialogues in the banter B.dlg file which will be called eventually anyway. If you are talking about scripted dialogues then scripting them the way that the dialogue is only called once is actually bad practice because in case the dialogue start gets disturbed (because the player klicks the mouse or whatever), then the dialogue will not trigger, but the trigger variable will still be open, meaning: either the player triggers it instead of the PID by klick-initiating dialogue, or this dialogue will trigger the next moment a dialogue should fire - with the new dialogue then holding the queue until it is triggered by accident later. This is especially bad for scenery dialogues which would then fire way too late.

In your case here with Imoen's Dialogues in her banter file that's not such a big deal as the engine will call them eventually anyhow. Doing this in scripted dialogues in the j-file however would lead to the skipping and "queueing" of dialogues I described and let to a lot of bugs in the past, that is exactly why Kulyok wrote her tutorial "How to ensure your banters always run when you want them to", so that "skipped and queued" dialogues are no longer a problem. This gave a new kind of bug of course, the stutter bug. But that's a bug which can be fixed, whereas the skipping/queueing of unfired dialogues that are triggered only once is something that can happen randomly to any player wile playing.

To prevent Ascension to trigger Imoen's dialogues a second time after Imoen Romance already did, best practice would be the script checking the variable of that dialogue, e.g. Global("ExpBImoen10","LOCALS",2) for the "Global("YagaShuraHeart1","GLOBAL",2)" dialogue, assuming Imoen Romance doesn't delete this.

In short: for Imoen's dialogues in Ascension using trigger variables that are set once and have nothing to do with the dialogue they are supposed to trigger works, but only because the dialogues are in the B.dlg.  The "Interact()" action can be disturbed by the player giving a click command before it is executed. This wasn't perceived as a bug probably because the engine calls the banter file randomly anyhow so the dialogue could trigger later.

 

Link to post

That's interesting; thanks. This is my relative inexperience with NPC mods showing up - I guess what makes sense for the banter file isn't what makes sense for the main NPC dialog file. And I didn't know that about Interact() being interruptible.

But wouldn't it make sense, in that case, to set the Interact() to repeat on (say) a 12-second timer until the dialog fires, rather than just having it trigger constantly? Stutter bugs are quite serious, after all - I'd rather code in a way that's properly proofed against it.

(EDIT: and no, it doesn't come across as patronizing.)

Link to post

Hi, for this compatibility bug i am going to make some changes.

I believe the best way to make everything work is to remove checks introduced in BIMOEN25.dlg, that way the talk will trigger from any of our timers (or the games own banter engine).

Let me know what you think.

Link to post

tipun from the Russian forum about Baldur's Gate asked to write the following (he is not registered here): 

"Local variables can also cause problems with starting dialogs. According to my observations, they work in B * .dlg, in other dialogs not always. In my IWD2 port, in the Oswald dialog, there were local timers (timers are the same variables), and for a few checks the necessary dialogue never started. And after changing the type of variables to global, everything worked."

Link to post

I don't think it's also dependent whether we talk about a joinable or non-joinable NPC. As far as I know, local variables are not stored in the savegame for non-joinable characters, which makes their use for quests unreliable.

Link to post

I think I have it fixed on my side; no need to do anything on yours.

The problem with removing the checks entirely is that (since banters are called randomly from time to time) you might by chance get the banter implausibly early. I assume that's why Imoen Romance's original writer added them, and it's why I put them into Ascension. They just need to be coordinated - but I've done that (locally) in Ascension now, so I think you can leave Imoen alone for this one.

Link to post
2 hours ago, jastey said:

I don't think it's also dependent whether we talk about a joinable or non-joinable NPC. As far as I know, local variables are not stored in the savegame for non-joinable characters, which makes their use for quests unreliable.

Local variables are stored for non-joinables. (The engine represents them as an opcode-187 effect attached to the CRE file.)

Link to post
On 2/15/2020 at 1:54 AM, Bartimaeus said:

I wish weidu didn't spit out "INSTALLED WITH WARNINGS" for this, since it can be a bit misleading. Basically, the mod expected to modify a file (specifically an item), but didn't end up doing so. That's all the warning is there for. It is almost 99% sure to be inconsequential.

I'm glad it does; otherwise the modder doesn't notice bugs. In this case, it was a clash between the beta fix component of BG2 Fixpack and Ascension - not game-breaking, but Melissan's spear ends up more powerful than it's supposed to be. Now fixed, but I'd probably never have known about it without that warning.

Link to post
1 hour ago, DavidW said:

Local variables are stored for non-joinables. (The engine represents them as an opcode-187 effect attached to the CRE file.)

Thanks!

Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...