two npc conversation infinite loops

[davidlallen]

Thanks for the feedback. I don't quite understand the details of your approach. I wrote originally:

The fourth line does "setstage myquest n". Mypkg has a condition which is "if getstagedone myquest n == 0" so it should be prevented from running again.

This is the termination condition you mention. Once the conversation finishes, the package which was addscriptpackage'd no longer qualifies for selection. The removescriptpackage shouldn't be needed. Do you have any thoughts on why it was ignoring the termination condition? Or did you mean something different?

 

Also, can you say a little more about your method for adding a timer? Package scripts cannot themselves have timer loops ("begin gamemode" is not valid there) and I am starting this from a dialog topic result, which also cannot have a timer loop. Where do you put your timer loop, in a dummy script? Then you let the dialog play one time with a stopwatch to find out how long it takes, and use that to set the timeout limit of the dummy script?

[Astymma]

Thanks for the feedback. I don't quite understand the details of your approach. I wrote originally:

The fourth line does "setstage myquest n". Mypkg has a condition which is "if getstagedone myquest n == 0" so it should be prevented from running again.

This is the termination condition you mention. Once the conversation finishes, the package which was addscriptpackage'd no longer qualifies for selection. The removescriptpackage shouldn't be needed. Do you have any thoughts on why it was ignoring the termination condition? Or did you mean something different?

 

Also, can you say a little more about your method for adding a timer? Package scripts cannot themselves have timer loops ("begin gamemode" is not valid there) and I am starting this from a dialog topic result, which also cannot have a timer loop. Where do you put your timer loop, in a dummy script? Then you let the dialog play one time with a stopwatch to find out how long it takes, and use that to set the timeout limit of the dummy script?

 

Hmm if you have that condition, have you verified you're advancing the quest stage beyond stage 0? Perhaps at the end of your dialog the update to the stage is bombing...

 

You can implement the timer in a few ways like calling a dummy script or adding a timer quest. And generally I wouldn't use it for a dialog conversation, that's something I'd use for an AI script for things like movement and such. In the case of a dialog, they have built in conditions that *should* handle an infinite loop.

[davidlallen]

Yes, I have verified that the quest stage is done. Using console, I can see that "getstagedone <quest> <stage> returns 1, even while the conversation is infinitely repeating. This should obviously not happen, but there you are.

[Astymma]

Yes, I have verified that the quest stage is done. Using console, I can see that "getstagedone returns 1, even while the conversation is infinitely repeating. This should obviously not happen, but there you are.

The only thing I can see is your use of a variable named "n" in your setstage and getstagedone commands. Is this a local variable in your dialog script or is it a quest variable from the dialog quest script? Local variables in dialog scripts can act oddly. Seems to have ambiguous syntax as well. As an example, if n == 0 then "setstage myquest n" sets it to 0. But if n==0 then "if getstagedone myquest n == 0" evaluates as getstagedone myquest (result of comparing n==0, which is true, which is the value 1) which is likely not what you intended. I think you should probably just use "if !getstagedone myquest n" or even "if !getstagedone myquest 0" and dispense with the unnecessary variable use.Or maybe you intended to use getstage instead which returns the stage number as opposed to getstagedone which checks if a specific stage number has been marked completed.

 

In any case, when constructing a line like "if getstagedone myquest n == 0" you should probably use explicit grouping with parentheses to guarantee operator precedence like "if (getstagedone myquest n) == 0". Or, as I said, reconstruct the comparison to eliminate the need such as "if !getstagedone myquest n".

At this point I'd need to know more to make an educated guess :)

Edited March 13, 2011 by Astymma

[davidlallen]

Sorry for the confusion. When I write something in <> it means the exact value doesn't matter. So "getstagedone <questname> <n> == 0" would actually appear in my mod as, "getstagedone TDGGenQuest 30 == 0" or something. As I have learned recently, you should never ever *ever* use local variables in dialog result scripts, and I am not doing that.

[Astymma]

Sorry for the confusion. When I write something in <> it means the exact value doesn't matter. So "getstagedone <questname> <n> == 0" would actually appear in my mod as, "getstagedone TDGGenQuest 30 == 0" or something. As I have learned recently, you should never ever *ever* use local variables in dialog result scripts, and I am not doing that.

 

Ahh... gotcha. But that still has ambiguous syntax. in that example 30 is a valid RHV(right hand value) but so is 30 == 0. I don't know how that would behave so because I'm not 100% sure I use parentheses to be sure. Of course that may or may not be the problem you're experiencing. Sorry to go off on a tangent :) At this point I don't think I have enough information to hazard another guess at a solution. Maybe some more specifics?

[davidlallen]

This particular expression is done by selecting from dropdowns in a package, so there is no opportunity to make a mistake with parentheses. I will create a standalone small mod which tries to show this problem. If the small mod works, then the mistake is on my side, otherwise it is a bug in geck.

[Astymma]

I am wondering if this note from the cs wiki has anything to do with your problem:

 

 

The stage result script will be processed immediately after the SetStage call. The main script containing the SetStage call will be halted until the result script is finished. It is even possible to use the SetStage command inside a stage result script. In this case the new stage result script will run in place of the SetStage command and the old stage result script will continue after the new one has finished. Unlike Activate, it seems that any number of recursive SetStages are allowed (at least 250, tested from the same quest, are possible).

 

[davidlallen]

That is interesting, but the problem is that when the conversation plays the second time, the package which is selected is illegal. That is, it is selecting a package which clearly cannot be selected because its condition is false. The order of operation within the setstage command does not seem to affect this.

[Astymma]

That is interesting, but the problem is that when the conversation plays the second time, the package which is selected is illegal. That is, it is selecting a package which clearly cannot be selected because its condition is false. The order of operation within the setstage command does not seem to affect this.

 

Oh, don't get me wrong... it IS most certainly possible that there's an error in the geck and/or game engines that is causing your problem, hehe. Was just curious that perhaps there is an order of execution/interpretation that is causing your situation making what you expect to happen differ from what is actually happening. Perhaps toss in a bunch of debug statements like "entering NPC1 convo", "leaving NPC1 convo","current quest stage is n" and such throughout the process.

 

As the above cs wiki entry points out, there might be situations where you end up winding up a massive recursive endless loop which never unwinds. In such a case, you might never actually mark a quest stage completed, only endlessly reiterate the stage result.

Edited March 15, 2011 by Astymma