Messages

I'm glad to hear you're figuring out the ins and outs of it. If I understand what you're saying correctly, I believe there is still one part of your thinking that isn't quite right (at least, it confuses me), and it might be good to clear it up right away:

it only looks RTL when drawn in the application, but the data is LTR.

I think by this you mean that the string is stored with its beginning (i.e. the letter you're supposed to start reading at) at Char[0]. Great, that sounds like how it's meant to be. But it's wrong to say that this means "the data is LTR": the memory doesn't have any particular direction. We are used to arranging consecutive characters from left to right, but that's just habit, not anything inherent in the string or data (or properly designed Unicode string rendering libraries).

If I understand the Unicode documentation correctly, there is normally no explicit information stored in the string about whether it should be displayed LTR or RTL. Instead, each character (code point) is associated with a directionality flag, depending on the convention of the script it belongs to: letters in the Latin, Greek, Cyrillic, etc. alphabets are LTR, while letters in Arabic and Hebrew scripts are RTL. Punctuation characters are typically neutral (can go either way), and take their directionality from the surrounding characters. There are override codes that can force a particular directionality, which can be used for example to clarify if punctuation between a LTR and a RTL text chunk belongs to the preceding or following chunk (if it's the end of the LTR chunk, it should be placed at the right end of that; if it's the start of the RTL chunk, it should be placed at the right end of that).

tl;dr: LTR/RTL is not a property of the way strings are stored in memory, and it gets confusing if we talk as if LTR is the true and natural way memory is ordered. For accuracy and clarity, the question is whether the strings are reversed, so that Char[0] represents the end (as it would be read in that script).

The correct order in the array is always the reading order.

Before you deleted it, @Crimson Wizard, you asked what this was based on and if I had tested it in AGS. I have not tested in AGS because I'm talking generally about how it is meant to work (specifically in Unicode), whether or not that it how it is currently implemented in AGS.

The Unicode document I linked to states it explicitly or implicitly in a few places (e.g. "No matter how the layout is resolved the order of characters in memory essentially follows the order they are typed."), but I also think it's kind of true more or less by definition: A text string starts at the beginning and ends at the end, so that the first symbol (apart from any metadata like control characters) is the one at index 0. The layout of the string for display is a secondary consideration or formatting convention that is not strictly part of the string itself, comparable to things like font face and line-wrapping. (And like for line-wrapping, it is sometimes necessary or desirable to embed hints/overrides within the string representation to get the correct/preferred appearance, e.g. non-breaking spaces, optional hyphens, explicit line breaks.)

Now, that said, for all I know it is possible that some tools we want to support (perhaps indeed the Scintilla editor) do provide "RTL" text by just reversing the string and treating that as a LTR string. If so, I think some (compile-time?) process to convert it back to the correct representation is required, if we want to do it right.

BTW, does TextBox support RTL input?

OK, so I've done a minimal amount if research to check my intuitions, and it does look like I was right.

The correct order in the array is always the reading order. String.Char[0] is the start of the text, and whether that first symbol is displayed on the left or right end of the string depends on the script. If the text is totally RTL, this is no more complex than in LTR: you can use the same layout logic only mirrored. It does get more complex if you have a mix of text chunks going in different directions (bidirectional text), such as if RTL strings are embedded in LTR code. Unicode has an algorithm for determining the layout in those cases: http://unicode.org/faq/bidi.html

If we hack RTL by just reversing the strings so that .Chars[0] is the end of the text, that is going to break ligatures etc., as @Mehrdad reports.

These sounds like problems with the way AGS and the AGS editor treats RTL strings. To me it seems like the correct behavior is quite clear in each case:

1. A RTL string has its beginning on the right and its end on the left, so obviously the first sentence goes first (that is, on the right).

2. And it is processed from beginning (right) to end (left), just like a LTR string is (from beginning to end, so in that case left to right). OK, so there is a question of how the '/n' separator is parsed, but the way you have written it here, I would guess that there must be an invisible control code that switches from RTL to LTR for that bit, so that it's read:

[5:LTR "/n"],[4:RTL "The sun is high."],[3:LTR "/n"],[2:RTL "The water is warm."],[1:RTL "I love beaches."]

If there is no such control character, and it's all part of the RTL string, I would guess you'd type '/' and then 'n' as normal, but your cursor would be moving "backwards" so that it would appear onscreen as "n/".

3. Here I think you're making the incorrect assumption that a RTL string still begins on the left and ends on the right, and that its internal representation has simply been reversed, so that something concatenated to it is added to its right side. I believe if the strings have been correctly set to RTL, concatenating them will make the added part show up on the left. Similarly, if you took s.Chars[0] in your first example it should return the rightmost character (the one that looks like a bar, '|').

Now, it could very well be that the AGS editor doesn't properly support RTL strings in string literals, so that this bears little resemblance to how it actually works in AGS, but intuitively this is how I think it should treat them. Though it's probably worth verifying that with someone who actually uses a RTL script and is familiar with how it is embedded and edited in otherwise LTR text.

I think you've confused yourself there. I am 99% sure that in RTL scripts, everything works about the same as in LTR scripts, except mirrored.

No, that is not valid AGS code. Both the logic, syntax and names of functions it calls are wrong. Neither Bard nor ChatGPT have had enough training to generate usable AGS code.

For your case, you can use either a GUI (with the background or a button set to the close-up sprite) or a graphical Overlay. Another option, if the close-up fills the whole screen, is to do each close-up as its own room—that way you can (more easily) allow the player to examine and interact with parts of the close-up.

Just try it out!

But the whole point of sharing my file was so you wouldn't need to build it yourself with XCode.

You should just need to copy the AGS Windows files into the app bundle I linked, and probably fix the permissions.

BTW, you can get an Apple developer account here.

Given the perspective of the ceiling, I'd say we shouldn't be seeing the top of the cabinets at all. If anything, we should be seeing the underside. (Remember, if we see the top of a flat horizontal surface, that implies that our eyes/camera are above it.)

Hallelujah! 

I suppose one alternative could be to implement a fully custom dialog system, but I'd like to avoid that as much as possible.

I might be wrong, but I believe this is your only option, because that is what you are in fact trying to do: a dialog system where you pick inventory items as responses is pretty much the archetypal example of custom dialog options.

On another note, has anyone built a game on which inventory items were also possible dialog options?

Yes, certainly people have. You may want to check out the Custom Dialog GUI Module.

Global Messages have not been supported ever since AGS 3.0, 15 years ago. (The functions to display them are still there, but there is no way to view or edit them.) See this thread: https://www.adventuregamestudio.co.uk/forums/beginners-technical-questions/global-message-solved

A boolean is a value that is true or false.

You shouldn't have bool at the beginning of the line because starting a line with the name of a data type (such as bool, int, String, etc.) means that you want to create a new variable of that type. What you actually want to do is to just set the value of a variable that already exists.

In this case it's giving you an error when it gets to the period in oFridge.Solid because it thinks you're trying to create a variable, and you can't create a variable inside an Object (at least not this way), or use periods in variable names.

So, as you found, you just need to delete bool and it works. This has nothing to do with any AGS updates, it has always worked like this.

Can you not use the file I shared? There is nothing I can do that you shouldn't be able to do yourself.

My grocery store switched from carrying the brand of orange juice I like to another brand that I find undrinkably bitter, and I can't find any other store that sells it. 😭

You don't actually need to write the topic title in all-caps. It looks like you're shouting.

Here is a download of the app bundle I built for my own use:

Ags-v.3.6.0.44 (RC9)

(This was built on MacOS High Sierra 10.13.6, on an Intel Core i5 MacBook.)

To make any AGS game run on Mac, I simply copy this app bundle into the game directory, select all the game files and copy them, right-click on the bundle to "Show package contents," navigate to Contents/Resources/, and paste the game files. (You probably don't need all of them, but it's easier not to think about it.) Then I rename the app bundle to the same name as the game exe (except for the extension), though I'm not sure that's even necessary, and that's it.

However, since you'll be running it on a different computer than I built it on, you'll probably need to follow the instructions to disable the quarantine restrictions for an unsigned app.

Check out the list Crimson Wizard just linked to: https://www.adventuregamestudio.co.uk/forums/adventure-related-talk-chat/a-sticky-list-with-open-source-ags-games/

[Edit:]

In principle yes, @tilapisha, but the problem with 3.6 is that there isn't a pre-compiled shell application available (because 3.6 isn't yet officially released). Edit: Or rather, the problem is that the 3.6 bundle available is older than many games built with 3.6, so they will not work with it. I ended up building it myself from source according to the instructions here. This solution does require you to install XCode, homebrew, and cmake if you don't already have them, which takes several hours and a couple of gigabytes of storage. (And since my Mac is really old and still on MacOS 13.10/High Sierra, I had to delve deep to find an older version of XCode that is compatible.)

I can share my shell app (when I get home, since it's on my private computer); it works fine on my own machine, but I'm not sure how well it would work on other Macs; there might be additional steps required.

I'm also trying to finish up a few games before the deadline. I played all of the nominees during the nomination stage, but there were too many full-length ones to complete them all. So now I still have three full-length games that I need to see through (one I'm a good bit into, the two others only at the start).

It probably isn't the best way to enjoy these games—I'm a fairly impatient player in the first place, and even more so when under time pressure, so I think it makes me more intolerant of games that "waste my time." Naming no names, there was one I gave up on because of the character walking speed.

But on the positive side, it does help the ones I think are particularly good stand out.

Welcome!

The usual solution is to set continuous scaling on the walkable area in that part of the room. If you set a max-scale and a min-scale, the maximum scale will be used at the bottom of the walkable area, the minimum scale at the top, and it will gradually scale in between.

I also recommend that you check out the tutorial in the manual that is included with AGS, and also available online. It explains scaling here, and answers a lot of other questions you'll probably have as a newcomer.

If you want a more advanced effect (like gradually scaling if you move horizontally), you will have to script it.