Messages

Looking at how character move with debug mode enabled to show walkable area, apparently it seems that check is performed on single pixel on foot of the character versus edges of nonwalkable area. In other words, the "nonwalkable hole" around character's feet can overlap the nonwalkable area, as long as the single pixel at (playerwidth/2 , playerheight) is out of the area.

Can this be considered a bug?

No, this is not a bug, this is an intended behavior of AGS. I tried to explain above, that this "hole" is used only to prevent other characters from walking too close to the "solid" character.

Yes, like you say, when calculating a path, the check is only performed against a single pixel on foot of a character, and not the area around it.
IIRC, this particular character's "hole" is edited out while calculating the path, so it does not block itself.

[SOLUTION 1. Keeping track of what music you are playing]

There are two approaches to this.

SOLUTION 1. Keeping track of what music you are playing

If you have only 1 channel reserved for the music (this may be checked in the Editor: Audio -> Types -> Music -> MaxChannels).
Make a global variable of AudioChannel* type, and save returned value from Play() function. Next time you need to play a music, test this variable and see if same music is played on that channel.
Name that variable "MusicChannel", for example.
The global variable may be created in "Global Variables" panel, or by hand in script if you know how to do that.

Every time you play a music, any music, you must remember to assign Play's return value into that variable:

Code: ags

MusicChannel = aSomeMusic.Play();

And for each case where you want to prevent same music restart, use this code:

Code: ags

function room_AfterFadeIn()
{
    // This means that you will start music IF:
    // * the channel variable was not initialized yet (this means no music played before), OR
    // * the currently playing clip is NOT this music
    if ((MusicChannel == null) || (MusicChannel.PlayingClip != aMusic1))
    {
        MusicChannel = aMusic1.Play();
    }
}

SOLUTION 2. Test each channel to see if your music is playing

All audio channels can be accessed using System.AudioChannels[] array, and their total number is in System.AudioChannelCount. This means that you may iterate through all of them and find out what is playing on them at any given time.

For convenience, make a custom function in GlobalScript:

Code: ags

bool IsAudioClipPlaying(AudioClip* clip)
{
    for (int i = 0; i < System.AudioChannelCount; i++)
    {
        if (System.AudioChannels[i].PlayingClip == clip)
        {
            return true; // found it
        }
    }
    return false; // nowhere
}

Declare this function in GlobalScript's header, this will let you use it in any room:

Code: ags

import bool IsAudioClipPlaying(AudioClip* clip);

And now you can do this in your rooms:

Code: ags

function room_AfterFadeIn()
{
     // '!' sign means logical NOT, so this means "if NOT playing"
    if (!IsAudioClipPlaying(aMusic1))
    {
        aMusic1.Play();
    }
}

[assume a side-view game]

I can't find any example or explanation about sprites collisions management, any suggestion? I see I can monitor collision of objects and characters, but nothing specific about sprites (more specifically: dynamic sprites).

The collisions in AGS may be misleading if not confusing at first; primarily because they were meant to emulate some old adventure games and also assume a side-view game.

1. Characters and Objects have Solid property. If this property is set, they actually paint "holes" inside walkable area mask, and update these "holes" as they move. These are rectangular holes positioned around their "feet", and this is what you may see on a walkable debug overlay. These extra holes prevent other character from walking over, so it looks like a collision test. The sizes of these "holes" are determined by BlockingWidth and BlockingHeight properties.
Painting over a walkable mask yourself (as you already do) would give precisely same result.

2. The "IsColliding" functions. Their behavior depends on the kind of object.

Character.IsCollidingWithChar, Character.IsCollidingWithObject functions are special, because they are testing against some rectangular areas at their feet; but I cannot remember if it's exactly the same area as BlockingWidth/Height or some arbitrary one; knowing AGS it could even be some hardcoded factors.

Object.IsCollidingWithObject tests full bounding rectangles of two object sprites.

AreThingsOverlapping also tests full bounding rectangles of two sprites (characters or objects).

But only one is documented both in offline and online help, "AreThingsOverlapping". Maybe the others have been deprecated in 3.6.0? I see that there are Character.IsCollidingWithChar , Character.IsCollidingWithObject, Object.IsCollidingWithObject  , maybe they replace the missing global functions?

There's a table of deprecated functions and their suggested replacements:
https://adventuregamestudio.github.io/ags-manual/ObsoleteScriptAPI.html

I remember now that I had the same problem a while ago, but probably forgot about it.

EDIT: right, this also happens with "Lock screen orientation" setting. It keeps resetting to default "Portrait".

I opened a bug ticket in regards to this problem.

I'm running the latest version of the APK (3.6.0.39) on my Samsung Tab A (2019). Every game runs without problems, but there seems to be an issue with the touch-to-mouse emulation. The only option that allows the imitation of a right click (by taping with both fingers on the screen) is the "Two Fingers (tap to click)" option. The "One Finger" option doesn't seem to allow for a right click. Now whenever I restart the AGS app I have to configure it again even though "Two Fingers" is selected in the preferences: In order for it to work again I have to first select one of the other options (either "One Finger" or "off") and then immediately re-select "Two Finger". Then I can start the game and use right click. If I don't reconfigure it this way everytime I start the AGS app, I'm unable to use right click.

Hmm, so, this sounds like preferences (or certain option) are not applied after you start again?

I think I got it (maybe? ). I conflated a channel being null with a channel not playing anything. But my channel was probably null because I hadn't played anything on it yet, so it hadn't been assigned one of the 16 permanent game channels. Would that make sense?

Indeed, if you have not assigned anything to a pointer, it would be null. Every pointer starts as null.

Like Khris mentioned above, if you have a "chained" structure like Channel.PlayingClip.ID, then you have to test for every nested pointer there that theoretically may be null: Channel != null, then Channel.PlayingClip != null, and so on.

Ah, good question, I don't remember if the PlayingClip property is set in the same frame or only in the next one.

I don't think this is what Honza was asking about.
But to give an answer, PlayingClip should have a valid return value immediately after Play() is called.

In other words, the non walkable area surrounding player's feet, currently used to avoid collisions with other characters, should be used also to avoid collisions with nonwalkable areas.

Cannot you make the non-walkable areas wider, giving them the extra "outline", so that the character walks at certain distance from the forbidden tiles?

If this is about having many items to check in a single "if", like in Khris's example:

Code: ags

if (player.HasInventory(iRope) && player.HasInventory(iHook) && player.HasInventory(iInsurancePolicy)) {

Then what you may use instead is a list of required items, which you would iterate in a loop and test whether each of these items exist. Such list could be created in various ways, even as a comma-separated list in String, for example. The only issue would be to convert a textual name into inventory item's pointer or ID.

Simply hypothetically, it could look like this:

Code: ags

if (TestAllItems("iRope, iHook, iInsurancePolicy")) {
}

where TestAllItems would parse the string and check for all the items there.

But I am currently speculating, as I do not see your real code, so I don't know which kinds of cases you are trying to work on.

It was only to check if the player had certain items then the other character would respond without having to type long lines with "if" and "else" statements.

I guess I could run a loop check to check all items in the game and use their ID in a switch statement that way but wasn't sure if it was exactly possible to do so?

I honestly do not see how having a switch inside a loop over all items would help you to achieve what you want in the above case (simplier code).

What exactly do you want to make simpler? Do you have a response per item, or a response per a combination of items?

I do not understand full situation here, but may mention this article about order of game events and script callbacks:
https://adventuregamestudio.github.io/ags-manual/GameEventsOrder.html

Perhaps it will help to know when to do, after you find out what to do.

My character apparently has .z and .Baseline values constantly = 0 while it moves around the room (I put their values into a label in global script, together with x and y). Should I enable anything to get them updated?

Additionally, "z" looks more like a "real world" value rather than an "engine value", as if I manually increment .z, the character raises, but if I increment .Baseline, character does not move, but it gets drawn behind some objects with different baslines...

When Baseline reports 0 that means that Character's Y is used instead. If you set Baseline to something besides 0 that would use that fixed value regardless of character's location.
https://adventuregamestudio.github.io/ags-manual/Character.html#characterbaseline

Character's "z" is a special graphical offset by Y axis, which does not affect sorting at all. It's mostly a historical feature, used to simulate "levitating" while keeping same y position in the room.
https://adventuregamestudio.github.io/ags-manual/Character.html#characterz

So, room background is always behind everything, so whatever you draw there will always be behind.

Characters, room objects and walk-behinds have Baseline property, that determines their sorting on screen. By default character's and object's baseline is automatically bound to their Y position. Setting Baseline to any custom value will override it, and let you sort these objects differently.

Since AGS 3.6.0 Overlays use ZOrder property, but that's essentially the same (it was called to match the GUI's property of same name). If you create overlays on the room layer, their ZOrder will sort among other room elements' baselines.

EDIT: Oh, right, Overlays have their ZOrder set to some very low negative value by default, this is for backwards compatibility with older versions of AGS, where they were always drawn behind GUIs. Possibly this was a design mistake to keep exact behavior for room overlays, but it is like that right now.

EDIT2: So, if you like to have Overlays sorted by the same rule as Characters and Room Objects, you need to set their ZOrder to their bottom Y position.

The documentation for Overlay.CreateGraphical also sais this:

if the Overlay variable goes out of scope, the overlay will be removed. Hence, if you want the overlay to last on-screen outside of the script function where it was created, the Overlay* variable declaration needs to be at the top of the script and outside any script functions.

If you want overlay to remain after the function is finished, you need a global variable (declared outside of the function).
The creation of overlay remains inside a function (as AGS script does not support calling functions in the global scope).

For example:

Code: ags

Overlay *myOverlay;

function Room_AfterFadeIn()
{
    myOverlay = Overlay.CreateGraphical(100, 100, 300);
}

@vga256,

The documentation appears to be wrong where it sais that "Ghost GUI" works with everything.

The reason why "Ghost GUI" does not work for GUI & controls is quite simple. With "Ghost" GUI/Overlay the module must draw the dragged object on that GUI/Overlay. With characters and objects this is straightforward: you draw their current sprite (or animation frame). But with GUI it's not easy: there's no way to ask AGS to draw a GUI or control on a drawing surface or a dynamic sprite, so I would have to reimplement virtually whole GUI drawing in script! Naturally, I decided to not do that.

One may speculate that this could be worked around using a screenshot feature, but this approach will be additionally complicated by other screen elements which would have to be hidden (and that's not reliably possible to script in the module, I think).

Another workaround would be to only support controls which are drawn using sprites:
* Empty GUIs with background image and nothing else;
* Buttons which have a graphic assigned to them.

With the current module though, you would have to resort to scripting a custom drag-drop mode. The easiest method may be to replicate "Ghost GUI" or "Ghost Overlay", but let it set any image instead of knowing what AGS object you're dragging. You may follow examples in documentation, or use either demo game or DragDropCommon module as an example.

[Editor:]

Updated to RC4 (3.6.0.39)
(use download links in the first post)

Editor:
- Fixed project tree items not updated when changing item ID.

Engine:
- Various performance optimizations for both raw drawing and texture updates (Direct3D/OpenGL). (This will be mostly noticeable in high-resolution games.)
- Fixed software renderer may have an unpainted black line at the bottom, if there's a GUI or Overlay positioned partially offscreen.
- Fixed Parser.Said() could lead to a program crash in case there are space-separated words following the comma (e.g. "climb,get in bed").


Reported issues remaining:
* GUI controls incorrectly blend (mix colors) with the parent GUI if parent's transparency is anything but 0. Unfortunately this takes longer than expected to fix, because some of the new feature should be rewritten. This is related to the rendering performance optimization, which proved to be too significant to drop.
* Direct3D is said to still be not fully stable when alt+tabbing in exclusive fullscreen mode: https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-3-6-0-release-candidate-rc1/msg636650995/#msg636650995
* Linux port cannot load a AGSSteam plugin. There's a workaround mentioned right above this post.

Did you perhaps mean to use Character.ActiveInventory? In that case, you could do something like:

AFAIK in AGS you can also use Character.ActiveInventory directly in a switch, and compare to item script names:

Code: ags

switch(player.ActiveInventory)
{
case iKey:
case iBlueCup:
}

@Stranga, please clarify, what are you trying to achieve with this, what this code is for? The answer will depend on that.

[EDIT]

There's a sudden problem found, that 3.6.0 seem to not able to load a Steam plugin correctly on Linux.
According to the log output, it finds and tries to load `libagsteam.so`, but then fails to load a `libsteam-api.so`, which is a dependency of `libagsteam.so`. The reported error is "No such file or directory", although the file is right there in the same dir.

Other plugins load fine, which makes me think this problem manifests when the plugin itself requires a second library.

I've been testing older builds of 3.6.0, but none work so far, including versions which are year and more old.

Have anyone else tried using 3.6.0 on linux with the steam plugin yet?


EDIT

So, this looks like not an engine's own problem, but the engine's build / setup issue. I still do not know what exactly did change in 3.6.0, but now it may require a different launch script on linux to make it work with the steam plugin. Namely add "LD_LIBRARY_PATH" option.

Something like:

Code: sh

if [ "$(uname -m)" = "x86_64" ]; then
    LD_LIBRARY_PATH="$scriptdir/data/lib64" "$scriptdir/data/ags64" "$@" "$scriptdir/data/"
else
    LD_LIBRARY_PATH="$scriptdir/data/lib32" "$scriptdir/data/ags32" "$@" "$scriptdir/data/"
fi

Alternatively:

Code: sh

if [ "$(uname -m)" = "x86_64" ]; then
    export LD_LIBRARY_PATH="$scriptdir/data/lib64":$LD_LIBRARY_PATH
    "$scriptdir/data/ags64" "$@" "$scriptdir/data/"
else
    export LD_LIBRARY_PATH="$scriptdir/data/lib32":$LD_LIBRARY_PATH
    "$scriptdir/data/ags32" "$@" "$scriptdir/data/"
fi

We'd need to adjust the Editor to generate a launch script with this addition.

Thanks a lot Crimson, you guys are so helpful and kind. I already had AGS 3.6 beta, opened the game with it and problem is solved. But is it safe to use AGS 3.6 beta? I'm asking because it seems it's not officially released.

More or less, and some people are already making games with it. But there are couple of known bugs, which we are trying to resolve at the moment. There's a chance that you won't notice them, depends on what do you have in your game.

These known problems are mentioned in the end of this post:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=60323.0