Login | Register


All times are UTC + 1 hour [ DST ]


It is currently Wed Aug 15, 2018 6:41 pm




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: v3.0 bug carried over from v2.5
PostPosted: Thu Dec 31, 2015 9:25 pm 
Newcomer

Joined: Wed Aug 06, 2014 3:29 pm
Posts: 18
Location: Canada
There is this little problem that wasn't resolved in v3.0

The scripts/SOA/misc/aerie.baf can get conflicted with other dialogue:

IF
RealGlobalTimerExpired("MRAerieFriendshipTimer","GLOBAL")
IsValidForPartyDialog("Imoen2")
See("Imoen2")
See(Player1)
OR(2)
Global("MRAerImFriend","GLOBAL",0)
Global("MRAerImFriend","GLOBAL",4)
THEN
RESPONSE #100
IncrementGlobal("MRAerImFriend","GLOBAL",1)
StartDialogNoSet(Player1)
END

What needs to be done is:

IF
RealGlobalTimerExpired("MRAerieFriendshipTimer","GLOBAL")
IsValidForPartyDialog("Imoen2")
See("Imoen2")
See(Player1)
OR(2)
Global("MRAerImFriend","GLOBAL",0)
Global("MRAerImFriend","GLOBAL",4)
THEN
RESPONSE #100
IncrementGlobal("MRAerImFriend","GLOBAL",1)
END

IF
OR(2)
Global("MRAerImFriend","GLOBAL",1)
Global("MRAerImFriend","GLOBAL",5)
THEN
RESPONSE #100
StartDialogNoSet(Player1)
END

If this is not done, you may have to have Imoen force talk Aerie to start the friendship.


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Thu Dec 31, 2015 11:02 pm 
Priest(ess) of the Pink Mage

Joined: Tue Aug 05, 2014 5:06 am
Posts: 278
There's no functional difference in the code you wrote.

Just tested it and it triggers fine, could be some other mod you have installed?


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Sat Jan 02, 2016 9:17 pm 
Newcomer

Joined: Wed Aug 06, 2014 3:29 pm
Posts: 18
Location: Canada
Usually, it will trigger normally. There is, however, a functional difference. If another dialogue triggers after the current script, the imoenaerie dialogue will not, and a force talk becomes necessary. The revised script, in these circumstances, will retrigger, and the intended dialogue will appear as normal. It is the old trick used by virtually all normal dialogue generating scripts. The first of two scripts gates itself and sets the secondary trigger, after checking for the conditions required for the dialogue. The second script triggers the dialogue but does NOT gate itself; the gating is handled by the dialogue. This is what ensures that the dialogue occurs.


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Sat Jan 02, 2016 11:36 pm 
Priest(ess) of the Pink Mage

Joined: Tue Aug 05, 2014 5:06 am
Posts: 278
the problem is another mod script is not gating the dialogue correctly.

Your second block essentially is a loose check 'trigger all the time until something else (the dialogue) sets the variable not 1 or 5'.

Your situation works like this

1. Another mod sets a global that evaluates to true in Dialogue file, BUT DOES NOT TRIGGER A TALK

2. If the dialogue state is the lowest weighted dialogue that evaluates to true, any startdialog (anywhere from any script file from any mod) will trigger this particular mod's dialogue.

3.Your second script block essentially will keep triggering EVERY dialogue that evaluates to true until the dialogue with its global is hit.

Regardless in these scenario's, this is a workaround to essentially fix other mods doing something wrong so its not a problem of this mod.

However there is a greater problem here, script files are executed in this way

1.Run through it, if a block is parsed then start from the top again
2. If Continue() is used, keep parsing the file instead of starting over BUT nothing is actioned till the end of the script being parsed (which means thing's are queued).

Now a problem arises because your first script block will execute and gate itself true, but it's a failed gating because it forces the script to be re-parsed before hitting the second block which can cause all sorts of problems.


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Mon Jan 04, 2016 8:38 am 
Newcomer

Joined: Wed Aug 06, 2014 3:29 pm
Posts: 18
Location: Canada
If I have this right, I think it is a bit more complicated than that. If (as I believe) the finite state engine runs processes asyncronously, It does not require that another mod set a true state without starting a dialog. If it's true state is set prior to calling for a dialog, and another process interrupts or intervenes, the same problem occurs with your current code. I'm sorry I called it a bug but, even without asyncronous problems, I think it wise to protect against other mods over which one has no control.

I didn't really follow your last bit. I was under the impression that the script parsing completes a cycle when it finds a true without a continue (or hits the bottom, of course). I have been assuming that, at that point, cycles are made available for other scripts and the one just finished goes back into some kind of queue. I do not know how IE handles its queues, but the choice of method will have been selected for efficiency. There is a limit to how many processes/threads can be running at the same time, so queue management is critical. I know because I had to shoot a deadly-embrace bug once. It wasn't pretty.


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Mon Jan 04, 2016 9:22 am 
Priest(ess) of the Pink Mage

Joined: Tue Aug 05, 2014 5:06 am
Posts: 278
If all mods were coded in this way for dialogue

Mod 1
IF
See("Badguy")
Global("mod1talk","GLOBAL",0)
RESPONSE #100
SetGlobal("mod1talk","GLOBAL",1)
StartDialogNoSet(Player1)
END

IF ~Global("mod1talk","GLOBAL",1)~ THEN BEGIN
SAY ~something~
IF ~~ THEN DO ~SetGlobal("mod1talk","GLOBAL"2)~ EXIT
END

Mod 2
IF
See("Badguy")
Global("mod2talk","GLOBAL",0)
RESPONSE #100
SetGlobal("mod2talk","GLOBAL",1)
StartDialogNoSet(Player1)
END

IF ~Global("mod2talk","GLOBAL",1)~ THEN BEGIN
SAY ~something~
IF ~~ THEN DO ~SetGlobal("mod2talk","GLOBAL"2)~ EXIT
END

It would be impossible for there to be any conflict, no matter install order or player action (it is not interruptible) because each script block locks down the dialogue talk to occur in that exact moment the block is parsed.

It is also better for debugging because if you coded the dialogue wrong and it doesn't trigger you can check the global to know your script block did trigger.

For your code you have a problem that you do not lock down the dialogue to occur exactly in the script block, forcing another cycle of all scripts to be parsed again before hitting the second block.

A script cycle is usually one second on the least busiest area and can take longer the busier the area for a whole cycle ( Override, Area, Specifics, Class, Race, General and Default)

In the time between your first block and second,
all these other scripts for the area, every actor and every creature needs to be parsed again before your second block will be triggered and we have no idea what will happen.

Your npc will stop moving for seemingly no reason, as a script block being parsed for a creature will stop the creature moving (this is the reason why some people experience permanent stuttering of characters, something is repeatedly triggering in their script), which is made weirder if the script block has a See(Player1) and you move away from the npc.

So you'll have a situation where you might be moving your party, your first script block triggers and Imoen stops moving all of a sudden.

Now does the second block trigger after 1+ seconds? we don't know, if the blocks are protected by See(Player1) then you moved out of her range so it won't trigger and the player will notice imoen for some reason stopped listening to their commands.

What if the dialogue is supposed to happen when you see another npc? what if he teleports away quickly after you see him? or dies? like the teleporter bhaalspawn?

Then my code will work, but your one may not work.


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Mon Jan 04, 2016 5:23 pm 
Newcomer

Joined: Wed Aug 06, 2014 3:29 pm
Posts: 18
Location: Canada
"It would be impossible for there to be any conflict, no matter install order or player action (it is not interruptible) because each script block locks down the dialogue talk to occur in that exact moment the block is parsed."

I assume you mean that the StartDialogueNoSet locks down the dialogue function when it is executed, because there is no way the script can lock down a specific chunk of dialogue code. Now, the StartDialogueNoSet is (as far as I can tell) NOT executed immediately by a script, but is placed in an action queue, so the script parse time is not directly related to the action execution time, which would seem to me to provide occasion for interference.

I acknowledge that you know far more about these things than I do. What I do know is that I had a problem that the fix fixed. Since there does not seem to be a complete technical manual with well-defined functions and operations, and the aspiring modder is left to following the example of others and experimentation, that remains my final touchstone: NEVERTHELESS, IT WORKED! (With apologies to Galileo)

And apologies to you if I have abused your many kindnesses with my attempts to come to grips with this chaotic modding world.


Top
 Offline Profile  
 
 Post subject: Re: v3.0 bug carried over from v2.5
PostPosted: Mon Jan 04, 2016 11:43 pm 
Priest(ess) of the Pink Mage

Joined: Tue Aug 05, 2014 5:06 am
Posts: 278
hey its no problem talking about it i wasn't annoyed, the scripting for bg2 has always been troublesome because it is completely un-documented.


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron