Messages

It also used to be the case that AGS couldn't handle ligatures (which are apparently necessary to make Arabic look right and not R.E.A.D. L.I.K.E. T.H.I.S.), but perhaps the Unicode support fixed that?

No, it still cannot, we would have to add different font library for this in the future; and currently it is not know whether we will be able to maintain backward compatibility with this (this may break text looks in previous games), so it was left for the future (or ags4).

I heard that Merhdad was able to achieve acceptable results with Persian language, using some conversion program. I am not completely certain, but  suspect it converts the text, merging letters into complex symbols. That's just a guess though (never tried myself).

[without BOM]

You can change fonts in AGS game by placing fonts with corresponding names into the game folder. Fonts should be called as agsfnt0.ttf, agsfnt1.ttf and so on (you will have to guess their numbers by experimenting). AGS engine prioritizes files from the disk to ones inside the game (this is how "unofficial" translations were made to AGS games all these years).

But there's more than that. In the past AGS did not support Unicode, so to make it work with language like Arabic you have to use the new 3.6.0 engine from here:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=59842.0

Your TRS files must have a new "Encoding" option in them set as "//#Encoding=UTF-8" at the beginning of TRS file, and saved as UTF-8 without BOM.
More information on TRS options may be found in the AGS manual:
https://adventuregamestudio.github.io/ags-manual/Translations.html#additional-options

TRS should also be compiled with a new tra compiler which understands this option.
We don't distribute this tool here yet, but you may get one here:
https://www.dropbox.com/s/42widlilgfa2aoq/trac%20--%20ags%20translation%20compiler.zip?dl=0

The tool has to be run from command line as: trac.exe <input.trs> <output.tra>

[@Dualnames]

@Dualnames, also, to double check, since I cannot remember if you mentioned if the game is set to unicode mode:
- General Settings -> Text format -> should be Unicode
WARNING: if it's not, make sure to make a backup of your game, because switching to unicode will reencode and resave most game files.

if you're using translations, they all also need to have a utf-8 Encoding option in TRS, because translations switch the engine between ascii and utf-8 modes for backwards compatibility.
(actually, I wonder if i should disable this if game is already utf-8, as it's difficult to imagine why you would use ascii translation in a unicode game, other than by mistake)

More detailed info here:
https://adventuregamestudio.github.io/ags-manual/UpgradeTo36.html#unicode-support

Meanwhile on the "on_text_input(int ch)" front, it seems to work, but it's not capturing all keys. Specifically, for example greek alphabet/happens partially on korean too.

Code: AGS

function on_text_input(int ch)
{
player.SayBackground(String.Format("%d",ch));
}

Shows nothing on the majority of the key presses. For instance typing "αβγο" which would be A->B->G->O doesn't show any number on that say command.

I would have to make a test game and investigate this.
Could you tell which keyboard layout do you use on your system?

[If you are scripting a custom textbox (using a label or drawing surface)]

This callback never gets executed, unless it needs to be in globalscript. I assume me pressing any key on a textbox would trigger this.

No, it does not trigger by the textbox, as textbox steals the key presses. As I mentioned, you should be using that If you are scripting a custom textbox (using a label or drawing surface) (not using default one).

Do textboxes support unicode? Meaning can I write something in a textbox, and provided the font exists, have it displayed properly? What i mean specifically, is let's say i have a font on a textbox that displays greek characters, can i write in greek in the game on said textbox or no?

It should, if I remember correctly.

If you are scripting a custom textbox (using a label or drawing surface), then you should utilize the new "on_text_input" callback, as "on_key_press" cannot handle full unicode range:
https://github.com/adventuregamestudio/ags-manual/wiki/Globalfunctions_Event#on_text_input

Bump.

Have anything tried running latest 3.6.0 on linux in fullscreen mode? Trying this on a linux virtual machine results in a completely black window with no video or audio or reaction to input, regardless of the chosen renderer; so I am wondering if that's vm or engine's problem.

It's a well known problem that when you change text in script, the translation system thinks it is a different text and adds it separately to the TRS file. In fact, if you change even a single letter it will be considered a different line from now on. That's why people often suggest to not create translations until your default text in script is all ready.
This can only be fixed by changing how translation system works in AGS, sometime in the future.

So yes, you will need to use new lines with & signs now; and may delete all lines without & signs as they will no longer be useful for anything.

Alternatively, you could backup your trs, delete everything from the one in the project folder, tell to update, then you will have a clean trs to where you may then paste translations from backup correspondingly.

@Dualnames, have they tried different audio drivers?

The selection is now available in winsetup, on advanced tab.

Meanwhile regarding the audio:

Here's an mp4 recording that showcases the problem.
https://drive.google.com/file/d/18aGJbJisQdNvLuBzX6ujDfzNGzj7vPnE/view?usp=sharing

EDIT: Ah, sorry, nevermind again.
The problem is in sound cracking, correct? The sounds overall are not distorted or anything (it seems).

AGS runs game and graphics in the same sequence, so either it would need to render separately (in different threads), or separate this just for the mouse somehow, perhaps using the OS mouse if it's available - but keeping the existing approach if it's not, or doing this by a setting, I don't believe every platform will allow to override system cursor graphics, like mobile probably won't.

There's SDL_Cursor, so perhaps we could use SDL_CreateColorCursor, but not sure what that will entail, because then the lifetime of the cursor sprite is disconnected from the game graphics.

EDIT: scrapped previous post.

Do i understand correctly that this is about "hardware cursors", which do not depend on game's own rendering?

audio driver in my windows 10 machine, when I leave to default, is WASAPI, not sure if it's the same in the person of the case Dualnames mentions

By the way, it's logged, so you may ask a player to run with logging and check the info.
Log is set in config as

[log]
file=info

and the log file may be found in %USERPROFILE%/Saved Games/Adventure Game Studio

[@Baguettator]

@Baguettator, the bug was introduced in AGS 3.5.1 Patch 3.
I think in order to be noticed, there have to be separate GUIs with text on screen. If you have only 1 gui displayed with a button which changes translation, then the whole gui gets redrawn as soon as the button is pressed, so text is redrawn with the new translation as well. But if you have multiple guis, then you will see that only one with a "change translation" button is changed, until you do something with others.

Here's a fixed temp build for 3.6.0:
https://cirrus-ci.com/task/5957467392704512

The 24bit 44khz in the OS settings works. OS is Windows 10, audio driver is default.

Could you clarify what setting that is, just to be sure, because I don't remember ever using such setting, neither thought that an os setting could conflict with the program.
I found one on Windows 7 in sound devices, according to it I have 48khz set apparently. Changing to 44khz on my Windows 7 does not seem to make any difference.
I may try on Windows 10 virtual machine later (although idk how close it is to emulate this behavior).

Is there a reason why changing one's OS settings from 24bit 48khz to 24bit 44khz would make an audio thing play properly (audio-crackling)?
I even tried rendering the file to 48 [it's originally at 44khz, and an ogg], but the issue i think lies outside the specific gamefile.

The same file plays fine outside of the engine. Is the default sample rate in-game set to 44?

For the reference, according to the library code, the default openal's context is 48 khz.
But indeed we need more information on what os, what settings do you change, which audio driver do you use, and so on.
Also, I did not quite catch which frequency worked and which did not from your explanation.

Before I was with 3.5.1 (not the last patch), and it worked perfectly for me. It's only since 3.6.0.25.

I just tested changing translation in the latest 3.5.1, and this bug is also present.

I missed this problem, it exists even in 3.5.1, which is very unfortunate. So it has to be fixed there too, and a new patch must be released.

Also, I have a problem trying something...?

Please, don't just say "I have a problem", tell what the problem is, what is happening.

Your code itself looks fine.
First of all double check that the functions are connected to room events and actually run.

I tried to change the game translation, and it seems that the texts don't update when the function Game.ChangeTranslation is called. For example, I change my game from french to english, nothing happenned (texts still in french), but when the mouse went on a button, suddenly its text changed to the english one. Labels were not translated and the mouse didn't do anything on them. Surely because their image doesn't update when mouse is on them (and buttons do update).

Is it a problem with the Beta 3.6.0.25 ?

This sounds like a problem with control texture update; i thought that this was fixed long ago, but will look again.

They are already both unclickable.

Note that if gGuiLine is also unclickable, then " if (GUI.GetAtScreenXY(mouse.x, mouse.y) != gGuiLine)" won't work, as GUI.GetAtScreenXY only looks for clickable guis.