43 réponses à ce sujet

[henesua]

Failed.Bard wrote...
I never thought about how it handled the conditionals.  Just knowing that part will let me chop most of them out of the dynamic convos I use in my little mods deity system.

Agreed, this is also a new discovery for me. As soon as I get around to it, I'll be slimming down my module's scripts a gread deal. My deity setup system has 32 scripts that I will no longer need.

[Lightfoot8]

henesua wrote...
Thanks to Lightfoot8 for teaching me that the "Text Appears When" scripts execute in order from first to last.

I can not take credit for the original idea.  I got it from reading the conversations in DMFI 1.09

[Shadooow]

FunkySwerve wrote...

It also has a couple of glitches we've been patching case-by-case instead of within the general system, making it unsuitable for distrubtion in any case (the why of that is far beyond the scope of this thread).

Funky

I think these glitches happens when:
there is SetCustomToken used twice in one moment (like first call it to "" and then refill)
the SetCustomToken are called in text appear when node an the given (doing this on action node in previous line should fix it)

[FunkySwerve]

ShaDoOoW wrote...

FunkySwerve wrote...

It also has a couple of glitches we've been patching case-by-case instead of within the general system, making it unsuitable for distrubtion in any case (the why of that is far beyond the scope of this thread).

Funky

I think these glitches happens when:
there is SetCustomToken used twice in one moment (like first call it to "" and then refill)
the SetCustomToken are called in text appear when node an the given (doing this on action node in previous line should fix it)

No, the glitches are entirely unique to the system. Things like not being able to get the speaker properly in some circumstances. They make it unsuitable for public release, but have no other bearing on the discussion. The system itself performs flawlessly ingame, but would be a nightmare to support. Thanks for the attempt to help, though.

Funky

[Shadooow]

I shouldnt quote you probably because I dont know what are you talking about. I know nothing about your HGLL - what I meant was the glitch desribed in the OP's post about not all lines showing up sometimes - I thought you are also talking about this one.

Modifié par ShaDoOoW, 22 janvier 2012 - 04:32 .

[Kato -]

As an additional info, there is something else causing some missing entries: Calling SetShowEndSelection(TRUE). Filling a page(list) with 11 elements if the setting is true will not work, you'll only see the first 10. For the system to properly display the next page section where the 11th element is, adding a few more elements(going over 13) "fixes" the problem. If unset or false the behavior returns to normal(thus clicking on "Next" will display the 11th element).

And then a precision: In the last, short example I posted(with guild territories), only the first 6 entries are displayed, sometimes. If I set the loop to iterate 12 times instead of 10, then the first 8 elements will be displayed, and so on. Always the same number of missing entries.

The above statements have been extensively tested and the results are quite consistent, hopefully this can help...


Kato

Modifié par Kato_Yang, 22 janvier 2012 - 06:23 .

[Kato -]

Hey there,

Although I did not find yet the problem with the system, I wish to share something in the hope it will be useful.

As I've already mentioned, there are two ways to fill pages with the elements to display, assuming that the dialog script mimics the template provided/recommended by the author, Paul Speed:

- In the PageInit() function
- In the HandleSelection() function

In one of my own dialogs, a big(700-800 lines) script for all the merchants of my PW, I'm setting the pages in the PageInit() function, and it never ever broke in 3-4 years. However, in all of the situations where I have seen the bug appearing, the pages were set in the PageInit() function.(I did not know this when I coded my dialog, and since it works well I did not change it)

Looking at Funky's HGLL system, one can see that the pages are set in the HandleSelection() function instead, and I have never seen a single problem with HGLL so far, wich is impressive considering the number of operations involved during the level-up process.

So, for now, I'm forced to conclude that Funky's approach is the way to go. If anyone has some problems with this approach, I would be truly grateful if you let me know, as it will confirm if the above theory is right or wrong(I'm not saying it will fix the bug, but if it never appears, it's almost the same).

Thank you all


Kato

Modifié par Kato_Yang, 05 février 2012 - 08:22 .

[FunkySwerve]

That's interesting. It's tickling a memory about the initial testings I did with z-dialog, way back when. It's entirely possible that page init is too late to be reliable with z-dialogue. FWIW, our current convo system does page changes from both onaction (selection handling) and the conditional.

Your issue may related to issues surrounding custom tokens, which can be touchy in certain situations. I'm being deliberately vague here because, while I remember issues surrounding them, and working around them, all but the most recent issue with colors has escaped my memory.

Of course, the current system we use is completely different from z-dialogue, but it IS built to mimic the bioware convo setup, as z-dialog was.

Funky

[Kato -]

FunkySwerve wrote...

...It's entirely possible that page init is too late to be reliable with z-dialogue...

Indeed, and indeed again. This would explain why the pages are correctly displayed if the needed infos are retrieved from simple variables stored on the PC speaker or the convo owner. However, when the code needs, for instance, to loop over many objects in different areas, wich was often the case in the broken dialogs I've seen so far, CRAC, too late, missing entries appear.

Many thanks for confirming this, Funky.  


Kato

Modifié par Kato_Yang, 05 février 2012 - 11:18 .

[FunkySwerve]

I posted notes on a diff of HGLL's scripts and pspeeds Vault/Sourceforge version in another thread. There was indeed a lingering bug, just fyi.

Funky

[Kato -]

Thanks Funky, I should have mentioned before that I've always been using the version packaged with HGLL.


Kato

[henesua]

Kato, how is this project going? I've encountered the issues you are working on, but have held off from solving the problem because you are already on it.

Also, I read an interesting article taken from a GDC talk that others following this thread might be interested in: AI Driven Dynamic Dialog

I haven't come up with a way to assemble a rulebook in NWN (I am not a programmer) but am thinking about it, and may get around to it in NWN. More likely I'll make use of this on a Unity project, but still it seems that this could be a nice extension to Z-Dialog.

[Kato -]

Well, the system seems ok since I set the pages in the HandleSelection() function instead of the PageInit() one.

@Henesua: Do you mean that the above described technique does not work for you? BTW, thanks for the link.

Kato

[henesua]

Unfortunately for me, I glossed over those comments because I figured it was discussion that was leading you in the direction of rewriting z-dialog. AND I am not using Higher Grounds version of z-dialog. I am using the version from the vault.

The way I am handling the convo is as follows:
PageInit() finishes set up with these functions:
// Set Prompt and Response List ............................................
SetDlgPrompt( sPrompt );
SetDlgResponseList( sPage, oHolder );

HandleSelection() finishes set up with these functions:
// Set Page
SetDlgPageString(sPageString);

[Kato -]

henesua wrote...

Unfortunately for me, I glossed over those comments because I figured it was discussion that was leading you in the direction of rewriting z-dialog. AND I am not using Higher Grounds version of z-dialog. I am using the version from the vault.

The way I am handling the convo is as follows:
PageInit() finishes set up with these functions:
// Set Prompt and Response List ............................................
SetDlgPrompt( sPrompt );
SetDlgResponseList( sPage, oHolder );

HandleSelection() finishes set up with these functions:
// Set Page
SetDlgPageString(sPageString);

Looks good, you should be fine as long as you add list elements from the HandleSelection() function. Replacing the scripts from the vault version with the ones from HGLL would be well worth the time spent, of course.(no spamming here, only plain truth)  

Kato

Modifié par Kato_Yang, 17 mars 2012 - 08:24 .

[henesua]

Why would you add list elements from the HandleSelection() function? That is counter intuitive. The Response List should be related to the page that you are initializing.

Anyway... I'll have to search for the higher ground scripts. Haven't looked.

[Kato -]

henesua wrote...

Why would you add list elements from the HandleSelection() function? That is counter intuitive. The Response List should be related to the page that you are initializing. 

Yes, it's counter intuitive because it makes the refreshing of pages less obvious, but setting list elements in PageInit() is sometimes too late, resulting in missing entries, as explained a few posts above this one. SetDlgPrompt() and SetDlgResponseList() should be called from PageInit(), however.

Here are some more details and a few examples if you're interested:

social.bioware.com/forum/1/topic/192/index/9171975  


Kato

[henesua]

At some point I suppose I'll rewrite the system then. I'm not going to go through contortions to make a broken system function. I've already made a few fixes so it won't hurt to make more. That will have to wait however till I am finished with my current project.

Thanks for the link. That will be useful.

[Kato -]

Well, good news for those interested, setting lists in the HandleSelection() function never seems to break the dialog. I have performed hundreds of tests during the last few months, and even with a 2000 lines dialog displaying up to 200 entries at a time, everything works like a charm(Thanks once again for your guidance Funky!).

Since this counter intuitive approach tends to produce redundant code, because lists must often be set from several different places in code, as correctly pointed out by Henesua, it's often a good idea to define one specific function per different page to display, when/if necessary, at the top of the dialog script. This way, whenever any page/list is needed, one simply needs to call the corresponding function, which first line should always be: DeleteList(<list to delete>) followed by the code filling the list. No missing entries, pages are always up-to-date, no code redundancy, and it makes the dialog easier to read/debug/expand. If it can be helpful to anyone, I have several working dialog examples I'll be happy to share, and for a bit more complex and instructive one, I suggest studying the dialog used in HGLL, coded in the same fashion by Funky(it's complex but one can learn so much from it).

Cheers! 


Kato

Modifié par Kato_Yang, 14 juillet 2012 - 06:40 .