Adventure Game Studio

Hello all, another beginner question:

I have the following code to be used in a cutscene:


  cOtherCharacter.RunInteraction(eModeTalkto);
  cPlayerCharacter.Walk(x, y, eBlock);
  [other stuff]

Elsewhere I have the following function defined in GlobalScripts.asc that should be called from the RunInteraction function:


function cOtherCharacter_Talk()
{
  cPlayerCharacter.Walk(225, 235,  eBlock);
  cPlayerCharacter.FaceCharacter(cOtherCharacter);
  dConversation.Start();
}

Here is what I want to do: The player should walk to the normal dialog spot of the other character (defined in cOtherCharacter_Talk) then trigger the dialog, then walk somewhere else to continue the cutscene.

Using only the RunInteraction command works like I want it to. If I add the walking code, however, the RunInteraction is ignored and the dialog does not take place. Is there a way to make the RunInteraction blockable?

I guess I could make it work by fusing the functions like this:


  cPlayerCharacter.Walk(225, 235,  eBlock);
  cPlayerCharacter.FaceCharacter(cOtherCharacter);
  dConversation.Start();   
  cPlayerCharacter.Walk(x, y, eBlock);
  [other stuff]

But since later I want to come back to the room and have a normal player-triggered conversation, I found the first option much more elegant, since I would not have to have the walk-to point for the conversation twice. For the second way to do it I posted above, I'd still need the cOtherCharacter_Talk function for the player-triggered conversation, thus having the coordinates twice (redundancy).

Is there something I'm missing here? What would be the best way to do this? I assume it has something to do with the blocking mechanism and the fact that the conversation runs in the Global thread, but I am lacking the experience to judge what is happening behind the scenes

Thanks.

Edit: Apparently the second option does not work either since the dConversation.Start(); does not block either.

So here is what I would like to do:
- Walk to A
- Talk to Character
- Walk to B
- Pick up item
- Walk to C
- Exit Room

With the first implementation, I get:
- Walk to B
- Pick up item
- Walk to C
- Exit Room

So he does everything right but forgets the dialog.

With the second implementation, I get:
- Walk to A
- Pick up item
- Walk to C
- Talk to Character

So he walks to C instead of B, talks to the Character, but does not leave the room. :confused:

I guess I need some more information about the thread system, is there maybe more than in the manual (I read Understanding blocking scripts)

What does dConversation consist of? Does the player have a dialog option or is it just the characters talking? In the former case, I'd just stick all the code going from walking to B onwards inside dialog script, something like:
//in dialog script
@1
PlayerCharacter: Blah
OtherCharacter: Stuff
  cPlayerCharacter.Walk(x,y,eBlock);
  [other stuff] //etc etc

If, however, the player doesn't have to choose any options, then you don't really have to have dConversation at all, just put all the talking in the function:
function cOtherCharacter_Talk()
{
  cPlayerCharacter.Walk(225, 235,  eBlock);
  cPlayerCharacter.FaceCharacter(cOtherCharacter);
  cOtherCharacter.Say("Blah");
  cPlayerCharacter.Say("Stuff");
}

However, this won't solve the issue that RunInteraction seems to be non-blocking. (The manual strangely doesn't mention it) I can see two solutions:

1) If you don't mind replicating code, doing what you did in the second implementation should work fine, just swap dConversation.Start() with cOtherCharacter.Say("Blah") etc etc.

2) If you want to never replicate the code, you could stick it in an external function. Something like:
//Somewhere in global script above cOtherCharacter_Talk()
function TalkToOtherChar(){
  cPlayerCharacter.Walk(225, 235,  eBlock);
  cPlayerCharacter.FaceCharacter(cOtherCharacter);
  cOtherCharacter.Say("Blah");
  cPlayerCharacter.Say("Stuff");
}
//Then
function cOtherCharacter_Talk()
{
  TalkToOtherChar();
}
//And again, in the cutscene code:
  TalkToOtherChar();
  cPlayerCharacter.Walk(x, y, eBlock);
  [other stuff]

This should hopefully do the trick :)

Thanks for the hint.

I got the same idea this morning (to use the Say command instead of the dialog system). I'll give it a try and post later whether it worked.

In fact, since it is a no-choice conversation (cut-scene after all), it would be quite okay to do it that way. In the game later on that conversation will not be needed anymore. The only thing that I am not quite happy with is that I would either have to duplicate the cPlayerCharacter.Walk(225, 235,  eBlock); call, since number redundancy is bad style. However, using an external function might actually remedy this. So I'll give it a try and see how it works.

I was hoping that I could do all my conversations in a unified way using the dialog system. But I can live with doing cutscenes differently.

The only thing I would like to change now is to add some more information about this to the manual, since a few extra lines would have prevented some hours of head-scratching for me. Specifically the information that RunInteraction is non-blockable and that the dialog system might not be suitable in cutscenes for certain situations would have been quite valuable. Fortunately there is a thread about improving the documentation, so I'll post there as well.

Why would you use a dialog to display a conversation without choices in the first place? This makes no sense at all, and the manual doesn't need to address this in any way.

The RunInteraction entries however should indeed mention that these commands get queued (they aren't non-blocking, they just aren't executed immediately but rather after the current function has finished.)
It does so for Dialog.Start() and Character.ChangeRoom().

BUT: there's no reason to use cOtherCharacter.RunInteraction(eModeTalkto); here, since you can call cOtherCharacter_Talk() directly by importing it in GlobalScript.ash.
You only need .RunInteraction in situations where you don't know the part before the dot (when it's a pointer with unknown content) and/or the mouse.Mode, and in those cases you wouldn't call specific commands afterwards anyway.

If the manual did address every single way you can misuse AGS, we'd need a way bigger server.

Just because it does not make sense to you does not mean it does not make sense to someone else. There are two ways of implementing dialogs. How should a beginner know that one way makes sense in a certain context and the other does not?

The piece of information about when to use RunInteraction and when another function would be more appropriate is also something I would really like to see in the manual somewhere.

Don't worry about server sizes, the manual the mainly text based. Do you have any experience with Qt? They have a truly epic manual that contains a lot of text, addresses many pitfalls and is a delight to use, especially for beginners. It is not perfect, but it comes close to perfection in my book. Do you think they worry about server size for documentation when they can create something that is easily accessible for beginners?

Quote from: KhrisIf the manual did address every single way you can misuse AGS, we'd need a way bigger server.

Hey, Khris, think of how much forum space will be saved!

I'll repeat myself, maybe you missed something there:
Why would you use a dialog to display a conversation without choices in the first place?
Where in the manual does it mention that the best way to implement a static conversation (otherwise known as cutscene) is using a dialog? Because this would actually need correcting. (Don't bother to look, it isn't mentioned anywhere. Rhetorical question and all that.)
It's like complaining to a knife company that you can't eat soup with their products.

I have been active in here since August of 2004, and yet I don't remember a single occasion where somebody tried to implement a static conversation, used a dialog for it unnecessarily, suffered from repercussions and consequently complained about the manual not mentioning "the other way". This simply has never happened yet, ever. (I don't mean to brag about my forum time, I'm just saying that apparently beginners DO know when to use dialogs and when not to. Although maybe before August 2004 they were all really, really confused about this.)

.RunInteraction getting queued is worthy of adding to the manual, yes, but I reckon people who actually need to use this command (because they're for instance writing a UI module) already now their way around AGS enough. When I used .RunInteraction for the first time, I already figured it was probably going to end up getting queued without even bothering to check the manual first.

Long story short: my comment about a bigger server was basically drenched in sarcasm, but you seem to have missed that, too.

The manual is far from perfect, but other stuff is much more urgent than catering to your every quirky mistake.

Please stfu, and focus on making your game instead of barging in here and whining about a whole lot of nitpicky bullshit. Also: congrats for making me this angry. Rarely happens but you did it.

Now, I must disagree.

Quote from: Khris on Sat 09/03/2013 20:54:58
Why would you use a dialog to display a conversation without choices in the first place?
Where in the manual does it mention that the best way to implement a static conversation (otherwise known as cutscene) is using a dialog?

Does the manual mention opposite? Why wouldn't someone want to use Dialog to display a simple conversation? It is much easier to comprehend, IMO, especially for the beginner, that you should use Dialog item, and not manually write several functions in alien-looking script.

Quote from: Khris on Sat 09/03/2013 20:54:58
I have been active in here since August of 2004, and yet I don't remember a single occasion where somebody tried to implement a static conversation, used a dialog for it unnecessarily,

Well, I did, actually, in my first game attempts, simply because I found it's natural to script conversation in Dialog. Even today I am not sure what would be "right" way to script conversation, and could do that in Dialog, instead of putting everything into script module.
I am speaking of simple game template, of course, not the one having some advanced dialog/speech UI.

Also, I find it pretty natural for beginners to complain about everything... And sometimes the old tool's flaws are not visible by experienced users so clearly as for newcomers.

You can't just cut off a vital part of my argument, then go ahead and rebut the crippled version. But since you did: thanks for confirming that you figured it out on your own and refrained from posting a complaint (which was my point).

And do you think that a knife should come with a label that says "use this to cut stuff"?

I could also argue that what actually does get asked a lot by beginners is "why is my dialog run after the other commands", although the manual entry for Dialog.Start() mentions this explicitly. Which only underlines the sad reality that the requested manual changes are pretty much pointless.

Khris, they have a point. If someone's just starting to use AGS and is trying to make some characters have a static conversation, and they come across the Dialog part of the editor, it'll seem like exactly the thing they're looking for. "Hey, a way to create conversations between characters! Of course that's what I should use! I don't need those branching options right now, but I see how it could come in handy later. Man, AGS really makes it easy!"

And it even works, almost. That's what makes it so confusing: it looks like you're on the right path, but you get some pesky bugs that you can't fix.

OK, so you haven't heard of anyone having this problem before, but I'll raise my hand, you can add me to the list with Cerno and CW. It wasn't exactly this same issue that tripped me up, but I was definitely confused by the overlap between Character.Say and the dialog system, why there were two ways to have characters speak, what the differences between them were, and when to use one or the other. I also had some trouble figuring out how to actually launch a dialog, since the tutorial section on conversations doesn't mention it.

While not mentioned in "Setting up the game -> Conversations", how to start a dialog is mentioned earlier in the tutorial, in "Tutorial Part 8 - Conversations" in the "Starting off" section.

Cerno:
I read what you posted so far as basically "I couldn't figure out x, y, z and it's the manual's fault. I know, I just discovered a powerful and invaluable, yet completely free game creation system, however, here's a list of what it does wrong."
It got me riled up, but I'll freely admit that I tend to overreact when people exhibit what I perceive as unwarranted entitlement.

I hope the planned changes to the manual, should they ever see the light of day, will have a positive impact. I'd be pleasantly surprised.

Khris, I'm sorry if I offended you.

I know I'm taking a lot for granted here, having a free, flexible and powerful tool at my disposal, and I agree I should shut up more when I am just beginning to use the tool.

I am used to stating room for improvement when I see it which is something that is well-received at my day-time job. However, it is not the first time that I got into trouble after my well-meant suggestion was interpreted as a complaint. I don't if it's just the way I use words, maybe it is because I am no native speaker or I have some social defect ;). Again, despite what I might seem to have meant, all I wanted to point out that I have seen something that could make AGS better. Whether it actually does is another issue but I thought that is what forums are for: To discuss thoughts and ideas.

Again, I apologize for getting you angry, that was not my intent.

I hope we can get along in the future despite my seemingly nitpicky comments. I wouldn't post them if I didn't think there was some merit in them.
Also, I'd be willing to volunteer writing the addenda to the manual myself (if time permits), if it is okay with you to let a noob touch anything AGS.