Messages

Is it normal that the tables do not have any borders on the new forum?

Example:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/attn-plugin-authors-gathering-plugin-sources/msg636479467/#msg636479467

I think what could work is another, thicker, object with Transparency set to 100.

According to AGS logic, Transparency does not affect interactivity, so even fully transparent objects will be clickable.

I'm running it on AGS 3.5.0 and everything seems to work fine, except the dialogues are broken.

Hello. The dialog API had changed since AGS 3.4.0 (which probably was after this template release), you need to either update the script to the new rules, or enable Backwards compatible mode called "Use old-style custom dialog options API".

More information may be found in the manual:
https://adventuregamestudio.github.io/ags-manual/CustomDialogOptions.html
check out where it sais "COMPATIBILITY NOTE"

@Snarky, I did more actual tests and you are correct. When I copy a "proper" unicode RTL text into the editor, it's saved LTR, in other words, first "syntactical" character appears in Char[0], and rest follow. In other words, it only looks RTL when drawn in the application, but the data is LTR.

I did the test by simply printing Char[0] on a separate label.

What this means is, that if you print a "proper unicode" RTL text, then everything just works, so long as you set "Right-to-left" mode in the settings.

There's still a letter-linking problem, but that's an issue on its own.


The letter linking may be solved by a program called "Parsi Negar" that comes with its own fonts, suited for this particular purpose.
https://leomoon.com/downloads/desktop-apps/leomoon-parsinegar/
This is pointed out by @Mehrdad.

This program somehow converts the text. I am not 100% certain, but I think that it merges the linking letters into a single glyph with special number, and in combination with the special fonts it allows the Persian (and maybe Arabic?) text to be drawn visually correctly in AGS.

The problem with ParsiNegar is that by default it actually stores the text RTL, meaning its already reversed. This does not work with AGS linewrapping, neither LTR not RTL one.

I found that it's possible to workaround by disabling the "reverse" option in this program. If you do, then it seemingly works well in combination with AGS's RTL mode.
The nuance is that the text possibly looks "weird" in the script & translation file. I suspect that it will probably be hard to read by the native language speakers (as it looks literally reversed).

I am currently in the process of checking this out with Mehrdad on Discord. If he thinks that the workaround I found is not convenient for him, then the only option for us would be to introduce a 3rd selection to the "text direction" option, that would assume the text is only reverted in data.

[WARNING:]

Updated again. There's a working solution. Can't tell if most optimal one, but it formally works.
Technical details are here: https://github.com/adventuregamestudio/ags/pull/1923#issuecomment-1502145700

May be downloaded and tested with this build (UPDATED 17th april):
https://cirrus-ci.com/task/4872943738552320

WARNING:
* Changes compiled game format and save format;
* Based on AGS 4 experimental version, which means that it will irreversibly update your game project too if you are coming from AGS 3.*. Better test on a project's copy.
* If you are already a AGS 4 user, this does NOT change the AGS 4 project format further, so it's safe to test on your real projects, except you'll have to fully rebuild if changing to a previous AGS 4; also the new engine will produce incompatible saves.

EDIT: scrap this, I need to check something out when I have more spare time.

So, the important question is, how the characters of these strings are positioned in char array.

[paragraphs]

I was discussing this late at night on Discord, so may have had strange ideas. I will try to explain my confusion with the images.

If you type Arabic text, using google translation for example, this is how the text appears:


In English this sais "I love beaches. The water is warm."
Notice there are 2 sentences. Not only the words & letters inside a sentence are revertse R->L, but also sentences themselves are reverse R->L.

Now, if I put this full text into the AGS script as-is, it will look like this:


Is this how it's supposed to be in script and translation file?

OR, should we require the sentence in the L->R order, and only text R->L? Like:



Now, let's assume that there are paragraphs in this string.

In English this sais: "I love beaches. The water is warm. \n The sun is high. \n"

How do we treat these sections separated by \n? In R->L or L->R order?




In regards to the line-splitting and text wrapping. If everything is treated R->L (sentences are R->L and paragraphs are R->L), then we basically just need to have a reverse splitting algorithm, that is: run the string from back to front and split like that.
That's the easiest solution.


After this there will still be a logical problem of string concatenation, e.g.:

Code: ags

String s ="احب الشواطئ."; // I love beaches.
s = s.Append("الماء الحار."); // The water is warm.
s = s.Append("الشمس عالية."); // The sun is high.

This will be displayed in a wrong order on screen.
But I guess we cannot do anything about it, unless we introduce a R->L aware "String.Concatenate" function?

[last]

This question is partially about syntax and partially about a technical issue in AGS.

There is a number of languages that are written right-to-left (Arabic, Persian, Hebrew, few others).

AGS has a built-in "Right to left" text mode, but it looks like it was meant strictly for ASCII method, and is not fully usable with Unicode texts. The thing is that unicode texts may already be written right-to-left (they may contain control characters for this, if I understand correctly).

The problem with AGS though is that the way it wraps the text assumes the text was originally written left-to-right (in script or translation files). In the Right-to-left mode the engine will wrap the text same way as for left-to-right, but then reverse each line separately.

This does not work at all with "proper" R-to-L Unicode texts. As they already are reversed, the line splitting may result in beginning of the sentence appearing on the last line.

My first thought was that a fix should simply be to revert the order of the split lines instead.
Or, more correctly: do the line splitting by scanning the text in reverse.

But then I started considering things like multiple sentences in the same string, or even multiple paragraphs in the same string, and got very confused.

My question is: supposing you have 2 sentences in, say, Arabic or Persian. How are those 2 sentences are written normally? Is their order also reversed? If yes, then the above fix will work... if not, then it won't work, because you will need to have first sentence arranged first (which may take multiple lines), then the second, and so on.

And then there's a case when you have a number of paragraphs in one string. Obviously, the order of paragraphs must not be reversed. But if a single sentence inside a paragraph is wrapped, then wrapping of that particular sentence will have to be reversed...
In other words, there may be groups of lines wrapped in reverse order, but groups themselves have to be arranged in original order...

So, thinking about this, I was coming to an idea that there's no trivial generic solution here.

Or rather, the only "trivial" generic solution is to write R-to-L languages completely left-to-right in the source texts, and let the engine revert them after splitting in lines.

Without this, the engine would have to parse the text's syntax using punctuation, finding where the sentences are (separated with fullstops), and where the paragraphs are (separated with manual linebreaks).
Well, this is not impossible, but at the same time things like that was not done in the AGS engine before.

Does anybody have ideas on this?

[without changing it]

Oh, if you meant the player issue, it's in a different room's AfterFadeIn function.

Code: ags

function room_AfterFadeIn()
{
  player.Move(40, 185, eBlock, eWalkableAreas);
}

But Move does not run walking animation, only Walk does (unless view is locked using LockView and similar).


In regards to ChangeView, it does not unlock the view from the previous LockView, but apparently may halt current Animation, if one was running.

Code: ags

cRich.ChangeView(21);
cRich.UnlockView();

I suggest changing the order of these commands, to avoid any weirdiness. Also, if 21 is already cRich's normal view, then ChangeView call is not necessary.
Overall, character Animation should be "guarded" by LockView and UnlockView calls. LockView overrides normal view without changing it, and UnlockView releases the locked view, returning the character to its normal view.

Code: ags

cChar.LockView(N);
cChar.Animate(...);
cChar.UnlockView();
// here it will return to its normal walking view automatically

Hmm, another thing that may cause this (i think) is if character was locked for animation, but then not unlocked back (LockView, UnlockView).

Are you certain that you are using Walk and not Move function?

An update: fingers crossed, the saves problem seem to be fixed to some "minimal necessary" degree.
(details are in comments to the ticket https://github.com/adventuregamestudio/ags/pull/1922)

The latest code I wrote there is quite ugly, so I will take couple more days cleaning it up, and testing.

There are still certain things that you may do to managed structs that will break older saves. There may be potential solutions, but not all of these are worth considering at the moment (too much work, and likely not much use on its own).

For example, the biggest break is if you change the order of member variables inside a struct, and pointers will appear at different offsets. This breaks the structs in saves even without pointers, actually.

From a non-artist perspective, the ai-generated art seems like a good source of both placeholder and concept art for ideas. It looks like a randomizer that gathers everything found on the internet and gives you a random and semi-unique mashup. Sort of a kaleidoscope art.

[PS.]

If you're beginner in AGS, I also suggest using "Global Variables" panel in the project tree. It makes creating global vars easier, with the exception of custom types (it can only work with built-in types for the moment).

PS.
Regarding ChatGPT, from what I understand it learns from stuff found on the internet, and then generates the answer by merging common things together. I've seen examples of people asking it to write AGS script, and most times it writes a believable, but not accurate code. It often uses non-existing commands too, probably inventing them based on something found elsewhere. In other words, at this point it reminds a child who tries to imitate what adults do.

A temp build with a fix for above problem:
https://cirrus-ci.com/task/5255564800819200

I suppose I will delay for a week or two before releasing first patch to 3.6.0, in case something else is found.

EDIT: currently planning on early May. There were few fixes made, but nothing too critical so far.

[EDIT:]

Unfortunately, a problem is found in this version already, that was somehow missed earlier.

In short: if you had an object with a DynamicSprite assigned to it, and delete a DynamicSprite in "room leave" event, then the object will be invisible during transition (like fade out). EDIT: this is happening only to Room Objects (not even Characters, for some reason...).

It probably does not matter if your room transition is Instant, or you are scripting fade out yourself.

The problem here is that "room leave" event is called BEFORE the transition (fade out). This is something I did not pay attention to somehow... But apparently, for all those many years, AGS lacked a proper event like "room unload" (to match "room load"), called after the room is faded out and no longer drawn.

Why did it "work" in previous versions: in short - because of some coincidences (it happens alot in AGS).

In full length, with technical explanations: https://github.com/adventuregamestudio/ags/issues/1970

I found what seems potentially could be a fix to this in the engine, but will have to make few tests to be certain.

EDIT: The existing workaround is to fade out manually using script commands, before deleting the sprites (while optionally having room transition set to Instant).

In that case, if I need two or more walk-behind regions, only one can be an imported bmp, and the rest must be regions drawn with the AGS drawing tools, right?

You draw all of the walk-behinds on the same bitmap, using different colors.

@AGA thank you,
I noticed one problem: the button remains even though I removed the "in-development version" data (because there's no Beta version currently).

[Engine]

Full version released: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0/

FYI there was one extra fix compared to the latest RC11:

Engine
 - Fixed FadeIn/Out and ShakeScreen prevent audio from starting if you started it right prior to them (it was starting afterwards).