Is it possible to have two characters speak in different fonts during dialog?

Started by Volklaw, Fri 18/05/2018 13:58:36

Previous topic - Next topic

Volklaw

Hi everybody

I'm back with what I can only assume is another total novice question.
I've checked the manual and couldn't find anything. I checked the forums and found something from over ten years ago suggesting what I'm after is techincally not possible but that it might find it's way into a later version of A.G.S. I have the latest version so I was wondering if it is now possible to have two characters speak to each other using different fonts.

In my example, I have an interaction where the playable character is talking to a character who is talking hieroglyph style gibberish. The whole dialog takes quite a while to the deliberate and intended annoyance of the player. I have imported a dingbat/wingdings style font that I can use for the unintelligible character, however; I have only been able to change the fonts of all characters in any given room by using the Game.SpeechFont = eFontRuritaria; on the room_Load() function.

Is it using the most recent A.G.S. to have characters display speech in different fonts?

All answers and thoughts are appreciated!
Regards

Crimson Wizard

There is still no per-character speech font setting, it is only possible if you set SpeechFont everytime before calling Say line.

Obviously, manually adding such action every time will be inefficient (and drive you mad), but this is where custom functions may come handy. For example, you may write following extension function:

Code: ags

void SayGibberish(this Character*, String text)
{
    FontType oldFont = Game.SpeechFont; // remember previous font
    Game.SpeechFont = eFontRuritaria;
    this.Say(text);
    Game.SpeechFont = oldFont; // restore previous font
}


Then use it like:
Code: ags

cNPC.SayGibberish("Hello, my name is Bob");


Expanding this method, you may set up personal font for each character in your game, if necessary.

Snarky


Volklaw

Thanks guys

I'm still getting my head around all that "void" business but both your posts, and the explanation in that other post of Snarky's, are very comprehensive.
Thanks a million.

Snarky

Quote from: Volklaw on Sat 19/05/2018 09:57:44
I'm still getting my head around all that "void" business

The short version is that "void" is what you put in front of functions that don't return any results.

The long version gets complicated because AGS has two quirks that are meant to make things easier (but actually just confuse things):

Functions can return values. For example, the built-in function Random(int max) returns a random number between 0 and max. You can write your own functions, and then you should put at the start of the line what kind of value it returns: is this a function that calculates a whole number (int), that gives you back some text (String), that tells you whether something is true or false (bool), etc. If the function doesn't give any output at all, you should put void, which here means "nothing" or "not applicable". For example, a SaySomething() function doesn't really have any answer it can output: it should just do it.

So:

Code: ags
// This is a function that returns an int
int Max(int a, int b)
{
  if(a>b)
    return a;
  else
    return b;
}

// This is a function that doesn't return anything, it just carries out a series of commands
void TryFishing()
{
  player.Say("Nice day for fishing!")
  player.Walk(123,58);
  player.LockView(34);
  player.Animate(0, 3, eOnce, eBlock, eForwards);
  player.UnlockView();
  player.Say("No luck today!");
}


See the difference?

Now, the quirks are:

1) Instead of putting "int" in front of a function, you can just write "function". In that case, the return type is int by default.
2) If the return type of a function is int, you don't actually have to return a value at all. (If you don't, it will return 0 by default.)

This means that you can get away with not using "void" or "int" functions, you can just write "function" for both. In fact, all the standard script functions (on_mouse_click(), repeatedly_execute(), etc.) do this. However, it is better to be consistent and always put the correct return type explicitly: that way there's never any uncertainty about whether it's meant to return anything, and it helps avoid certain kinds of bugs.

Volklaw

Thanks Snarky!

I think it's starting to make sense.
I was wondering how repeatedly execute was operating... So to speak.

Thanks for your insight :smiley:

SMF spam blocked by CleanTalk