Jump to content

Dynaheir repeating same lovetalk


dizzyorange

Recommended Posts

I'll check it, if you want me to, but if Minsc is interjecting into Dynaheir's LT, it isn't an ICT of any flavor, it's written as part of a chain, more than likely.

 

Since the Dynaheir romance is mod-added content, I just can't see anybody coding Minsc's interjections *within the same mod* as true ICT/ICT2/INTERJECT, especially when the dialogue state wouldn't be nailed down, and when the phase II material (interjections) is compiled before the phase III material. It would throw out parsing errors.

 

The short story: that isn't what I'm working on right now, specifically, although I'd be more than happy to look into it. I suspect there might be a bad COPY_TRANS or EXTERN somewhere. I can look into it if you like, but it will have to wait until tonight.

Link to comment
I can look into it if you like, but it will have to wait until tonight.

 

WHAT?

 

We have to wait till -tonight- for a fix for a bug that's easily avoided (now that we know what it is)?

 

Sheesh - totally unacceptable - I want a refund of every penny that I paid for this mod!

 

*grin*

 

Sorry, couldn't resist :)

 

Qwinn

Link to comment

berelinde is right - this is all built-in, rather than an I_C_T. I wonder if there is an sadditional problem with RestParty().

 

We already found that RealSetGlobalTimer() blocked materials past it on actions, so we moved the global before it. v15 should have no troubles, but it does.

 

IF WEIGHT #-2 ~%BGT_VAR% Global("X#DYLoveTalk","GLOBAL",22)~ THEN BEGIN X#DYLoveTalk10
SAY @647
= @648
= @649
= @650
++ @651 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.1
++ @652 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.2
++ @653 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.3
++ @654 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.4
++ @655 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.5
END

IF ~~ THEN DYRO10.1
SAY @656
++ @657 + DYRO10.6
++ @658 + DYRO10.7
++ @659 + DYRO10.5
++ @652 + DYRO10.2
++ @660 + DYRO10.3
END

IF ~~ THEN DYRO10.2
SAY @661
++ @662 +DYRO10.8
+ ~!InParty("minsc")~ + @663 + DYRO10.9
+ ~!InParty("minsc")~ + @664 + DYRO10.9
+ ~InParty("minsc") InMyArea("minsc") !StateCheck("minsc",CD_STATE_NOTVALID)~ + @663 EXTERN ~%MINSC_BANTER%~ DYRO10Minsc1
+ ~InParty("minsc") InMyArea("minsc") !StateCheck("minsc",CD_STATE_NOTVALID)~ + @665 EXTERN ~%MINSC_BANTER%~ DYRO10Minsc1
+ ~InParty("coran") InMyArea("coran") !StateCheck("coran",CD_STATE_NOTVALID)~ + @666 EXTERN ~%CORAN_BANTER%~ DYRO10Coran1
+ ~!InParty("coran")~ + @666 + DYRO10.8
+ ~OR(2) Class(Player1,FIGHTER_ALL) Class(Player1,PALADIN)~ + @667 + DYRO10.10
END

IF ~~ THEN DYRO10.3
SAY @668
= @669
IF ~~ THEN + DYRO10.3A
END

IF ~~ THEN DYRO10.7
SAY @670
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.8
SAY @671
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.9
SAY @672
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.10
SAY @673
= @674
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.15
SAY @675
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.16
SAY @676
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.17
SAY @677
IF ~~ THEN + DYRO10.5
END

IF ~~ THEN DYRO10.5
SAY @678
= @679
IF ~~ THEN + DYRO10.3A
END

IF ~~ THEN DYRO10.3A
SAY @680
= @681
++ @682 + DYRO10.11
++ @683 + DYRO10.12
++ @684 + DYRO10.13
++ @685 + DYRO10.14
END

IF ~~ THEN DYRO10.4
SAY @686
+ ~InParty("minsc") InMyArea("minsc") !StateCheck("minsc",CD_STATE_NOTVALID)~ + @687 EXTERN ~%MINSC_BANTER%~DYRO10Minsc2
+ ~OR(3) !InParty("minsc") !InMyArea("minsc") StateCheck("minsc",CD_STATE_NOTVALID)~ + @687 + DYRO10.15
++ @688 + DYRO10.16
++ @689 + DYRO10.17
END

IF ~~ DYRO10.6
SAY @690
++ @691 + DYRO10.18
++ @692 DO ~RestParty()~ EXIT
++ @693 DO ~RestParty()~ EXIT
END

IF ~~ DYRO10.11
SAY @694
IF ~~ THEN DO ~RestParty()~ EXIT
END

IF ~~ DYRO10.12
SAY @695
= @696
= @697
IF ~~ THEN DO ~RestParty()~ EXIT
END

IF ~~ DYRO10.13
SAY @698
= @699
IF ~~ THEN DO ~RestParty()~ EXIT
END

IF ~~ DYRO10.14
SAY @700
= @701
= @696
= @697
IF ~~ THEN DO ~RestParty()~ EXIT
END

IF ~~ DYRO10.18
SAY @702
IF ~~ THEN DO ~RestParty()~ EXIT
END
END

APPEND ~%MINSC_BANTER%~

IF ~~ DYRO10Minsc1
SAY @703
IF ~~ THEN EXTERN ~%DYNAHEIR_JOINED%~ DYRO10.9
END

END

APPEND ~%MINSC_BANTER%~
IF ~~ DYRO10Minsc2
SAY @704
IF ~~ THEN EXTERN ~%DYNAHEIR_JOINED%~ DYRO10.15
END
END

APPEND ~%CORAN_BANTER%~
IF ~~ DYRO10Coran1
SAY @705
IF ~~ THEN EXTERN ~%DYNAHEIR_JOINED%~ DYRO10.8
END
END

 

I will swap out the

 

IncrementGlobal("X#DYLoveTalk","GLOBAL",1)

 

for

 

SetGlobal("X#DYLoveTalk","GLOBAL",23)

 

which is pretty much cosmetic (for quick search of project files);

 

but why is an EXTERN in a reply breaking the first action?

Or is it the RestParty() evaluating true before the initial actions *because* of the EXTERN?

 

Hmmm...

Link to comment
We already found that RealSetGlobalTimer() blocked materials past it on actions, so we moved the global before it. v15 should have no troubles, but it does.

 

No, this is not correct: I posted this when the subject first arrived, and now I post it again: numerous mods have other actions after RealSetGlobalTimer(), from Xan to others, and they work perfectly.

 

Both players in this topic are talking about 14. v15 has not been updated to the official mirrors yet. I have explained the problem and the solution in the post above: on very fast computers, each block with Variable=22 trigger executes, even if the variable's already been updated. Do NOT check for Global("X#DYLoveTalk","GLOBAL",22) in dyrom main script at all, and you'll avoid the issue entirely.

Link to comment

(Bloody heck. The current version 15D has the .baf changes reverted. In my quest to make sure that the master copy only gets tested changes, I must have fixed the dyrom.baf on the backup copy but not the actual master. Now I have to go through the whole bloody worklog again and recheck the master copy against everything I logged as fixed. Again. I am done with being so careful. I am going to just work on the master copy directly, and follow the logs to rebuild from the last version. Resynching the versions - again.)

Link to comment

OK, berelinde, quick recheck on the ~RestParty()~ stuff tonight, if RL will allow. I checked on v14 and v15D; identical code, which it *shouldn't* be, from my worklogs.

 

I am doublechecking the behavior on all other materials for RestParty() which might use EXTERN, as well, to try to see if everything else is working. That is really the only difference between

 

 

++ @651 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.1

 

leading directly to

 

IF ~~ DYROwhatever

SAY @702

IF ~~ THEN DO ~RestParty()~ EXIT

END

 

as opposed to

 

++ @651 DO ~IncrementGlobal("X#DYLoveTalk","GLOBAL",1) RealSetGlobalTimer("X#DYLoveTalkTime","GLOBAL",DYROM_TIMER)~ + DYRO10.1

 

leading eventually through

 

APPEND ~%MINSC_BANTER%~

IF ~~ DYRO10Minsc2

SAY @704

IF ~~ THEN EXTERN ~%DYNAHEIR_JOINED%~ DYRO10.15

END

END

 

and finally to

 

 

IF ~~ DYROwhatever

SAY @702

IF ~~ THEN DO ~RestParty()~ EXIT

END

 

 

If it were a blanket problem with gloabls setting/setting multiple times/evaluating multiple times, it would show up on all instances, not exclusively the replies with EXTERNs to Minsc and Coran.

 

So I will do some testing, andreport. Thanks, Quinn :) a fun puzzle to solve!

Link to comment

Ok, everything you guys are discussing is still way beyond me, I'm afraid I can't read that code yet :) But let's see if I can provide any help in tracing the problem.

 

1) My main PC -is- a paladin... just in case you wanted to evaluate this bit:

 

+ ~OR(2) Class(Player1,FIGHTER_ALL) Class(Player1,PALADIN)~ + @667 + DYRO10.10

 

2) When I modified the code to say OR(15) instead of OR(20) in override/_YNAHEIR.BCS, none of the timed lovetalks would fire anymore. By that I mean that I have a whole bunch of games saved where various lovetalks trigger within seconds of the load. When I would load them up after the change to OR(15), nothing would happen (although other NPC's whose talks seemed dependent on Dyna's talk firing -would- fire, such as the Khalid "congratulation" talk that comes right after, er, LT 8 I think it was). One lovetalk I -could- get to fire after the OR(15) change was the notorious lovetalk 11, I think probably because it was triggered by resting rather than on a timer.

 

3) Not sure if I mentioned it before, but my PC isn't very fast at all. It's like a 3 or 4 year old dell. 2.8 GHz. Probably pretty fast compared to PC's available at the time BG2 came out, but...

 

4) My own programming experience (in a business app language called Progress) would lead me to ponder the possibility that it's a "scoping" issue. Meaning, variable's existence is limited to a certain scope, such as the script it's declared in and stuff, and hopping out of the script to do the Minsc interjection could cause the problem by going outside the scope of a key variable? Now, I know that the X#DYLOVETALK counter is declared as a global variable, so that shouldn't matter there, but is any other variable in this mess a local that might get tossed as a result of exiting out of the script to handle the Minsc interjection? Assuming it even -is- leaving the scope of the script, I can't quite tell. Probably nothing in this paragraph made sense or is applicable to the current issue, but I thought I'd give it a shot, I'm probably way beyond salvaging any possibility of avoiding looking like an idiot anyway...

 

5) Just wondering, now that I've nailed down which conversation paths break it, is anyone having any difficulty reproducing the problem? It should be easily duplicated now, I would think... and thus should allow for testing with debug messages...

 

Qwinn

Link to comment

OH, YIKES! Resynching the versions? Now?

 

Well, you know I'm working with only Phase II stuff, not phase III. Can you please make it so I don't have to repeat the 50 hours work I put into this since 15D was released last weekend? In other words, I'll package what I've got as of this moment and send it to you, and can you please make the changes to that?

 

It's still not finished, but if you want to start 15E right now, well, at least all reported problems are fixed, and a whole bunch of preemptive ones.

 

I'll zip what I've got as of this moment and send it to you via every means available.

Link to comment

@berelinde - Nope - as per conversation offline, I am holding on the resynch until your materials hit my in-box - I am only occasionally around this weekend, and I already have Kagain's Silvershield and Quinn's reposrts above to play with, so I won't be touching any serious recheck of versions until Monday evening (and possibly later, depending on RL). No worries!

Link to comment

@Quinn -

the possibility that it's a "scoping" issue. Meaning, variable's existence is limited to a certain scope, such as the script it's declared in and stuff, and hopping out of the script to do the Minsc interjection could cause the problem by going outside the scope of a key variable?

 

Good thinking; it is something well above what we deal with in terms of .d compilation and working with scripting. I think that what you are talking about might be waht the IESDP gurus are talking about when they talk about how some actions ack as "blocks" to setting other things, and why ActionOverride() commands work to avoid problems (as they change when in the order of processing and what actor accomplishes the actions). We are stuck with the low-level "observable behavior" stuff in here, though. What we have to do is write something that we think works, then try to break it - the Minsc and Boo approach. "Let's give it a shake and see what falls out!".

 

Just wondering, now that I've nailed down which conversation paths break it, is anyone having any difficulty reproducing the problem? It should be easily duplicated now, I would think... and thus should allow for testing with debug messages...

 

That's this afternoon's project for me, if I can free up the time :)

Link to comment
Good thinking; it is something well above what we deal with in terms of .d compilation and working with scripting. I think that what you are talking about might be waht the IESDP gurus are talking about when they talk about how some actions ack as "blocks" to setting other things, and why ActionOverride() commands work to avoid problems (as they change when in the order of processing and what actor accomplishes the actions). We are stuck with the low-level "observable behavior" stuff in here, though. What we have to do is write something that we think works, then try to break it - the Minsc and Boo approach. "Let's give it a shake and see what falls out!".

 

Mmm, not sure if we were talking about the same thing here. What I'm talking about is the difference between local and global variables. The way I -think- it works is this: A global variable is accessible by all scripts at all times. A local variable is only accessible from the script it's declared in. Now, let's say that a local variable (let's call it LocalRomanceVar) was declared in Dynaheir's script, and then during the Minsc interjection some reference was made to that variable. Now, if that local variable wasn't also declared in the Minsc script, it would probably result in a syntax error when compiling Minsc's script. But if it -was- declared in -both- scripts, the program would essentially treat them as two separate variables, and a change made to that variable during the time where the banter was in Minsc's script would effectively be ignored when control reverted to the Dynaheir script. Well, hope that made some sense. I'm probably way off because all the variables in play seem to be declared as globals, not locals, but still, this is the sort of issue that the behavior seems to remind me of. I really gotta get better at reading this scripting though. It would probably help me if I could see what all the "Dyro10.10" and "@687" were in reference to... what file would I look in to see that stuff?

 

Qwinn

Link to comment

Hmmm, running into what seems to be a very similar problem. It was referred to in the following thread, regarding lovetalk 16 (actually, the problem is within lovetalk 15)

 

http://forums.gibberlings3.net/index.php?s...11381&st=15

 

 

This is the "ribbon" talk. I had a feeling and checked, and sure enough, it seems some conversation paths set the lovetalk variable to 31 and others don't. Obviously, though, it's not going to be dependent on other NPC's interjecting, because they interject in -all- of them. This may mean that the "fix" for the lovetalk 11 issue may reside in seeing how the conversation paths in 15 that work are handled and see if it's different from the ones that don't.

 

I can beat this to death and see if I can find any pattern to which ones work and which ones don't. Would that be helpful, cmorgan? I don't know what if any progress you made with the info so far, so :) Just ask if you'd like me to do this.

 

Qwinn

Link to comment

Update to that last post:

 

Urf. It's -not- consistent. The vast majority of tries where I've done it, regardlesss of conversation path, the variable stays at 30 (and therefore breaks the romance). I found a path where it -sometimes- sets to 31, though, and sometimes stays at 30. So it appears that in this lovetalk, at least, the issue is not caused by the conversation path. Bleah.

 

The path where it sometimes updates, sometimes doesn't is (abbreviated):

 

1. softly

2. Now that's better

3. How did naked?

4. O... I see, I think

5. O, I am willing to take the risk

6. And if I asked you to accompany me

7. I am getting you a ribbon

8. Setta, a blue ribbon please

9. You're welcome, my soul.

 

I wanted to make sure I wasn't sending you off on a red herring regarding lovetalk 11, so I went and did about 15 more tests on that lovetalk, randomly trying paths where Minsc interjects and ones which he doesn't. In the new trials, it was every bit as perfectly consistent as before, if Minsc interjects, the variable fails to update, if he doesn't, it works fine. Oh, and in doing so I found another path where he interjects, try the "Damn you witch!" and then "Has it been that long?" options, that gets Minsc to butt in, and as expected it consistently fails.

 

To be hoenst, finding that it's not consistent in lovetalk 15 made me think I must've been wrong, I was quite skeptical that it could be a consistent problem in lovetalk 11, but seriously, I -can't- seem to make it do anything unexpected. It's completely predictable - the three paths where Minsc interjects, it fails to update, every other path, it always works. Must've done at least 40 trials of both conditions altogether by now.

 

So anyways... yeah. Lovetalk 15's a much bigger problem than 11 was, I'm afraid. 11 seems to be avoidable, but 15 seems to fail to update the counter about 9 out of 10 times, and I can't find any consistent way to get it to update, it seems very random. I'll keep trying to find one though.

 

Qwinn

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...